[Mike Copioli]

My primary concern with the current system is the long reboot time for the DS.

On a couple of occasions a reboot of the DS was necessary during our build. At FLR not being able to reboot or power cycle the DS in a reasonable time caused us to sit dead in the water during Teleop for two practice matches. Auton executed but during teleop the robot did not respond to either gamepad. At the time we assumed the issue was either FMS or a problem with our robot code or possibly CAN. The symptoms were as follows:

- Auton executed as expected (the robot moved and obtained a ball)
- The FMS performed its transition to teleop. The robot did not respond to input from either Gamepad during the entire teleop period but all non-gamepad dependent systems performed (compressor tasks).
- Both Gamepads showed up in the dashboard view.
- All Jaguar LEDS were solid orange during the teleop period.
- The 2CAN status LED indicated the Plugin has loaded properly and that Comm with the crio has been established.
- The robot was rebooted between practice matches but the DS was not. The matches were back to back.


After all practice matches were finished, the FTA (Liz) allowed us and several other teams that were having different issues to connect to the FMS and pinpoint the issue. We regressed our robot code three versions from what was on the robot during the failed practice matches. We performed four tests with the last test using the code that was loaded during the failed matches. All four tests produced the same results.

-The Robot moved in auton and in teleop without issue.

This result led me to conclude that the problem was most likely an issue with USB. We were not able to reproduce this issue after several attempts. The next day (Fri) while on the practice field, the symptoms appeared again. Good com, Good CAN, solid orange LED on the Jaguars, both gamepads showed in the dashboard view and auton executed as expected. We rebooted the DS, re-enabled, and both auton and teleop executed as expected. The DS was not hibernated between matches I know this because we disabled hibernation after experiencing Ethernet issues when waking. What we did as a workaround was as follows.

Before each match the robot was tethered and a full system check was performed as part of our normal pre-match check list. Instead of powering down the DS, we kept it in the EXACT state as when the system check was performed.

I do not know if anyone else has experienced this EXACT issue if they have I would like to know. It would be more suitable for FIRST if when this happens during a match a timely power cycle or re-enumeration of the USB ports was possible. This is one of the many issues that presents when using a DS that requires a bulky OS to operate. The current DS provides some nice features such as camera feedback and a customizable dashboard. I would trade all of these features for robustness and expeditious and deterministic behavior. Camera feedback is nice if you are driving your robot through a building from a remote location or trying to defuse a bomb but I feel it has little value in a FIRST competition. As I tell my drivers, if you are looking at the dashboard during a match you are looking in the wrong place.