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.
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.
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.
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.
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.
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.
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.
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);