Startup Twitch
 

After a robot reset, our robot doesn't respond for about 5 seconds after enabling, and then twitches (quite violently) and then responds to our control. We're using Java. Can anyone think of a reason for this twitchiness?

Re: Startup Twitch
 

it could twitch from all components powering up and testing, or it could be because of a bad CRiO.

Re: Startup Twitch
 

Check to make sure your automated processes are not initializing and that your variables are not being set to anything odd initially.

Also, if you are using PID, you may have to tweak your gains so that they do not need to work themselves out.

Re: Startup Twitch
 

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.

Re: Startup Twitch
 

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.

Re: Startup Twitch
 

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?

Re: Startup Twitch
 

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.