1st Gen Roomba Overview

Before I can rebuild Bumblebee, my 1st generation Roomba, I need to figure out how he works.  I’m going to split this into three sections; Power , motors and sensors.  I’m going to cover how to interface with each of these in future posts.


This was simple enough, I charged the battery and put a multimeter across the terminals, the battery showed 16v across the terminals.


A quick count shows that there are five motors.  One for each wheel, one for the brush motor, one for the side sweeper and one for the vacuum.  From the fact they all seem to have a black and red wire going into them and from the age of the device I took an educated guess and assumed they are simple DC motors.  In order to test this theory I took the probes from my voltmeter, plugged them into my bench supply and poked at the motor terminals with the voltage and current limit set low.  With this simple setup I was able to give the motors different voltages and easily reverse the polarity, sure enough the speed changed with voltage and direction changed with polarity.  The wheel motors will need to run in either direction but the other three only need to run in one direction.


There turned out to be a lot more sensors than I realised and it’s quite a packed little robot!  The sensors fall into two categories; IR sensors and switches.  The microswitches are on either wheel and the caster wheel at the front, it looks like all three are currently wired to the same header so the robot knows only that one wheel is up and not which.  The rest of the sensors are a bit more convoluted.

Wheel Encoders

The drive wheels have an encoder each with four wires going in, once I’d opened one up it turned out that they are comprised of an IR LED and a light dependent resistor.  I checked to see if they were IR by giving them just over a volt and there was no light, I then got out my phone camera and saw the telltale purple glow.  Shortly after this I realised the error of my ways as the LED went out, without a current limiting resistor I burnt it out!  Thankfully the LDR worked with visible light so I ended up replacing the LEDs on both sides with red ones.

Cliff Sensors

Along the underside of the bumper there appears to be four cliff sensors, again IR LED/LDR combos which in this configuration are known as IR distance sensors.  I’ve used these long ago when I built a PIC16F84 based robot at college so these aren’t a mystery.  The resistance of the LDR varies depending on how much light bounces back, you need to calibrate them in your code or circuit but they are simple enough.

Wall Sensor

This is an IR distance sensor on the right hand side of the bumper, it works the same as the distance sensor.


This one confused me for a while as I couldn’t see any switches on the end of the arms of the bumper, I ended up taking the bumper out which required removal of the logic board and the penny dropped.  At either end of the logic board there is an IR/LDR pair and when the bumper is hit the light level changes.  I wondered to start with why they didn’t just use a switch but the video linked at the top of this page explained it all.  A switch would be hammered that often it would fail in no time, the design of the bumper mount also cleans the area between the LED/LDR too which is handy.

IR “Eye”

On the top of the bumper at the front is a 360 degree lens which directs light on to an IR sensor of some kind, I’ve not dug deeper in to this one yet.  I believe it acts like an IR receiver for a remote in a TV as it is used with the Roomba’s virtual wall.  If the robot detects the IR code that is being sent out by the virtual wall it acts as though it hit a solid object, this is useful for preventing your hoover from escaping.


I’ll cover how I use each of the above in upcoming articles for each part above.

Project Bumblebee



Bumblebee is my Roomba, so named as long ago he lost his voice.  About a year ago his logic board started playing up and though he was still able to clean, at the end of each cleaning cycle he wouldn’t go into standby and his battery would drain in no time.  At that point he stopped actively gathering dust and started doing it passively as he sat behind my sofa.

Bumblebeee MK2

Since a kid I’ve always wanted to build a robot and figured I’d kill two birds with one stone and use Bumblebee as a chassis for a mobile robot, he already is one after all, but also have the aim of returning his base functionality of being a robot hoover.

The Plan

Bumblebee is an original model Roomba from 2002, he was a gift from a friend who knew I loved to tinker and gave me him broken.  If I could fix him I could keep him, thankfully an easy fix as the battery was dead.  This model is very simple in it’s function and behaviour, it has no mapping capability, no dock or wireless control.  It apparently can be controlled using IR but I’ve never had a remote.  It also lacks the diagnostics port that the newer models have that make hacking a Roomba really easy now so this is going to be a bit trickier, a lot more education and most importantly more fun!

The parts I’ve used to partially resurrect him are a Arduino Leonardo and an Adafruit Motor Controller Shield.  I’ve also a Raspberry Pi 3 to add into the mix, for Wifi control and more processor intensive tasks.  The idea is to use the two to thier strengths; the Arduino will control the motors and read the sensors allowing for real time override in case of collision and the Pi will be able to sit back and give out the orders.  It’s a classic split for mobile robots but thankfully very cheap to implement now.

Current State

As I said I’ve been working on this for a while, I’ve a load of notes to type up and a loads of “learning experiences” to share.  Mostly when I made a rookie error and burnt out one of the motor controllers…  I’ve now got the motors under control over serial, I’ve also a simple console application that lets me drive him around and toggling the sweeper/vacuum fans on, here’s a video of him in action:

Next Steps

