Encoder distances different in forward/reverse direction (Falcon 500 + MK4 Swerve)

We are running a swerve chassis with MK4 modules and Falcon 500 motors for both azimuth and drive motors.

After locking the azimuth motors in place, we manually push the robot forward exactly 1 meter. We confirm that it is 1m with a measuring tape on the ground, as well as reading the encoder ticks off of the drive falcon via the CTRE client.

Then, without rotating the azimuth motors, we push the robot exactly 1 meter backwards using the measuring tape on the ground. The CTRE client reports that we have over-shot our mark by about 500 encoder ticks.

We have tested this dozens of times and the results are repeatable. We have also tested that the behavior scales linearly when going further distances.

My ask to the community is as follows:

  • Is there a setting on the Falcon that we have missed that alters the forward/backwards encoder counts? I have looked at the CTRE docs and haven’t found anything
  • Any ideas as to why this happens?

We have confirmed that the sensor phase and motor directions are as we expect.

1 Like

How fast are you pushing the chassis? Mechanically, the only explanation I can think of that makes any sense is that there’s slipping going on and it’s slipping different amounts in each direction. Make sure you push the chassis very slowly. It’s best if you drive the chassis for a test like this (still, slowly!).

If it’s a software problem, it’s an obscure one. Maybe a firmware bug? I doubt it. Check the mechanical stuff first.

1 Like

Very slowly lol. We were driving it initially, but putting the robot in a known location was a little harder to do via the controller than just manually setting things up by hand. Therefore we switched to manually moving it.

We have focused a lot on guaranteeing no mechanical slip in these tests, so I am confident we can look past that problem

It could also be an anisotropy in the wheel/carpet interaction (what surface are you testing on?). The linear scaling you mention is particularly weird - I’d suggest asymmetric backlash as a possible cause, but this isn’t consistent with that.

Have you repeated this test on the carpet 90deg to the original test location?

Paging @Mark_Wasserman carpet nap issues?


Yes all of our testing has been on competition carpet

We have tested the following:

  • Robot pointed towards opposing driver stations, driving in the X direction. When driving positive X, accuracy is perfect. When driving negative X, accuracy is wrong
  • Robot pointed towards opposing driver stations, driving in the Y direction. When driving positive Y, accuracy is perfect. When driving negative Y, accuracy is wrong
  • Robot pointed 90 degrees to driver stations, driving in X direction. When driving positive X, accuracy is perfect. When driving negative X, accuracy is wrong
  • Robot pointed 90 degrees to driver stations, driving in Y direction. When driving positive Y, accuracy is perfect. When driving negative Y, accuracy is wrong

Just as a trouble shooting step…
(I dont think carpet nap is the issue given the above tests, but it is the only thing I can think of…)

On a hard surface (non carpet) similar results?

Is there any weird backlash in the drive gear-train (doubt it, but check again i guess…)?

What happens if you go 1 meter in the positive direction, then go past it d amount. Then back up to the 1 meter mark (get that tick measurement), then towards the 0 point. Still wrong?

I am convinced there is some weird backlash somewhere, if not in the geartrain in the wheels or something. The linear scaling of the error is the confusing bit.

As annoying as this may sound… have you tried driving in different order? negative FIRST and THEN positive.

And then, is this ACTUALLY a big deal? 500 ticks for our MK3 swerve drive is 3.5% (500/14000 ticks per wheel revolution) which is 1.1 centimeter off per meter of driving.

If you have similar gearing, you should be around the same error.


Why limit yourself to one meter? Take it out to 5 meters and back and see what you get. If the error is the same, it’s a backlash issue. If the error grows larger, then oddly it would seem there is some kind of directional issue.

They said it increases linearly. Fyi

1 Like

You said you’re using MK4 modules. These can be flipped 180 degrees for steering. Try initializing everything like you’re ready to do your initial move, but just before moving, rotate two of the modules 180 degrees, so they are rotating “backwards” compared to the others. Compare the results of the odometry and see if these two modules match the others. The results may be instructive.

