How important is Linux?

[Kevin Watson]

There have been many discussions over the years about having Linux as a target operating system on the robot controller and I'm just curious if this is really what teams want, or is it just a few vocal members expressing their desire. What about VxWorks? QNX? Some other RTOS?

-Kevin

[chris31]

To avoid confusion, are you talking about having Linux having am official supported IDE and code loading OR are you talking about the controller running something like uClinux?

[Kevin Watson]

Originally Posted by chris31

To avoid confusion, are you talking about having Linux having am official supported IDE and code loading OR are you talking about the controller running something like uClinux?

Running Linux on the controller, not the development environment.

-Kevin

[stevethetinker]

I would say that Linux on the controller is not important unless the robot controller system can also have disk files, a much wider telemetry link to/from the OI, etc. I suspect using Linux would make the "level playing field" problem worse rather than better. I agree with one of the other posters to this thread - writing Linux drivers is no picnic. The system we come up with needs to be much easier to use than that. Maybe one of the real-time variants of Linux would work. (I'm not familiar with any.)

No doubt there are a number of good RTOS designs that we could borrow from to implement these or similar ideas once we have a processor that can support them.

What we need is a basic RTOS that can provide one background "process" and provide an API that allows the programmer to hook up interrupt handlers. The one background process lets the programmer do compute-intensive tasks like navigation in a process that is not tied to the OI cycle. With the current framework such a process needs to be split into stages with such awkward constructs as switch statements. The worst part is writing the functions so that they can be called from the top each cycle. A background process in a RTOS does not need to be staged, or if coroutines are desired, a simple call to a RTOS function can be made to suspend the current coroutine so that another coroutine can be activated. The first coroutine then picks up at the spot where it left off next time it is activated through the coroutine interface. Coroutines don't require much API support (setjmp and longjmp are almost enough).

One key is that the 26.2 ms OI cycle needs to be driven from an interrupt, and there needs to be more than one priority of interrupts, so that things like gear tooth sensors can interrupt the 26.2 ms OI cycle interrupt (to be counted) and return to it. I think a system like this would help with the level playing field problem by providing support for interrupts (takes most of the arcane mumbo-jumbo out of it, though your new framework does a pretty good job).

Such an RTOS would not be complex (it could probably be written in less than 1000 lines of C code), but supporting it on our current processor would stretch it to the outer limits. I investigated the idea a couple of years ago and while I think it could be done, it is not practical.

[Bigcheese]

This year we are using Linux via a desktop PC modified to fit within the rules. There is almost no latency if you use the programming port to communicate with the RC, and the only code we have on the RC is code to send input updates and receive output updates (only 5 lines of code (and a lookup table (It's dang fast))).

I feel that Linux is very important due to ease of use, support, and no vendor lock in. You can figure out how to do just about anything on Linux with only a good understanding of google, and most of the code you need for anything is already written in just about any language under the sun.

[dcbrown]

and the only code we have on the RC is code to send input updates and receive output updates (only 5 lines of code (and a lookup table (It's dang fast))).

Since there is no code within the user PIC processor - which PCI boards are you using to do data aquisition (analog and digital) on the PC? How expensive were they? Did you find it difficult to write the linux drivers for these boards and for the sonar, gyro, accelerometer, etc. drivers? What was the interrupt latency you measured? Really interested in this last one since latency needs to be down under 20us for things like the GTS sensor. The only unix kernel I know of that has decent real time latency are unix kernels built on top of the MACH OSF/1 microkernel.

[Bigcheese]

Originally Posted by dcbrown

Since there is no code within the user PIC processor - which PCI boards are you using to do data aquisition (analog and digital) on the PC? How expensive were they? Did you find it difficult to write the linux drivers for these boards and for the sonar, gyro, accelerometer, etc. drivers? What was the interrupt latency you measured? Really interested in this last one since latency needs to be down under 20us for things like the GTS sensor. The only unix kernel I know of that has decent real time latency are unix kernels built on top of the MACH OSF/1 microkernel.

None. $0. No. 0μs.

Hope that answers your questions.

And then to explain. We do, as I said before, have a minimal amount of code on the PIC processor to forward input/output data between the robot controller and the Linux machine.

[dcbrown]

Hope that answers your questions

Not really. You stated

only 5 lines of code

and I'm wondering if that is true or if you are using the PIC to do all the robot h/w interfacing and only using linux for processing of that data.

It *is* possible to have five lines of code if the robot isn't using ANY controller digital inputs or outputs and has no pnuematics or sensors of any kind attached to the robot controller. In this case you can just pass the data packet from the OI to the linux box and vice versa. If that is the case then such a setup isn't useful for most teams.

[Cuog]

I think he has 5 lines of code that loop through the lookup table and send the data stored there back and forth. That would be pretty low line count and also give useful access to controls.

[ebarker]

Kevin,

That is a great question. No doubt there are some advocates pushing linux because it is linux.

I think the better question is what is the best platform for this target audience?

For many users the code is input->process->output. The input being external I/O or the telemetry stream and vicey versey. That is even true for the camera and such. What I trying to say is the most users don't deal with interrupt driven routines or 'hard real time' requirements.

Momentarily ignoring things like interrupt driven pulse counters the user could write a plain old gnu app that interfaced to the external world via a kernel drive (supplied).

One downside is the development environment just got a whole lot bigger (relative to MPLab) plus it is more difficult for this level of user to hook custom hardware to the software or to configure some I/O pins.

I'm not sure that chasing an RTOS for this audience is a good idea. The linux idea has plus and minus points. I'm not too sure the plus'es outweigh the minuses primarily because of what it takes to get to the hardware.

I write linux kernel drivers to do I/O to the world and it ain't trivial. (Kevin already knows this isn't trivial because he is Kevin).

What say you world out there ?

[MrForbes]

Originally Posted by ebarker

No doubt there are some advocates pushing linux because it is linux.

either that, or because it is NOT (insert unfavorite OS name here).

[Qbranch]

I'm an Assembly/C guy... i feel like you have enough problems debugging your own code let alone the 10's or 100's of people's code you add in to the mix with an RTOS...

Plus, the FIRST controller as it sits doesn't have enough MIPS and memory to run much of an RTOS along with running the user's tasks at the same time... it's more than enough for Assembly/C/EasyC people to run wild but I'm not sure about a full blown RTOS...

Just my 0.81 Rupees...

-q

[Rickertsen2]

Does an OS necessarily have to complicate things? I would think some example/default code could be provided that runs in a single thread, follows the input->process->output paradigm and in general behaves in much the same way as the current system. If more advanced users want to explore the extended feature set an RTOS has to offer they may do so. If you look at a PC running windows it is extremely complex, but you can still write a "hello world" program without understanding the many levels of abstraction below you.

[eugenebrooks]

There is a small vocal crowd that would like linux as a platform
do develop their RC program, and other things, but running an
OS on the robot controller itself is a bad idea.

Having at least a 16 bit processor for the RC, with a clean
implementation for the I-O, and most importantly, interrupts,
would be great. One does not really need an OS running
on the RC to get these things.

The 8 bit addressing, the interrupt functionality that has suffered
from gremlins since the 8722 was introduced and the arcane
violations of the ANSI C standard to obtain more efficient
execution on an 8 bit processor would most certainly be things to
leave behind.

Eugene

[jtdowney]

Outside of the technical details of actually implementing Linux on the RC the amount of very good and free development tools provided by GNU would be an incentive.

In addition the community and spirit of open source is highly compatible with FIRST and gracious professionalism.