cRIO, has it 'upped the game'?
 

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?

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

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

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

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

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

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.

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

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.

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

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.

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

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?

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

Good feedback so far. Thank you all.

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.

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

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.

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

Here's what we're using that the old controller could not give us on its own: Responsive 6-sensor drive train control in parallel with 15fps image processing WITH 900 bytes of WHATEVER data we want sent back to the driver's station, in WHATEVER format we want the data. In addition, we hook a laptop up to the driver's station to easily read the data, interpret it, and display the data in whatever format we want, using ANY language we want for the GUI (Java for us). Useful languages include Java, C++ (etc), Flash, good ol' perl/asp/whatever lollipop flavor script with html/css webpages, Oracle for data storage, and the list goes on, and on, and on. Sometime this summer we'll write a whitepaper on how we custom-wrap and decode the data.

Sure, the mechanics of this year's game make it hard to utilize all of that functionality properly ... just disregard the fact that we've had issues with the hopper jamming and our team would be perfectly satisfied with our bot. The thought of using additional microprocessors with the IFI controller in order to offset the extra CPU time required to do all of the above would add unnecessary complexity to an already complex system of systems.

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

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.

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

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.

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

Couple things that immediately come to mind:

--In circuit debugging (:yikes:). This allows programmers to very easily see what they're code is doing while it's running. While one could argue that the same thing could be accomplished with printf statements, the amount of data that is available more readily in a much more logical format (i.e. code tracing) is a vast improvement.

--Custom dashboard with increased user data size. Yes you could write your own dashboard client for the old control system; again I could argue the ease of implementation here, but I won't. To me, the big thing is increased communication between the robot and dashboard. 984*50 bytes per second as opposed to ~15*50 max (assuming you make use of unused PWM readouts, all the user bytes, etc) on the old system. With this kind of capacity you can now stream back live video. Not possible on the old system, unless you're a fan of 8x8 pixels video...

--Increased processing. New controller: 400 MHz, 760 MIPS, including a Floating Point processor; Old controller: 80MHz, 10 MIPS., no hardware FP support. I.e. we can process video now, among other things.

--Graphical programming language: Some people hate LabVIEW, but my experience is it makes programming much easier for people just learning it. Case in point: the LEGO NXT software is based off of it.

Just because teams haven't started using all of it yet, doesn't mean that it isn't an improvement. As has been noted, that's more a factor of little time to explore the capabilities of the system.

--Ryan

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

Our robot was doing a lot more this year during build than last year because of the new programming system...however, making it work under actual field conditions has been a challenge, and the long time it takes to build and deploy code in LV seems to discourage our programmers from wanting to make changes to code during competition events.

We could have easily used last year's control system to make our robot do what it does.

I think we'll take a long hard look at how we approach programming next year...this year we seemed to spend a lot of time playing with neat sensor features, rather than starting with the basics of making the mechanisms do their job well with well organized code, and having a good, flexible dead reckoning autonomous.

I think there are a few teams who have been able to do some neat things this year they couldn't before, and hopefully next year we'll see more.

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

We absolutely did things this season that wouldn't have been possible on IFI hardware, given the time limit on development. Had FIRST put an illuminated target on the trailers, we may be humming to a different tune right now.

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.

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

The question cannot be fairly answered, because as the weeks unfold, we find it less and less necessary to utilize the newer features of the cRIO, that could have easily been done with the IFI system.

Example, color and camera tracking is not vital (nor an advantage) to win in this year's game. We spent so much time on a shooter, turret, and camera tracking, when indeed a team that didn't put in the time, create a basic dumper bot which is more effective and accurate, and most importantly, easier to build.
Lets all remember what happened early on during the build season. Many were skeptical about dumper bots, simply because you had to aim perfectly and be at almost zero range (bumper to bumper) to score points. After participating in two events, a great no. of teams barely knew the basics to get their robot going. How do I know this? Just look at the amount of teams that either didnt move or move during autonomous in matches. Even though the code was provided, teams still had a difficult time.
Due to how the game is playing out and level of support this year, it was not necessary to maximize the potential of the cRIO yet, to be successful in the robot part of the competitions.

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

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.

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

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.

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

