|
[DPRG] Tarzan's lessons learned at the DPRG Outdoor Challenge
Subject: [DPRG] Tarzan's lessons learned at the DPRG Outdoor Challenge
From: Robert F. Scheer
rfscheer at speakeasy.net
Date: Wed May 14 23:53:39 CDT 2008
Most of this is or soon will be posted on Tarzan's website at:
http://www.scheerstuff.net/tarzan
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
Verdict on logging - thumbs up!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
More information about the DPRG mailing list
|
