We are really trying to adhere to the new command framework. Something interesting happened last night while testing and we haven’t found a good way to address it in the framework. So, I’m curious if we missed something.
While we were testing the indexer we tripped a Spark MAX and it reset. In code we tell the controller to invert. The inversion is set in the constructor. After the Spark MAX resumed functioning it lost its inverted setting. While it was fun to watch half the indexer run one way and the other half run the other it isn’t a comforting result.
In fairness we haven’t been able to replicate the behavior yet, but a restart of robot code fixed everything.
Any clue on how to detect this?
Is there a better place to put the inversion setting?
Right now we’re heading towards a “panic button” that an operator can hit to cause all motors to re-init. (And flashing the controllers to default appropriately.)
You can “burn flash” through the API for extra insurance during competition. Apart from that, your “panic button” is the only other realistic solution; detecting a motor reset in code is difficult.
There is a ‘hasReset’ flag in the status bits returned by the controller at a rate of 10ms. The flag is cleared by the API when you first run, so if this is set it is safe to assume the controller reset during operation. You can monitor this flag and take action to reinitialize. Make sure to monitor the sticky fault version.
The burnFlash() command run once after initialization of the code will work too as this causes the invert flag to persist a power cycle. This is the same as if you had set the invert setting in the PC Client and press ‘save configuration’