|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: Startup Twitch
it could twitch from all components powering up and testing, or it could be because of a bad CRiO.
|
|
#2
|
||||
|
||||
|
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. |
|
#3
|
|||||
|
|||||
|
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.
|
|
#4
|
|||||
|
|||||
|
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.
|
|
#5
|
|||
|
|||
|
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? |
|
#6
|
||||
|
||||
|
Re: Startup Twitch
Quote:
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|