Subsystem Disable Option

[jasondaming]

The goal here is to reduce the headache that teams have when running a robot with a subsystem not present physically on the robot. This happens often when trying to get practice while the robot is being built or when a specific part (like a climber) is being repaired off of the bot. Missing items can throw a lot of errors and unnecessarily consume utilization.

To implement this it would disable the periodic of the subsystem and any calls into it would be blocked from running (not sure the best way to do this). Ideally all of the HW it creates would also be suppressed from reporting errors.

[Starlight220]

all of the HW it creates would also be suppressed from reporting errors

As far as I know, something like this would require either an inheritance hierarchy (ie substitute a different subclass) or a Mockito-style solution -- both are much more complex than commenting out relevant code.

If runtime enabling/disabling of subsystems is firmly established as a non-goal, this can be somewhat simpler.

Feasibility of this is also very dependent on coupling of team code: we can stop commands from running on the subsystem, but if subsystem methods are called from a ton of other places -- there's not much we can do about that.

[KangarooKoala]

~~With the addition of opmodes in 2027, a new use case has come up: Disabling subsystems in particular opmodes.~~

• ~~This would need to be done at runtime, since that's when opmode selection happens.~~
• ~~The goal of the subsystem disable is to prevent the subsystem from being commanded at all, not to handle a subsystem not existing (which could be handled at compile time by commenting out the subsystem code). As was pointed out, we can prevent any commands using the subsystem from being run and skip the subsystem periodic, but there's nothing we can do about method calls that happen outside of commands.~~

Update: From further discussion in Discord, disabling subsystems leads to issues where trigger bindings are no longer accurate (since sometimes the trigger binding won't actually do anything) and can encourage excessive use of broader context categories than necessary. Instead, the opmodes should be excluded from the trigger context(s) (which can be stored as variable(s) to faciliate reuse).