Re: How important is Linux?
 

I just want to add a few words to this conversation.

I agree with all the comments on this topic regarding having an RTOS on a new controller that hail the benefits of being able to write higher level and complex code with less effort. Having well-defined high-level APIs for programming a system are an absolute must. Why should I have to know how to make the microcontroller do backflips in order to do something that any RTOS would provide to me by default? I'm all for learning about what makes the box tick, but in 6 weeks I refuse to perform open-heart surgery every time I want to do something new.

Does Linux have to be that RTOS? Well, we should definitely have an RTOS that is suited to a particular hardware controller, and have good APIs for working with the hardware from the native development environments. I honestly don't care what RTOS is on the controller, so long as it's fairly well documented and supported - If I can't get an answer on why X does Y when I do Z in 48 hours or less, then it's junk to me. I do expect some growing pains during the first year while we're all trying to learn the new system, but a bank of somewhat-experts would be nice to consult with if such a group could be assembled.

I am probably biased since I work on an RTOS for a living, but if *I* had to know everything about the hardware I am writing my RTOS for in 6 weeks then I'd be in a heap of trouble - I couldn't do it. Once you move away from hobby components and into more cutting-edge technology, you just can't know everything you need to know to perform direct programming NOR SHOULD YOU HAVE TO.

-Danny

Re: How important is Linux?
 

I'm not sure I see the benefits to the students in moving away from what we have now.

It seems to me that what we have now allows students to learn basic programming structure. Variables, arrays, lookup tables, the importance of good clean code, etc. You should see the looks on their faces when they begin to understand why order of operations is so important in integer math. It's a thrill to see.

No offense to the many incredibly talented mentors out there - but everything you are throwing around seems to be more complicated than what we have now.

I have my kids code in notepad for exactly that reason. Having them learning how to code in the most basic environment where they have to worry about syntax, manual spacing, capitalization and spelling teachs them what I consider the most important basic programming skills.

You should see the victory dances when they write their first subroutine in notepad and it works, cleanly, the first time they compile it.

I'm not sure what have an RTOS would really gain for the students in terms of learning, but I can see where it will definitely increase cost.

Re: How important is Linux?
 

I think the purpose would be to break the system up into 3 major ways to write code. The first would be very similar to how it is now were we write C, compile, etc. The second would allow the user more control over the system but require them to know the specifics of the hardware. Lastly, with an RTOS you would be able to run a scripting language that would allow for simple and quick prototyping or even full use for those teams that dont have hours to spend writing code.

Re: How important is Linux?
 

My view is quite different. Student programmers should not be forced to work in an environment where implementation details break common-sense rules of mathematics. They shouldn't learn to treat an error-free compile as a victory. There are just too many ways for a simple typographical error to result in a program that's syntactically correct, but which doesn't do anything like what it was supposed to. C is convenient and ubiquitous, but I think that its many "gotchas" make it a poor language to use when learning how to program.

EasyC comes close to that already.

Re: How important is Linux?
 

I didnt mean to imply that it would be different but that with all of the advantages of an RTOS you would still have an EasyC or similar way to code.

Re: How important is Linux?
 

I'd love an off-the-shelf OS with a powerful enough processor to deal with the overhead.

My dream would be a full industrial PC (PC 104 form factor???) that would allow teams to build expansion as needed. That said, I'm assuming that we'll get another microcontroller. And while there are microcontrollers capable of running modern a OS, most cannot handle the overhead, memory and interrupt requirements.

Re: How important is Linux?
 

I am one(of the apparently few) saying that I would like to see Linux. Now this is not because oh snap its linux or i hate(MS/MAC) but because there are a few features that Linux is (as far as I know) the only one that supports it. If there is another simpler system out there that provides what I want, I'll take that.

One thing that drives me insane with the current system is the serial port programming, few laptops built recently have a serial port. Personally I'd like a controller I could connect remotely and program with in one of two ways.

First is directly with a network and something like ssh/telnet. My reasoning is that almost every computer in the past 10 years has an internal network card so user hardware is not a problem. Also the compiler etc can be stored on the robot so that I can ask any person on the team if I can use their laptop real quick to ssh/telnet into the robot(with PuTTy in windows or typing ssh in the command line in mac/linux) both of which are programs already installed or only a few k to install on a computer. Also something such as sftp to send the text file or precompiled files to the robot directly if you prefer to compile on your laptop etc.

Alternatively, removable media would be nice for uploading code. Simply write it onto a usb or sd card and pop it in the controller. That would also make swapping autonomous much easier.

Another thing that I like about the use of Linux is easily logging robot actions errors etc into plain text that I can easily read later.

I understand some peoples complaints about accessing hardware via some abstraction, but I'd personally take a layer of abstraction on a system with megabytes of ram and a few hundred megahertz processor over no abstraction on a 26ish mhz processor and only a few k of ram.

There is also the complaint of difficulty. With a pic you need to code every little bit thankfully most of the stuff is provided by IFI/FIRST/Kevin currently. I seriously doubt that we would be given a system with no default code and told to have at it and figure out how to interface with the hardware. Examples and defaults would be given for most interfacing and Kevin would of course astound us with even better possibilities, interfaces etc.

Re: How important is Linux?
 

It's been a while since I've posted on ChiefDelphi hasn't it?

I'll try and keep this one as short and sweet as possible (not likely).

An RTOS on our future controller - absolutely. What people might be forgetting is we *almost* have one already with our controller's "Master Code." It manages all the lower level functions (radio, timeslicing, etc), and exposes an abstraction layer for us to access all the I/O on the RC. Some of the hardcore here will probably berate me for using an analogy like this, but I'm calling it as I see it.

An RTOS is not a giant leap of faith, especially if we're going to get a significant microcontroller upgrade. To me, it's an evolution of something we're already doing, except it would be more well-defined, widely accepted, and extensible if we go with one of the more popular RTOSes.

Do I think Linux should be that RTOS? How about QNX? VxWorks? LabView RealTime Embedded? Or any other RTOS? SHOULD I LOOK IN TO ECOS?

It's a loaded question, as is my answer: As an FRC programmer, it doesn't matter at all, because we HAVE TO BE GIVEN another secured abstraction layer, in which we'll be limited to: accessing robot and OI related I/O, and executing sequential code. I'm on the fence if we programmers should even be able to spawn a thread. We SHOULDN'T ever see an interface with the RTOS directly, at least never in a competition environment.

Regardless of the underlying RTOS, I'm pretty sure the abstraction layer presented to us FRC programmers could be made exactly the same - in fact, my money is that it will look very similar to the one we're given now through the current IFI headers / MPLAB toolchain.

NOW, if you put me in the position of being the head honcho at FIRST who gets to call the shots on this project, my answer changes dramatically:

1) Who's on my dev team? Who can I get with significant experience with Arena Controllers/RCs/OIs (read: did I poach anyone from IFI =P)? What RTOSes do they already know?

2) What's my bottom line on each control unit? Can I afford licensing on a commercial RTOS? How much am I paying my developers? Can I afford to pay them to learn an open RTOS if they don't already know it? Does the licensing $ vs learning curve $ make sense? What about the support costs if/when something blows up during development, or god forbid, competition week 1?

3) Am I toying with any crazy ideas like putting all wireless communications on WiFi, or Bluetooth, or ZigBee? What's each RTOSs support for those stacks?

and finally

4) Is any commercial RTOS developer willing to pony up the cash, support, and time for the privilege of putting their product into the hands of thousands of the world's best future embedded developers?

At the end of the day, FRC programmers won't and shouldn't have any say in a decision like this. And that's not a knock on Kevin, or anyone else in this forum, but this is me with my business hat on, and I think I'm making a lot of sense on this one. :p

Cheers, and I looking forward to what we end up with in 2009!

-Shawn T. Lim...

Re: How important is Linux?
 

I feel like I can (hopefully) provide a lot of insight into this debate as our team presently uses Linux to run our robot. The IFI chip is just an I/O slave between the radio, PWMs, Victors, etc, and our co-processor - which is running Linux. The coprocessor is a 400 mHz GUMSTIX embedded processor, and I think it's a fair equivalent to what could possibly be used on robots in the future. (Teams interested in reading more about this, feel free to visit our site - but be warned, in changing over to mediawiki we lost some stuff, so a lot of the information is outdated (ignore all things "modules"))

