Good Evening!
We’re having an issue with our swerve where the turn wheels sometimes jitter on startup.
When we enable our robot for the first time after starting up, one or more of the turn motors “jitter”, meaning they move back and forth erratically. When we disable and reboot the robot code from the driverstation, the robot behaves perfectly. This makes us think it isn’t a PID tuning issue, rather some bug in our code. Does anyone see anything that could cause this in our code?
Thanks!!
it looks like you want the wheels to steer to zero on startup? that will but a lot of effort into the position controllers, so maybe don’t?
Are you straight up using the AdvantageKit swerve drive template code, or did u add external modifications? If so, what are they
We modified the Advanced Swerve Drive template to use off-board PID control on the TalonFX. The feedback is in the module IO implementation rather than the module subsystem.
One thing of note: on line 106, you guys seem to be using faulty logic for your config logic(you need to do && every single time error is modified).
Second of all, what’s the purpose of withUpdateFreqHz() calls on your PositionVoltage and VelocityVoltage signals? That might be causing them to not apply correctly, which could be causing the jittering.
Thirdly, make sure that your modules aren’t jittering in sim either.
Here’s some updates on the problem:
Other things we’ve tried:
We found that we were calling the Module.java class’s periodic loop in our drive subsystem without checking if the driverstation was enabled. We added a condition to running the setpoints in Module.java to check if the driverstation is enabled. This also didn’t fix the problem.
The most important part of our debugging came when we took out the call to setPosition() from the turnTalon. When we did this, the turn motors didn’t jitter, but, as expected, the turn motors don’t move to the correct position because they didn’t have their positions set.
This leads us to believe we are calling .setPosition() incorrectly. The code has been updated to reflect our most recent testing.
Thanks to everyone who has helped us thus far!!
It looks like you are defaulting your TURN_KP to 50.0 and it is a tunable number so it might be set differently on your dashboard. You might try reducing TURN_KP to 5.0 or even less and seeing if you still get the jitter. It’s possible that by not calling setPosition(), the turn motors have no error to correct so they don’t start moving and the controller instability never appears. If reducing TURN_KP clears up the jitter, you could watch your turn position logs as you increase TURN_KP until you are getting fast response to position setpoint changes, but not large overshoots or instability. I’d also start with TURN_KD at 0.0 until geting KP tuned and then see if some KD lets you go to a larger KP and still remain stable.
Unfortunately, that didn’t fix the problem. It works perfectly fine after the code is restarted from the driverstation, so the PID tuning doesn’t seem like it would be a problem. Could it be a problem with setting the talonfx configurations?
Do you get the jitter with TURN_KP and TURN_KD both set to 0.0? Have you looked at your logs for the voltage going to the motors? The voltage must be moving up and down to cause the jitter. Is there any pattern to the voltage? Does it look like a square wave, a sine wave, a few pulses, or anything else that looks like a pattern? Maybe working backward from what you see in the voltage trend could give you a useful clue.
The robot still jitters when kD is set to 0. When kP is set to 0, the jittering stops, as expected when the error is multiplied by 0.
This is what the voltage looks like when jittering.
The pattern doesn’t indicate anything that we can think of. Especially as the jittering goes away after the code is restarted from the driverstation.
Another thing of note here is that all of our drive and turn motors, as well as our cancoders and pigeon2 are on a canivore bus. However, we are seeing some CAN message is stale warnings on the driver station for some of the motors on the RIO bus. We aren’t surprised about this, because the CAN wires attached to those motors are not twisted and got thrown on before our offseason event. Is it possible that the bad wiring on the RIO bus could have something to do with the erratic behavior of the turn motors on the canivore bus?
If you are trying to record if any error was detected then you need to “or” || all the conditions. The first two getConfigurator().apply could fail but you won’t retry them if the third one passes. Why not print something if error is true? Likely there is no error but it’s nice to know for sure.
What is the scale of the voltage oscillation graph? I assume the center is zero but what are the extrema?
We see kP=5 is potentially causing oscillations and kP=0 does not. What value of kP between those two values starts/prevents the oscillations? It might be a reasonable value.
I would next graph the encoders positions to verify that I wasn’t double correcting for the encoder absolute offset - that is both in the code and also having zeroed the encoder. Also, to verify position isn’t conflicting with turn the shortest path (minimum angle and reverse drive direction).
Your code appears to be modified to use some advanced functions of CTRE motors, so I’m not sure if it’s those problems. However, the original Advanced Swerve Drive Example needs about 10 seconds to warm up after boot. If jittering happens only in the first 10 seconds after boot, maybe it’s due to loop time overruns.
Here are some updates:
Good catch!! After implementing this, We can confidently say that the TalonFXs are being configured properly, but the jitter still remains.
The center is 0, and the extrema are ±10(ish) volts
As kP is decreased to 0, the jittering is just decreased proportionally. There isn’t a value where the jitter goes away. Except for 0.
This seemed to be the problem, After removing the call to SwerveModuleStates.optimize() the issue seemed to go away, but at the cost of non-optimized swerve states. We’re currently in the process of trying to figure out why this is causing us problems.
That’s a good point! We’re going to add a testing step to wait before enabling after a power cycle.
