Inconsistent Odometry Readings with Swerve Drive Between Power Cycles

Technical Programming
, ,
1

Hey all,

We’re encountering a bizarre issue while using PathPlanner for our autonomous routines, where the robot follows a different path about once every 3 power cycles of the robot, despite no code or mechanical changes between those power cycles. However, re-running the auto routine without power cycling will consistently follow the exact same path (even if it’s not the path we’re asking for). Our robot is quite precise, but hardly accurate!

We believe this issue stems from incorrect odometry, as some simple straight-line paths have revealed that the distances measured by each individual drive encoder are not always the same as the distance calculated from our WPILib SwerveDriveOdometry object. For example, in this video (where the robot was told to drive its front bumper to the end of the measuring tape), the individual drive encoders correctly measure that the robot has overshot its target, while our Pose2d object claims we hit our target pose within a few centimeters;

Furthermore, when we turn off the closed loop trajectory following (by setting the PID gains given to PathPlannerLib’s SwerveAutoBuilder to all be 0), we always follow the same path no matter how many times we power cycle, and the path also gets us to the correct end pose (within reason). This leads us to believe that when the robot misbehaves, it’s because it’s trying to correct for an error that doesn’t exist.

However, there are also some power cycles where the drive encoders and Pose2d object both agree on the distance traveled, and will continue to agree until we roll the dice on the next power cycle. And just to reiterate, we are making no code or mechanical changes between power cycles.

We have tried:

  1. Swapping out our gyro, first to a different navX-MXP (1st gen), and then upgrading to a navX2-Micro.
  2. Waiting a full minute after connecting to the robot before running auto, to make sure everything has had enough time to initialize
  3. Verifying that the conversion factor between motor rotations and distance traveled by the drive wheels (in meters) is correct and is constant.

Here is a link to a Google Drive folder containing a snippet of the code we run, as well as videos showing the problem in action

1 Like
2

Have you considered it’s because you are setting voltage and not percentage of power?
If you check your DS logs look at the starting voltage of “successful” runs.

I love the simplicity of your code too btw!

1 Like
3

Unfortunately I won’t have access to our DS logs until Saturday due to our school’s spring break. However, I don’t understand how that would explain why our pose does not align with our encoder readings.

1 Like
4

Just to note, the logs from the night that this video was recorded has been added to the Google Drive folder.

5

Interesting, we are having similar issues. Hope you guys get this fixed!

1 Like
6

After a lot of testing, we discovered a fix for our problem was to simply add a simple Timer.delay(10); call in our Robot.java class before calling m_robotContainer = new RobotContainer();. We believe that the problem was that we were initializing objects that reference our navX before it had enough time to fully calibrate. This is just a theory and the issue could be caused by something different but we do know that the 10-second delay fixes it.

2 Likes