Lessons Learned at the DPRG Outdoor Challenge 5/10/2008
I flew to Dallas for this wonderful event, organized by David Anderson, and not only had a great time but also learned a thing or two. So, let's write some of this stuff down before it's forgotten. Here is most of the text verbatim from a posting I made to the DPRG list...
Air travel - Pelican traveling case and
custom styrofoam packing made it possible to bring Tarzan as checked
luggage. The thing was huge and
heavy (54lbs loaded), but with
built-in wheels it was not so bad at airport and hotel. Don't ask
how much the oversize/overweight charges
were. No
breakage! TSA inspection is a given. Styrofoam was 3" thick
insulation from a building supply and it was cut by hot knife from the
hobby
store and glued with low temp hot glue. Although this system
works fine, it would be far cheaper and less hassle with a
smaller/lighter
robot to begin with. From now on, lighter and smaller will be
important to me, since I intend to travel often with robots.
Verdict on air travel - not much choice so live with it.
R/C
car conversion based on Traxxas Emaxx with most parts replaced by
aftermarket versions - It all works and didn't require a machine shop to
build
and took a day or two to put together. It met my basic goals for
all-terrain, especially with good ground clearance and good traction on
thick
wet grassy hills. The suspension works quite well and contributes
both to "wheels on the ground" traction and cushion ride for the
electronics.
Looks pretty good. The chassis plate/deck was just large enough
for the electronics without needing a mezzanine. Downsides:
Turns
like an oil supertanker, made worse due to the stretched
wheelbase. Expensive. Adding optical encoders to the
drivetrain is
always problematic on r/c conversions. One of my
top priorities was to have passive wheel encoding (that is wheels that
aren't driven don't
slip much and so are more accurate than driven
wheels). I chose to disconnect the front wheel driveshaft and use
it to turn a single
optical shaft encoder. This seems to be
quite accurate and reliable for measuring distance, but of course it
trades off the 4WD advantage.
Others would probably find a way to
attach an encoder to the motor or transmission or tap into a built-in
encoder on the motor if possible. I
may do this also, but be
warned that there is a lot of slop (an inch?) in the drivetrain and
this will likely accumulate substantial error
during the jack-turn
maneuvers. This platform will not climb stairs. It's too
heavy and large to cart easily up and down the stairs from my
basement
lair. Overall verdict - not recommended. The 3-wheel
diff-drive configurations can be easier to build, are more maneuverable,
nearly
as all-terrain if well designed, much cheaper, simpler and usually much
uglier. But I'll trade function for beauty anytime. There
are
also ways of accomplishing both at once using more than 3 wheels and
that's where I'll be headed next. Verdict on r/c conversions -
thumbs
down.
Programming in C with the GCC compiler and GDB
debugger just works. Eclipse (a full-featured IDE) was a great
discovery for me. This was
for the Linux side of the control
system. I'm not a strong programmer, and have only 1 year's
experience now with C, and don't exactly enjoy
the C experience, but
it looks like that's what I'll stick with for the basic reactive
behavior robot core system and things like vision
processing and
mapping. But I'll probably ditch Linux and go to some type of
RTOS and there's no question - no more x86 PC's on robots for me
in the near future, not unless the robot scales up to a full size car. Verdict on C - unenthusiastic thumbs up.
AVR
Studio and JTAGICE MkIII greatly helped with Atmega128
programming and debugging. This was new to me. Previously
just used avrdude and gcc. I'll never program another micro
without the appropriate debugger and IDE. Verdict on AVR Studio
and JTAGICE MkIII - thumbs up.
Microstrain IMU/Compass - this
$1500 sensor has been surprisingly easy to use, given that it is far
from simple inside and is a serially
interfaced device; it has
required almost no fuss except for the hassle of the tall mast.
On the other hand, it is mandatory to do the hard
iron calibration,
which I haven't done yet on Tarzan. Also, the compass just won't
work inside buildings with steel components. It probably
won't
work well on steel robots. Conceivably, it might have trouble
with the re-bar grid under a well-made concrete sidewalk or driveway.
I'm
not sure whether asphalt parking lots ever have iron underneath.
On the other hand, I was very impressed with the robots that
didn't
bother with a compass of any kind and yet were still accurate
in their angular headings. Several of these robots, including
jBot, can easily
get close to 1% accuracy on the simple courses of
challenge 1-3 with heading derived from differential encoders
alone! Bottom line - in
terms of priority in the development
of the navigating robot, the IMU/compass comes AFTER you have tuned
differential encoders to give
heading accuracy of 1.5deg or
so. That's what I calculate from jBot's demo's and Teeter
Totter's trials. Verdict on Microstrain - thumbs up.
x86
PC for "high level program" - I tried 3 different PC's during the
development of Tarzan, a Core 2 Duo mini-ITX (25W), a VIA Artigo
pico-ITX
(15W) and a fitPC (5W), which is what was used in Dallas. This
was a holdover concept from my first robot project, Conan, last year,
which
was designed for RoboMagellan and the PC was intended for "vision
processing". I won't do this again on another navigator for
several
reasons: high power drain, unnecessarily complex
interactions between the Linux OS and real time serial communication
tasks, size and weight, and needless expense. Vision can be
accomplished with "smart cameras" such as CMUCAM or AVRCAM or the
Blackfin camera board from Surveyor and more advanced vision can be
accomplished in FPGA-augmented dedicated ARM processors at much lower
power drain. Verdict on PC - thumbs down.
Ackermann
steering - not maneuverable enough to easily get out of tight
spots. Some type of rack and pinion servo setup might be more
appropriate
for actuator if you really want front wheel steering. Or maybe a
servo on each of the 2 front wheels or all 4 wheels, but this is
getting
needlessly heavy imo. Just go differential and drive the wheels
as directly as possible. Verdict on Ackermann - thumbs down.
Serial
interfacing between the Atmega128 hardware interface and the Linux PC
was very difficult in this project. It still isn't reliable
enough.
The previous project, Conan, did not have this problem and I don't know
what the difference is, although considerable time and effort
was
put into it including careful oscilloscope timing analysis.
Bottom line - future serial interfacing will use SPI or CAN or RS485 and
error-detection/correction
methods where appropriate. And I suspect also that not using a
high-level OS (such as Linux or Windows) could
improve the reliability of interrupt-driven serial interfacing.
Another
lesson about serial interfacing was that 500kbaud is no more
error-prone than 38400 and it greatly simplified the program
architecture
on the master controller side. With slower baud rate, you are
forced into parallel threads (and interprocess communications) to
service
the various producers. For the simple types of sensors we use on
our robots, near-megabaud makes it a no-brainer to simply poll each
producer in the main update loop. You would have to be using update rates beyond 1000Hz to need parallel threads.
Boot-up
time is important. In my case, the embedded PC running Linux
boots up in a bit over a minute, but it needs a PC on the other end of a
wireless
connection to set the course and run the script to start the control
program. The particular Fujitsu UMPC that I'm using takes
literally
forever to boot up Ubuntu and this is a major limitation. If you
try hibernating to save power, then you have a serious issue of
re-establishing
WLAN communications on power-up. I think the ideal remote
controller/monitor might be something like a Nokia 800 using
Bluetooth
for the temporary connection, but not if you have to do any real
programming or editing of files. Verdict on current boot time -
thumbs down.
Logging
is exceedingly important. Tuning and debugging are so much more
practical when you record the state of most of the variables for each
update cycle or at least a sample every so many cycles. The
applications of logging range from tuning PID parameters to verifying
sonar
readings to calibrating compass headings and so forth. When
Tarzan does the unexpected, you need to know what was going on in that
tin head. Verdict on current logging - thumbs up.
User
interface - Most serious builders decide to put a small LCD display and
a few buttons on the robot for rudimentary monitoring and tweaking.
I've been using the easy extension that Linux makes possible with
ssh and nfs. This is simple and nearly ideal but since I expect
to give up the Linux box on the robot, I expect to substitute a
purpose-coded user interface on the remote laptop or Nokia 800 or
whatever. For serious debugging and programming you need the
remote anyway, so why go to the extra trouble of designing a UI on
the robot too? Anyway, that's how I feel atm.
Reset button
- Some of you may have seen the pushbutton on top of the mast, by the
Microstrain. This is a very useful button and I'll keep
doing
something like that. It does double duty as an emergency stop
button if the robot is moving. Verdict - thumbs up.
Remote
enable - Nobody probably noticed I was wearing a keyfob on a chord
around my neck. This is basically a garage door remote that
wirelessly
throws an on/off signal in a box on the robot wired to the AVR
controller. These transmitter/receiver pairs can be found on many
of
the electronic supply catalogs for $10 or so and are easy to hack into
convenient remote enable controls. Verdict - thumbs up.
Encoder
- Tarzan uses a single US Digital ball bearing shaft encoder coupled to
the front differential gearbox. The A and B channels of the
encoder
are wired to interrupt pins of the AVR. One wheel revolution
produces 6000 interrupt-driven counts. During the challenge
events, the
top speed was about 1.5 meters/sec or about 2 revs/sec
or 12000 counts/sec. Here are my interrupt service routines for
the 2 interrupt
pins. This is all it takes to figure out how
far (in encoder counts) the robot has moved in the sample period, which
is 20ms for Tarzan.
Verdict - thumbs up.
/****** quadrature ENCODER interrupt service routines *****
- Interrupt occurs on rising and falling edge
- Ch A is PortE.5, Ch B is PortE.4
- Signed encoder counts directional clicks per sample period*/;
ISR (INT4_vect) {
if(tst(PINE,4)==tst(PINE,5)) encoder--; else encoder++;}
ISR (INT5_vect) {
if(tst(PINE,4)==tst(PINE,5)) encoder++; else encoder--;}
Motor
- I wanted to investigate brushless DC motors so a brief bit of
research led me to using a Novak Goat Crawler system that is meant for
r/c
rock crawlers. Coupled with the lowest tranny gear ratio
possible, this setup seems to be very smooth, power efficient and
powerful. I
don't know the top speed yet but expect it's
around 20 miles/hr, which is of course way too fast. Although the
motor is listed at 120W, I'd be
surprised if it uses more than 5W on
flat pavement. On the negative side, there's no technical
documentation for the motor or it's ESC, the
electronic speed
control. It's quite easy to provide a servo PWM signal for the
ESC and this is a convenient serial interface. The fact that
there's
no feedback from the motor though is a big negative. I hate
knowing that there's some speed control processing going on inside the
ESC
but it's not documented. It's a true black box. In the end,
because my initial playing around with it revealed that the robot
coasted
and didn't reduce speed when power setting was reduced, I just found a
convenient single PWM setting for forward and a different one
for
reverse and just used those constants. So Tarzan had one forward
setting, one reverse setting and stop. I really do like BLDC
motors but
don't like r/c ESC controllers. From now on I'll
use brushed motors with simple H-bridge drivers that respond well to
PID control until I
find a convenient way to interface BLDC motors. Sure, you can do it now, eg
http://www.luminarymicro.com/products/rdk_bldc.html
but it's a whole project unto itself. Verdict - thumbs down.
Subsumption
- Tarzan's behavior was based on the principles of reactive behavior
that dpa has written much about. There's a lot out there on
this
topic and I found this book especially helpful - "Robot Programming A
Practical Guide to Behavior-Based Robotics" by Joseph L. Jones.
The obstacle avoidance behavior needed for challenge #3 was one of 4
behaviors coded for Tarzan and it had never been tested before the
event,
due to running out of time. The fact that it worked as you all
saw had nothing to do with any skill or luck really, just the fact that
this behavioral approach is really simple enough to work out of the box. Verdict on subsumption - thumbs up.
Well, that kinda sums it up. I hope the boring analysis doesn't affect anyone's fond memory of a fun event.
- Robert