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

Wed Apr 23 17:05:59 CDT 2008

> 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).

I don't know the particulars of his problem.  But I can imagine some
scenarios that could cause this kind of problem.  Potentially a poor
choice of communications that was not capable of the throughput he needed.
 If he was trying to use an RS232 link for high throughput, the buffers on
the UART chip can cause all kinds of problems if not handled carefully.

> 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?

According to the FAQ on the Real-Time Linux Wiki:

http://rt.wiki.kernel.org/index.php/Main_Page

  "On 2006-2007 high-end AMD and Intell CPU's systems have been deployed
with 10-30us scheduler and interrupt latencies; on other platforms, your
mileage will definitely vary."

Pretty much everything you need to know about real-time processing on
Linux can be found on that page.

> 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?

If all there is to robotics is to make the robot move, then we are
finished and can all go play golf now.  But I believe there is much more
to it than just making it move.  There are many non-realtime things left
to be done.  All of the tasks that get accomplished by the motion.  After
all, humans are inherently non-realtime, but we do much more than just
move around.

What I see as so desireable is to not have to create everything from
scratch myself.  By using an Operating System, many people can work to the
same API and build parts of the system.  But by using an open source
operating system, you still get all the source code so you can tweak it if
you so desire.

I choose Linux because of consistency.  I can use the same tools
regardless of what platform I am developing for, and my code compiles and
runs on several platforms with consistent interfaces and API's.  And this
is all possible without spending large sums on development tools.

Choice of Operating Systems, be it Linux, Windows, Mac, etc, or none at
all, is a personal choice, and discussions about it tend to degrade into
flame wars, so let's keep this one calm.

Ed Okerson