NEW 2009 Control System Released

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

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

[Danny Diaz]

Originally Posted by yoyodyne

I kind of figured ... there ... would not be per-seat licensing for the new control system development environment.

Originally Posted by Joe Ross

The Labview that is provided in the kit the past few years has been an unlimited license for FIRST use. See the following post: http://www.chiefdelphi.com/forums/sh...ad.php?t=51405

Thanks Joe - there will NOT be a per-seat licensing for any software from National Instruments. Plus, to my knowledge, NI has even made sure that per-seat licensing restrictions for WindRiver tools have been removed as well. If only one person on your team can program, what good is that? I will refer back to the link Joe provided above, and state that everything in that thread still remains true.

-Danny

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

[Jay Lundy]

Originally Posted by adman

I think we are starting to get a consensus here.

I agree these seem to be common concerns, so I'll put in my 2c.

* We all want our students to learn how things really work.

Two points:

1. The old system and the new system teach different skillsets. Which one is more important is a matter of opinion.

2. If you want to teach both skillsets, just buy a PIC on your own and interface it with the cRIO. That's a lot easier than building a custom board with a PowerPC running VxWorks and interfacing it with a PIC.

So if your goal is to build a robot, the cRIO is clearly better (there's a reason they send 32-bit processors running VxWorks to mars and not PICs). If your goal is to teach, the cRIO gives you more opportunities to do that.

* We all see students become somewhat intimidated sometimes by C at first.
* We all have seen students overcome their fear of C
* We know LabView is a great way to teach control system basics but
can mask the background info that leads to true product design
in the embedded world if that is our cause

These are all related to the fear that NI's ultimate goal is that someday we will all be programming our robots in LabView because the C/C++ interface is crippled. The NI reps have stated many times that is not the goal and the C/C++ and LabView libraries will be of similar quality. If you want to program in C, nothing is stopping you.

* We are all very nervous about how much these systems will cost

I agree that the overall cost will increase for teams that may want a second controller and that's something FIRST should consider. However I don't think the wild speculation in this thread about what the actual cost will be and then coming to conclusions based on that is helping anything. What is clear is that the cRIO's will be sold for around how much each unit costs to manufacture, which is significantly less than the normal price.

* We see the split in minimally backed teams and the teams that
may have these already on order from NI.

Back in 2003 WildStang used a custom board to program a positioning system for their amazing autonomous when everyone else was programming in PBasic with like 100 bytes of RAM. Now veteran and rookie teams both have access to incredibly powerful hardware. The libraries and the increased emphasis on code sharing will help the rookies take full advantage of the cRIO. I predict the split will always exist, but next year it will be smaller.

*Also considering we are adding more parts to the system, the analog
adaptor plugin and the expansion board and the power inverter the
robot now has potentially more things to trouble shoot to keep the
robot running.

I agree, but I don't see that as a significant challenge. Plus with the wireless programming interface and the increased debug capabilities, programming problems will be a lot easier to find so it kind of balances out.

IMHO I think everything except for the cost is a non-issue.

[Doug Leppard]

Jay,

My big concern is that with current system we could have many kids on a vex system in preparing for FRC. You could proto-type what you wanted to do on vex.

But the new system you don't have that link to the two systems other than a labview similiarity.

I am sure it will all work out.

Plus most of us will not get the crio system until Jan 2009 because of cost and there is a lot to prepare for in understanding crio.

Should be an interesting year.

[Arefin Bari]

This was sent out tonight...

Greetings Teams:

We have some important information from National Instruments (NI) to share with you:

-------------

Firstly, we would like to extend our congratulations to all FRC Regional and Championship teams for a very successful 2008 FRC season.

As we know you’ll soon begin preparing for the 2009 competition season, we wanted to answer the two questions we’ve heard most frequently asked about the new control system. We are excited by the energy and enthusiasm you’ve shown for this technology change, and will continue to share information as it becomes available.

When will we receive the new control system? Is there any benefit to purchasing an NI CompactRIO controller now?

FIRST is continuing to work out the logistics of the exact availability date for the new control system, but it will be no later than Kickoff of the 2009 season. We are working extremely hard to make the new system available as early as possible.

We know some teams want to begin using the new control system. However, we advise against purchasing a current NI CompactRIO system from National Instruments. The prices listed on www.ni.com do not reflect the discounted price FIRST teams will pay for purchasing additional controllers, and more importantly, the software experience for the 2009 FRC controller in the 2009 Kit of Parts will differ significantly from an off-the-shelf NI CompactRIO system. Additionally, you will not be able to work with the other components of the control system. Instead of purchasing a NI CompactRIO controller now, we recommend that teams begin learning programming skills in C/C++ or LabVIEW.

What can we do now to learn more?

You can begin reviewing the training material already available online at:

* Tutorial: Getting Started with the New Control System
* Slideshare: Training sessions from the 2008 Championship
* Tutorial: Program the New Controller with NI LabVIEW
* Tutorial: C / C++ Programming for the 2009 FRC Control System


FIRST, National Instruments, and WPI will continue to develop and distribute training materials to support the set-up and use of the control system in preparation for the 2009 season. This training will be distributed through the web and live workshops, and there will be training available for the summer months. We will always post the latest training information on www.usfirst.org/community/frc and on www.ni.com/community/first.

Please send us your questions, comments and feedback via the National Instruments Community blog found at www.ni.com/community/first. We wish you the best of luck in the off-season, and thank you for helping support the FIRST mission and vision.

Go Teams!

[dcbrown]

Previously with the PIC, "system programmers" had the advantage and "application programmers" who wanted all that h/w stuff hidden were at a disadvantage. The advent of WPILIB and EasyC closed some of that gap, but still the plaform was more systems programmer friendly.

The platform was kinda backwards, often requiring a lot of systems knowledge before you could become an applications programmer. This typically meant new programmers were at a disadvantage.

The new platform is more the norm/inverse of that. The entry level for all is as applications programmers using the API of the RT/OS either within kernel tasks or RTPs (real time process). If you want to be a systems programmer, the entry costs in terms of time, effort, and knowledge just increased. But that is usually how it is. The new platform should align better with both sets of folks.

The WPILIB will be just another library/plugin option on top of the RT/OS that provides an API to access the pins, PWMs, etc. that we're familiar with on the PIC. Having the source may or may not help much unless the NI drivers for the modules have the source included in the cRIO kit also. But this library will be *the* method of accessing DIO, ADC, PWM, and relays for almost all but a few teams.

For example, lets say the device special file for the digital io module was /tyDIO and pins 0-15 were /tyDIO/0 .. /tyDIO/15. Then WPILIB would need to do something like the following to read an input pin.

fd = open( "/tyDIO/0", O_RW, 0 );         // open DIO driver for NI module, pin 0
bytes_read = read( fd, &byte, 1 );        // read value of pin 0
close(fd);                                         // close device

** this is pure swag -- there are several ways of doing this, but this is the
     most direct but again depends on the device naming scheme for the
     modules and its subparts.

This assumes the VxWorks io driver model is used and not bypassed in some bizarre fashion. Or instead of using the provided NI module driver, WPILIB may decide to directly implement their own replacement NI module driver to collapse some of the details but that sounds like way too much effort and then they'd need to support that flavor of NI module driver... Anyway in the PIC, systems programmers knew how to directly access the h/w. In the new model it isn't that simple, its easier to just access the NI drivers. It will be nice to get at least some documentation on the NI module driver APIs -- it would go a long way to understand how some of the system pieces fit together.

The biggest problem I'm having wrapping my head around is the sheer size of the API and doc set for VxWorks along with a lack of information on what the NI driver/library interfaces look like. But all in good time...

[Greg McKaskle]

The NI I/O model depends on the HW target, but in this case the FPGA and the PPC use a memory mapped register set. Instead of the driver kit seen above, you'd see something equivalent to an

NI_RIO_PEEK(FPGARef, address, &result);

The FPGARef is the result of an early Open that loads and/or connects to an FPGA image.

Then because some of the access would be difficult, there is a layer that supports critical section exclusion and provides cleaner C datatypes. This layer of C++ objects is generated with the FPGA image, and that is what WPI will link against.

Greg McKaskle

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

[yoyodyne]

Originally Posted by dcbrown

Previously with the PIC, "system programmers" had the advantage and "application programmers" who wanted all that h/w stuff hidden were at a disadvantage. The advent of WPILIB and EasyC closed some of that gap, but still the plaform was more systems programmer friendly.

The platform was kinda backwards, often requiring a lot of systems knowledge before you could become an applications programmer. This typically meant new programmers were at a disadvantage.

Working with software at the device level is what made the FRC embedded software development experience different and in my opinion more valuable then just more applications level programming experience. After all, application programming experience is widely supported and easily accessible whether it be using the free microsoft C++ express or win/mac/linux JAVA, Python, etc. As a small example, it is clearly important that the students have the opportunity to understand that a gyro outputs a voltage proportional to rate and you can integrate that to get direction, likewise for an accelerometer. If the programming experience is totally abstracted we may as well just compete in a totally simulated first fantasy competition. Why get your hands dirty fabricating metal and hooking up wires with CAD, animation, and applications level software? Because the FIRST experience gets you beyond the computer screen. The cRIO system experience could be fantastic as long as the teams are allowed to and rewarded by writing their own VHDL or developing custom sensors and sensor interfaces. On the software side it might actually be a wonderful eye opening experience to realize that there are other data types besides long and double because in the real world of robotics and other real-time number crunching applications you might have to actually use fixed point math. It is never too early to get a taste of the real world.

[dcbrown]

You can begin reviewing the training material already available online at:

* Tutorial: Getting Started with the New Control System
* Slideshare: Training sessions from the 2008 Championship
* Tutorial: Program the New Controller with NI LabVIEW
* Tutorial: C / C++ Programming for the 2009 FRC Control SystemThis was sent out tonight...

My guesses on what the links should be based upon the above descriptions...


You can begin reviewing the training material already available online at:

* Tutorial: Getting Started with the New Control System
* Slideshare: Training sessions from the 2008 Championship
* Tutorial: Program the New Controller with NI LabVIEW
* Tutorial: C / C++ Programming for the 2009 FRC Control System

[Al Skierkiewicz]

There has been a lot of discussion about the new controller in this thread, especially on the software/programming side. (I will leave software to the experts ) I however, have an opinion similar to Mark McLeod's above. What the new controller and interface represent is a nightmare for rookie teams and those with little or no electrical mentorship. In comparing with the present controller where single point failures are reduced to an absolute minimum, the future contoller has multiple power supplies (I count five min.), negative power on the case, multiple interfaces and multiple connections between the RC and the outboard hardware. Diagnosing a failure in the controller will be next to impossible for anyone that is not skilled in in this black art. Rookie teams will be especially vulnerable to failure and damage of the control system.
We need to put ourselves in the shoes of a rookie team to see what they go through. As an inspector and mentor who regularly visits rookie teams, I can tell you that many rookies can't get a motor connected properly without guidance. To add this level of complexity will doom many rookies from participating once registered or from enjoying their first year's experience. Although, a lot of thought has gone into the interface boards and connector design, there is just too many places for something to go wrong. As Mark has pointed out, the power supply wiring is just one place that things can go horribly wrong.
Power distro is another area of concern. As I have pointed out in lectures for many years, the battery is capable of supplying 600+ amps and the power distro needs to be able to withstand that current. In addition, the design must take into account the voltage drop across the distro panel as far as power supply droop and noise is concerned. At what voltage does the DC-DC power supply drop out? I can tell you that the battery terminal voltage regularly drops to 4 volts (for short pulses) under load. Add a game that requires pushing and you will find teams with six motor drives drawing the battery down below 8 volts a regular occurence. These same teams will (and have in the past) depleted a battery in less than two minutes.
Although weight is not an issue for most rookies, it is more than considerable for experienced teams that weigh in at 120 lbs. Added together with the multiple modules teams are likely to want, the control system, DC-DC power supply and interface boards will likely produce a system that weighs in excess of 5 lbs. A considerable mass that will need secure mounting.
Finally, a delivery date of kickoff is too late (see above). When asked, I stated I need it next week. FIRST, if you are listening, please consider giving some teams prototype systems now so we can break them. Give us the chance to work out problems and solve them before the 2009 season starts.

[dcbrown]

Originally Posted by Greg McKaskle

The NI I/O model depends on the HW target, but in this case the FPGA and the PPC use a memory mapped register set. Instead of the driver kit seen above, you'd see something equivalent to an

NI_RIO_PEEK(FPGARef, address, &result);

The FPGARef is the result of an early Open that loads and/or connects to an FPGA image.

Then because some of the access would be difficult, there is a layer that supports critical section exclusion and provides cleaner C datatypes. This layer of C++ objects is generated with the FPGA image, and that is what WPI will link against.

Greg McKaskle

So NI_RIO_PEEK and NI_RIO_POKE (assumption) would work within kernel applications/tasks, but what about RTPs? Since opens are not traditionally shared across the RTP/kernel interface could RTPs do their own open on the FPGA image or will this type of macro call only work inside the kernel?

Is there a technical architecture overview document for the FPGA and NI I/O modules - essentially similar to VxWorks component API manuals? Trying to find any real tech information on this platform has been particularly frustrating. Especially since this is NOT a new platform. I don't need to know the particulars of how the FPGA/IO interface will be set up for FRC, but it would help immensely to know what a typical engineer recieves in terms of documentation, software templates, and information when they buy an cRIO IO module.

[Doug Leppard]

Excellent comments Al.

Our team has consistently helped hurting teams, and they are not all rookies, many are below 1000 in team number. It takes a deep rich team to have the skills for the mechanical, pneumatics, electrical, programming and sensors. Much less PR and fund raising skills.

Even at championships 1/3 of the teams couldn't drive forward to get the 4 points. Many teams we helped had electrical shorts or bad connected cables. Robotics, especially one that takes such abuse game after game is a complex challenge.

To me the biggest programming problem of teams is that the hardware is usually not done until shipping day, thus the programmers usually don't get the machine until that day or at competition.

I do hope they will allow a few teams (like 1902) to have the processor ahead of time if they have the commitment to help others. Our fear is that with a new system in competition there will be many problems and even the experienced teams will be scrambling to make it happen and will not be able to help others.

FIRST is committed to the kids and their future. I have high confidence they will do what is right and in the end this will work better for the kids. As a much older kid I am excited about a new toy and to be able to learn more myself.