I believe the cRio / Jaguars in general has upped our game. We were able to run 7 PID loops updating at 5ms on our robot without the cRio even breaking a sweat. With the help of vision assistant to calibrate lighting, we were able to get our robot consistently scoring in auto mode using the camera to track/hunt our opponents. Anyone watching or that went Chesapeake can attest to this. Our swerve drive was alot more responsive with the cRio as well.

On a down side the system feels unpolished overall. It has so many parts and pieces that can lead to unexplained issues it's hard to know were to start debugging. Our team used Windriver, and while it worked OK, sometimes it would refuse to connect to the cRio after a reboot. Having to manually change the path to Deploy user code was annoying. We would sometimes get kernel errors if we didn't reboot the cRio between testing versions of the code. We have also been adversely affected by other teams shutting down mid match for no apparent reason, and in a game where a dead robot means death this can be hard to swallow. Was it a Driver Station ESD Issue? Did the E-stop connections come loose? Did the Bridge Reboot? Is the connection to the Camera Loose? Did the code crash? Is a crimp on one of the RJ-45s Bad? Why has the robot run all weekend and then suddenly stop running?

The old IFI system was simple, give it power and plug in the radio. I don't think I would want to go back to a 8-bit PIC, but I wouldn't complain if they released another all in one unit.

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

So, to paraphrase, this year's game didn't really tax the capabilities of the controller?
I think several others have made similar observations and they too framed their reply in the context of competing and scoring.

It seems apparent to me that FIRST designed Lunacy so that those measures of success could still be achieved by most teams while still planting the seeds of, and providing the foundation for, more creative use of computation.

Personally I feel that, had any team fielded a robot that could juggle 3 orbit balls under software control, that team would have been a winner -- even if their bot never scored a point.

But that's just me. ;-)

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

Same on our camp. The game really didn't call for much over-the-top sensory or programming other than the usual TCS and camera tracking. Time will tell (and the GDC) about how useful and powerful the cRIO actually is in competition.

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

I've thought about this a bit more, and have a theory for why we're seeing answers from emphatic YES!-es to less-enthusiastic "ho-hum, nothing new here".

I think there are multiple ways to answer this question, and I'll give my answers to each formulation of the question:

Did it raise the game of the least-competitive team? Probably not: a team that couldn't program last year still will be perplexed by the cRio, which will not be helped by the more-complex setup procedures.

Did it raise the game of a 25th-percentile team? Probably: once setup was complete, labview allows for nearly anyone to hack together a very basic robot program, add new motors, maybe even a limit switch or two. Just add the motors and link them to joystick buttons or axes and you're done. Granted, you could do this on the IFI controllers (pwm03 = oi_input1_x), but it required you to be able to read and understand C++ in order to figure out that that was the line of code you needed to add. Labview is a bit easier.

Did it raise the game of a 50th-percentile team? I'd say probably to definitely: No-penalty floating-point use in C, the quite reliable WPILib and the easy-to-use advanced labview VIs probably helped teams in the middle of the pack for whom things like PID control or camera tracking was previously far out of reach. I taught a first-year programmer from another team the basics of what a PID loop was, how to add it to his robot, and how to tune it in an hour at the Waterloo regional. That would've been unthinkable on the IFI controllers.

Did it raise the game of an elite 99th-percentile team? Most likely not: These teams were already capable of using whatever sensor or control technique they wanted in the pre-cRio days, no matter the difficulty of integrating it with the IFI controller. These teams had/have the experience and/or mentors who knew how to get things done no matter the controller.

So really, the answer to this thread's posed question depends entirely on how you interpret the question. Most of the 'no' answers I've seen are probably coming from teams in the latter category. Personally, I think the cRio is something of a field-leveler, at least until the more-advanced features are allowed to be unleashed.

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

Ditto to that. If anything I have seen more simple robots this year.

There is potential but the execution has been horribly difficult. I can envision a great improvement next season once the teams have experience with all the peculiarities of the system.

WC :cool:

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

