Team Robo Monster™

Thursday, July 14, 2005

Gumstix Robostix

Gumstix, which has created a nifty and tiny 400mHz single-board Linux computer (see at recently released RoboStix, and add-on board. Overall, the gumstix plux RoboStix are the size of a pack of gum with 3 sticks in it - impressive. The RoboStix supplies PWM connections, and I2C interface, and various other goodies (including an array of colored LEDs useful for monitoring program execution).

We've been experimenting with the Gumstix for some time. Our hope has been to link one Gumstix to several microcontrollers, which in turn link to multiple sensors following our "sensor dense" concept. One of the problems is that the Gumstix runs at 3.3V instead of 5V, and can't simply be plugged into a sensor array like a standard microcontroller. Various groups have developed the hardware to hook up Gumstix, but we decided to wait - we want to concentrate on the programming rather than hardware configuration. The gumstix also supports ethernet, usb-ethernet and bluetooth (not all at once) but this doesn't seem to be the best way to hook up the microcontrollers.

We are actively investigating CAN (see for the link - but now we'll have to look at the I2C interface on the Robostix. It seems possible that the Robostix will allow us to easily put the gumstix into an I2C network of several microprocessors and sensors. Our current microcontroller is "master" but this actually fits our idea for forcing the data from the "bottom" rather than requesting from the top.

Unfortunately, the growing popularity of Gumstix has held things up - the first batches of the Gumstix RoboStix board sold out almost instantly. So for now, we're going to concentrate on our microprocesor arrays and make them as "smart" as possible. Instead of reporting raw data, the microprocessors report time vectors - changes in the sensor output. If nothing is happening, the microprocessor puts out a slow "heartbeat" (once every 5 seconds). However, if the data is changing, the microprocessor puts out vectors as fast as it can. It does this by comparing a filtered average to the current values. We're also thinking of allowing two kinds of outputs - one which shows the current and smoothed averages, and another which simply records a +/- for the sensors showing rapid change in data. This might help speed up processing.

Still looking around for our "junker" car to test our stuff on so we don't have to use the rock-crawler. Ideally the junker will be street-legal (the rock-crawler is not) so we can drive directly to test sites. More on this later.


Post a Comment

<< Home