How important is Linux?

[Kevin Watson]

Originally Posted by Tom Bottiglieri

The wonderful thing about using a RTOS is you can effectively cut the programming down to writing a simple script. (Stored on an SD card, USB stick, SCP/SFTP'd in, etc.)

I think it will be a big step to get over the "that seems too hard" barrier. We are used to writing C code to run on an embedded controller in real time... not an easy task for a high school freshman! But, there are tools to help facilitate in this process (default code, EasyC). These tools make it possible for people with absolutely no knowledge of C to program a robot to do basic functions with a very shallow learning curve. There is no reason why using an OS on the robot should be any different. If anything, it makes it easier because we can interface standards that most people are familiar with, instead of trying to teach them something entirely foreign.

I think Tom has nailed it. Running a RTOS doesn't necessarily make it harder to program your 'bot as you would be able to easilly abstract the complexity of the underlying hardware and software to whatever degree desired.

I ask this question because it's been announced that we'll be getting a new controller in 2009 and I'm just curious what teams will want running on that controller in the hope that FIRST and their corporate sponsors will listen to us, the FRC community when these decisions are made. With this in mind, I strongly urge folks to take the time to fill out the RC survey.

-Kevin

[SuperBK]

What about Windows Embedded instead of Linux? That would give students some exposure to something that they might be come across in industry. RTOS'S like QNX aren't free either.
Brian

[Daniel_LaFleur]

Kevin,

My biggest concern for running a RTOS on the robot controller is the overhead and resources the RTOS will take. I wouldn't want to compromise the prossessing power just for the convienience of some available services in an RTOS.

[Qbranch]

Originally Posted by SuperBK

What about Windows Embedded instead of Linux? That would give students some exposure to something that they might be come across in industry. RTOS'S like QNX aren't free either.
Brian

I saw windows embedded at the Freescale Technology Forum 2007 this summer. It was pretty cool, but they had it running on i.MX processors... pretty fast. I think it might run on some of Microchip's big dsPIC24 processors but i'm not sure.

However, the cool thing about Windows XPe/CE is that they run the .NET MicroFramework .... which can run code from Microsoft Robotics Studio. For those of you who havent played with Robotics Studio it has a pretty neat system where you can target your code to an on-computer physical simulation of your robot then turn right around and target it to your MicroFramework compatible controller. It includes drivers for heavy hardware (like Sick scanners n such)....

Really after writing this i think this is way too overkill for doing FIRST robotics. The controller's cost would get way out of hand to have enough hardware to run XPe... plus I think the simplicity and close proximity to the hardware that MCC provieds is a great experience for FIRST programmers.

-q

[Kevin Sevcik]

I think it's assumed that if we're running an RTOS on the controller, then we'll have more than enough processing power left over to do many interesting things. Honestly, once you've made that decision, it's rather easy to get enough power to do whatever you want. Freescale has some 32-bit automotive processors (MAC7101) that run 50+MHz and could support 16 PWM channels on chip with no interrupts along with A/D, 2 SPI channels and a host of other nice features. Actually, after looking over that random processor I hunted up at Freescale, I'm almost drooling over the sorts of things that could be done with it. The real problem is just the development time to get something like that up and running. And even more importantly, making absolutely sure the users can't shoot themselves in the foot and get the controller into a completely unrecoverable state via bad programming. I think the amount of development and debugging necessary for something like this would be the primary hurdle to get over, but I have to say it'd probably make programming a lot easier in the long run.

[Dave Flowerday]

I personally don't see why you'd want Linux on a robot. For those in favor of it, can you please specify in more detail what specifically having Linux would do for you? I suspect many of the reasons (other than the "gee whiz" reasons) are possible with much simpler software.

If all you want is to run multiple tasks with some priority mechanisms, something like FreeRTOS would be much simpler and better. Don't forget that when you make things more complicated (like by adding an OS) you increase the difficulty of debugging. With the current system (which has no in-circuit debug capability), I would really not want to do anything involving multiple concurrent tasks, simply because we don't have good enough facilities to debug it. Debugging a multi-threaded real-time application is very tricky and is really beyond the capabilities of many teams.

[Kevin Sevcik]

Originally Posted by Qbranch

I saw windows embedded at the Freescale Technology Forum 2007 this summer. It was pretty cool, but they had it running on i.MX processors... pretty fast. I think it might run on some of Microchip's big dsPIC24 processors but i'm not sure.

However, the cool thing about Windows XPe/CE is that they run the .NET MicroFramework .... which can run code from Microsoft Robotics Studio. For those of you who havent played with Robotics Studio it has a pretty neat system where you can target your code to an on-computer physical simulation of your robot then turn right around and target it to your MicroFramework compatible controller. It includes drivers for heavy hardware (like Sick scanners n such)....

Really after writing this i think this is way too overkill for doing FIRST robotics. The controller's cost would get way out of hand to have enough hardware to run XPe... plus I think the simplicity and close proximity to the hardware that MCC provieds is a great experience for FIRST programmers.

-q

I'll agree that running embedded windows would probably take too much hardware, but uClinux or some such would be pretty easy and not too expensive. I'm working with a $99 plug-in Freescale module with a 10/100 LAN interface built in for a research project. It's running uClinux with a webserver and some other things, along with some hardware interrupts, timer interrupts, and SPI code, most of which I'm coding straight to the peripherals. An RTOS doesn't force you to abstract away from the hardware, it just gives you the option to do so to make your code cleaner and more maintainable.

[Kevin Watson]

Originally Posted by Daniel_LaFleur

Kevin,

My biggest concern for running a RTOS on the robot controller is the overhead and resources the RTOS will take. I wouldn't want to compromise the prossessing power just for the convienience of some available services in an RTOS.

What if we get a real computer based upon a PPC or x86 for 2009 (yes, maybe I'm dreaming). Are you saying you don't want an off-the-shelf OS and want to write your own code to run on bare metal? Or are you assuming we'll get another microcontroller-based setup?

-Kevin

[ebarker]

Moving from a microcontroller to a computer with an OS certainly has merit.

We just want to make sure that it doesn't take rocket science to interface to the hardware for those that have custom or unique sensors or controls.

If the OS had the i/o support and built in telemetry and safety stuff then things can get real straightforward is all you have to do is drop an app inside.

Ed

[Phalanx]

Being in the corporate business sector where you need to make the trade offs between "get the product out there yesterday" and the "do more with less" or "make it work on our existing systems without upgrading them" and the "Oh BTW the transaction has to be finished in 3 seconds or less" I find myself straddling the fence a little on the subject.

On one since of the fence:
Having a RTOS running on the RC with the necessary and appropriate drivers for various hardware and sensors using standardized API calls for accessing and using said hardware is very much like todays methods of application development and programming. Most of the complex underlying programming of error handling, interrupt handling and so forth are hidden from the developer and the developer really doesn't need to know or care about them.
It certainly does make code development easier and faster. The downside is you tend to get larger code with more overhead that functions less efficiently which in turn requires more RAM, bigger Hard Drives, faster CPU's to get the job done. While this is not always true, it is the case more often than not.


On the other side of the fence:
Not having a RTOS allows the developer to intimately learn the inner workings of the system and hardware they are using. It does take A LOT longer to program and develop applications, but you generally can write more efficient code that will need less hard drive space require less RAM, less CPU cycles. This side of the fence in my opinion provides the students the opportunity to gain a greater depth of knowledge and understanding of computing at both the hardware level and the software level.

So the key question in my mind is which side of fence will the students benefit the most from? In my personal opinion, not having a RTOS would serve well, but I'll be honest and say that my view is slanted for 2 reasons.
1) I was the taught program/develop code in that way myself.
2) Currently one of my professional roles is application and overall system performance across the corporate enterprise. And believe me, the less the programmer understands of the inner workings the tougher my job is.

