Re: cRIO, has it 'upped the game'?
 

Yes, very good feedback.
The range of replies was really interesting.
For me, a little insight into the broad range of motivations for those involved in FRC.

Re: cRIO, has it 'upped the game'?
 

I joined last fall, so i only saw a few lines of IFI code, but from the older programmers on my team, this sounds way simpler, no interupts needed, no simple functions needing rewrite, etc... I came about 3 weeks before we got our crio (i was only in "old" programming 1 day), and once we got it, everyone was like "What?? how does this work???" from my C# and eclipse experience, i saw how simple this was, if you knew how to do it.
Once i looked at some of the functions, i saw things amazing to me, like barcode recognition and pattern matching, to userlights and switches

Re: cRIO, has it 'upped the game'?
 

the cRIO and all the modules are under warranty. If a team experiences a failure they can call into NI support and NI can try to get a new one shipped out overnight.

Re: cRIO, has it 'upped the game'?
 

Last year we had only one PID loop, and it took us about two weeks to get it working.

This year we have around 5 of them.

I think it has, yes (Though it could just be the fact that we finally got some mentors for our programming team).

Re: cRIO, has it 'upped the game'?
 

For once, we finally see eye to eye on something. We had Labview lock up on us several times at both of our regionals and had to run through a similar cycle. Not really sure if we should blame our ancient programming laptop (which is a P3 that ran MPLab and the IFI software like a champ), or Labview. Sadly, we didn't have the money this year to splurge on a new programming laptop. :( We've had similar issues with Labview in previous years when using it to work with the old CMU camera. We weren't able to get our camera working as we wanted to, but that was more of a fault to our programmers, not the hardware or provided software. Our team shared the same feeling as far as programming changes, especially since it could easily take 30 minutes to update a single thing in the program.

As far as the cRIO goes, I had my reservations about the system, and I still have them. Our IFI controllers have never failed us, and it never took 6 hours to get the field running on practice day (LA regional). Given, it wasn't the fault of the cRIO - but still frustrating none the less. I worked with a team in San Diego for several hours with pneumatics problems only to find out that the D I/O on the Sidecar was bad (the PWMs worked fine, and so did the relays) and wasn't able to read the pressure switch to turn the compressor on. It is a little bit annoying to have to plug the driver station into power in addition to tethering it to the robot. They solved this on the field with POE switches, but that doesn't help you when you're getting the robot inspected or on the practice field. Maybe we've just been spoiled by the tether providing power on the IFI system.

I know our mentor involvement as far as programming this year was concerned was minimal, but I'm not too sure if that was a result of the new control system or the game in general. Our robot was very simple this year, and had minimal feedback systems. In the past we've opted to use steering wheels (which required a lot of programming for the controller to interpret how we wanted it to move) and potentiometers/encoders for feature control, but they weren't needed this year, and we went for 2 stick tank drive.

I think I'm going to share Jon's view and reevaluate this in a couple years.

Re: cRIO, has it 'upped the game'?
 

When our robot was on blocks and we were just doing systems tests, we found that the best way around this problem was to plug the DS into the wireless bridge power supply. The plugs are both the same size and voltage. Obviously it doesn't work for when the robot is on the move (unless you build in a retractable wireless bridge power cord), but it is very nice because it allows you to do basic tests anywhere in the arena, not just near a plug.

Re: cRIO, has it 'upped the game'?
 

We found the best answer is to use a Vex Transmitter battery to power the DS. You can buy all the connectors to make a cable at Radio Shack.

Re: cRIO, has it 'upped the game'?
 

Not sure if you saw this at other regionals, but in Las Vegas the team setting up the network for the field were having a very difficult time. Apparently, everything has to be done in a very specific order to setup the game correctly, and if something is done in the wrong order or screws up on its own, the server takes over an hour to reboot and reconfigure.
We spent the entire Thursday morning waiting to test our robots because they couldn't get all the bugs fixed with the field.

On a local level, I think the cRio is great, though! Ethernet really makes it easier to interface your computer with the robot, and the wireless is definitely an upgrade. We were using the Labview Dashboard while running our robot on the field to look at motor pwm/traction control telemetry. My only complaint is that the refresh rate is relatively low, and the fact that we weren't allowed to use the cameras for real-time visual feedback (although I know some teams managed to do this by fitting the camera data into the standard data packet that you always get). Hopefully we can utilize this feature in the future.

Let me also mention that the USB chicklets we used in the past really were a hassle -- they were only compatible with certain devices, and even the ones they were compatible with had issues. In 2008 my team used a steering wheel on the chicklet, but whenever the OI was bumped slightly the chicklet would restart and take up to a minute to reconnect to the device. Sometimes not at all, so we had to give the drivers backup serial joysticks in case it happened mid-match.

Re: cRIO, has it 'upped the game'?
 

For anyone having issues with LabVIEW build time, 8.5 definitely has issues with libraries, especially the large analysis libraries, which we will be addressing next year. For this season, there are best practices which can help. Threads such as

http://decibel.ni.com/content/message/4818#4818

cover most of this. The summary is to try the other setting on the build specification, additional exclusion, library reductions. Depending on which libraries are being used, the setting may speed up your build or may slow it down depending on the actual libraries being used. Additionally, virus scanning will often lengthen the build by a large amount. If you need additional assistance, feel free to post specifics in the programming section. And again, we expect the to be much improved for next year when the schedule will allow us to make bigger changes.

Greg McKaskle