If you haven’t seen one yet, the Arduino microcontroller is the cutest piece of hardware since WALL-E, if you think circuits are cute that is. Like my first iPod, every time I see it I am surprised by how small it is. The hardware is pretty simple, just an ATmega168 microcontroller and some inputs/outputs, meaning that they’re pretty cheap too.
I’d known about them for a while (and had attended Adrian McEwen’s talk at the Liverpool BarCamp back in December) but had put off buying one because I’ve always been under the impression that hardware is much harder to debug than software, and I pictured myself spending hours of my precious free time trying to detect an elusive problem. So it wasn’t until Adrian and Thom Shannon organised the inaugural Howduino event in Liverpool that I finally got an excuse to buy one.
When I finally took the plunge, I bought an Ethernet shield along with the Ardunino itself, partly because it looked like tinker.it would sell out before the event, but also because I thought that whatever project I did would have to involve the internet.
Preparing for the event – My first project
So upon receiving my Arduino I set about getting an LED to blink (the “Hello World” of Arduino development). That was easy, so the next step meant an excuse to use the Ethernet shield – controlling an LED via the web. This turned out to be suprisingly simple thanks to an open source library named Webduino.
Webduino is a small HTTP server for the Arduino, and handles GET requests, including parsing query string parameters. That was all I needed to start receiving HTTP requests on the Arduino. So with a simple web page which contained 4 checkboxes and a submit button, I was able to turn 4 LEDs on or off depending on the value of their checkboxes.
This was very encouraging, as although lighting up LEDs isn’t very useful, the implications of being able to control something physical via a web page was quite exciting, especially considering that I’d only spent a few hours getting it to work. I was an Arduino fan already.
At the Howduino event, I decided that I would try to race remote controlled cars based on how well certain search terms were doing on Twitter. I would generate a two timelines, and trigger the forward motors of the cars according to their timelines.
Getting the timeline data
When I initially conceived of the idea I had been intending to use the ethernet shield to access the Twitter API in real time, but it soon became obvious that the ethernet shield would be unnecessary. I could get all of the data I needed before the start of the race using a Ruby script, and then send it to the Arduino in a stream of serial bytes via the Arduino IDE. Each car would have a character in the stream, and when that character appeared it would move a little (more on this later).
A snippet of a timeline with a
0 representing one car and a
1 the other would look like this:
1 9 1 1 0 9 9 0 0 1 9
9 is a null, meaning that neither car moves for that step.
I wrote a simple program in Processing for simulating the timelines to see which races would be most exciting in terms of a close race, so that I could choose which races to show to people.
Cheap Remote Control Cars
I bought two similar remote control cars that operated on different frequencies. My plan was that I could simplify the project by just connecting the remote controls to the Arduino rather than trying to control the motors of the cars themselves. I planned to connect the forward switch on the remote control and trigger it whenever the car appeared in the timeline.
I had written the Ruby timeline processing code before the day of Howduino, so I was pretty confident that I would be able to have some exciting Twitter races on the day. Unfortunately, two problems meant that the races didn’t quite go to plan…
Getting ahead of myself
Before the event, I started to get clever, thinking that this was too simple and needed a bit more control. I’d bought an analogue slider, so I thought I would use it to control the speed of the race. My intentions were good – while testing with the Processing simulation I had found that some races were very fast and some were very slow, depending on the participants of the race.
For example a race between the finalists on American Idol during the final itself would be very fast as hundreds of Tweets occur each second, but two more obscure topics would be much slower as their Tweets trickled in over months.
I later found that adding the slider actually meant that I couldn’t limit the rate of the serial bytes to the Arduino, and it ended up being flooded. The end result of this was that the race would be over before it began, and the cars would just stutter a little and then stop. I didn’t actually realise this until after Howduino.
Survival of the fittest
Something else I discovered after the event when I started running a control race – both cars being sent the exact same timeline – was that one car (the blue) was much less powerful than the other. This was a big setback, because without adding a handicap in the code the race could never be fair.
Maybe I should have bought more expensive cars!
The future of Twitter Racing
I learnt a lot from my couple of days of Twitter Racing, but haven’t played with it since. If I attend another Arduino hacking event I’m sure I’ll revisit it and make it much more of a success!
The Twitter Racing code is available on GitHub. It’s pretty rough and needs refactoring, particularly the Processing code as it was my first attempt at Processing.