DPRG mailing list archives: [DPRG] Processing unit for mobile robot

Wed Apr 23 15:09:55 CDT 2008

On Wed, 2008-04-23 at 13:09 -0500, Randy M. Dumse wrote:
> ed at okerson.com said: Wednesday, April 23, 2008 8:23 AM
> > Today I would probably go with one of the many smaller 
> > processors capable of running Linux, but it could still be 
> > done witn a PC.  My current favorite is the AVR32 processor 
> > from Atmel.  ... Real time processing on 
> > Linux is now easier than ever.
> 
> Hi Ed, there was a big discussion on the PARTS list where Robert
> F. Scheer was prep'ing his Outdoor Challenge Robot, and intended
> to use Linux in a real time mode, and found he couldn't get more
> than (something like) 20 updates a second from his remote micro
> without horrible jitter in the time of the messages arrivale,
> even though he had been sold on the idea of Linux as very real
> time capable, so he abandoned the idea of doing PID on the PC
> and moved it out to the external AVRs (appologies if I got
> details slightly off, if someone was following that more closely
> than I, feel free to make a more accurate report).

Tarzan, the robot in question, has a plane ticket to Dallas and will be
in the DPRG OC May 10.  

The resolution of the real-time Linux thread (yes it did resolve!!) that
Randy refers to was that one of our members, a professional Linux kernel
hacker, gave us a small lesson on how to use the kernel's scheduler and
also how to build posix threads.  He's currently working on a study of
statistical timing "jitter" for serial port/USB reads and usleep() and
stuff like that, which he'll present at our June meeting.  The simple
result was that, if you know the magic incantation, the Linux kernel is
quite happy to grant your program or thread a very high priority, and
this will result in real-time-iness good enough for what I wanted (50 Hz
update loop with accurate time stamping of reads).  Tarzan's core real
time loop executes in an atmega128 to accurately capture encoder
distance vs. time (ie speed) and this provides a convenient interrupt
driven 50Hz timer.  The original problem was the Linux program couldn't
reliably respond within a few ms to the packets from the micro.  That
turned out to be my own noobishness, not any lack on the part of Linux.

> 
> Now my basic opinion is today with a program like LabVIEW I can
> get to 1mS timings on the PC even under windows, but Robert had
> problems, and many suggestions on Linux settings were discussed.
> I didn't follow that part because I have never used Linux, nor
> do I understand the desire to do so.
> 
> So! Maybe you want to expound on Linux a bit, and tell us 1)
> what is the real nature of the realtime limits of Linux and 2)
> Why Linux anyway? 
> 
> For me Linux is just so much interference in my way, preventing
> me from getting the real time stuff I've been able to do for
> years without an operating system in the way nearly impossible
> to get right and under the same control I have with a micro
> without an OS in the way. I recognize I could run some PC
> applications so maybe I could do some vision processing, and
> some networking that would be beyond my experience of doing with
> a micro, but to me, this stuff isn't robotics. It isn't the
> stuff that makes the robot move. So I just don't get the
> excitement about getting Linux on to a processor so it can be in
> my way. What do you suppose I'm missing that you see as so
> desireable?
> 
> Randy

For my part atm, my next robot version will not use a PC onboard.  The
advantages I expected haven't really outweighed the negatives.  So far,
there have been greater problems than I expected to see in the more
fundamental requirements of the robot such as driving through high grass
and evading evil squirrels so there hasn't been much time put into
development of video processing on the PC.  And the more I learn about
image processing, the more I realize one small, low-powered PC isn't
really an adequate vision processor anyway.  I'd rather save the weight
of batteries and superstructure, simplify the power supply and keep all
the code contained in one micro of some sort.  

The development platform and vision processing for the next version will
be offboard though.  Wireless makes it easy to control and experiment
with the robot without hard mounting all the processors to the robot.
This will allow all sorts of flexibility to try various equipment and
code without physically hacking up the robot every time a change is
needed.

And it can still run in events like the DPRG challenge without the big
hump on its back.

- Robert