2015 RoboRIO/Control System Feedback

[Kevin Sevcik]

Spawning a separate thread for Positive/Negative control system feedback, so it doesn't get lost in the mass of replies to 2015 Lessons Learned. I figure it'll be easier for our NI denizens to keep track of things in here.

Our experience was overall positive. We were already using CAN, and the new 2-wire native CAN bus and web config made things so much simpler that setting up our 9 Talon SRXs was laughably easy. I nearly giggled updating the firmware of all the devices via the web config.

My only bad experience was with the analog inputs. We had string pots for feedback on our elevators, and we ran into a baffling issue trying to add any other sensors to the robot. We wanted an IR prox switch, IR distance sensor, or ultrasonic to tell when we had a tote to stack, but adding any one of those screwed with the string pots. I'd plug in the IR distance sensor and the elevator would start twitching as the signal for each pot started bouncing around. I originally figured it was because our 5k pots were outside the 3k impedance NI recommends, but switching to 1k pots at Champs didn't help. I finally gave up worrying about that and plugged in our navX MXP board just to see how bad that would make things. Except plugging in the navX magically made everything stable, even when I plugged in the previously problematic IR distance sensor. I'm still slightly lost as to what was going on, but I'm hooking up an o-scope to the bot when the crate shows up to see if I can at least isolate the problem to the 5V, GND, or signal lines.

[Oblarg]

Reposting my comments from other threads:

The new control system rocks. I cannot stress this enough. This was the first time in my 8 years of FRC that my team has fielded a robot without a single major controls problem during competition. The new motor controllers are absolutely fantastic; we didn't have a single problem with our Talon SRX's, and the integrated signal wires are a godsend (even using them in PWM mode, being able to easily daisy-chain motor controllers on the same side of the drive train saved us a lot of wiring effort and mess). Just about everything is a huge upgrade from what it was before.

I'll add one more minor quibble in that the signal cables, when plugged into the RoboRio, seemed mechanically less-secure than they ought to have been, though this is fixable by simply dabbing some hot glue on the connector once it's plugged in (thanks to team 1678 for showing us this trick at championships last year).

[Thad House]

The mDNS SmartDashboard issue cost us a match thursday at champs. I hope they can figure that and maybe a few other mDNS issues out for next year. Having to restart Driver Stations when running back to back matches is sometimes very odd.

Also, what happened to allowing F1 to enable the robot? It doesnt work anymore on the new DS.

[Alan Anderson]

I saw lots of teams with lots of control system issues this year. None of them was really the fault of the control system itself. When the instructions are followed by someone who actually pays attention to them, and who is not sloppy with the wiring, things just work. The roboRIO's web console is great, and the rework of the DS-to-robot communication protocol seemed to make a positive difference in connectivity. I just wish Windows weren't so unpredictable in how it deals with switching between networks with and without DNS active.

I do have one other mildly negative observation: the Weidmuller connectors seem to be happiest with 20 gauge wire, but teams seem to want to use 18 gauge or thicker. This makes inserting the wires without risking short circuits more difficult than it ought to be.



More than one team accidentally enabled their robot by pressing the F1 key while in another application on the Driver Station, so using F1 to enable was changed to the three-key "[]\" combination.

[Thad House]

Originally Posted by Alan Anderson

More than one team accidentally enabled their robot by pressing the F1 key while in another application on the Driver Station, so using F1 to enable was changed to the three-key "[]\" combination.

Oh thats good to know. I didn't see that get published anywhere. For demos in the past where WiFi connection was awful, we would sometimes put the computer in the robot, and use a wireless keyboard or controller to enable and disable the robot. Good to know there is still a button combination to allow this.

[Sparkyshires]

The smartDashboard introduced an issue to our team. On the second final match on Galileo, the smart dashboard did not populate with the sendable Chooser we use to select our autonomous program. If we hadn't had some of the absolute best volunteers and tech guys I've seen in my entire time in FIRST helping me figure it out, our robot would have run an incorrect default autonomous and flipped over.

The fact that they took the digital input away from the driver station and put selecting something as undeniably important as selecting autonomous and put it something as shaky and unreliable as the SmartDashboard was, in my opinion, the worst move FIRST made this entire season.

