[Dave Scheck]

We use the C++ side of the world and have been happy with download times. We've found that if there is running code on the cRIO that flash downloads take a much longer time to download than when there is no code running. It almost seems like whatever is doing the installing on the cRIO has a lower priority than what is already running. Could this be something that would apply to the LabView side too?

Something that I would like to see improved is safety at the driver station. As it currently is, the driver station remembers the teleop/autonomous state between robot resets and between enable/disable cycles. This scares me tremendously for teams that aren't careful about the way they write autonomous. These apply to runs in the pit and practice field, not necessarily the real field. Here are my concerns (the theme is a robot should not move unless expected to):

1. If a team doesn't protect their autonomous code with a flag to tell if it has already run or not, they can accidentally rerun their autonomous if they go from auto-disable -> auto-enable -> auto-disable -> auto-enable. PROPOSED FIX: Always move the mode to teleop when disabling. Yes, if the team wants to run auto again they'll have to change the mode to autonomous, but I think that's a fair thing to do to protect people from a runaway robot.

2. If a team doesn't protect their autonomous code with some sort of lock in procedure (i.e. a switch that if not set at the OI will cause the robot to not move), they can accidentally run autonomous if they go through this sequence auto-disable -> auto-enable -> auto-disable -> robot reset (say, for a download). After the reset, if they want to run teleop and simply click enable, they will actually be in auto-enable since the mode hasn't changed. PROPOSED FIX: The driver station already automatically changes from enabled to disabled across a reset/comm loss. It should also force the state back to teleop.

3. There is no fast way to disable a robot with the Classmate. In years past, we've always had an external disable switch that we could physically have our hand on when testing in close quarters. Now, we have to move the mouse to the disable button and click. This reaction time could mean the difference between safety and tragedy. We have implemented an external software disable switch that neutralizes all of our outputs. Once that is switched, we can worry about moving the mouse to the disabled button. Yeah, I know there's the E-stop button, but I think it's ridiculous that when pressed, the robot needs to be completely rebooted to regain operation. PROPOSED FIX: Change the way the E-stop works. Rather than completely disable the robot, allow the user to re-enable it at the driver station (a simple disable-estop button would work). This button could be made available only when not connected to the FMS to prevent people from messing with it on the field.

There are far too many teams that veteran teams will be helping in the pits that won't have any of the three protections above. For our safety and theirs, please do something about this.

All three of these issues seem like they could be easily handled (at least on the surface) in a much welcomed DS update.