My next item to look at is getting sensor data into the Arduino, first up the encoders.  Encoders are devices that allow you to measure the movement of a wheel, you’ve likely used a rotary encoder on a hifi to control the volume, and the Roomba has one is each wheel.  Right now I can control how much power goes to each wheel but because of differences in the state of the gearboxes, carpet and who knows what other factors, the wheels spin at different speeds.  By measuring the speed from the encoders we can compensate for this, we can also use them to calculate the distance we’ve travelled.

After that is the rest of the sensors, those I’ve found so far are;

  1. Cliff sensors – these are under the bumper and detect drops to prevent him falling down stairs, I think there are four of them and they appear to be IR distance sensors
  2. Bumper sensors – these detect collisions, I think there is one at either end of the bumper so I’ll know if I’ve hit something to the left or right
  3. Wall sensor – another IR distance sensor mounted on the right of the bumper, this allows for wall following behaviour
  4. Wheel up/down switches – One on each of the drive wheels and one on the caster at the front.  They detect if the wheels are up or down and can be handy for detecting when we’ve beached ourselves.
  5. Wheel encoders – these were IR LEDs and a light dependant resistor.  I blew one of the LEDs by accident so replaced them both with red LEDs.
  6. Beacon IR Reicever – Not sure how this works yet, it’s a 360 lens on the top that receives a beam from the virtual wall, a device you place by your door to stop him escaping, I’m hoping to add more sensors to make this redundant.
  7. Buttons – there are three buttons for room size to start different cleaning cycles.  They could be useful though I may not bother with them.

Once I’ve all the sensors connected I’ll be able to hook up the Raspberry Pi to start working on reproducing his original behaviour.  After that I’ll be able to build up his capabilities over time and add a load of new ones too.  I’m not intending this just to be a hoover but a mobile robot platform that happens to be able to hoover.

If you’ve got this far, kudos!  That’s it for now, more posts will trickle out as i write up my old notes.  I’m going to carry on having fun building things and write posts in the order they happened.  Hopefully I’ll catch up fairly quickly!

Controlling a Syma S107G with an Xbox 360 Controller

As a tie in to my No ‘Air Ambulance Challenge, a sponsored body wax for the local Air Ambulance charity, I’ve decided to upgrade my old project by swapping the RC car out for a Syma S107G.  If you enjoyed this post, please donate a few quid or whatever you can here.  It’s for a very good cause and as it’ll put me through a *lot* of pain you can be sure I’m not asking for my health!

I tried to implement the IR protocol in C# using the .NET Micro Framework for the Netduino but it proved more than a little tricky to get the timing right.  As there are a few implementation out there for the Arduino I decided to stand on the shoulders of giants and build on top of existing code, two in particular.


One thing worth of note is that my helicopter uses Channel B, as you can see in the comments in my code (heavily based on Kerry Wong’s) it is easy to switch between the two channels.  For the serial control aspect I implemented a similar method as with my Netduino project and in Andrew Barry’s implementation.  For the Xbox 360 Controller interface, I updated my previous application to listen for the trigger for the throttle and the right analogue stick for pitch and yaw.  I had some fun when I got the values backwards and I slammed the copter into a wall.  Thankfully they are built tough to survive kids and geeks alike…

The IR emitter is  a 500Ohm resistor inline with a pair of IR LEDs, connected to Pin3 on the Arduino.  Video demo below;

Xbox 360 controller interface to enable control of a Syma S107G.
Xbox 360 controller interface to enable control of a Syma S107G.

You can find the code here Syma360.

Microsoft Surface, MSR and Robots

Microsft Research never cease to amaze me, I was lucky enough to briefly visit the labs in Cambridge last week and I’ll freely admit I was gushing like a star-struck fan!  Engadget have an article up featuring some of the work MSR are doing with Surface and SAR robotics, well worth checking out.



Netduino Quadcopter

In my first post last year I stated that my New Years resolution was to build more stuff, the Jukebox lights are wired up and that project is more or less done.  One of my other ambitions mentioned was to design and build a UAV.

Now, I’m a Microsoft guy.  It’s what I know and do for a living so I know thier developer stack pretty well so upon learning of the Netduino a plan came together and this years project was born!  So far I’ve the Netduino, a Razor 9 DOF sensor board and a plan!  I’ve been following other similar projects such as Aeroquad and I plan to blog the project as I go.

The plan is currently fluid, I’ve not built anything like this before though have flown model helicopters before.  I’ve a few specifications that the copter will be built around;

  1. Autonomy – With the sensors onboard, the IMU and GPS, it will need to be able to fly a set path.
  2. Payload – Along with flying a path the copter will have a camera or two to capture aerial photographs.  Ideally from multiple angles to have some fun with Photosynth
  3. Telemetry – The copter will have a live telemetry link back to a PC and on board storage for later review of flight data.  Ideally a live video feed too which will be the stretch goal.
  4. Easy Mode – As with the Aeroquad I’d like my copter to have stable and agile settings, I wan’t my friends to be able to fly this easily with minimal practice.

I’ve set myself quite a challenge though as with all my projects it should be a hell of a lot of fun and quite a challenge.  Stay tuned for more…