Adam Ziegler - St. Norbert College, Class of 2010 - CSCI 460: Senior Capstone
The Day After - 27 Jan 2010
I was expecting some type of despair this morning, as I've had a night's sleep to let the project sink in.
There was none, however...a good sign, perhaps?
Heavy research on available materials. Apparently, this "Command Module" holds C programs which
then communicate directly with the robot through the serial port, using the iRobot Serial Command Interface
prevalent from the Roomba Reds on up. So, essentially, this puts autonomy into the robot insomuch as the
programs are preloaded onto the microcontroller, which executes them as a normal C binary would on any other
The controller needs specially-compiled C through something called AVR. If I'm lucky, I'll find - and I just
did. I don't believe it...GCC has an official toolchain for AVR, with official packages for almost every Linux
distribution. Okay, that's cool, but what about integration with Eclipse? Surely there can't be - ...wow.
There's an Eclipse plugin to handle GCC-AVR compilation, with a handy option to upload to a target device over
an arbitrary port. This is getting better...
Discovered that the Command Module's onboard microcontoller is an Atmel, a brand which is apparently fairly
well known for this type of work. The flashing process for the 16 kB onboard flash memory is relatively
simple - press a button on the robot, then upload the memory image through the onboard USB port. Based on above,
I'm guessing I could have the GCC-AVR toolchain compile the binary, then upload through my USB port...
...This just seems too good. The Eclipse AVR plugin uses GCC-AVR to compile the flash image (not a binary,
as I thought before), then uses a utility called "avrdude" (also an official Linux package) to upload
the image through the USB port directly to the Command Module. I now quite literally have a full development
environment to compile and upload a new flash image to the robot. This will need some testing, but it looks