Just food for thought.

[AdamHeard]

Originally Posted by Qbranch

I saw windows embedded at the Freescale Technology Forum 2007 this summer. It was pretty cool, but they had it running on i.MX processors... pretty fast. I think it might run on some of Microchip's big dsPIC24 processors but i'm not sure.

However, the cool thing about Windows XPe/CE is that they run the .NET MicroFramework .... which can run code from Microsoft Robotics Studio. For those of you who havent played with Robotics Studio it has a pretty neat system where you can target your code to an on-computer physical simulation of your robot then turn right around and target it to your MicroFramework compatible controller. It includes drivers for heavy hardware (like Sick scanners n such)....

Really after writing this i think this is way too overkill for doing FIRST robotics. The controller's cost would get way out of hand to have enough hardware to run XPe... plus I think the simplicity and close proximity to the hardware that MCC provieds is a great experience for FIRST programmers.

-q

Oh Noes!!! you can't possibly like the microsoft product that is trying to take over FIRST!!!

/end sarcasm

Microsoft Robotics studio is actually pretty cool. I've programmed in MpLab a lot and it wasn't necessarily hard, I just didn't like how constrained it was. The MS studio isn't the most open thing out there, but it definitely has the support behind it to make it grow and work.

[Tom Bottiglieri]

After doing some quick research, it would definitely be a better decision for the RC to run a commercial RTOS (I really liked VxWorks and QNX) than an open source implementation of RTLinux. It seems like the commercial options were built from the ground up to run in real time, while the latter is just a way to de-prioritize the linux kernel to keep important threads running in real time.

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

[Kevin Watson]

Originally Posted by Tom Bottiglieri

After doing some quick research, it would definitely be a better decision for the RC to run a commercial RTOS (I really liked VxWorks and QNX) than an open source implementation of RTLinux. It seems like the commercial options were built from the ground up to run in real time, while the latter is just a way to de-prioritize the linux kernel to keep important threads running in real time.

Assuming you don't use any skanky drivers, the 2.6 linux kernel does pretty well in near real-time systems. For hard real-time applications, there is also Monta Vista Linux (mvista.com), which I would prefer to RTLinux.

-Kevin

[Kevin Sevcik]

Here's a thought on the abstraction vs. bare metal programming split. I think it works out exactly like anything else on the robot. For a transmission you can either design your own from the ground up, cookbook one up out of a DeWalt, or buy one from AndyMark. These are sorted by decreasing time and effort and increasing knowledge of the nuts and bolts of the systems. Each of these approaches has its place in the mechanical design of the robot, and I fail to see why they shouldn't all have a place in the programming of the robot. There will be times when bare metal programming is the best or only way to accomplish something, but should we really force every team to build everything from scratch? I think the teams should really have the option of piecing together all three kinds of code as best suits them. Near as I can tell at the moment, the only options are either an entire AndyMark robot (EasyC) or an entire cookbooked and from scratch robot.