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?
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
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
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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. 98450 bytes per second as opposed to ~1550 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
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.
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.
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).
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.
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.
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.
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.