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