Mapping with the iRobot Roomba

Brian Gerkey, SRI AI Center (gerkey [at] ai [dot] sri [dot] com)

31 March 2006

iRobot recently released an API for programming the Roomba vacuumming robot. It's a pretty reasonable little robot: motors, encoders, bumpers, a couple of IRs, good battery life, and, best of all, cheap.

Several interesting things have been done so far in the Roomba hacking community. I figured I would try building a map. Besides the obvious technical appeal of mapping with a cheap consumer-grade robot, there's an opportunity to improve the performance of the Roomba by allowing for more sophisticated cleaning strategies (not to mention giving the poor robot a better chance of finding its way back to the docking station).

This page describes my proof-of-concept of a mapping Roomba robot.



What I used:

Electronics assembly

We need 5V to power the Gumstix and the URG laser. I chose to slap on a 12V battery that was close at hand and run it through a 12V/5V DC/DC converter. You can instead draw battery voltage (nominal 14.4V, I believe) from the Mini-DIN port on the Roomba.

The serial interface to the Roomba operates at TTL level (0V/5V), not the RS232 level (-12V/+12V) used by serial ports on most computers. Fortunately, the waysmall STUART board allows us to tap into the serial lines at TTL level, before they go through the TTL/RS232 level shifter. I found a Mini-DIN cable in the lab, cut it in half, and soldered onto the send, receive, and ground solder pads of the STUART on the back of the waysmall board. I could then talk to the roomba over /dev/ttyS2. Check the specs on the waysmall board and the Roomba programming manual for the wiring details.

The serial connection to the URG laser operates at normal RS232 levels. So I plugged the cable that comes with the URG through a NULL modem adapter, a gender changer, and the DB9/Mini-DIN NULL modem cable that Gumstix sells into the FFUART port on the waysmall board (yes, there's an unnecessary straight-to-NULL-and-back-to-straight change going on there; I am not optimizing for cable length :). To use that port, I modified /etc/inittab to turn off the getty that normally runs, and gave init the old kill -HUP 1. Then I was able to control the laser over /dev/ttyS0.

Physical assembly

Basically, I just velcroed everything together. The battery sits upright roughly in the middle of the robot. The laser sits just in front and is velcroed to the robot and the battery (for extra stability :). The Gumstix is velcroed to the back of the battery, and the cables are zip-tied together.

Here's what my Roomba looks like (click for full-size):

No points for style, but it works.

Software configuration

I used Player to control the robot; as of 2.0.1, Player includes working drivers for the Roomba and the URG laser. I cross-compiled Player to run on the Gumstix, following this tutorial. I included the following drivers in my build of Player: My configuration file is here. It logs the robot's odometry and the laser scans to a file on the Gumstix.

Controlling the robot

I used playerv to control the robot. Because of the lag in the wireless network, I used playerv to provide position targets to vfh, which then did the velocity control locally on the robot, using the laser to avoid obstacles. This setup worked quite well.

Making a map

Mostly because I didn't want to spend much time on this project, I went on the assumption that the Gumstix is not powerful (in processing and/or memory) enough to do 2D SLAM (simultaneous localization and mapping) online. I don't know whether this is true. See the links below for an attempt at real-time SLAM with vision.

After taking a run down the hallway, I pulled the data log onto my desktop machine and ran it through a Player SLAM driver. I used an SRI proprietary SLAM system, but there are a number of Open Source SLAM systems available online that can read (possibly with some munging) Player log files.


So far, I've done one experiment, an 8-meter run down the hallway oustide my office. Here's a plot comparing the path from the raw odometry with the corrected path produced by the SLAM system, along with the laser scans projected from the corrected path (click for a nicely-scalable PDF):

The odometry is pretty bad, but still informative enough for the SLAM system to determine the robot's real trajectory.

Here's the resulting occupancy grid:

When I get some more time, I'll do a longer run to test loop closure.


All things considered, the Roomba is a pretty nice robot. As this experiment shows, it's now possible to build a laser-equipped mapping robot for US $2,000-$3,000 (depending on how much you pay for your URG laser). For reference, the conventional SICK-equipped Pioneer will cost you 3-4 times as much. And if you don't need a laser, you can build a Gumstix-controlled Roomba for under US $500.


Some related pages: