NEW 2009 Control System Released

[yoyodyne]

Originally Posted by Mark McLeod

I am concerned about the development software licensing issues. I really liked the team-wide mcc18 license that allowed multiple students to learn to program at once, in the lab and at home. gcc will still allow this, however, Labview will not. I had similar issues with the limitations on the single team EasyC license.

Wow! I kind of figured that along with the new WPILib being open source there also would not be per-seat licensing for the new control system development environment. I guess it was naive of me but I figured that is why we would be getting a "custom" NI build. If there is, it is really going to negatively impact the way our team develops and unit tests software. Do you think that there will be license costs from both Wind River and NI? If that is the case, then there will be an impact to the teams that take the C route as well.

[Eldarion]

Originally Posted by yoyodyne

Wow! I kind of figured that along with the new WPILib being open source there also would not be per-seat licensing for the new control system development environment. I guess it was naive of me but I figured that is why we would be getting a "custom" NI build. If there is, it is really going to negatively impact the way our team develops and unit tests software. Do you think that there will be license costs from both Wind River and NI? If that is the case, then there will be an impact to the teams that take the C route as well.

I agree 100% with the above.

One other issue that I haven't seen brought up here is platform lock-in. With the old system, teams could use Windows, Linux, or Mac to program the robot with, and the robot code itself was fairly portable between microcontrollers. In addition, low-level C programming is pretty much standard in the embedded systems world, so students are gaining real-world experience with direct application to industry.

With the new control system, you are locked to Windows, regardless of the method you use to program. LabView will run on Linux; the software that it uses internally to generate the VxWorks image will not (BTW I don't think Wine will solve this problem unless you can get an entire LabView install into Wine along with the other tools.)

If you decide to use LabView to program, the problem is even worse. LabView programs cannot be used on anything that is not directly supported by LabView, or converted to another, more standard programming language! Also, I question the applicability of LabView programming knowledge in industry--sure, some large companies and colleges have access to LabView, but most do not due to the extremely high cost involved.

The OS lock-in problem will only get worse when Vista takes over--I have spoken with many developers who cannot stand Vista and have switched to Linux, finding it better suits their needs.

Just some futher thoughts, feel free to comment on them...

The new cRIO system looks like the cRIO-9012 model (specs wise) with the integrated controller and chassis. The price range looks like it will come to ~$2000-$3000 dollars for the whole system.

When at one of the presentations, one of the NI reps said that the 802.11a standard would be used. This would make sense because of the 11 channel system that it has.

The fact they are letting us compile with C++ opens up lots of oppurtunities. You could actually code in a different languages (provided that you could convert the C++ libraries to a different language) and then convert to C++ to use with the cRIO system.

I think that this new system is way better than the old. The IFI system always seemed very limited to me. You had limited memory. The system couldn't support higher level language and as a result class files/namespaces/polymorphism and other higher level language features could not be used. I'm really excited to get my hands on this new system. I heard that this system will be available for us in November, can anyone confirm this? Meanwhile, I'll practice LabView with mindstorms

[Adam Y.]

Originally Posted by Eldarion

With the old system, teams could use Windows, Linux, or Mac to program the robot with, and the robot code itself was fairly portable between microcontrollers. In addition, low-level C programming is pretty much standard in the embedded systems world, so students are gaining real-world experience with direct application to industry.

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.

[Doug Leppard]

Help me with this. As presented I thought this was a FLL-FTC-FRC solution. How does new system work with FLL and FTC? Do they have smaller cheaper systems that can migrate from FLL to FRC and beyond?

Or did I get this wrong and this is only for FRC.

[pogenwurst]

Originally Posted by Doug Leppard

Help me with this. As presented I thought this was a FLL-FTC-FRC solution. How does new system work with FLL and FTC? Do they have smaller cheaper systems that can migrate from FLL to FRC and beyond?

Or did I get this wrong and this is only for FRC.

I believe the point is that the controllers for the FLL (NXT), FTC (an NXT-ish device), and FRC competitions are all programmable with LabVIEW or a LabVIEW-derivative, so that students can more easily build upon prior experience as they "graduate" from program to program.

[yoyodyne]

Originally Posted by Adam Y.

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.

Keep in mind that the cRIO is an embedded system. VA Tech did use Lab View on their DARPA urban challenge robot but the image processing, navigation, obstacle avoidance, etc. was performed on a pair of quad core servers. The cRIO was relegated to the break, throttle, and steering control functions that are pretty much what we have been doing with the current control system for years. I’m not saying that you can’t do a lot more with 64MB of RAM and a 32 bit processor but you still might actually have to worry about the efficiency of the implementation. You will always find yourself in a resource constrained situation if you are in a competitive real-world situation. I'm sure that the game designers will make sure of that soon enough.

[Kevin Sevcik]

Originally Posted by Adam Y.

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.

*chokes* Erm. A bold statement there. But I'd venture to guess that procedural programming makes up a majority of the actual robotics work out in the Real World. (ie. not NASA, academic research, or the military) See this post for an idea of things. OO is fine and dandy, and useful for doing highly complicated and difficult tasks like machine vision and such.... But there's a distinct difference between complication and utility.

[steveg]

Originally Posted by Adam Y.

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.

This is not really true at all. You can do anything that you'd like to do in an object oriented language in a procedural language. Having worked on EKF and SLAM algorithms on both a PIC and a Blackfin (just to clarify, the EKFs were on both the PIC and Blackfin. SLAM was only on the Blackfin. I imagine with all of the multiply-accumulates SLAM needs, it's not really feasible to implement on a PIC.), I can tell you that if you're doing something where you need an object oriented language, you're doing it wrong.

Having said that, an OO language does make it much nicer, especially if it supports STL classes.