Either bring the digital input on the driver station back or fix the SmartDashboard. And if the smartDashboard is fixed then make it easier to implement. I consider myself an experienced programmer, and if I was not able to figure it out to the extent that I was still having issues, then that means other teams were not afforded the luxury of selecting an autonomous before a match.

That is an issue.

I apologize if this sounds angry and emotional, and definitely biased. It is. As I said earlier I had to work through this issue in the finals on our division so it is quite near and dear to my heart.

P.S. Also shout out to the guy who was finally able to fix it! I'm afraid I didn't catch your name during it, but not only were you polite during that stressful period, but you were kind to me, told me what was wrong and how to fix it, and then took your time without me even asking to come back to the pits and fix it on our other computer. I cannot thank you enough.

[tStano]

Originally Posted by Alan Anderson

I do have one other mildly negative observation: the Weidmuller connectors seem to be happiest with 20 gauge wire, but teams seem to want to use 18 gauge or thicker. This makes inserting the wires without risking short circuits more difficult than it ought to be.

The spec says they're good to 16 gauge if I remember correctly. If they're not, the spec should reflect this. Also, there are a couple places where 18 gauge is the minimum, namely Vin for the PCM and compressor out on the PCM. The problem is remedied slightly if you use wire with thinner insulation.


And now, to some of my personal complaints.

There was a windows 8 setting this year which didn't play nice with the driver station. It disabled controller outputs sometimes.

The Axis camera thing where it would work only on the field, not at home and not in the pits unless you're a networking whizz with time to figure it out.

Also, those fuses which were really hard to put in.

