cRIO, has it 'upped the game'?

[gvarndell]

Originally Posted by Greg McKaskle

Very interesting and informative thread.
Greg McKaskle

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.

[byteit101]

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

[StephenB]

Originally Posted by Uberbots

When one of these controllers breaks its a huge expense to get a new one, and its virtually impossible for a hobby developer to even lay a finger on. I guess the price point really isnt arguable, but it is pretty high.

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.

[Oblarg]

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

[Mike Hendricks]

Originally Posted by AdamHeard

The build time kills me, In the past changing the direction of a motor or a value, compiling, then downloading took a minute tops, less if you had an embedded serial port.

With Labview, I'm scared to let any development happen at the regional, because of the several minutes it takes to download. Not to mention, THREE times at Los Angeles, LabView locked up during the deploy and had to be exited. At this point, the robot wasn't running, and we had to restart labview, reconnect, redeploy. We may be doing something wrong, and I may be lacking a detail or two, but this pains me.

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.

[Bongle]

Originally Posted by PhatMike

It is a little bit annoying to have to plug the driver station into power in addition to tethering it to the robot.

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.

[Kingofl337]

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.

[seg9585]

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.

[Greg McKaskle]

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