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

Thu Apr 24 00:43:26 CDT 2008

At 08:54 PM 4/23/2008, Randy M. Dumse wrote:
>ed at okerson.com said: Wednesday, April 23, 2008 5:06 PM
> > http://rt.wiki.kernel.org/index.php/Main_Page
>
>Thanks for the link, I did some reading/scanning. It is
>difficult to get far thought. I don't know if you can appreciate
>it or not, but to an outsider, you can't read a single page
>without running into a dozen acronyms or terse references that
>can't be understood.

Hi Randy and Ed,

So another link for you Randy : http://ecos.sourceware.org/

This is an embeddable real time OS that runs just fine on PC type 
hardware (I've got it running on a VIA ITX Mobo at the moment) 
interrupt latency (interrupt to first line of code executing in the 
interrupt handler) is around 2 - 5uS on the VIA (1ghz processor). I 
don't know if that is typical for all interrupts but its what I see 
with the ethernet driver (easiest to measure).

>Okay, I hear that you want to make use of others code. I know
>there are some vision programs. I know you can make use of
>network codes. Believe me I'm not trying to be facetious, but,
>does useful code for robots exist? Is there OpenPID? OpenNav
>OpenSteering?

Good question, if it does exist its not well collected as far as I can tell.

>Oh, I agree, completely. The subject to me of interest is: OS -
>why? And not OS - which one?

This is the question I wanted to respond to ;-). The answer of OS vs 
no OS comes down to whether or not you are sharing the hardware or 
not. An OS brings you 3 things, two of which are of value to Robots, 
a uniform programming model, resource sharing and allocation, and 
inter-process protection. The question is the software equivalent of 
"specific chip or MPU?"

We've had that latter discussion on this mailing list, at the time it 
came up in the context of using a 555 timer vs using an 8 pin MCU. 
For much of what the 555 does, you can program an 8 pin AVR or PIC to 
do, so why would you use a 555 ? Of course the only reason that this 
question can come up is because the underlying technology has allowed 
us to put a lot of silicon assets into a very small space. While the 
555 hasn't really changed all that much.

So when you ask the question "Why would I use an OS?" the answer 
might be because your program can execute just as quickly, even 
accounting for the overhead of a system call model, as it could 
before when writing "right to the metal" except that as an abstracted 
concept you can easily write a simulator/emulator on a machine where 
you can more conveniently develop the code.  Or your processor has 
gotten so fast you feel its a waste to spend most of its time in a 
"TEST BIT/BNZ $-1" loop, so you need a way of switching between a 
couple of programs running at the same time. You can do it explicitly 
with a sort of yield() library, or you can let an underlying 
abstraction model pick the "right" program to be running right now 
(where you get to define "right")

Another reason might be because the problem you are trying to code up 
has exceeded what will fit comfortably in your brain at one time. If 
you are doing a balancing robot and you've got motor PWM functions 
and IMU integration and goal planning and environment interaction 
Etc. You might find it is more convenient to have a task that runs 
the motors, but it isn't a fire and forget routine you want it to 
continuously measure battery voltage and adapt to the available 
current (which affects parameters to your PID routines).

My experience is that it is easier to come back to a program that 
runs under an OS than it is to try to figure out what all the 
constraints were in a hard coded program image, but I am getting 
older and I cannot rule out that this contributes to a smaller stack 
space in my head.

As for which that question is like saying "which microprocessor" the 
answer is "what do you want to do with it?" If you're writing all 
your own code then something like uC/OS-II (http://www.micrium.com/) 
is pretty small and tight and gives a simple abstraction to write to. 
I'm not a big fan of it because I like better preemption than that 
but next up the food chain might be FreeRTOS 
<http://www.freertos.org/>. The make controller uses that and its 
also pretty simple but not really something that could deal with a 
MMU I don't suspect. For ease of porting because you are using 
someone else's code might be uCLinux ( http://www.uclinux.org/) that 
has a programming model that lets you compile an application easily 
to it, but the tasking model can twist your head. For really hard 
core real time stuff you might use RTEMS (www.rtems.com) which was 
born as an OS for missles (now THAT is a hard real time requirement). 
Its got a lot of structure and some really smart people coding on it 
but since its roots were in ada much of it seems overly heavy weight 
to me. ECOS of course which I mentioned above or Linux as Ed points 
out. FreeBSD / NetBSD / OpenBSD all have good support on the x86 
architecture but only NetBSD really has a credible claim to 
supporting non-x86 completely. (I run NetBSD on my VAX).

So the bottom line is that if you have a piece of code that is 
semantically "common" (the idea of an Open PID library is a good 
example for that) and the OS provided a standardized system call 
interface to motors, then having the OS lets all the investment in 
writing the PID code get re-used on every platform that runs that OS.

--Chuck