Team Robo Monster™

Thursday, July 14, 2005

Gumstix Robostix

Gumstix, which has created a nifty and tiny 400mHz single-board Linux computer (see at http://www.gumstix.com) 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 http://www.machinebus.com) 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.

Saturday, July 09, 2005

Testing the "sensor dense" idea
Despite the long lazy days, we're pushing ahead with our "sensor dense" concept. In addition, we're modifying some of the controller software and testing controls.

Our big work for the last several weeks is evaluating particular sensors for use in a "sensor dense" configuration. This involves hooking them up to a microprocessor and evaluating their response under different conditions. In the next step, software filters smooth the data and detect when the data is changing suddenly - when there's no change in readouts, the sensors don't output. Finally, the information from each sensor is formatted into a NMEA-like string which is sent out via the serial port. We have been talking to MachineBus (http://www.machinebus.com ) about using a CAN network for this, but at present we are still "all serial".

Here is a list of the sensors we have tested. "Direct connect" means that the sensor has to be wired to input/output pins on a microprocessor, in contrast to I2C or other mini-network protocols. For testing we have been using the Basic Micro Atom Pro - mostly because it has a large (2k RAM) and is faster than other hobby microprocessors:

Ultrasound SRF04, SRF08, SRF10 (Devantech) - the 04 is a direct connection, while the SRF08 and SRF10 use I2C, allowing several devices to be on the same bus. All these ultrasonic devices do good detection, though the spread of the beam is fairly wide. At present, we'll probably put only one of these per body panel - their range is out to 30 feet. We also experimented with the Senscomp/Polaroid ultrasound but it's pretty clear that the Devantech devices are easier to set up and use. The SRF08 also has a photocell, which gives a crude light/dark reckoning - it will allow us to determine which parts of the vehicle are in shadow as it moves under, say an overpass.

Ultrasound SRF235 (Devantech) - this I2C device uses a 235 kHz beam, in contrast to the 40 - 50kHz beam used by most ultrasonic devices. Due to the high frequency it can only detect to about 1 meter - but the beam is only about 15 degrees wide! This makes this sensor much like a long invisible "hair" on the robomonster body. It also updates faster - up to 100 Hz. Finally, since it operates at a different frequency, it can fire at the same time as an SRF04 or SRF08/10 without interference. We see it as a secondary confirmation system for our close-range IR sensors (see below).

Senscomp (Polaroid) - This larger ultrasonic device has about the same range as the Devantech sonars, but uses more power. We found it was difficult to set up compared the Devantechs, and also has large power draws (transient 2 amps).

SportsImportLTD sonar - This is a commercial sonar system from one of our sponsors. The weather-hardened sonars are designed to point in an array to the front and back of the vehicle. Interestingly, there are only two wires going into the system. Our plan is to put this packaged system as a "canned" secondary detector for objects while the vehicle is trying to back up.

GP2D02 IR sensor (Sharp) - This direct connect device reports a range from about 3" to 30". Its low price makes it possible to use several, and connections are straightforward.

GP2Y0D02YK IR sensor (Sharp) - This direct connect device thresholds at abouty 30" inches. In the "sensor dense" concept, threshold sensors typically trigger more detailed readouts of other sensors reporting position/range.

GP2Y0A02YK IR Sensor (Sharp) - This is the sensor we had at our 2005 site visit - it reports distance as voltage in an analog circuit 3-30". It has pretty good performance - a set of 4 gave reliable indicators of a person moving in front of the vehicle. However, the analog system draws more power and can't be hooked into a network like I2C.

GP2Y0D340K IR Sensor (Sharp) - This tiny IR sensor thresholds at 16". However, its small size is less of an advantage than one might think - it requires additional wiring and some electrical components to function.

Memsic accelerometer (Memsic) - We're testing the surface-mount version of this tilt sensor from Parallax. We've found that it is pretty good at working, but the raw data needs a lot of massaging to convert to tilt angle. We haven't run it on a moving vehicle yet, so we don't know whether tilt or vibration will predominate under actual driving conditions.

Magnetic compass (Devantech) - We've experimented with the Devantech compass and find it useful - however, the new Hitachi compass surface-mounted by Parallax is more compact. We are considering mounting multiple compasses on the vehicle body, and using the combined input to factor away effects of metal/electric fields.

Magnetic compass (TCM) - This high-end compass was mounted, along with our JRC GPS system during the 2005 site visit. It gives a reliable signal and can tilt-compensate after callibration.

Magnetic compass HM55B (Hitachi/Parallax) - This tiny compass performs similar to the Devantech, with the advantage of very small size - we're using the Parallax surface mount.

Sensirion humidity sensor SHT11 (Sensirion/Parallax) - Why a humidity sensor? Well, the system has a thermometer, which gives temperature output. Second, by taking temperature and humidity it is possible to calculate dewpoint. In a real robot car, reaching dewpoint is significant - moisture will begin condensing on the vehicle body, lenses, etc. and affect sensors. This sensor will warn the vehicle to take action (e.g. running heaters on lenses). The system took some effort in programming - it has a custom read/write protocol which takes some effort to decode on a microprocessor.

TAOS color sensor (Taos/Parallax) - This sensor reports the relative Red/Green/Blue values of its field of view. We plan to use it to detect blue sky versus cloudy conditions to callibrate our other cameras.

TAOS Light to Digital (LTD) sensor (Taos) - This sensor can measure brightness ranges of 40,000:1 - about the same as the human eye. We plan to use these sensors to determine absolute scene brightness for camera callibration. Combined with the color sensor telling us if it is a cloudy day, it will also allow us to predict the contrast of shadows. Shadows fooled lots of the 2004 Grand Challenge vehicles, and we feel this will provide a workaround.

CMUCam - We've been working with this system, both the standard CMU version, and the alternate system developed by Acroname. The goal is to use multiple CMUCams to detect motion around the vehicle, and quantify "optic flow" of the environment as the vehicle moves. Object recognition comes at a later date, with a higher-resolution system.

Bump sensor - We're putting a few standard switches on each body panel to detect contact. These are contact switches with a small wheel allowing them to roll against a substrate.

Flexiforce - This strip of material can measure pressure. It may be useful for detecting pressure on the bumper if contact is made, going beyond a contact switch

MSI piezo tab - These small plastic strips send a small electrical pulse if the are snapped or vibrated. They form a perfect close-range "whisker" for selected vehicle body panes. Since they can generate high (50v) voltages relative to microprocessor pins, wiring a large number of them will be tricky.

We're also planning to test several other sensors. Chief among these is a microphone, a kind of vibration sensor. The plan is to use it to confirm things like engine noise and the siren (when it is sounded). Audio sensing/voice recognition for the moment lays well in the future.

In other work, we've set up a working servo control system for our throttle. We had tried to use the Polulu system, but found it simply would not respond to Visual Basic signals sent out the serial port. The Parallax servo controller is more forgiving, and we have not problem with servo control now. However, our "leaf blower" effectors are going to need a more sophisticated system. We're looking at a very interesting servo controller which combines servo output, a microprocessor, and multiple A/D and digital I/O ports. This should allow us to build the leaf-blower effector with sensors for contact, vibration, etc.

Later this summer: Integration. Now that we've tested individual sensors, it is time to put some together on test body panels to see overall performance. Our plan is to try one panel with all-analog sensors, and another with digital/I2C sensors. The resulting output should allow our system to use each body panel like a low-resolution "retina" to examine its environment.