MK4 drift

The encoders return a value ±1 degree off which should not explain the amount of drift we are seeing

1 Like

This has to be a hardware problem. Do all or just 1 module drift?

Depends, all 4 some days, only 1 other days

Are you sure the encoder are not losing power at any point or the can bus being lose?

I dont see any CAN errors about loss of signal or too stale frames, and the encoders don’t flicker red/off at any point

Are you using field oriented drive? Is the Pigeon drifting?

1 Like

Something else we have just noticed is that some of the modules seem to spin slightly faster than other modules, this might be our problem

How are you getting the encoder values for the steering motors? Our robot is configured so the FalconFX uses the CANCoder as a remote sensor. I had one module consistently off and finally found that the call to get the selected sensor position wasn’t getting the absolute position of the CANCoder, and I had to set the position using the setPositionToAbsolute method on the CANCoder during initialization.

If you aren’t using the CANCoder directly, how are you calculating the steer position?

1 Like

We are and the pigeon has been very accurate, we have seen minimal gyro drift and is definitely within acceptable error. But the robot’s forward doesn’t drift, the chassis does.


are you seeing carpet drag where one or more wheels are just completely useless and being dragged (usually pointed in wrong direction)

Swervelib is supposed to be handling all of that, but from browsing the repo it seems to be setting the remote sensor of the rotation motor to the module encoder

Here is the link to that part of the repo

I feel at this point it may be an issue with the repo, rather than something physical.

If the encoder values are the same then to the repo, everything is working correctly. I’m pretty stumped on this.

You’re running open-loop drive velocities. Variable friction in the module gearboxes will cause drift, for the same reason that differential drives often fail to drive straight under open-loop control.

To track straighter, implement better velocity control or add gyro feedback.

We considered this, we thought of using the gryo to keep the robot at a set heading and only updating the heading when the robot is spinning. Would this be a good remedy or is there another solution we should try?

You should update the odometry with the current (rather than desired) heading, but yes, that’s the idea.

If it is too close the the magent what we did was put small pieces of paper between the sensor and the magnet until it turned green. You are right that that should not be the cause of the problem but my ocd demanded them all to be green.

1 Like

Im also apart the original poster’s team, this seems to the solution, we have it adjusting for the drift in real time and update it’s heading. We just need to tune our PID values to make it feel less mushy and stop it from overshooting slightly. We will post the code once we think we got it fixed.


If your PID loop is closed on gyro heading, I’d advise focusing mostly on the D term to keep the robot stable while moving, with a little bit of P to clean up the steady-state error.

PID driftCorrectionPID = new PID(0.07, 0.00, 0.004);
double desiredHeading;
double pXY = 0;

public void driftCorrection(ChassisSpeeds speeds){

double xy = Math.abs(speeds.vxMetersPerSecond) + Math.abs(speeds.vyMetersPerSecond);

if(Math.abs(speeds.omegaRadiansPerSecond) > 0.0 || pXY <= 0) desiredHeading = pose.getRotation().getDegrees();

else if(xy > 0) speeds.omegaRadiansPerSecond += driftCorrectionPID.calculate(pose.getRotation().getDegrees(), desiredHeading);

pXY = xy;


This seems to have fixed our drift problems and work pretty reliably, the PID could probably use a bit more tuning but it works pretty good for what it is


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.