Page 183 - Introduction to AI Robotics

166
5 Designing a Reactive Implementation
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 lim-
itations on what hardware and sensors can be added, or with relatively in-
expensive kit type of platform where weight and power restrictions may im-
pact 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 Ro-
botics, 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 foot-
print 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 en-
coders 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.