Disable robot from controller?

[Discord2974]

Hi! I'm a third year programmer for team 2974 and I've got one question. Is there a way to remotely disable/enable a robot from a controller? This is for a past year's robot and and is still using the 2014 code if that clarifies anything.

[dc74089]

How creative are you looking to get? You can map one of the controller's buttons to be f1 and one to be enter, but I'm not sure if the driver station is smart enough to catch on to the fact that that input wouldn't be from a physical keyboard. The other option would be to do something crazy ala modifying OpenFMS to recognize a controller button as an enable command.

It's not exactly what you're looking for, but would modifying that robot's code to have an "enable" and "disable" button work? That way you could leave your robot enabled via the DS (you still need a DS connected), but "disable" all robot functions (write all outputs as zero and ignore almost all inputs) until you "enable" the majority of your code via a button on your controller. Especially if you're using simple or iterative templates, that method wouldn't require more than an extra boolean, and an if/else statement.

[Ozuru]

If you want to be really, really ghetto you could map a button to a boolean (isDisabled) and just surround everything in teleop and autonomous with

if(!isDisabled) {

}

Now that I think about it, if you surround the scheduler parts with that it might actually work...although there won't be an easy way to re-enable it -- in that case, just put something in teleopPeriodic that's a toggle.

[JacobD]

Originally Posted by Ozuru

If you want to be really, really ghetto you could map a button to a boolean (isDisabled) and just surround everything in teleop and autonomous with

if(!isDisabled) {

}

Now that I think about it, if you surround the scheduler parts with that it might actually work...although there won't be an easy way to re-enable it -- in that case, just put something in teleopPeriodic that's a toggle.

Before you try something like this, you might want to be careful because FIRST might give you problems when they see that. They have the enable/disable functionality for safety reasons. I understand that you might want to enable/disable from a wireless remote, but consider safety first.

[matthewdenny]

Anything that interferes with the fields ability to disable a robot would be a bin no no.

[dc74089]

Originally Posted by JacobD

Before you try something like this, you might want to be careful because FIRST might give you problems when they see that. They have the enable/disable functionality for safety reasons. I understand that you might want to enable/disable from a wireless remote, but consider safety first.

Originally Posted by matthewdenny

Anything that interferes with the fields ability to disable a robot would be a bin no no.

This wouldn't interfere with the enabling and disabling of the FMS. The robot still has to be connected to and initially enabled from a driver station, and it still can be disabled (it can always be disabled if everything is working as it should, FIRST makes sure of this). Enabling starts the user code on the cRIO, and surrounding your code with this if/else doesn't let your actual code start once the bot is enabled from the DS until your Boolean is flipped. It interferes with the FMS's ability to get your robot to move, but so would putting a robot on the code without any code or just not touching your controls, which is legal. You'd have to go deep into WPILib to let your bot actually do stuff while it was disabled by the DS, and I'm not even sure if it's possible at all with FIRST's firmware.

And plus, OP said this was for a demo bot, so while safety is definitely more of a concern than at competition, if safety is preserved FIRST legality is close to irrelevant.