Case Study: Unmanned Ground Robotics Competition

Case Study: Unmanned Ground Robotics Competition

This case study is based on the approach taken by the Colorado School of
Mines team to the 1994 Unmanned Ground Robotics Competition.98 The objective
of the competition was to have a small unmanned vehicle (no larger
than a golf cart) autonomously navigate around an outdoor course of white
lines painted on grass. The CSM entry won first place and a $5,000 prize.
Each design step is first presented in boldface and discussed. What was actually
done by the CSM team follows in italics. This case study illustrates
the effective use of only a few behaviors, incrementally developed, and the
use of affordances combined with an understanding of the ecological niche.
It also highlights how even a simple design may take many iterations to be
workable.
Step 1: Describe the task. The purpose of this step is to specify what the
robot has to do to be successful.
The task was for the robot vehicle to follow a path with hair pin turns, stationary
obstacles in the path, and a sand pit. The robot which went the furthest without going
completely out of bounds was the winner, unless two or more robots went the same
distance or completed the course, then the winner was whoever went the fastest. The
maximum speed was 5 mph. If the robot went partially out of bounds (one wheel or
a portion of a tread remained inside), a distance penalty was subtracted. If the robot
hit an obstacle enough to move it, another distance penalty was levied. Therefore,

the competition favored an entry which could complete the course without accruing
any penalties over a faster entry which might drift over a boundary line or bump an
obstacle. Entrants were given three runs on one day and two days to prepare and
test on a track near the course; the times of the heats were determined by lottery.
Step 2: Describe the robot. The purpose of this step is to determine the
basic physical abilities of the robot and any limitations. In theory, it might
be expected that the designer would have control over the robot itself, what
it could do, what sensors it carries, etc. In practice, most roboticists work
with either a commercially available research platform which may have limitations
on what hardware and sensors can be added, or with relatively inexpensive
kit type of platform where weight and power restrictions may impact
what it can reasonably do. Therefore, the designer is usually handed
some fixed constraints on the robot platform which will impact the design.
In this case, the competition stated that the robot vehicle had to have a footprint
of at least 3ft by 3.5ft but no bigger than a golf cart. Furthermore, the robot had to
carry its own power supply and do all computing on-board (no radio communication
with an off-board processor was permitted), plus carry a 20 pound payload.
The CSM team was donated the materials for a robot platform by Omnitech Robotics,
Inc. Fig. 5.4 shows Omnibot. The vehicle base was a Power Wheels battery
powered children’s jeep purchased from a toy store. The base met the minimum footprint
exactly. It used Ackerman (car-like) steering, with a drive motor powering the
wheels in the rear and a steering motor in the front. The vehicle had a 22 turning
angle. The on-board computing was handled by a 33MHz 486 PC using Omnitech
CANAMP motor controllers. The sensor suite consisted of three devices: shaft encoders
on the drive and steer motors for dead reckoning, a video camcorder mounted
on a mast near the center of the vehicle and a panning sonar mounted below the
grille on the front. The output from the video camcorder was digitized by a black and
white framegrabber. The sonar was a Polaroid lab grade ultrasonic transducer. The
panning device could sweep 180. All coding was done in C++.
Due to the motors and gearing, Omnibot could only go 1.5 mph. This limitation
meant that it could only win if it went farther with less penalty points than any
other entry. It also meant that the steering had to have at least a 150ms update rate
or the robot could veer out of bounds without ever perceiving it was going off course.
The black and white framegrabber eliminated the use of color. Worse yet, the update
rate of the framegrabber was almost 150ms; any vision processing algorithm would
have to be very fast or else the robot would be moving faster than it could react. The
reflections from uneven grass reduced the standard range of the sonar from 25.5 ft to
about 10 ft.