cRIO, has it 'upped the game'?

[gvarndell]

With all of you presumably having been to a competition or two now, what effect do you think the new controller and software development tools have had on the games? Are you doing things now that you couldn't do in previous years? In general, do you think other teams are?

[JamesBrown]

I think that the potential of the cRIO has been seen. I am not sure that we have seen a real increase in the quality of software developed across the board. However I believe this could be expected, there is a learning curve when any new technology is introduced. WPI and NI spent a lot of time working on minimizing this curve however the build season was the first full scale release so a completely smooth transition could not be expected.

I believe that with off season training of programmers and some additional time to develop new libraries we will see the potential of these controllers unlocked in the next year or two. The best way to ensure that this happens is to release the code you are working on along with associated documentation. There is no reason for 200 programmers to write functions that do exactly the same thing. I understand that this is a competition but the time to develop secret code to give your team the edge is during build season. The rest of the year we should focus on raising the bar.

--James

[Nick Lawrence]

You just lost the game.

On a serious note, the cRIO has for sure upped the game. It allows for a much higher calibre of software to be run on the cRIO, and, well, moar processer power is better than moar cowbell.

-Nick

[Greg Needel]

I can tell you with 100% certainty that we could do the exact same thing on the old controller that we do on the c-rio. The only nice feature which we utilized differently than the old system was USB game pads, although that was possible with chicklets.

[AndyB]

We found it pretty clear that the cRIO was going to be a big upgrade this year when we were started playing with it in early January. It may be have to do with the new speed controllers as well, but everything felt a lot more fluid and smoother. The camera was a lot easier to work with (this is what I've observed, they don't let me touch the code).

I think this year's game was designed in a way to start using the extra processing power (tracking of multiple moving targets). I think this game was harder mechanically to build a system that could shoot and track and actually give the cRIO a good workout. This is definitely what we found at least.

Overall, for a first year system, I am very impressed. I was expecting a lot of last minute bugs and problems at the regionals which we really haven't seen... minus the static issues of course. Bear in mind that I know next to nothing about programming and controls, so maybe I'm overlooking something. After using the system for a year and getting a good feel for it, I'm looking forward to another cRIO system.

[Bongle]

I can tell you with 100% certainty that we could do the exact same thing on the old controller that we do on the c-rio. The only nice feature which we utilized differently than the old system was USB game pads, although that was possible with chicklets.

This is true, but a lot of tasks were harder on the old controller. If you wanted to do any heavy amount of floating-point math, you had to either use a coprocessor or implement a fixed-point system and use that. On the crio, you just use floats and doubles since they are natively supported. If you wanted to do debugging on the camera, it was a 5 minute download via serial cable into labview rather than a real-time feed. Although we were never able to get our WindRiver debugging working, the fact that it supports instruction-by-instruction debugging (or even real-time debugging in Labview) is pretty huge. The multithreading available on the cRio and the WPILib library supplied with it made it easy to use encoders, gyros, and accelerometers without worrying about interrupts and things like that.

However, the crio isn't all good: the weight and size penalty of the crio and associated breakout boards is pretty large compared to the old, flat IFI boards.

[Dave Flowerday]

Originally Posted by Greg Needel

I can tell you with 100% certainty that we could do the exact same thing on the old controller that we do on the c-rio. The only nice feature which we utilized differently than the old system was USB game pads, although that was possible with chicklets.

I agree with Greg. The one other nice feature is the wireless download capability.

After participating in 2 competitions, I have yet to see any robot that does something that wouldn't have been possible with the old control system. Everyone in this thread is saying it's a big upgrade - can you please point out examples of robots that are doing something that wasn't possible before?

[gvarndell]

Good feedback so far. Thank you all.

Originally Posted by Dave Flowerday

saying it's a big upgrade - can you please point out examples of robots that are doing something that wasn't possible before?

This response made me realize I probably should have used the topic 'cRIO, has it 'upped the game yet?'.
My point is, I think we all realize the new controllers have enormous potential.
But has that potential gone largely untapped this year?
I too would love to hear from teams that feel they've exploited the new controller's power in some specific way -- that would not have been possible before.
Also, if your team has ambitious (and specific) software based capabilities you're kicking around for future years, would love to hear about it.

[Ackermani]

One example, Skunkworks swerve drive. From experience in past years, running full scale vector math for a holonomic drive base of any sort eats up the majority of the IFI's capability. With the ramping of speed on our lift and the array of PID's controlling everything (not to mention the camera), our controls would lag significantly. Also, I've been working on some equation handlers capable of calculus operations, so I've been pretty happy with the cRio system.

[JesseK]

Originally Posted by Greg Needel

I can tell you with 100% certainty that we could do the exact same thing on the old controller that we do on the c-rio. The only nice feature which we utilized differently than the old system was USB game pads, although that was possible with chicklets.

Here's what we're using that the old controller could not give us on its own: Responsive 6-sensor drive train control in parallel with 15fps image processing WITH 900 bytes of WHATEVER data we want sent back to the driver's station, in WHATEVER format we want the data. In addition, we hook a laptop up to the driver's station to easily read the data, interpret it, and display the data in whatever format we want, using ANY language we want for the GUI (Java for us). Useful languages include Java, C++ (etc), Flash, good ol' perl/asp/whatever lollipop flavor script with html/css webpages, Oracle for data storage, and the list goes on, and on, and on. Sometime this summer we'll write a whitepaper on how we custom-wrap and decode the data.