The post was about whether or not the new control system has upped the game. The fact that many teams designed robots that in general may be less complex than last season (i.e. dumper bots) with no camera or other sensors is evident. Of the 100++ robots I have seen this season so far, only 1 team effectively demonstrated the use camera tracking and sensors to score in a trailer during autonomous (team 192). The most dominating team that I have seen at a regional is 254. They did it without using a camera and by having the most dominating dumper bot. They are successful in large part by having a disciplined drive/coach team that have practiced more often than an opposing alliance combined. cRIO or IFI, the results would have been the same for them. :)
Is there lots of potential? Of course! :)

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

With the amount of time it took to setup and the complexity involved due to the number of auxiliary components, it only added to the frustration of knowing so much more. Don't get me wrong - I think the cRio is an awesome product with capabilities way beyond that of the IFI controller. After having used it, I would love to use it if I were to build a complex robot that required a lot of processing power. However, my question is how much of this EXTRA juice can you really use in an FRC Competition? I am sure if you really wanted to add many sensors and write thousands of lines of code, you very well could. A match is only about 2 minutes long and autonomous is only 15 seconds long. Does the processing power and the use of extra sensors really help up the quality of the robot that much?

On team 25, we try to keep things as simple as possible and at a level the students can comprehend. The extra power and complexity has not really helped other than cause a lot of frustration and a huge learning curve. Rather than "upping the game", I think the change over to the new control system has simply caused a lot of frustration. I feel the focus was on adding a lot of extra functionality rather than giving us something that is tested and reliable for its basic purpose (Ex, Jaguars, Driver Station).

Overall, I am pleased with the cRio but not with the implementation. It needs to be more reliable and way simplified for a FRC Competition. While many of us on here are very knowledgable and into "building robots", there are many schools I help out at competitions who barely get around to have a working robot. FIRST is also supposed to help those students get inspired into careers of science and technology. It is certainly not easy when they have a system beyond their comprehension.

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

We're measuring (and using) wheel RPM from encoders without worrying about timers and interrupts.

We're doing trigonometry and physics calculations everywhere without worrying about how to deal with floating point math.

We're tuning PID controllers without downloading the code more than once.

We're using the object-oriented features of C++ and loving them.

We're running separate code in separate threads rather than worrying about countless state variables.

This year, thanks to the cRIO, we've been able to spend more time thinking about what we're going to do and less about how we're going to get the computer to do that.

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

No. Not with considerable difficulty and bashing of the head against the wall. The problem is that the power probably overshoots a significant number of people on this forum. Even the concept behind the PID controller overshoots a lot of people

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

Very interesting and informative thread.

There was a mention of cables coming loose. The primary one I've seen is the bulky cable that connects the digital module to the digital breakout board. The connectors on the cable cannot reach the breakout board, and since it is a bulky cable it can/will work its way loose. I'd highly recommend adding hex extenders from a video card or another cRIO module to retain the cable. Zips or other retention to keep the cable from flopping would also be a good idea.

Greg McKaskle

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

I'm not sure what the problem is that you've seen. The 37-pin cables we received can be secured to the Digital Sidecar just fine. The 4-40 standoffs that came with the control system for that purpose are exactly the right size. No extenders should be necessary.

We're actually using a shorter and lighter ribbon cable on our robot, but we're still fastening its connector to the Digital Sidecar using the provided standoffs.

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

oh its upped the game alright. A whole new level of challenges to work through!

the rio is a great piece of hardware; insanely durable and reasonably powerful for a realtime controller. it could be said, however, that its not inexpensive (get it? ni? har har... har... ehem). 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.

with the power too comes loads of fluff. Im sure teams who are downloading and programming code in labview note a significantly longer code-change-to-execution time than we could have possibly even imagined in previous years. Youd figure that these libraries would be optimized to cache themselves on the rio properly so they arent downloading every time you make a change.

ok, time for some positives. Full control over image processing code, double precision floating points, "massively" parallel programming WITHOUT LOW LEVEL INTERRUPTS (yay), a huge library of analysis and mathematical functions at our disposal, professional-grade PID controllers (or P^3 1/I D controllers rather...), and all the well-timed subprocesses that you could ever need.

Its the first year we have been exposed to this powerful peice of hardware, but as with all upgrades there are always the bugs that need a squishin'. i say give it 2 years and we will start seeing more utilization of this controller's power.

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