Open brettle opened 3 months ago
We'd need to do more than unregister the subsystem. MockCANCoder
registers itself with the async periodic methods, which are not run by CommandScheduler
. It might make more sense to just expose a general disable
method that disables the actual run logic of the subsystem.
However, the general idea of Lib199Subsystem
is that it's used for stuff that is expected to always run. i.e. when you create a method or call an object that requires periodic functionality, it handles it automatically. Thus, I think that exposing a such a method could be dangerous and lead to unintended side effects. (e.x. calling it from competition code would disable SparkMax temperature and error checks).
If there's a specific feature that's causing problems, a better course of action would be to just not use that feature. In this case, it might make sense to instead expose variants of the functions in MotorControllerFactory
and SensorFactory
that never create a simulation-device variant.
This should be public:
https://github.com/DeepBlueRobotics/lib199/blob/946c6fa0392f013c2670d88ea510d7e33121b589/src/main/java/org/carlmontrobotics/lib199/Lib199Subsystem.java#L11
So that one can call
CommandScheduler.getInstance().unregister(Lib199Subsystem.INSTANCE)
if it's periodic methods interfere with other things. For example, at the moment,MockCANCoder
interferes with other simulation code trying to useCANcoderSimState.setRawPosition()
.