Quote:
|
Originally Posted by gnormhurst
Another concern is about state machines getting left in a state != START. If the autonomous code stops being called while a state machine is doing something, that machine will be in the middle of its sequence when it is called again e.g. from non-autonomous mode. I wish I had a way to reset all state machines to their initial state.
It is also not clear how the match computer will sequnce autonomous_mode and disabled_mode. disabled_mode is true before autonomous starts, but the state of autonomous_mode at that time is not clear. Likewise, at the end of autonomous I'm pretty sure that disabled_mode will be set to true, but when does autonomous become false?
I think the rule has to be: the state of autonomous_mode should only be trusted when disabled_mode is false. And if PID loops use integration, they should only be updated when the robot is enabled:
|
All very important points (though I would implement it differently). The current PID code does
not take into account disabled mode (though easily fixed through if's and ternaries). Integral wind-up is probably the biggest problem in this 'active' disabled mode (as opposed to previous years, where if you were after the match started, nobody cared).
I would not be worried so much about the scripting except for testing. The easiest way to fix it is to move the state variables to a single global and use that, and if you enter user mode (when you're enabled), then clear it.
Also, can some one with more expieriance than me reiterate what integral wind-up is? (and add it to
FIRSTwiki?)