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

Your experience may differ, but from what I've experienced the frame rate is a much larger limiting factor than the calibration and color recognition in terms of real-time tracking. This may vary from regional to regional (say if you weren't able to lock on at all in the very... unique... lighting at Boston), but even teams who are able to lock on haven't had a whole lot of success using camera-guided scoring outside of particular scenarios and autonomous (particularly once other robots sit still towards the end of auto).

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

I agree with you Sean. This year's game didn't call for a hugely advanced robot with tracking, pitch, and velocity controls. Some had it, but most weren't brilliantly successful due to the difficulty of the orbit balls. The most complex programming most teams had to do was throwing in some sort of traction control... and even that was optional. There is practically no autonomous either.

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

If I understand the way the color thresholding works, a smaller band of threshold values should process faster. An illuminated target throws more consistent light, allowing you to tighten your calibration. The main issue with tracking now is the latency between the real world and output of tracking software. We are getting relevant data at 15Hz, which is plenty fast for "sit and pick". Unfortunately the name of the game is "pin and puke", at least up to this point.

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

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.

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

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.

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

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.

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

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

Our robot did not do anything this year that it couldn't have done last year and moving the image processing from the camera co-processor to the cRIO was a step backwards in my opinion. We spent a lot of time optimizing for 15fps and still had a hard time getting the thresholding completed in less than 10ms so we could guarantee that all the processing completed each 20ms frame. In the end we still had a lot of trouble with different lighting and the black curtain background.


The good things about the new control system include:

1) The ability to read and write files larger than the IFI EEPROM area. Although we found that under some circumstances file I/O caused image capture pipeline "slips" that we never resolved - the last WPILib update may have fixed that. We were able to do pretty much the same thing with old dashboard telemetry stream but you needed a laptop or PDA at the OI to capture the data.

2) The debugging environment was helpful. (It would have been nice if the profiler was enabled, though)

3) The use of floats and doubles is nice but in my opinion it took away the opportunity to teach the programmers about integer numerical methods (pre-season, of course).

4) Fast program downloads

The bad things about the new control system include:

1) SWaP (size, weight and power) and Cost

2) Strange and largely undocumented FPGA limitations - only two analog channel accumulators on module slot 1 only? Shaft encoders. No apparent way to synchronize interrupts with analog samples?

3) Very constraining default implementation for the gyro and accelerometers

All-in all we will be able to do more with this processor in the future but you have to keep in mind that the cRIO system was designed to use the FPGA for all the hard real time functionality and the teams need access to that in order to really take advantage of the architecture. Also, the image processing should be off loaded in the future as well.

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

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.

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

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.

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

Is that because of the tools or is it because no one knows how to use the tools? I can think of so many things I can do with LabView that quite frankly I would never be able to implement in the IFI controller nor would I want to. As an electrical engineer give me a block diagram and the Laplace transform and I can build you a PID controller faster than you can write one for the IFI controller.

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

^ Came here to say this. ^

I predict that next year will open up a lot of functionality in the system. All those extra inputs on the Jaguar? The matching RJ-11 plug on the digital sidecar? These items together make for a very powerful control system. I expect they'll allow use of CAN next year, and that the mechanisms people build will benefit from the built in encoder inputs and limit switches on thee jaguar.

Once these features are enabled on the jaguar (and the cRIO libraries include CAN), the system will be very close to some of the (very expensive) hardware I use on a daily basis in the real world.

While you can do many of the same things on the IFI, not having to spend a week learning each complex task allows you to focus on even better parts of the cRIO, and allows entry level teams with no programming mentors to still be very competitive from the software standpoint.

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

We aren't doing anything this year that we couldn't have done before... in fact, in many ways we are doing less than a couple years back when we had a mecanum drive with four PID controllers reading encoders and managing wheel speed combined with camera tracking.

Labview has allowed us to develop some nice graphs, charts and display software for the driver station, but we had done that already using labview and the feedback from the IFI controller.

Using labview on the robot has made some things, such as drag'n'drop PID controllers easier... which, while good in the sense that it makes it easier to implement also means that the students don't get the experience of building and tweaking their own PID code.

Wireless programming is nice, but wouldn't have been too difficult to implement on an IFI controller if we felt it was that important. The biggest upside to the new control system seemed to me to be real-time video feedback from the robot... something that has yet to materialize as far as competition goes.

I guess my feeling is that we've stuck a 600Hp Corvette engine into a Pontiac Firefly. Yeah it's cool, and it sounds really great when you rev it, but for the most part it is overkill and the full power of the engine (or cRio) is unlikely to be used. In many ways (size, weight, cost) it is actually a step backwards. I thought the IFI controller was a very appropriate tool for the job we needed it to do and was disappointed to see it dropped... but the students seem happy enough with the new system regardless of whether or not it has "upped the game" for us.

Jason

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

That's not a matching RJ-11. Look closely and you'll see the locking tab is to one side rather than in the middle. It's an I2C connector. It doesn't provide a CAN interface.

In order to use all the Jaguar's fancy features, we'll need a CAN module for the cRIO. I do expect one to be in the 2010 Kit of Parts. I also hope the Jaguars' reputation for frailty turns out to be a fleeting thing.

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

I don't see a big upgrade either. A lot of what teams are doing this year, could have been done with the IFI controller. The difference is the speed of software development. As Alan and Dave have pointed out, there's more out of the box code than with the IFI system. I know teams that I've worked with have said they've got sensors worked quicker than every before. Outside of that, I haven't heard of any big improvements. Really, we've a few more inputs and outputs and that's it...

That being said, this control system DOES have a high ceiling in terms of what can be implemented in future years. Being able to use the CAN interface, and getting new modules in future years will change the game. Like with any major platform change, it'll take time for people to see the full benefits. Because this year is the first year for the new control system, FIRST didn't want to overload teams with a high learning curve. I expect this transition to take 2-3 more years. Perhaps then we should discuss this.

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

On our team, we are really not doing anything that we have not done before. There are really no features on this robot that we could not have implemented in C on the old IFI platform controller.
To me the key benefit has been that I have found it much easier to teach students how to program in LAbview vs programming in C. The Graphical flow langauge seems to be easier to understand for inexperienced programmers as compared to written code (especially when I write it :] ).

In future years, as everyone becomes more comfortable with the new hardware, I think more advanced features will begin to come into play.
Just on speed alone, we can certainly all do way more on a 200MHz machine compared to 10Mhz, especially when we do not need any interrupts to support real time features.