[Mark Pierce]

I like the closeness to the hardware of the current non-OS setup. The main input,process,output loop, idle task, and some interrupt processing is able to handle what most teams want to do. Our current default program doesn't isolate the low levels of the system well enough and confuses many first time users but that can be improved. A more capable processor, better access to hardware, better communication schemes, more reliable wiring methods are much more important to me than an operating system.

I do see how a simple RTOS would help. It could isolate the various layers of software and make life easier for the majority of users. It could provide decent timer functions and separate tasks for things like serial port drivers, etc. However, even the most simple OSes can have a steep learning curve and can run into difficult to debug issues like stack overflow and resource contention. I've seen this even with experienced software engineers using a commercial OSEK compliant operating system. If we go to an OS, a well documented system with decent training materials is a must.

I suspect that many of the Linux fans might be disappointed to find that using a version of linux suitable for a robot controller will not feel much like the Linux they use on their desktop computers. It would be nice if the programming tools are available on multiple OSes, but running linux on the controller is overkill in my opinion.

Products like Microsoft XPe/CE and others concern me because the tools often are extremely bloated and difficult to load on the hand-me down laptops many of our teams use. Even worse is attempting to install on multiple computers on a secured, locked down, five year old school network.