Also, between the two moves, pick up the robot, spin it 180 degrees, and push it back with the modules rotating in the same direction. Then do the same thing with the robot facing the opposite direction.

Also, mark the wheel hub, and move the wheel (in air) in opposite directions for a large number of turns, confirming that you get the correct number of encoder counts going in each direction.

I’m going to bring this up with our software folks this afternoon and see if they’ve seen anything similar. We’re using Neo’s though, so we might not see the same issue. If we do, it will be VERY interesting.


drive_encoder_test.xlsx (18.2 KB)

All encoder values were read directly from the falcons using the CTRE Phoenix tuner.

The test was as follows: Starting at (0,0), robot was pushed forward to (1,0) - 1 meter forward. Encoders values were recorded, and then robot was pushed back to the starting position. Test was repeated from the same starting position for 2m, 3m and 4m. Robot was pushed at a very slow rate of speed ~0.25m/s to avoid any wheel slip with the carpet.

In the spreadsheet you will see the encoder deltas going forward and backwards for the distance traveled. I have included the “delta from origin” which measures how far off from the original starting ticks we were when the robot got back to the physical starting position.

We also did a free spin test with the robot on it’s side and manually rotated each wheel 5 rotations forward and backward, and recorded the encoder ticks. Looking at this data, it is clear that the encoders are working as expected, and they give the same results forwards or backward for a given number of wheel rotations. We also tested our backup swerve module, with the 20.0 firmware and tested it again after updating to the 21.0 firmware.

To the comments about backlash - we would expect a “constant” error in this case, since once the backlash moves through the gearbox, there should be no more buildup of error. Instead we are seeing a linear increase in error as the distance goes up.

To summarize the errors:
In the backwards direction the encoders are providing ~4% more encoder ticks than we would expect, compared to the forward motion. Applying a factor of 0.94 to the rear encoder ticks puts the values exactly in the same range as forward.

I will try some other tests with overshooting the setpoint and rolling back into it as suggested, to see if we can account for some sort of “backlash” in the change of direction.

1 Like

I still think this is a wheel/carpet anisotropy, and that there is differential scrubbing in each direction (albeit not very much of it).


Yeah, this is the only assessment that really makes sense.

At the very least it is seemingly (at this point) predictable.

I would be curious to see what happens at speed. The wheel slip probably makes all of this just noise in the system.

1 Like

I’m also curious to see whether the direction of the asymmetry is flipped when you power the robot through the wheels as opposed to pushing it.

Absolutely, maybe in competition conditions it will meet in the middle and all but cancel out XD


Did you ever resolve this issue? Because we are just today seeing the exact same thing. We do not have a swerve, just a skid steer (arcade). But when working on path-following we found that driving forward gave us one value (raw encoder ticks from Falcon integrated encoder); then driving backwards the raw encoder ticks were off by about 10%. Very curious.

Any insight would be greatly appreciated!

Hi Mray! Did u test that the different direction of carpet may cause this problem, I remember that in Team1323’s code of 2019, they have a carpet scrub factor seems to solve this problem. This may because of the way that carpet is produced, and finally cause a different slide factor to chassis. Sorry I can not describe it more clearly(for my bad english.
You can check the code below and test about is this the encoder problem or the carpet.

//Scrub Factors
public static final boolean kSimulateReversedCarpet = false;
public static final double[] kWheelScrubFactors = new double[]{1.0, 1.0, 1.0, 1.0};
public static final double kXScrubFactor = 1.0 / (1.0 - (9549.0 / 293093.0)); public static final double kYScrubFactor = 1.0 / (1.0 - (4.4736 / 119.9336));
deltaPosition = new Translation2d(deltaPosition.x() * xScrubFactor,deltaPosition.y() * yScrubFactor);

More in 1323’s code:https://github.com/Team1323/2019DeepSpace

1 Like

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