According to http://findingada.com, “Ada Lovelace Day is an international day of blogging to celebrate the achievements of women in technology and science”.
So, I would like to celebrate the open source hardware achievements of Limor Fried, whose store http://www.adafruit.com/ sold me my first Arduino, the first serious electronics kit I soldered together, a USBtinyISP AVR Programmer Kit, and whose instructions and forums have been an invaluable resource in my Arduino and AVR-based projects.
Blog post about an Arduino command line shell. I/O is through the serial port, and commands are available to set/reset pins, timers, inspect registers etc. Could be pretty useful for experimenting with a circuit before the code has been finished.
I just built a little audio amp using an LM386 chip and the Little Gem amplifier circuit. I plugged it into my Arduino and programmed up a little well-tempered scale. I found to my surprise that if the Arduino was off and I touched the amplifier input, then I got very faint speech out of my little speaker, which I am pretty sure is NPR!
Today, I interfaced an Arduino to a stepper motor – the hardest bit in the end was figuring out which pins of the Unipolar stepper motor do what. The motor, available as Jameco 171601, has six wires – yellow, red, orange, black, green, brown – which come out in a connector. The most useful reference I found was Tom Igoe’s Stepper Motor Control page. In the color sequence above, the wires are those numbered 1, 5, 2, 3, 6, 4 in Igoe’s diagram.
As a demonstration I wanted to turn it into a little weather toy, but it has been very difficult finding machine-readable real-time weather data on the web. The NOAA site is chaos. Eventually, I settled on this:
NOAA CA weather data.
It was easy to grep and sed the data I wanted out of its text and tables. God forbid that whoever produces this should take a more literary turn – then I would need NLP! 
Using EZ-4 sonar on my robot, I attempted to get a depth map of my view
of the opposite wall in our office at home. The arduino was taking sonar
readings at a rate of 20Hz and sending down the serial port to my Mac. I
pointed at the wall and then scanned across at an even speed clockwise -
taking about 6 seconds to cover 30 degress of arc – then put my hand in
front of the sonar to get some easily recognisable low readings to mark
as end-of-row, tilted the arduino up 5 degrees and scanned right to left
at about the same rate. I repeated this backwards and forwards scanning,
increasing the angle from the floor at the end of each row, until I had
9 rows.
I normalized the data by assuming that each sweep (left-right or
right-left) covered an equal angle but possible at a different speed
(resulting in a different number of readings for different rows – the
average number of readings was about 120 (6 seconds at 20Hz)).
Here is the raw data.
The readings were now – with a little work – in the 3d polar form with
variables phi, the angle the sonar beam made to the center of my point
of view when projected onto an axis parallel with the floor, theta, the
angle the beam was pointing above the floor (0 ~ parallel to the floor),
and r, the sonar range in inches. With a fair amount of pain, I
converted the readings into XYZ readings with (0,0,0) where I was
sitting and plotted them in grapher.
The data is… hard to interpret. I just bought a copy of “Probabilistic
Robotics” by Sebastian Thrun, Wolfram Burgard and Dieter Fox and
although I have hardly had a chance to look at it I did notice that the
sonar maps they present are very noisy. It looks like my sonar map is
noisy too. The data points resolve into a few coherent blocks. Closest
to the viewpoint in the picture below is a block of points where a tall
filing cabinet is. A little deeper into the picture, and not extending
so high (up the screen in the picture) there is a sofa. The other points
are very noisy but are bounded behind by a wall. I expect that the wall
is quite a good reflector of sonar, and so results in very poor
readings.
Robot-derived floorplan
At the weekend I calibrated the robot. In some driving tests I found that it drives 7.5″ to the right for every 30″ it drives forwards – which is corrected by adjusting the left wheel speed to be about 80% that of the right wheel, drives forwards at a rate of 6″ per second, and turns on the spot at a rate of 96 degrees per second.
I made some changes to the software to get my robot to use the sonar range data to produce a map of the terrain it traverses. Initially the robot was saving the map to onboard RAM, but I found that plugging the Arduino in to the Mac to read the map out over the serial port would reboot the Arduino and erase the data. The next version saved the map to on-board EEPROM, and that properly survided the reboot and could be read out. At first the results were very obscure and disappointing. Until I realized that degrees != radians and fixed the trig appropriately. The map is a little hard to interpret – I plan to make changes to the software to help that – but considering that the robot has been only roughly calibrated, the results are quite impressive (to me – I built the robot and wrote the software so I might be a little biased).
The picture is of my robot-derived floorplan. The height of the bumps is proportional to the time from start of drive that the robot added that map point. Note that new map points could overwrite old ones.
I think that the ridge of high bumps which crosses the middle of the picture parallel to the X axis corresponds to the same part of the hallway as the longer ridge which was found much earlier in the run and which appears below it in the picture. The high ridge comes from the robot’s second tour around the hallway.
Experimenting with the Google AJAX API, I uploaded a graph which progressively shows the obstacles the robot detected as it drove. Note, these are the obstacles detected, and not the robot’s estimated path. This gives some idea of how the robot was moving around, and also of the accumulating inaccuracies in its estimation of where it and the obstacles were.
The next thing little robot needed was the ability to sense its environment. I ordered a MaxBotix EZ4 sonar from Sparkfun for less than $30, and with a little nervous soldering today got it connected up to the robot. The obstacle avoidance code is very simple – if the robot detects an obstacle sufficiently close, it turns left a little. An earlier algorithm had both left and right turning but needs some work to prevent excessive oscillations.
Below is a little video of the robot navigating around the hallway and avoiding a moving beslippered object (me).
robot081231
Today at around 4pm, a little baby bot was born. Oliver helped me with some of the design decisions, and with measuring and calibrating the little guy. He weighs about 2lb (including batteries), and is 14″ long. At this stage, he is blind. He does, however, diligently follow instructions fed to him as a program down a USB cable. After each programming, we remove the USB cable and he is reborn, newly obedient.
One of the lessons I learned with this robot was that the electronics and programming are at most half the challenge. What caused the most problems was the mechanical part. In the end, I settled for an old iPhone box for the body. We carefully cut holes in the sides for the motors, making the motors fit as snugly as possible to minimize wobble. Even so, a couple of folded pieces of paper and an earplug are used to pack the motors more tightly.
My first little Robot
It works! I built the beginnings of a little robot today. I have an Arduino Diecimila connected to a circuit built on a breadboard around a TI SN754410 Quadruple Half-H Driver, connected to two Pololu Gearmotors . I followed recommendations found in various net places to reduce motor noise by wiring each motor with 3 capacitors – fiddly work with such small motors, and followed a very clear example I found in a course on the web to hook up the Arduino via the H-Bridge to a motor.
I wrote some code to drive each motor forwards or backwards at a chosen speed, and on top of this wrote routines to drive the robot forwards, backwards, clockwise or anticlockwise. After a little debugging it all works. Only problem now is… the robot has no body, just guts.
I had in mind a Ferrero Rocher box for a transparent, light, appropriately sized body, but the particular – formerly ubiquitous – size which I wanted is nowhere to be found. I may have to cannibalize some tupperware.
