The 2015 FRC control system is a success

[MrRoboSteve]

Just returned from my second regional (one volunteering on the field, and one as a mentor). On the long drive back to Bloomington from Milwaukee, my thoughts went back to my nervousness about the new control system. I remember talking to Al at the regional in Minneapolis last year, relating my hopes that the roboRIO had the reliability of the cRIO, and not the Digital Sidecar. I've also heard tales of what happened in the last two control system transitions.

If you consider the logistics of deploying a new control system, there's a lot to be done -- think just about training 10,000 or so people on the new system, and installing new software on their machines. In the commercial world, a conversion like this would cost multiple tens of millions of dollars in people costs alone.

And yet we've done it. We learned at week 1 that the pit needed an organized software update process to get teams current. This last weekend, I saw CSAs and volunteers from teams worked together, getting the updates pushed in about an hour.

Good things about the new control system:

programming model largely retained (although the people who count from 0 (https://en.wikipedia.org/wiki/0_(number)#Computer_science) won)
superior mechanically (we'll need a game like last year's to be certain, though)
no more digital sidecar (yay!)
MXP ecosystem jumpstarted successfully
CAN on every robot just works
The PCM seems more reliable than the Spike for compressor control
Fewer mysterious on-field problems

Things that could be improved:

slow robot to field connection at startup
need to close/reopen DS software regularly at driver station connection
occasional issues updating firmware
occasional issues where the DS won't connect
occasional (less often, though) mysterious on-field issues

Based on my experiences, I consider the new control system a success.

Thanks to everyone -- the folks at NI, their suppliers, CTRE, the WPILib authors, the staff at FIRST, the alpha and beta test teams, the CSAs in the pit, and everyone I'm forgetting for contributing to a successful migration.

[tcjinaz]

Just returned from my second regional (one volunteering on the field, and one as a mentor). On the long drive back to Bloomington from Milwaukee, my thoughts went back to my nervousness about the new control system. I remember talking to Al at the regional in Minneapolis last year, relating my hopes that the roboRIO had the reliability of the cRIO, and not the Digital Sidecar. I've also heard tales of what happened in the last two control system transitions.

If you consider the logistics of deploying a new control system, there's a lot to be done -- think just about training 10,000 or so people on the new system, and installing new software on their machines. In the commercial world, a conversion like this would cost multiple tens of millions of dollars in people costs alone.

And yet we've done it. We learned at week 1 that the pit needed an organized software update process to get teams current. This last weekend, I saw CSAs and volunteers from teams worked together, getting the updates pushed in about an hour.

Good things about the new control system:

programming model largely retained (although the people who count from 0 (https://en.wikipedia.org/wiki/0_(number)#Computer_science) won)
superior mechanically (we'll need a game like last year's to be certain, though)
no more digital sidecar (yay!)
MXP ecosystem jumpstarted successfully
CAN on every robot just works
The PCM seems more reliable than the Spike for compressor control
Fewer mysterious on-field problems

Things that could be improved:

slow robot to field connection at startup
need to close/reopen DS software regularly at driver station connection
occasional issues updating firmware
occasional issues where the DS won't connect
occasional (less often, though) mysterious on-field issues

Based on my experiences, I consider the new control system a success.

Thanks to everyone -- the folks at NI, their suppliers, CTRE, the WPILib authors, the staff at FIRST, the alpha and beta test teams, the CSAs in the pit, and everyone I'm forgetting for contributing to a successful migration.


I'm with you, really pleased. Many problems we had in the past disappeared this year. If we didn't foul up the S/W update, the Phoenix CSA could have had a year without getting headaches in our pit.
Thanks NI.

[orangemoore]

The transition to a controller that is competently dedicated to the FIRST Robotics Competition platform was a big step that probably helped facilitate the "easy" transition.

While I wasn't around for the last switch from what I heard it wasn't as pretty and there were many problems.

[orangemoore]

superior mechanically (we'll need a game like last year's to be certain, though)


There was extensive beta testing with last years game that would probably indicate that it is well suited for robot to robot interaction. But that number was a small sample size. Another year where all ~3000 teams test it will prove its worth.

[JacobD]

And yet we've done it. We learned at week 1 that the pit needed an organized software update process to get teams current. This last weekend, I saw CSAs and volunteers from teams worked together, getting the updates pushed in about an hour.


I wish that the competitions that I went to had the same thing. Instead, they gave us a usb which actually had the incorrect firmware on it. So, I had to use my phone hotspot to get the correct version.

[Racer26]

The transition to a controller that is competently dedicated to the FIRST Robotics Competition platform was a big step that probably helped facilitate the "easy" transition.

While I wasn't around for the last switch from what I heard it wasn't as pretty and there were many problems.

The switch you speak of (in 2009) was FROM a purpose-built 8-bit PIC microcontroller based solution built by IFI that has since been discontinued AFAIK. We had serial radios operating in the 900MHz band, and you had DS->Robot Communications within 5 seconds (usually more like 1-2) of turning on your robot. The 8bit microcontrollers also left a hard limit on processing power that was significant.

Most teams didn't have issues, but a few of the do-everything teams had to start getting creative with their code so that they didn't run out of processing ability.

To me, I think the roboRIO transition is a reasonably good attempt to bring back many of the elements we used to like about the old IFI controllers (smaller footprint, robust construction that deals well with electrical faults), while keeping the improved processing power of the cRIO which has enabled many exciting computer-vision based autonomous routines to be so much more effective than the CMUCam based color-blob tracking we had pre-2009.

[Sperkowsky]

I was really happy with this year's change so much better. I agree with the driver station issues though i had to close it and reopen quite a few times throughout the sbpli regional

[Jared]

Although we have yet to finish the 2015 season, our team considers the 2015 control a significant improvement from the cRIO system. NI, FIRST, Alpha/Beta testers, and WPI have all done an amazing job once again.

The new system is cheaper, lighter, smaller, and faster - what more do you want?
The roboRIO appears to be quite robust, but not as heavy as the cRIO and can survive abuse from FRC competitions.
The PDB is smaller and lighter, and has built in current monitoring that works very well after you update the firmware.

The VRM seems to work well, though it is possible to burn out one of the supplies when it's run at full current for a long period of time. The connectors are much better than the old ones.

The compile/build/deploy times for Java are much faster than in previous years. Also, the imaging the roboRIO and setting up all the control components took me quite a bit less time than the cRIO, which I have a lot more experience with.

Minor issues:
PDP log files - they're saved on our computers, we send them to people to help us solve problems, but teams have no way to extract/view data (except for the name of the event they're currently at) from the log files.

There's no accurate timing on Java anymore for TimerTasks. This makes PID control or other control loops behave strangely.

The d-link radio still takes forever to turn on. Start up time for wireless connection hasn't gotten any faster even though the roboRIO boots much faster than the cRIO.

[Bob Schulz]

The control system does seem to be a success, however our team had two dreadful qualification matches where we lost communication between the driver station and the FMS. I documented this on the "Safety Issue with Driver Station cRIO mode" thread.

http://www.chiefdelphi.com/forums/showthread.php?t=136369

Team 5096 would certainly appreciate any troubleshooting ideas. We want to understand this problem thoroughly before competing next year.

[MrRoboSteve]

People will be happy to help you with your issue. It is almost certainly something about your robot and/or driver station.

I'd recommend starting your own thread, focused on your issue. Burying your issue in a thread started to discuss someone else's issue (some people call this "thread hijacking") means fewer people will pay attention to it.

Greg from NI is usually pretty good about helping out with issues, but you should note two things about the timing of your request:

1. It is Greg's day job, so you probably won't get a response from him immediately when you post on Friday evening.

2. There's an event this coming week that a lot of people in the FIRST community are focused on, so requests for help regarding next year's robot might not be treated with the same priority that they get during the competition season.

[simpsonboy77]

I wish that the competitions that I went to had the same thing. Instead, they gave us a usb which actually had the incorrect firmware on it. So, I had to use my phone hotspot to get the correct version.

I was the CSA at both of your events, and I'm curious what update was the wrong version. After week 1, leaving the thumb drive at pit admin was an 11th hour change and I should have definitely put a readme.txt to explain how to use all the updates, and which were which, I apologize for the inconvenience that caused. That thumb drive was identical to the others, and I used it at 6 different events this season. I think at Mount Olive I had 2 versions of the driver station, one was to update the DS, one was to overwrite the executable so it could view PDP logs.