We have been having a lot of issues with default commands not being interrupted by commands that are triggered by a whenPressed command. The system is working now, but only because every method in both the default commands and the interrupting commands contain a call to its super method (execute calls super.execute, etc). We have not had to do this in previous years, and I have not noticed it in any of the repositories I have seen on GitHub, or in the documentation. I should also note the setInteruptable is not mentioned in the Screensteps live documentation to my knowledge.
What are we doing wrong, if anything?
Am I missing something?
I encountered this issue last year. See the documentation for how the scheduler works in the command based robot.
Basically, what I’m assuming is that the default command is always running because it is at the end of the list of commands run every cycle. This is probably due to your default command doing something that is always called on each read of that command.
For example, lets say you have a button that just drives your robot forward, but never sets the output to zero in the end command. If your default command always polls the joystick values and you press the button the robot will quickly alternate between going forward and stopping due to always polling the joystick values.
You can solve this by reorganizing how you use each command. In the example above, it can be just poll the joystick after setting a deadband, or setting a static Boolean that other commands will set that will disable the default command if you need to. This is a hard problem to solve if you don’t provide an example since it can get very specific based on your use case.
Here is a link tour our active branch. JoystickDrive is the default command for the chassis and DriveArmWithJoystick is the default one for the arm. The arm overrides are RaiseArmTwo and LowerArmTwo. The chassis override command is the TurnPID in the auto package.
Something is defiantly strange. I was having this issue on bag day, and got the commands interrupting properly 10 minutes before we had to bag it, so I didn’t have an opportunity to see if it works without calling super in all of them. It seems like it can’t hurt to have them in at this point.
You have some commands that override start() and cancel(). First, I have never seen a command use case that needed to override these methods (yet) and everything you are doing in those methods would be better placed in initialize() or end(). Second, not calling super from those two overrides would definitely break things. The base implementations of those methods are essential to proper command scheduling. I suspect that this was your original problem.
One final note, if all you want your interrupted() method to do is call end(), you do not need to override interrupted() since the base implementation just calls end(). It didn’t use to do that. It changed two or three years ago.