search

strongback / strongback-java

A library for FIRST Robotics Competition robots that makes it easier to write and test your robot code.
MIT License
41 stars 38 forks source link

No robot code execution - FMS or roboRIO related instead? #78

Closed niharmitra closed 7 years ago

niharmitra commented 8 years ago

We are Team 8 at Silicon Valley Regional. We've been having issues in some (not all) of our qualification matches today, where according to the driver station, there is robot code and the communications are good, however no robot code runs (no autonomous, no print statements from our code, no control/teleop, so no code appears to be executing).

We aren't sure exactly what the issue was, but we were wondering if this lines up with any fault that can happen when Strongback is used incorrectly? We thought disabling Strongback (strongback.disable()) might cause this, as the FMS disables our robot shortly between auto and teleop modes, and we only start Strongback in robotInit, so it may have no restarted Strongback. However, at Central Valley Regional this was not an issue, so we aren't sure why this works.

Mid-match, restarting robot code from the driver station fixed the issue, restoring us to normal teleoperation.

If it's not a Strongback issue, we'd appreciate any information you may know about how this relates to the Field Management System or roboRIO instead.

rhauch commented 8 years ago

@niharmitra, If the FMS disables your robot between auto and teleop, this could definitely lead to a problem if your teleopInit() method doesn't call Strongback.restart().

Your robot code has to be able to handle any combination of being initialized, disabled, and started in autonomous and/or teleop.

Note that three of the autonomous, teleop and testing mode initialization methods call Strongback.restart(), which will kill any commands that might have been started but not stopped/cancelled in a preceding mode, and ensures that all of the Strongback components are running and ready to go. You can see these calls in our team's code from this season.

Our robot did have problems in the final matches in our regional when our robot appeared (via the robot signal light) to have lost power completely. Fortunately, it booted immediately, though this did cost us valuable 20 seconds during the match. We believe that our main breaker was the problem, since in the pit we could replicate the problem by simply wiggling the breaker body (not touching the actual lever or wires). However, this is clearly a different phenomenon than you describe.

UPDATE: Since it sounds like you're at a competition this weekend, you should be careful about what changes you make to your code. If you're currently calling start() or restart() in your robotInit() method, I might suggest leaving that there and simply ensure that each of the autonomousInit(), teleopInit(), and testingInit() methods properly call Strongback.restart() first thing. It should not hurt to call restart() multiple times in a row, since when the method is called while Strongback has already been (re)started all it does is kill any currently running command. Good luck, and let us know what happens!

rhauch commented 7 years ago

@niharmitra Were you ever able to get this working? I know it's months too late, but I know @AGausmann had stopped by your pit during the 2016 World Championships, and I thought he said you were running okay.

We'll close this issue without any changes if this is not a problem anymore.

niharmitra commented 7 years ago

We believe that the issue may have been related to some issue with Disabled. If we enabled and then disabled the robot in queue, then played a match, we would need to restart the roboRIO in match. When we restarted the roboRIO right before playing the match, we didn't experience this problem. So while we weren't able to ever precisely determine the problem, we did find that workaround.

rhauch commented 7 years ago

Starting in Strongback 1.2, we rewrote the logic for when and how the Strongback thread runs the various services and how the start(), restart(), disable(), and stop() methods work. The disable()method will kill all commands but keeps the services running (ready to restart quickly), while stop will stop the services. Either way, start() and restart() are identical now and both will get Strongback running again after being disabled or stopped. See #85 for details.

Anyway, it's far more efficient now and we've fixed some strange behaviors 1.1.x versions had. But whatever version of Strongback you use, be sure to test repeatedly disabling and re-enabling the robot with Strongback 1.2 or later (including the newer 2017.x versions).