We have written code for our robot this season and it works fine, except one oddity: when we disable the robot in Driver Station after enabling it, the robot code is gone (No Robot Code displayed in the driver station). We could not determine why it had this behaviour.
Specifically, we have noted that:
No exceptions or errors are shown in the Driver Station’s console except the loop overrun warning from IterativeRobotBase
It doesn’t matter how long we enable. As soon as the code is disabled the robot code is gone
After showing No Robot Code, Driver Station restarts the code, but only after a relatively long time (at least 10 seconds, sometimes more), which is longer than if the code crashed and restarted by the Driver Station normally
Deploying an empty project or a simple program does not reproduce the issue
It’s clear that there is something in our main robot code that has caused this, but we don’t know where to start looking. Any ideas for what could cause the robot code to be gone when disabled?
Can you upload your Robot.Java code? My guess is that there may be something happening with the scheduler when the robot is disabled, but we can’t really help unless we can see the code.
We use a custom logic system with TimedRobot, not the command-based/scheduler system provided by default. It consists of multiple files, not just the Robot file, so it doesn’t make sense for me to post the code here. Basically, we have a Subsystem abstract class which every subsystem extends. We then keep track of those subsystems in a list. When disabledInit is called, we iterate through the list and call an onDisabled() method for each subsystem. That’s it. We haven’t seen any exceptions in the console, so we don’t think there is an error with that specific logic.
We are more interested in knowing if there is anything in the internal system of WPILib or the RIO that act like a watchdog and stops the robot code after disabling when a specific condition is not met because we might be triggering it with our codebase system. If there isn’t, we’ll just have to comment out every piece of code we run until it starts working again.
I’ve occasionally seen where if the backtrace is extremely long (e.g. caused by infinite recursion) the code can crash without the backtrace making it to the DS console. You might want to try running your robot program via ssh. SSH in (login lvuser), rename robotCommand to something different, killall java, then run the (renamed) robotCommand script and try to reproduce the issue. This will print any backtrace or other crash information to the SSH console.