Main Page

From RedDwarf

Jump to: navigation, search

Red Dwarf

Ft. Mason, San Francisco: That's us (Allister, Shie, Evan, Sam) in the center grass, off in the distance.  Background: Golden Gate Bridge
Ft. Mason, San Francisco: That's us (Allister, Shie, Evan, Sam) in the center grass, off in the distance. Background: Golden Gate Bridge
RedDwarf, right before the race.  We were programming it and fine-tuning the hue thresholds for the orange cone right up until the start time!
RedDwarf, right before the race. We were programming it and fine-tuning the hue thresholds for the orange cone right up until the start time!
RedDwarf again... notice the camera on the top!  We used an orange hue threshold in order to recognize the cone.  We also used a lens filter on the camera since it was really only made to work indoors.  This lens cut down on the bright light and helped to get more consistent images.  Also, notice the OQO ultra-mobile PC on the right side of the picture.
RedDwarf again... notice the camera on the top! We used an orange hue threshold in order to recognize the cone. We also used a lens filter on the camera since it was really only made to work indoors. This lens cut down on the bright light and helped to get more consistent images. Also, notice the OQO ultra-mobile PC on the right side of the picture.
RedDwarf with the older bumper that we tried.  The bumper continued to stick, so we switched to the antennae, which helped.
RedDwarf with the older bumper that we tried. The bumper continued to stick, so we switched to the antennae, which helped.
Close up on the Hall-Effect sensor attached to the wheel.  (See the IC on the left of the image).  We used this to count wheel revolutions and adjust the power based on desired speed.
Close up on the Hall-Effect sensor attached to the wheel. (See the IC on the left of the image). We used this to count wheel revolutions and adjust the power based on desired speed.
Close up of the circuit board.  This drove the car through its two servo controllers.  We used a Parallax board, which was programmable via Basic.
Close up of the circuit board. This drove the car through its two servo controllers. We used a Parallax board, which was programmable via Basic.
Evan and Allister, happy with the results.
Evan and Allister, happy with the results.
Sam included his Lego version of our robot.
Sam included his Lego version of our robot.
A cool spherical robot in the show.
A cool spherical robot in the show.
Evan, Sam, and a Storm Trooper.
Evan, Sam, and a Storm Trooper.

June 15, 2008, Ft. Mason, San Francisco

San Francisco's skies were the usual gloom. What was not usual, were the guests in the Ft. Mason park: geeks, captivated children, cameramen, Star Wars storm-troopers, and hippies bearing clip-boards. It was the annual RoboGames event. Professors, students, and hobbyists came together in a celebration of their cranial creativity.

Among several groups of events--combat, sumo, soccer, mazes, weight-lifting, and hockey--was our game of choice, RoboMagellan. Consisting of a series of cones placed throughout the park, the course was to be autonomously navigated by a robot using GPS, cameras, and any other sensors that could be conjured up. The winner would be the robot that could reach the final cone the fastest, and each cone it touched (in order) before that, would chop time off the total.

Our solution--which relied on a Garmin GPS, a Logitech web-cam, and antennae sensors--was built around a radio-controlled car using my old erector set. At the center, was an OQO1 ultra-mobile PC, running Python on Windows XP. For image processing we used OpenCV. The Achilles Heel turned out to be the combination of the relatively slow processor; emulating x86 for Windows XP, Python, and OpenCV; the webcam driver; and the image processing. Because the processor was too busy with the web-cam driver and image processing, it could not devote the time required for pumping our servo loop.

The effect was that the robot would sit idle until the processor could finally pump the servos. Then it would know (based upon speed sensors) that it needed more power, so it would jolt the motor, causing it to lurch. When the robot was stuck in tall grass, this jolt was not enough to move it, but instead ended up burning out the motor. This lurching could have been fixed with a Servo-Buddy, which continuously provides a signal to the servos, but we unfortunately did not get one in time for this competition. Although, had the processor been able to natively support x86 and not need all the processing in the web-cam driver, I think we would have been fine. It would still lurch slightly, but would carry enough momentum to get through the tall grass.

In fact, for the 2nd and 3rd trials, we disabled the camera and image processing altogether and were able to keep the robot moving. It moved well enough to chase down an angry bulldog and since it was my turn to hold the kill switch, it pulled me through a tight spot under a tree, forcing me into a speed-crawl to keep up.

Since at that point, we could only rely on GPS, our precision was limited to the accuracy of the GPS device, which was a few yards. Once we had reached within that few yards of one or two of the cones we were satisfied and patted our robot's head and let its burnt, smoking engine cool.

YouTube Clip (Broken)

Our first run. It didn't run well this time, due to the image processing overhead.

YouTube Clip (Broken)

Our second and best run! We got the robot within a few yeards of the cone! In the middle of the run, this was where RedDwarf ran into the bulldog.

Evan was holding the wires to the kill switch, and he had to crawl under a small tree since he was following the robot! Go Evan! Go!


Our software dependencies.


Team Lead / Hardware: Allister Lundberg

Software / Wiki: Evan Andersen

Personal tools