How do you Account for Different Odometry Drift on Different Carpets?

Hey,

We’ve had issues with our autonomous pathing behaving very differently on different carpets. Reviewing the logs from various matches, it seems that the issue lies in the odometry drifting in different ways on different carpets. Over the last events we played, we accounted for this by fudging our waypoints in pathplanner, but this takes several matches to dial in correctly and often we only have one, maybe two runs on a new carpet before we have to have a new path dialed in.

If you have encountered a similar issue, how did you solve it and/or how are you mitigating it?

We have tried:

  • Double-checking the kinematic class has the right measurements (using distance from center of robot to center of wheel).
  • Retuning the PIDs on Pathplanner - we have confirmed that the robot odometry always matches the waypoints to +/- 3 cm, and the paths are precise - they just aren’t accurate.
  • Fudging our overall odometry based on distance traveled: This showed some promise, but the odometry is still not precise to field.
  • Tracking odometry for each individual swerve module: We were able to demonstrate some play between module odometries, which would imply some slip that would explain our issues. Looking into cross-referencing them to validate their positions.

We know vision is an option to combat this as well, and are investigating it. However, given the time constraints before worlds, we doubt this could be integrated successfully in 2-3 practices.

If this is something you think you know the root cause of, we would love to know.

Without vision, I think this is the best thing you got. You can try to be fancy by identifying when your wheels are slipping and taking that out of your odemetry, which might help. What exactly if wrong with the odemetry? Is it just showing up shorter or longer than expected?

The direction of the carpet nap and possibly the level of wear, has a fairly significant impact on wheel odometry. It may also depend on the type of wheel. You can find some conversations about this in this forum. You can also observe the effect if you have a field carpet available to you. Measure the effective wheel circumference using a tape measure when driving with and against the carpet nap and you will be surprised. You can also just mark a position on a wheel with a sharpie, and roll the robot back and forth a few times and see where the sharpie mark ends up.

Vision is your best bet to combat this.

1 Like

If you have extra time during auto you can reduce the acceleration of your paths and try to avoid rapid direction changes to combat skidding. Will is right that carpet nap and tread wear have a big effect too. Before the swerve era several WCD teams found that some wheel types were worse than others when it came to path consistency. I seem to recall a few high profile teams switching to blue nitrile over colsons (or maybe it was the other way, I don’t remember so someone please correct me). Depending on what wheels/tread you are already running you could experiment with that too.

Edit: found the post about switching to blue nitrile from 254: What are the benefits of using Colson wheels? - #5 by Jared_Russell

1 Like

Acceleration limits will mitigate slip but the only two real fixes are running an extended Kalman filter on a few accelerometers blended together and this will drift rapidly as error on acceleration grows rapidly after maybe 10-20 seconds, the proper fix this year is using the field April tags for localization as it’s not too hard to get within 2-4 centimeters of accuracy with them. If you need any help setting up either photon vision or a standard ROS implementation I’d be more than willing to help.