Archive for February 2009

Roomba Progress, 2/23/09

February 23, 2009

Not much progress this week.  I’ve just connected all the I/O wires to the breadboard and written a little program to control the outputs and interactively view the input states.  Everything “works” on the desk right now, but I’ll record a video once I’ve tucked away all the wires so it can roam free.

Roomba Progress, 2/16/09

February 16, 2009

As of February 16th, quite a bit has changed. Firstly, I’ve finished reverse engineering the Roomba circuit board and spent some time getting reacclimated to PIC microcontroller assembly language.  This took longer than I had hoped, but a week ago today I put a PIC 18F4550 MCU into a breadboard and began actual coding.  Gradually I brought the various subsystems online as I worked toward decent functionality for the robot.  Simultaneously, I finished up the process of assigning general purpose I/O pins to the Roomba’s peripherals.  Here’s is a link to my reverse-engineering spreadsheet:

View ‘Roomba Reverse-Engineering Spreadsheet’

Fast-forward to this weekend:  I now have the PIC receiving serial commands.  If I send the single-byte command ‘S’, the PIC responds with a five-byte status packet organized as follows:

struct StatusPacket {
byte type = ‘S’;
byte flags1;        // 8 sensor bits
byte flags2;        // 4 more bits
byte leftEncoder;    // keep a circular counter of encoder position…
byte rightEncoder;    // … increment when bot is being moved FW, decrement for REV
}

When I send five-byte command of the following format…

struct CommandPacket {
byte type = ‘C’;
byte flags;        // 2 L/R direction bits, 2 motors, 3 leds, 1 led color
byte speakerTone;    // 8-bit frequency (map to 16-bit, C-scale frequencies?)
byte leftMotor;        // 8-bit duty
byte rightMotor;    // 8-bit duty
}

… the Roomba updates the states of various motor and LED pins, and updates the duty cycle values of the main wheel motors.  The speed of the wheel motors can be varied via a duty cycle which provides power to the motor pin for the fraction (MotorDuty/255) of the internal timer’s overflow period.  Low duty values result in a slow speed, high values result in high speed.  Note that the speaker tone is non-essential so I have not implemented it yet.

With all of this in place, I began soldering to the Roomba control board:

You can click individual images to get a bigger view.  Click the resulting image to view full-size.  The second-last image shows my first test of the Roomba connected to the PIC.  The PIC is monitoring the state of one of the infrared sensors, sending its status as a single bit in the Status packet.  When I place my hand in front of the sensor, one of the bytes changes from ‘R’ to ‘Z’, then back to ‘R’ when my hand is removed.  This is a huge step because the small PC that will sit on top of the Roomba now has a means to obtain information about the Roomba’s sensors.  When it sees that there is an obstacle in front of the sensor, it can stop moving forward and turn to avoid the obstruction.

LOGO Robot Demo

February 5, 2009

Here’s an early demo of the other robot I’ve been working on.  This is the beginning of a LOGO “turtle” robot… a robot that follows instruction that tell it how to draw a picture.  It drives around on a sheet of paper leaving an ink trail with its pen.  I’ve written and debugged almost all of the verilog code, I just have to build its body and wire up some electronics.  In the video, it’s executing this program:

SET    r0, 1    ; initial box size
SET    r1, r7   ; number of rings
drawbox:
PD
FW     r0
R      90
FW     r0
R      90
FW     r0
R      90
FW     r0
PU

FW     1        ; Move to SW corner
L      90
FW     1
R      180      ; Face North

INC    r0
INC    r0       ; boxsize += 2

DEC    r1
JNZ    r1, drawbox

END

The above program assembles the following machine code:
6001 //SET r0, 1
6307 //SET r1, r7
5000 //PD
0800 //FW r0
2009 //R 90
0800 //FW r0
2009 //R 90
0800 //FW r0
2009 //R 90
0800 //FW r0
4000 //PU
0001 //FW 1
3009 //L 90
0001 //FW 1
2012 //R 180
7000 //INC r0
7000 //INC r0
8001 //DEC r1
B202 //JNZ r1, addr[2]
C000 //END

February 2nd Update

February 2, 2009

This week I painstakingly disconnected all of the wires attached to the Roomba’s PCB, documented each connection, unscrewed a few components, and I finally extracted the PCB.  I had originally hoped enough of the circuit board would be exposed so I could avoid the hassle, but no such luck.

cimg3652cimg3664

