Quote:
Originally Posted by Gregor
Could you go into detail about how you plan on doing that (because 254 apparently hasn't helped our auto enough yet this year  )? |
I'm sure 254 can go into detail on their particulars but here are some general principles:
- Add a hasRun flag into autoInit to sure any macro initialization runs once (resetting gyros and encoders for example)
- Make sure any PID with an I component behaves appropriately if the robot is disabled briefly. This may be the case already or it may require making sure that the PID is disabled when the robot is disabled or resetting it when the robot is enabled to avoid integral wind-up.
- Implement the auto routine as a state machine (as opposed to a hardcoded sequence). If using Iterative Robot, you're probably OK already in this regard. If using Simple Robot you may not be. I'll have to go back and look at some of the details of the Command Based implementation to give proper advice there.
- If using the Simple Template in C++ or Java, make sure to save the above state data in global variables (not in the auto method itself). This allows the state to be maintained if you drop out of the auto method.
- Again if using the Simple Template, make sure you have implemented the state machine above as a loop which checks that the robot is enabled. This is important to make sure that you are not taking actions and moving through states which have no external feedback with the robot disabled (and therefore not actually able to take these actions).