Startup Twitch

[apalrd]

If you have an I term, you have to reset it continuously while disabled. Or else, when you enable it, it has to unwind the I term before (or while) you begin to use it.

[Alan Anderson]

The five second delay might be a camera or gyro initialization. Make sure you aren't calling for something like that in your Teleop code.

[Geek 2.0]

Okay I think I finally found the solution. When the robot enables, it doesn't clear out the previous values from the registers of the Jaguars (via CAN). So, upon enabling the robot, the speed controllers start at the same values as the round before, and then stop when they receive a new value. That time between start and stop is the twitch.

Can anyone confirm or deny this?

[MamaSpoldi]

Originally Posted by Geek 2.0

Okay I think I finally found the solution. When the robot enables, it doesn't clear out the previous values from the registers of the Jaguars (via CAN). So, upon enabling the robot, the speed controllers start at the same values as the round before, and then stop when they receive a new value. That time between start and stop is the twitch.

Can anyone confirm or deny this?

Well... I can confirm this is definitely true with PWMs with both Victors and Jaguars but not sure about CAN as we have never used it. I would suggest that you "turn off" everything when leaving both the teleop and autonomous routines in your code (eg. set drive motors to 0.0, and clear any internal states of your control loops, etc). This will ensure that you don't need to be worried when enabling your robot about what it might do. We have definitely experienced this with the gyro initialization as well... but that was more of an issue in the pre-cRIO years.