How important is Linux?

[lynca]

To get more people involved with programming robots from their personal computer , FIRST must have a robot simulator. Microsoft Robotics Studio or Player/Stage are easy to interface if you have a x86 controller for a robot (or another commonly used micro-architecture). I think teams should have the option to include an RTOS controller. The development can actually start as a plug-in to the existing IFI Robot Controller. AdamBots FRC#245 has put together a great guide to integrating a Co-processor to your FIRST robot.

[artdutra04]

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

// Shudders at thought of using .NET Framework...

While the .NET Framework would be a nice solution, as you said it would be overkill for the task at hand. And what I think is more important, the .NET Framework is only available for Windows XP, 2003, and Vista. All the school computers in Team 228's high school still run Windows 2000 Professional; our team owns three iMacs and one desktop PC running XP. And it's not uncommon to see Ubuntu running on our programmers' laptops.

The ideal new control system would be one which is programmable from any of these operating systems, especially since the number of people using Linux and Mac OS X has only been growing. (If MSRS was cross-platform compatible, then I'd support it.)

[AndrewN]

I personally want Linux (old UNIX hacker) as a development environment (GNUtools mainly) but as the system running on the robot - no.

If you had a small well documented RTOS running on the RC that'd be great - as long as we can learn and understand it all in the six weeks. That's the main barrier - new programmers with no prior experience have to be able to pick up the language/OS, understand the RC, learn how to modify it etc.

The default program goes a long way to making the current RC easy to work with but be very careful about increasing the complexity. There's no guarantee that people from last year are on this years team.

[AndrewN]

Making a coprocessor running Linux easier to integrate would be a bonus for those teams that want to go that way.

[FourPenguins]

Everything I've ever heard in programming advice is "don't start with .NET." I did start with .NET (thanks to my high school for that one), and the advice is right.
While .NET is a valuable tool for adhoc programming, particularly by non-programmers, it's a sledge hammer where you often need a chisel. Rather than being tailored to what you need, .NET simply gives you everything you might need. Not only is this resource intensive for even the simplest applications, it also leaves you clueless about some of the things that .NET puts in the back-end.
The result is easy to learn, but leaves you without basic coding practices that you'll need later in life.
(This post is mostly about VB.NET. I know that some of it also applies to C#.NET. I don't know about VC.NET, ASP.NET, or any other .NET language, but I think my point holds for .NET in general.)

That said, I know how much our programmers have to know just to write an autonomous mode (their voodoo amazes me), and it may be time for an easier platform. The real question is whether linux would even be easier. Most of the students with linux experience have desktop linux experience. The build of linux that they would find on a FIRST controller would be a whole different world, and they might find that just as difficult to work with as they find the current microcontroller, but as linux is a more complex system, there would be even more opportunity to get lost in it.

[Tom Bottiglieri]

I'm still hard pressed to see how utilizing a RTOS increases complexity in programming. With multiple layers of abstraction, we can create a system that makes it extremely easy for novice programmers to get their bot up and running. In addition this allows more experienced developers to innovate beyond anything we could accomplish now, all without slow hardware interfaces.

[Alan Anderson]

Originally Posted by FourPenguins

...I know how much our programmers have to know just to write an autonomous mode (their voodoo amazes me), and it may be time for an easier platform.

I think the existing "platform" could be made a whole lot easier simply by changing the architecture of the default code. There's a bit of baggage still hanging around from the pre-2004 PBASIC days, and the division of code into separate "user" and "user_fast" files is a little ragged. It can be reworked to do exactly the same thing but be separated into smaller functional chunks, making it less intimidating and more approachable for the beginning user.

Rationalizing the interrupt service code, and incorporating some of Kevin Watson's contributions (interrupt-driven A/D conversions, for example) could make it even easier.

The past couple of years, we've taken the default code's "user" files apart and put them back together in a slightly different shape. The architectural philosophy of putting separate functionality in separate places, including keeping input and output processes detached from each other, seems to work very well. To bring this back to Ed's comment, having that detachment makes doing autonomous programming relatively simple.

[Astronouth7303]

Ignoring the whole "which RTOS?" discussion, here's my $.02.

The current generation of controllers just don't have a prayer of running an RTOS. Period. No easy multi-threading, inefficient indirect referencing, and a collection of other architecture issues make it pretty much impossible.

One of the issues of using any RTOS is the complexity of developing code for a new device. While I have no experience with any RTOS, I know that if you miscode a kernel module (or w/e the term is for the RTOS of your choice), the debugging could be a real hassle.

Even if you don't write code at a kernel level, you can still have issues with threading that just don't appear in current code.

At this time, FIRST robots do not (generally) meet complexity requirements to justify an RTOS.

[Kevin Watson]

Originally Posted by Astronouth7303

The current generation of controllers just don't have a prayer of running an RTOS. Period. No easy multi-threading, inefficient indirect referencing, and a collection of other architecture issues make it pretty much impossible.

We aren't discussing the current controller.

Originally Posted by Astronouth7303

One of the issues of using any RTOS is the complexity of developing code for a new device. While I have no experience with any RTOS, I know that if you miscode a kernel module (or w/e the term is for the RTOS of your choice), the debugging could be a real hassle.

No one is expecting teams to code at the kernel level.

Originally Posted by Astronouth7303

Even if you don't write code at a kernel level, you can still have issues with threading that just don't appear in current code.

Who said teams will be forced to write multi-threaded apps, or even know what a thread is?

Originally Posted by Astronouth7303

At this time, FIRST robots do not (generally) meet complexity requirements to justify an RTOS.

*sigh* I could write volumes about this one sentence, but I have other things to do...

-Kevin

[Mark Pierce]

Originally Posted by Alan Anderson

I think the existing "platform" could be made a whole lot easier simply by changing the architecture of the default code. ... The architectural philosophy of putting separate functionality in separate places, including keeping input and output processes detached from each other, seems to work very well.

I agree with this post entirely. Our team has done the same thing for the past few years. It's been frustrating to do some of this because of many quirks in the system, but it has resulted in a much easier program to work with. We'll be cleaning up last years code this fall, pulling out all the machine specific stuff as a baseline for next year. If we can find the time I hope to post the results as an alternative to the default code for teams to start from in 2008.

[AdamHeard]

Originally Posted by Kevin Watson

*sigh* I could write volumes about this one sentence, but I have other thigs to do...

-Kevin

I gotta agree with you Kevin...

I think many teams will expand their programming to fill the capabilities of the new system, whatever they may be.

Also, I think we should all assume (as Kevin stated) that even with a RTOS running, teams have the option of coding in a very simple fashion without having to deal with the OS at all.

[DonRotolo]

Before I start: I'm not well-qualified to comment. But that never stopped me.

Originally Posted by Dave Flowerday

(other than the "gee whiz" reasons

Originally Posted by Mark Pierce

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.

Originally Posted by Astronouth7303

At this time, FIRST robots do not (generally) meet complexity requirements to justify an RTOS.

Originally Posted by AdamHeard

I think many teams will expand their programming to fill the capabilities of the new system, whatever they may be.

I apologize for the many quotes, but to me they tell a story.

All of the HS kids I met who demanded Linux for their devel system could not really give a good reason, other than "it's not MS" (Dave's point kinda). Arguments of stability or 'openness' don't fly with me. So, Linux as RTOS in the RC wouldn't make a lot of sense for these folks, as it would look foreign (Mark's point).

The latter points are right on - FIRST robots are not sophisticated partly because the teams program to the current RCs capabilities. Increase capacity and you will see more sophisticated robots. So, the more power the better, IMHO.

On the other hand, if we consider a FIRST robot a learning tool, I would rather see lower-level programming than higher-level. But, considering the range of capabilities out there, Easy C is pretty high level (or can be if you let it). And, it is needed.

Conclusion: An RTOS might be great, it does not have to be Linux, the dev tools are what carry the greatest weight for me.

Don

PS:

Originally Posted by lynca

To get more people involved with programming robots from their personal computer , FIRST must have a robot simulator.

Now THAT would be worthwhile, but that's a topic for a new thread

[Gdeaver]

I started another thread - chicken or the egg - in the control section. Discussing a software programming environment with out knowing some details about the hardware design to me makes no sense. If First would give us a hint at the architecture they are considering, then we could go around and around discussing the advantages and disadvantages of every software platform discussed in this thread. With out some hardware details this thread can not lead to any meaningful discussion. First seams to intend to keep the new control system secret. When it is released we can revisit this thread and comment on they should have used Linux, Rtos would have been perfect, why didn't they use xyz system and on and on. Unless First opens up how can we debate the software. There are allot of smart people on this forum that could make meaningful comments on the platform direction. Don't think it's going to happen. Come on FIRST open up a little.

[Tom Bottiglieri]

Originally Posted by Gdeaver

I started another thread - chicken or the egg - in the control section. Discussing a software programming environment with out knowing some details about the hardware design to me makes no sense. If First would give us a hint at the architecture they are considering, then we could go around and around discussing the advantages and disadvantages of every software platform discussed in this thread. With out some hardware details this thread can not lead to any meaningful discussion. First seams to intend to keep the new control system secret. When it is released we can revisit this thread and comment on they should have used Linux, Rtos would have been perfect, why didn't they use xyz system and on and on. Unless First opens up how can we debate the software. There are allot of smart people on this forum that could make meaningful comments on the platform direction. Don't think it's going to happen. Come on FIRST open up a little.

I just kind of figured discussions like these would drive the hardware decision.

[dragoonex]

Originally Posted by Alan Anderson

I think the existing "platform" could be made a whole lot easier simply by changing the architecture of the default code. There's a bit of baggage still hanging around from the pre-2004 PBASIC days, and the division of code into separate "user" and "user_fast" files is a little ragged. It can be reworked to do exactly the same thing but be separated into smaller functional chunks, making it less intimidating and more approachable for the beginning user.

I agree entirely. Our team has developed a way to do that using interrupts so the data is always delivered no matter what, even if we're in a tight loop within the code. We're still testing it, and it's still in an SVN branch, but it looks promising. Having one loop is great and makes working with things a lot easier.

Using Linux on the other hand is too much work, for no gain. For one thing, it needs more than a PIC with 3KB of RAM, and 1KB of EEPROM. Secondly, interfacing with the hardware is too much work, and even if there was a nice API for it, it would again have too much overhead. Linux also adds another point of failure. What I would like to see are some Linux developer tools. MPLAB is WINE works, but its far from perfect.

IMO, a good solution would to be to create a nice API in the default code for drive code, sensors, autonomous, and all the other things. Right now we don't have that and our team is working very hard to create one, but it is a big undertaking. When it comes down to it, this is what embedded programmers do. Embedded systems don't need preemptive multitasking kernels and CPU hot plugging. I think it's important for everyone to try programming on the bare metal of the controller as it's a good learning experience.