cRIO, has it 'upped the game'?

[waialua359]

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.

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

[Kingofl337]

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.

[gvarndell]

Originally Posted by waialua359

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.

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

[Akash Rastogi]

Originally Posted by EricH

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.

In short, Not Yet is my answer as well.

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.

[Bongle]

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.

[Wayne C.]

Originally Posted by Dave Flowerday

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?

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

[waialua359]

Originally Posted by gvarndell

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

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!

[Bharat Nain]

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.

[FRC4ME]

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.

[Adam Y.]

Originally Posted by Bongle

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

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

[Greg McKaskle]

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

[Alan Anderson]

Originally Posted by Greg McKaskle

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.

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.

[Uberbots]

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.