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.

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

[ebmonon36]

Originally Posted by Alan Anderson

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.

This was the case with our team. We have never had a real programming mentor. We have had a few mentors and students who knew the basics of C and could write simple code for the robot, but we never graduated to learning interrupts and writing PID loops. It was all too intimidating for me. The robots were always limited when it came to sensors. I think we had the gyro and accelerometer on the robot for the last two years, but we never used them. We could make the CmuCAM find things in Labview, but never in the real code. Our autonomous code two years ago unfolded the robot arm. Last year, the robot attempted to drive straight, but instead turned left and caused penalties. By IRI we had finally worked out the bugs and made it drive straight and cross the first line.

This year, we began learning LabVIEW in December. I had about 7 hours of experience with the basic functions because of one of my college classes. We were able to get the camera to track things. The drive base took a while to get out of the shop, but when it did, the Ackerman steering code was ready for the robot and completely debugged by running the code locally and using gauges to output what was going on. The Ackerman steering on our robot had independently steered modules controlled by PID loops that we were able to tune in real-time. Each wheel speed is independently controlled. We are using the gyro, camera and two encoders and a few PID loops on the robot to guide it in our 7 different autonomous codes, which are selected through software (no physical autonomous selector switch) so we don't have to re-download if we want to change what we run like we did in previous years.

Most of what we accomplished this year could have been done in the old system, but we didn't know how. After having first hand experience with PID loops, I think if we had to, we could go back to the C coding and go through the thought process of writing a PID loop.
For our team, the cRio and LabVIEW has definitely upped our game.

[Kyle Love]

The cRio will be a bigger advantage next year, when you can use a lot more of the features, but as of now, nothing is really that much greater compared to the IFI controller. I have noticed that the auxiliary components to the new control system have had some issues. I know in one of our matches the power for the sidecar came out, simply because the screw that are meant to hold down the power connector into the sidecar were not long enough (they were the included screws). We have also noticed that the high impact hits that the IFI controller could handle, the new control system cannot (mainly not the cRio's fault, just all the other components). I'm sure it will get better as we get more years under its belt, but for this year at least, there was minimal advantages over the past system.

[Alan Anderson]

Originally Posted by Kyle Love

I know in one of our matches the power for the sidecar came out, simply because the screw that are meant to hold down the power connector into the sidecar were not long enough (they were the included screws).

I have no idea what you're talking about here. Unless I've totally lost my mind this morning, the sidecar power connection has no screws involved anywhere.

We have also noticed that the high impact hits that the IFI controller could handle, the new control system cannot (mainly not the cRio's fault, just all the other components).

The only thing like this that was even close to an issue for us was the power connector for the WGA.

[JesseK]

Originally Posted by Alan Anderson

The only thing like this that was even close to an issue for us was the power connector for the WGA.

This was true for us as well, and we solved it the same way we solved the problem with the loosening PWM's on the old IFI controller: clear nail polish.