Blinkenlights

I think we all agree that every computer is better with blinking lights. In an effort to overcome my fear of electronics, I have recently acquired an Arduino and one of my first projects was a CPU load indicator for my computer:



It was of course inspired by the blinkenlights on BeBoxes and the way it works is very simple. I got a 10 segment LED bar graph and two six-pin 330 ohm resistor networks (they're just five resistors in a single package with one leg of each resistor connected to the sixth common pin). I connected the positive legs of the LEDs to ten digital pins on the Arduino and I connected the negative legs to ground through the resistors. Here's what it looked like during testing:



Then I needed a way to tell the Arduino which LEDs to turn on. An obvious choice was to communicate over USB (which will also provide power). Here's the sketch that's running on the Arduino:

const int FIRST_PIN = 3;

void setup() {
  Serial.begin(115200);
  for (int i=0; i<10; i++) {
    pinMode(FIRST_PIN + i, OUTPUT);
  }
}

void loop() {
  if (!Serial.available()) {
    return;
  }
  int cpu_load = Serial.read();
  int n = (cpu_load+5)/10;
  for (int i=0; i<10; i++) {
    digitalWrite(FIRST_PIN + i, i<n ? HIGH : LOW);
  }
}

And here's the Python program that's running on the computer:

import serial
import psutil

ser = serial.Serial('/dev/ttyACM0')
while True:
    cpu_load = psutil.cpu_percent(interval=0.1)
    ser.write(chr(int(cpu_load)))

As you can see it sends a byte with the CPU load value (0-100) ten times per second. I only tested it under Linux, but the psutil module should also work on Windows and OS X. It can also give you per-CPU core percentages, but that would require more LEDs and some other way to drive them when we run out of I/O pins on the Arduino.

USB audio dock for Android

If you want to get audio from your Android device to your speakers in a transparent (not application-specific) way, there have traditionally been two options: Bluetooth and the 3.5 mm jack (I guess MHL and HDMI are also valid options on some devices). Android 4.1 introduced another way: audio over USB. This has one additional benefit: you don't have to plug in an additional cable for the phone to charge. Problem is, I'm not aware of any actual products like audio docks that would make use of this feature. So I decided to make one myself.



I used a simple USB dock and a Raspberry Pi. The Raspberry Pi's audio output is connected to my living room amplifier. Below I describe the steps necessary to make this work.

Obviously you'll need a dock that matches your phone's physical shape (or you can skip the actual dock and just use a USB cable). The Raspberry Pi could be replaced by any computer running Linux. The Pi is a good fit here because of its small size. Then again it is a bad fit because its audio components are low quality (this could be worked around by using HDMI as the audio output or connecting an external sound card via USB, but I haven't tested these options).

The good thing about Android's audio over USB feature is that it uses a standard protocol, so if you connect your phone to a modern Linux box, it just shows up as an audio input. Therefore we only need to do two things here: enable the audio over USB feature after the device is plugged in and route the sound from the input to the output that goes to the speakers. We'll use a simple Python script to send the necessary magic over USB and PulseAudio for the audio routing.

I used a Raspbian "wheezy" image on the Pi, if you're using another distribution (or not using a Raspberry Pi), some adjustments may be necessary.

First, install git and PulseAudio:

sudo apt-get update
sudo apt-get install pulseaudio git

Use git to install a newer version of PyUSB than is available in Debian repositories:

git clone https://github.com/walac/pyusb
cd pyusb
sudo python setup.py install

Next we configure PulseAudio. Edit /etc/defaults/pulseaudio to start the daemon at boot and allow module loading:

PULSEAUDIO_SYSTEM_START=1
DISALLOW_MODULE_LOADING=0

In /etc/pulse/system.pa change the line that says:

load-module module-native-protocol-unix

to:

load-module module-native-protocol-unix auth-anonymous=1

(This will allow us to use the pactl command without worrying about authentication.)

Add the following line to /etc/pulse/daemon.conf:

resample-method = trivial

(I don't know why this is necessary. It wasn't needed on my regular PC, but audio wasn't working without it on the Pi.)

Then create a file named /etc/udev/rules.d/dock.rules and put the following line in it:

ACTION=="add",SUBSYSTEM=="usb",ATTR{idVendor}=="04e8",ATTR{idProduct}=="685c",RUN+="/home/pi/phone_docked.sh %s{idVendor} %s{idProduct}"

This will run /home/pi/phone_docked.sh every time my phone is connected. As you can see, unfortunately the USB vendor and product IDs for my specific phone are hardcoded here (they are then passed to the script as parameters). You'll need to change them to match your phone (you can look up the IDs by running lsusb with the phone connected). I don't know how to write a udev rule that will trigger when any Android phone is connected (instead it's probably more feasible to write a rule that matches Android phones and also some other devices and then just try to talk to it as if it was an Android phone and gracefully handle the situation if it doesn't respond).

The phone_docked.sh script does two things, first it runs the Python script (android-usb-audio.py) that enables audio over USB on the phone (passing along the vendor and product IDs), then it loads a PulseAudio module that routes the audio from the phone to the default output. Here's what the script looks like (put this in /home/pi/phone_docked.sh):

#!/bin/bash

/home/pi/android-usb-audio.py $1 $2
(sleep 3s ; pactl load-module module-loopback source=`pactl list sources short | grep alsa_input.usb | cut -f 1`) &

As you can see, the second part is not very elegant, it just waits 3 seconds where it should wait for the PulseAudio source to actually show up. Also it assumes there are no other USB audio sources.

Finally, here's the Python script that sends the necessary USB magic to the phone. This tells the phone to send audio over USB. The script gets the USB vendor and product IDs from command line parameters (put this in /home/pi/android-usb-audio.py):

#!/usr/bin/env python

import usb.core
import time
import sys

dev = usb.core.find(idVendor=int(sys.argv[1], 16), idProduct=int(sys.argv[2], 16))
mesg = dev.ctrl_transfer(0xc0, 51, 0, 0, 2)
# here we should check if it returned version 2
time.sleep(1)
# requesting audio
dev.ctrl_transfer(0x40, 0x3a, 1, 0, "")
# putting device in accessory mode
dev.ctrl_transfer(0x40, 53, 0, 0, "")

(The magic numbers come from the Android Open Accessory protocol.)

Give the two scripts executable permissions:

chmod 755 /home/pi/android-usb-audio.py
chmod 755 /home/pi/phone_docked.sh

And that's it, reboot, connect your phone and enjoy audio coming from your speakers. (I know what you're thinking: all this work just to avoid plugging in the 3.5 mm jack??)

Since the phone will charge from the Pi's USB port, you should use a power supply that will be enough for the Pi and for the 500 mA that the phone will draw.

I'm not demonstrating it here, but while the phone is connected, you can also send HID commands like play/pause/next/previous to it. This way you could make some physical (or web) controls for the dock and pass them through to the device.

While you're at it, you could plug a Bluetooth USB dongle to the Rasbperry Pi and make your dock also accept audio via Bluetooth. There are tutorials on the web showing how to do that.

Face tracking robot

Android 4.0 introduced an API for face detection. It's really simple to use, you only have to set up a listener and it gets called each time a face is detected in the frame captured by the camera. I used it to make a Lego Mindstorms NXT robot that turns to look at you as you move around. Here's what it looks like:



The way it works is there's an application on the phone that checks if a face is detected. Then it communicates with the robot over Bluetooth and tells it to turn left or right, depending on the position of the face in the frame. Here's the application's source code if you want to take a look. I don't have building plans for the robot itself, but any robot with tank-like steering would work.

A cool way to demo this robot would be to use it for video chats or Google+ hangouts, but I don't think there's a way for two different applications to access the camera at the same time, so the face tracking functionality would have to be integrated into a video chat app. (Or I guess I could put a second phone on the robot.)

Fridge temperature monitoring with Raspberry Pi

Since I've discovered that it's relatively easy to access Raspberry Pi's GPIO pins, I'm constantly looking for stuff to connect to it. Fortunately the Internet is full of them.

One of Raspberry Pi's limitations (compared to, say, an Arduino) is that it doesn't have analog pins, only digital ones. So to connect a sensor with analog output, you have to go through an analog-to-digital converter (ADC). The fine folks at Adafruit have written a tutorial on how to talk to an MCP3008 ADC from a Raspberry Pi to read the state of a potentiometer. I swapped the potentiometer for a TMP36 temperature sensor and now my Raspberry Pi knows what the temperature is.

Here's a nice looking diagram of how the connections go:



And here's a considerably more messy real-life shot:



I monitored the temperature in my room for some time and decided that it was boring. So then I put my new creation in the fridge to see how cold it is in there. Initially I wanted to put just the sensor in and keep the Raspberry Pi outside, but with all the cables going from the Pi to the breadboard, it was easier to just put everything inside with only the power cable going out. The Pi didn't mind the low temperature and I hope the small amount of heat it produces didn't affect the fridge and the measurement. And if you ever wondered whether wifi would work from inside a fridge, I'm happy to report that it works just fine.

Here's what it looked like inside my otherwise mostly empty fridge:



And here are the results:



(I averaged the data a bit, because the readings from the sensor were pretty noisy.)

It turns out that the temperature inside my fridge varies quite a bit, from around 3 °C to around 8 °C. The compressor runs for about 37% of the time (though that number probably depends on outside temperature and possibly the contents of the fridge).

Here's the script I used to read the temperature from the sensor, but it's mostly identical to the one in Adafruit's tutorial. One interesting thing about it is that it uses what's called a "bit banging" SPI implementation (the Raspberry Pi also has hardware SPI and we could use that just as well).

Raspberry Pi controlled lamp

I'm a software guy and I'm scared of electronics. At the same time I find it exciting when software actually does something in the real world. (That's why I love Lego Mindstorms.) Home automation is my lifelong dream. I'd like to be able to use my computer to turn the lights on and off, roll up the window blinds and remotely control everything else that can be controlled.

That dream will have to wait, but today I used my Raspberry Pi to make a small proof of concept.



One of the many cool things about the Raspberry Pi is that it has some general purpose I/O pins exposed that can be used to communicate with the outside world using various protocols. The simplest thing you can do is to set a single pin to a high or low state. When combined with something called a relay, that is enough to control an electrical device plugged into a wall socket (or at least to turn it on and off). I used this relay from Seeedstudio. The relay has three pins (actually four, but one is unused), labeled VCC, GND and SIG. I connected VCC to the 5V pin on the Pi and GND to the ground pin. The SIG pin must be connected to one of several GPIO pins available. You can find a detailed description of Raspberry Pi's GPIO pins on the wiki. I connected the SIG pin from the relay to GPIO18, which is the sixth pin from the left in the top row.

Then I butchered a power strip. I removed the insulation from a segment of the cable, cut one of the cables inside, stripped some insulation from the ends and put them into the screw terminal on the relay. This is the part I was most uneasy about. You should obviously exercise caution when working with stuff that will be connected to mains voltage (extra caution when it actually is connected).

With everything attached, the only part remaining is software. The GPIO pins can be controlled through special files in the /sys filesystem, but I used a library called WiringPi. It includes the gpio command line tool, which makes working with GPIO pins easy.

First you have to configure the pin for output:

gpio export 18 out

Then you can set the state to high with:

gpio -g write 18 1

And to low with:

gpio -g write 18 0

Thus switching the relay on and off. I wrapped those commands in some trivial CGI scripts for the purpose of demonstration and controlled the lamp via a web browser.

NXT delta robot

A delta robot is a robot with three motors placed on a triangular base, connected to a smaller triangular platform through three arms (the second platform is called the end effector, because it's the part that actually does stuff). The arms have universal joints in them and work as parallelograms. Because of that, the end effector's movement is restricted to just X,Y,Z translations, it doesn't rotate and stays parallel to the base. Because of their speed and precision, delta robots are widely used in the packaging industry and other places.

They're also the kind of thing that you look at and immediately think hey, I bet I could recreate that with Lego Mindstorms!



To make the robot work, we have to take the desired position of the end effector and translate it to angles to which the three arms must be rotated by the motors (fancy term for that is inverse kinematics). It involves some geometry, but luckily for us a man named Maxim Zavatsky worked it all out and posted a nice tutorial here. The program that controls my robot (which you can see here) is mostly a copy & paste of his code.

When making this robot, I found out that even though the NXT motors have encoders that tell you their rotations with degree accuracy, it's not very easy to precisely reach a certain angle on the motor. Setting up a gear reduction would help with the precision, but the Mindstorms set doesn't come with enough gears for three arms. I ended up using absolute position regulation from the enhanced NBC/NXC firmware (PosRegEnable() and PosRegSetAngle() functions). Since the PosRegSetAngle() call is non-blocking (it returns immediately and the position regulation happens in the background), it would be good to have a way of knowing when the motor has reached its set point. One solution that comes to mind is to keep watching the motor's position and when it stops changing assume that it is as close to the desired angle as it's going to get. Right now I'm using hard-coded Wait() calls, which is obviously not optimal.

My robot doesn't actually do anything (except move), but it would be interesting to attach a pen to it and make it into a drawbot. For that I'd have to somehow mount it upside down and probably work on making it a little stiffer (right now it's pretty wobbly). Another thing to try would be to reverse the calculations and turn the robot into a 3D input device (you would move the end effector by hand, read the angles from the motors, translate those into X,Y,Z and send the data to a computer).

Here's an album with some pictures of the robot.

Subway buddies

Have you ever wondered if you're meeting the same people every day on your daily commute? Over half a million people ride the Warsaw Metro daily, but if I arrive at the station at roughly the same time every day, surely there must be others with similar schedules? But even after almost a year of taking the same route, I couldn't recognize any familiar faces. So I decided it was time for a more scientific approach.

A surprisingly large number of people leave their phone's Bluetooth in discoverable state (I find it strange, because on most phones I've seen the default behavior is only to become discoverable for 120 seconds or so when pairing). I thought if I scanned for Bluetooth devices every time I rode the subway and saved the results, I could then check if I ever saw the same device on different days. So that's what I did, I made an application for my phone that does a Bluetooth scan and logs all devices it sees in a SQLite database. That was not ideal yet, because I still had to trigger the scan manually every time (I didn't want to keep scanning all the time, because that would quickly drain the battery and also I'd get a lot of false positives from my neighbors, coworkers etc.). Happily, there is a solution. Living in a city, just about the only time I lose cell phone signal is when I get on the subway. So that's a good condition to wait for to trigger the scan (there will be occasional false positives, but they don't bother us much). Obviously, this only works if your commute involves riding the subway and not, say, a bus.

Here's the source code of the application if you'd like to play with it.

So are there any strangers that happen to commute at the same time I do? After just two weeks of the experiment, with the help of a SQL query:

select addr, count(*), max(sightingtime)-min(sightingtime) y, group_concat(sightingtime) from sighting group by addr having y > 3600 order by y desc;

I found two persons that I shared a subway ride with on two different days. Unfortunately I can't really say much about them, except for the fact that one of them had an LG phone and the other a Samsung.