Sure, the mechanics of this year's game make it hard to utilize all of that functionality properly ... just disregard the fact that we've had issues with the hopper jamming and our team would be perfectly satisfied with our bot. The thought of using additional microprocessors with the IFI controller in order to offset the extra CPU time required to do all of the above would add unnecessary complexity to an already complex system of systems.

[Alan Anderson]

Many of us don't see a big benefit -- but that's because we already knew how to use the IFI system to its full capabilities.

The FPGA in the cRIO provides features right out of the box that used to require adding files to the default code, modifying the interrupt service routine, and working with some fiddly configuration details. With the built-in encoder, accelerometer, and gyro support, the only add-on programming we used this year was the Driver Station display library.

For the teams lacking significant experience with programming embedded controllers, this year's FRC control system and development environment has indeed permitted them to do things that they wouldn't have been able to achieve easily with a PIC and MPLAB. Give it a couple of years, and I think you'll see LabVIEW VIs and C++ classes made available that will blow the doors off anything even Kevin Watson came up with.

[Tom Line]

Alan hit the nail on the head.

NOT having to teach the students this year all the tricks surrounding integer math and how to do it accurately was an improvement. Having code like the PID pre-written was an improvement (even though I made them write their own before allowing them to use it). Being able to do polynomial equations with doubles and floating point math rather than lookup tables was an improvement. Not spending a WEEK learning how to program fast trignometry estimates that are only useful on pics was an improvement. Having real-time debugging was an improvement. Having the Front Panel feedback and controls for tuning PID loops and other robot constants without having to do the old recompile-download-test and try again (or build you own custom tuning board with analog controls) was an improvement.

Here's the biggest difference. The CRIO DRASTICALLY lowered the bar for entry into FRC. Sure - the "old" teams like 111, 45, or anyone else with more than 3 or 4 years of PIC programming don't see a huge improvement. They know the tricks. They have the code pre-written. They don't have to spend a week just to learn how to do some basic function on the IFI that is built into the CRIO - like PID, trig, and floating point.

Finally, although I haven't seen anyone talk about it much, my team has universally agreed (even though they are experienced C programmers) that picking up the visual programming style of labview is quicker than learning to program a language if you've never dealt with languages much before.

The first year we were in FRC was '06. The learning curve on the IFI controller was huge. They were lucky to get their shooter running. '07 was very difficult as well - learning all these tricks, gyros, encoders.... basically learning how to make the system WORK was the first challenge. How many teams did you see using working gyros and encoders before Kevin Watson put out his code? And for some reason it still never made it's way into the IFI default release.

The Crio moves that challenge. I don't think the challenge with the Crio is getting the system to work. All those functions are built in and easy as drag-and-drop. Now the challenge is to how to beat the game.

[RyanCahoon]

Originally Posted by Greg Needel

I can tell you with 100% certainty that we could do the exact same thing on the old controller that we do on the c-rio. The only nice feature which we utilized differently than the old system was USB game pads, although that was possible with chicklets.

Couple things that immediately come to mind:

--In circuit debugging (). This allows programmers to very easily see what they're code is doing while it's running. While one could argue that the same thing could be accomplished with printf statements, the amount of data that is available more readily in a much more logical format (i.e. code tracing) is a vast improvement.

--Custom dashboard with increased user data size. Yes you could write your own dashboard client for the old control system; again I could argue the ease of implementation here, but I won't. To me, the big thing is increased communication between the robot and dashboard. 984*50 bytes per second as opposed to ~15*50 max (assuming you make use of unused PWM readouts, all the user bytes, etc) on the old system. With this kind of capacity you can now stream back live video. Not possible on the old system, unless you're a fan of 8x8 pixels video...

--Increased processing. New controller: 400 MHz, 760 MIPS, including a Floating Point processor; Old controller: 80MHz, 10 MIPS., no hardware FP support. I.e. we can process video now, among other things.

--Graphical programming language: Some people hate LabVIEW, but my experience is it makes programming much easier for people just learning it. Case in point: the LEGO NXT software is based off of it.

Just because teams haven't started using all of it yet, doesn't mean that it isn't an improvement. As has been noted, that's more a factor of little time to explore the capabilities of the system.

--Ryan

[MrForbes]

Our robot was doing a lot more this year during build than last year because of the new programming system...however, making it work under actual field conditions has been a challenge, and the long time it takes to build and deploy code in LV seems to discourage our programmers from wanting to make changes to code during competition events.

We could have easily used last year's control system to make our robot do what it does.

I think we'll take a long hard look at how we approach programming next year...this year we seemed to spend a lot of time playing with neat sensor features, rather than starting with the basics of making the mechanisms do their job well with well organized code, and having a good, flexible dead reckoning autonomous.

I think there are a few teams who have been able to do some neat things this year they couldn't before, and hopefully next year we'll see more.

[Tom Bottiglieri]

We absolutely did things this season that wouldn't have been possible on IFI hardware, given the time limit on development. Had FIRST put an illuminated target on the trailers, we may be humming to a different tune right now.