Anyway, here's some of the things that we noticed, day-to-day, that are very nice:
* Easy access to a hardware timer. Seriously, how many threads are there about the sketchy interrupt timer and all of that, whatever happens, the new chip MUST have a clock.
* No interrupt worries. It's really nice to have an 'unlimited' number of interrupts available and not have to worry about bogging down processing capabilities. In that same vein...
* Far fewer efficiency concerns. This one's a double-edged sword; at one point last year our robot had 4 PID and 4 PI loops running simultaneously without any slowdown. Point being that you forget about programming efficiently, which is a useful skill IMO that's easy to let go of when presented with greater resources. Even as computers get stronger, everyone knows they do get bogged down from time-to-time, but efficiency is continually becoming less of an issue to all programmers - a dangerous trend IMO, but I digress
* No flashing. This one's really nice, particularly for anyone who's had to tweak PID constants before. Even if the new controller had the most lightweight OS in the world just enough for a basic file system that would allow quick 'saves' and then a 'restart', the sometimes 2 minute flash process is unacceptable.
* Floats. I know there are bit-shifting workarounds for the sometimes sketchy floating-point performance found in all things IFI they just become one less thing to think about and one less thing that could go wrong.

The bigger things, that maybe not everyone will care about:
* Language flexibility. Our code is written in Python. Even if interpreted languages are a little slower in run-time, I prefer it to compiling. Error handling and such are much more flexible too.
* Threading. Sure, they aren't necessary, but they're nice. For instance, we ran each PID loop as its own thread and polled its state whenever we updated PWM values - why should the main program wait for this? This allows the very well optimized kernel to schedule work, not the inexperienced programmer.
* Non-volatile run-time memory. A file system allows you to run simplistic programs whose only requirement allows you to save data between runs. The simplest being one that simply polls all pertinent variables, records time and state for each. Then parses the file into variable values with delta t's and can playback and pre-recorded run. It's still dead reckoning, and wouldn't have worked for the last few year's autons, but it's nice nonetheless.

Random Cool Things That Also Become Possibilities:

* Wireless Programming. This was really convenient for tweaking drive wheel PID constants. We replaced the GUMSTIX with a laptop running the same set of code (it's python, it'll go anywhere -- flexibility) and a wireless card. This allowed us to update PID constants on the fly over an ad-hoc nework with ssh from another laptop while the robot ran by radio on our practice field. It's as close to tweaking under real time situations as possible.



If anyone has questions about our experiences, please feel free to PM me. Mostly, however, I encourage you to TRY IT. If you have a laptop with a serial port and python, you're good to go. I'll make an effort to update our site soon to make testing easier, but everything you need is there. You don't need to wonder about the future, try running your robot with Linux right now - adambots.com

Pat

Re: How important is Linux?
 

Bingo. We have talked about doing that for 2 years but never got around to it. I still think this idea has a lot of merit and would still like to do it one day. Too much to do, too little time.

Re: How important is Linux?
 

AdamBots CoProcessor Page

I've followed the AdamBots system for the last few years and I think this is the initial step for all teams looking to get involved with Linux.

Great Post Pat !

Re: How important is Linux?
 

To AdamBots:

How fast do you find the reaction time between setting a PWM on your co-processor to the speed controller actually reacting to it? Is there any delay or have you found it to be relatively responsive?

Re: How important is Linux?
 

It's against the rules for a co-processor to directly control/output PWM signals.

Co-processors can only take in data (whether from the RC or from other sensors), process it, and send it back to the main RC.

Re: How important is Linux?
 

I think what he is asking is when the co-processor calculates that pwm 1 needs to be at 201, how long does it take for that to be sent to the RC and then the RC to set it.

Re: How important is Linux?
 

I know, you set a pwm variable in the co processor, that gets sent to the RC and the RC sends it to the speed controller, is there any delay in this?