cRIO, has it 'upped the game'?

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

[thefro526]

I'm limited in my knowledge of the precise inner-workings of the C-Rio and other things in the new control system. But, to answer the question, "Not Yet."

I personally have not seen my team or too many other teams of our Caliber do anything particularly spectacular with the control system. I'd have to say that we could've done everything that we did on the C-Rio on the IFI system, but we're also more familiar with IFI's System. Really, the C-Rio is nice but most of it's features aren't used by most programmers and teams.

Where the game has been stepped up, Maybe even redefined is in the Interface. This years driver's station or operator interface or whatever you'd like to call it is Amazing. Outside of the robustness issues some have been having it think it's a huge advancement from the old system. I've seen many more teams pushing the envelope in terms of control layouts and feedback to operators then before. I think it's awesome now how someone can wire up a button in a few minutes without having to track down Gameport hardware.

[EricH]

Originally Posted by thefro526

I'm limited in my knowledge of the precise inner-workings of the C-Rio and other things in the new control system. But, to answer the question, "Not Yet."

I'm going to say that too. We've been severely limited this year; full capability is not here for our use yet. Over the next year or two, that will change.

However, before that happens, some reworking needs to be done. Not to the cRIO, necessarily, but to the DS. We've all heard the problems: ESD killing it, various ports dying for no apparent reason, etc., plus the cRIO or one of the other robot-side components has one or two "vulnerable" cables where, if they lose connection briefly, your robot is stuck until a reset happens.

Should this structural reworking happen during the offseason (as I hope it will), I expect to see many more things that the IFI processors couldn't do next year and the year after. If not, I'll see them stop in the middle of happening.

In short, Not Yet is my answer as well.

[AdamHeard]

It's been a while since my programming days as a high schooler, but mechanical is just too much fun.

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.

I hear using C and Windriver eliminates this issue, and we may switch to C during vegas.

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