And the fact that(at least at the beginning of the season, I've been too busy recently to check if that has been fixed), you couldn't use the new driver station to control cRio robots, and the cRio and roboRIO driverstations were recommended not to coexist.

[Alan Anderson]

Originally Posted by Sparkyshires

Either bring the digital input on the driver station back or fix the SmartDashboard.

Yeah, there are apparently some recalcitrant bugs in the Java Dashboard, especially around the Sendable Chooser. I have confidence that they will get fixed.

But even before they do, digital inputs are still available on the Driver Station. Just use the Launchpad board that was in the Kit of Parts this year instead of the Cypress board that was in the Kit of Parts previously.

Or use joystick/gamepad buttons to select the desired routine. Or use a physical control on the robot itself. Or any of about a half dozen other things that I can think of quickly.

[Jefferson]

Originally Posted by Alan Anderson

More than one team accidentally enabled their robot by pressing the F1 key while in another application on the Driver Station, so using F1 to enable was changed to the three-key "[]\" combination.

This has never happened to our team (to my knowledge). Moving it to the three button press seemed necessary, but I wasn't opposed when it was brought up in Beta. However, I witnessed a much more likely scenario at the shop. Because the old enable (F1) wasn't there, the drivers just moused over the enable button on the screen to enable and then used the enter key to disable. This meant the mouse was left over the enable key. During driver practice, the students had disabled the robot and were resetting the field, throwing pool noodles back to the other side of the drivers station when, you guessed it, a noodle landed on the mouse button, enabling the robot. Luckily it was just into teleop (not auto), so the robot didn't do anything.

Long story short, don't leave the mouse over the enable button or you could enable from across the room.

It seems to me an accidental mouse click is much more likely than an accidental F1.

[Jared]

Overall, the new system was a huge improvement.

Things I didn't like:

-MATCHES ARE NEVER THE RIGHT LENGTH OR EVEN THE SAME LENGTH. Seriously, most teleop periods are three seconds too long, but every now and then, we get a 2:15 teleop.

-Timertasks don't work properly if they are started before connecting to the driver station, but work if the reset button is pushed on the roboRIO. Troubleshooting this behavior is difficult, and it's never comforting when resetting or redeploying code puts the controller in a different state than a cold boot.

-Java timertask timing is worse than in previous years.

-It takes forever for robots to connect to the field.
-It takes forever for robots to connect to the driver station laptop after a match.
-Many of the workarounds and best practices to make these go faster (changing team number, restarting mDNS service, not having other stuff open...) aren't published anywhere.

-The log viewer was never released for the power board.

-Default joystick values used when a joystick is disconnected don't always make sense.

Good things
-WPIlib remained mostly the same
-Getting rid of CommandBase and putting the instances of Subsystems in Robot is a great change
-Toggle when pressed methods on Buttons is really useful.
-Loading code is much faster in Java, which is really nice for debugging
-The debugger works over an ethernet connection, which is awesome.

-The smaller size and weight is a huge benefit to teams.

-Current monitoring is an awesome feature to protect mechanisms from damaging themselves.

[Joe Ross]

Originally Posted by Thad House

Oh thats good to know. I didn't see that get published anywhere. For demos in the past where WiFi connection was awful, we would sometimes put the computer in the robot, and use a wireless keyboard or controller to enable and disable the robot. Good to know there is still a button combination to allow this.

See #2. http://wpilib.screenstepslive.com/s/...e#OperationTab

[MrRoboSteve]

I posted before on my feelings about the success of the control system. We need a physically rough game to make a final statement of success (hint hint GDC).

We used the current monitoring as a substitute for limit switches in one scenario.

Some areas for improvement:

. Transition between tethered in the pit and connected to the field was a continual issue.

. Certain laptops had trouble connecting when operating on battery. Theory is that certain network chipsets have some deep power saving mode that interferes with connectivity.

. physical retention for control cables at the roboRIO -- maybe someone should design a 3d printed part that sticks to the top/side of the unit, with retention like the Jaguar?

. Time between cold boot of robot and field connectivity was a lot longer this year than last. We actively avoided the power cycle this year, because it took so long. Maybe that was good, though, in the end, because we identified some faster ways of fixing things.

--

Regarding the complaint about match length, we did a fair amount of checking match length at one regional and didn't run into issues with running time. Jared, was there an event you noticed the issue at?

[JamesD]

Originally Posted by MrRoboSteve

. Certain laptops had trouble connecting when operating on battery. Theory is that certain network chipsets have some deep power saving mode that interferes with connectivity.

I've noticed this for several years now. You need to go into the properties of the WiFi adapter on the laptop and disable all power saving options. Otherwise when the battery gets below a certain level the Wifi adapter will actually disappear from the operating system until the power cord is plugged in again.

Originally Posted by MrRoboSteve

. physical retention for control cables at the roboRIO -- maybe someone should design a 3d printed part that sticks to the top/side of the unit, with retention like the Jaguar?

Team 111 Wildstang did this season: http://wildstang.org/blog/?p=225

[billbo911]

Originally Posted by Thad House

The mDNS SmartDashboard issue cost us a match thursday at champs. I hope they can figure that and maybe a few other mDNS issues out for next year. Having to restart Driver Stations when running back to back matches is sometimes very odd.

Originally Posted by Alan Anderson

I saw lots of teams with lots of control system issues this year. None of them was really the fault of the control system itself. When the instructions are followed by someone who actually pays attention to them, and who is not sloppy with the wiring, things just work. The roboRIO's web console is great, and the rework of the DS-to-robot communication protocol seemed to make a positive difference in connectivity. I just wish Windows weren't so unpredictable in how it deals with switching between networks with and without DNS active.

....

I completely agree with both of these quotes.

What I believe would make a huge improvement to the quirkiness of mDNS is to put a "Restart mDNS" button on the DS. It would give all users a really quick way to connect to the field and RR. Restarting the DS, changing the team number and changing it back, disabling and re-enabling the NIC all work, but they are all more difficult processes than what is needed.

[MrRoboSteve]

Originally Posted by billbo911

What I believe would make a huge improvement to the quirkiness of mDNS is to put a "Restart mDNS" button on the DS. It would give all users a really quick way to connect to the field and RR. Restarting the DS, changing the team number and changing it back, disabling and re-enabling the NIC all work, but they are all more difficult processes than what is needed.

The developers got a lot of feedback about the DS connection issues at the field. Based on historic response to feedback, it will likely be a focus for them in the off season.

Originally Posted by Alan Anderson

the Weidmuller connectors seem to be happiest with 20 gauge wire, but teams seem to want to use 18 gauge or thicker. This makes inserting the wires without risking short circuits more difficult than it ought to be.

Agreed. I saw a bunch of this last year as CSA, less this year as FTAA but I suspect a lot of it was dealt with by our crack CSA crews. I tell teams that, if you can't give the wires a good tug, they're not in there well enough.