cimg3672

cimg3675

The board is relatively simple; it seems to be no more than a bunch of driver circuits for its motors and sensors. Yet I’m inexperienced at reverse-engineering electronic circuits.  Surprisingly, the process was time consuming, but not too difficult.  I now have a spreadsheet containing information about which CPU pins interface with which other parts of the circuit.  I believe I now have as much data as I can possibly obtain through inspection, so next I plan to reconnect it to the Roomba peripherals and run it in debug mode.  Debug mode will allow me to determine what the CPU must do to operate the Roomba.  Afterward, I should be able to remove the original CPU and replace it with a microcontoller.

On the PC front, I set up a wireless adapter on the motherboard and configured VectorLinux to connect to an ad-hoc network automatically.  From another computer, I can now SSH into the Roomba computer.  I’ve also installed CMUCL (Common Lisp) and placed a copy of SNePs on the CF card. Next I need to power the board from the Roomba battery using the automotive ATX powersupply I purchased and write a program to communicate with the microcontroller.

cimg3673cimg3674

Cognitive Robot – Summary up to January 26th

February 2, 2009

This is the first of many (fingers crossed) frequent (toes crossed, too) posts detailing the progress of my cognitive robot.  I will use this blog to document the development process, share my project with friends and classmates, and to aid me in making weekly presentations about the robot.

Here’s a summary of what’s happened so far:  This semester, I registered for a “Cognitive Robotics” seminar in which students are required to buy/aquire a robot and somehow program it to perform an interesting task through reasoning.  It was suggested that we buy a suitable robot over winter break so we could begin working at the beginning of the semester.  I chose to put my electrical engineering skills to use hacking together my own custom robot to save money and gain flexibility.

Over the break I bought a first-generation iRobot Roomba to use as a starting point. At about $30, it was cheap, but I still have a lot of extra work ahead of me getting it to the point where it can reason. In short, newer Roombas have a serial port that allows external computers to tell them what to do, and iRobot’s Create is even better because it is intended to be a workhorse robot. Instead, I must open up my Roomba, learn how it works, rip out it’s brain (CPU), and replace it with my own microcontroller brain.  The microcontroller will then talk to a small computer mounted on top of the Roomba, enabling the Roomba to do the computer’s bidding.  It gets a little more complex than that, but not much. Next I’ll outline that extra complexity, so skip it if you aren’t interested.

I think about my robot in three layers: the Roomba & microcontroller, the PC running a C application, and a Lisp application.  The microcontroller solely collects commands from the PC via its serial port, it carries out these commands in the form of moving the Roomba, and it sends sensor data back up to the PC.  The PC is a small FlexATX motherboard with an integrated processor and 4GB compact flash card.  The PC runs VectorLinux Light (based on Slackware).  It will run standard applications and I will be setting up an SSH server and wifi so I can log into robot while it is online. The PC will have one or more cameras directly installed to supplement the sensory input acquired by the Roomba.  The planned C application will process the video and sensory input to medium-level tasks such as object recognition, movement planning, and obstacle avoidance.  Hopefully, the middle layer (‘behavioral’ layer?) will be robust enough to provide meaningful facts to the highest layer (‘cognitive’ layer?). By this point, Lisp and SNePs will be used to process facts and beliefs in order to enslave mankind :P.  I don’t know a great deal about knowledge representation and reasoning, so with any luck, the details of the cognitive layer will materialize in the coming weeks.

By classtime on January 26th, I had purchased all of the parts I need at the moment and presented a summary of cost and showed some pictures of my progress:

  • Roomba            ~$45
  • Battery              ~$33.49
  • Rapid Charger      $15
  • 4GB CF card        $45.62 – ($40) = $5.62
  • CF-to-IDE             $3
  • FlexATX mobo   ~$40 – ($20??) = $20
  • Car ATX Supply    $7.75
  • Total:                ~$130

I had installed Linux on the CF card, verified that the Roomba was undamaged, and begun disassembling it. The next step was to extract the circuit board inside the Roomba and begin reverse-engineering its functionality. I have some notes written by a team that hacked a Gen. 1 Roomba years ago, so I know that the motor drivers are active-low.  That means I can begin writing my PIC microcontroller code and designing its circuit even before I am ready to solder to the Roomba itself.  My plans for the robot are to implement some form of stereopsis (3D image processing) using one or more cameras and to run Lisp directly on the robot.


Design a site like this with WordPress.com
Get started