Swerve Odometry off

We had this working earlier in the season on our test bot but for some reason it is no longer working on real robot. When we run our robot our odometry readings are not right, they are severely undercounted. For example robot moves 1m but odometry read .07m moved. The distance returned from the drivetrain wheel encoders is correct though.

Code is on GitHub. Relevant files are probably:


So ours was off with a simple mistake early on in the season with the drive base constants. The trackwidth and wheelbase. It was entered as 29 inches which was the frame perimeter. It should be center of the wheel, which was then corrected to 23.75 inches. Also check the wheel diameter. Are your wheels 4 inches in diameter or 3.75 inches now due to wear? Something to consider.

1 Like

Swerve locations might be a tad off, we are double checking, but wheel diameter is fine. As I said we get the correct distance from our wheel encoders. We are driving a straight line and it does not come remotely close (off by a factor of 10).

Since you are coming up short, another thing to make sure is that you are not accelerating too hard and causing wheel slip. That will cause you to be short.

I’m seeing the following things, correct me if I’m wrong on any of them:

-You’re doing PID directly off the absolute encoder for module steering

-You’re using the integrated NEO encoder for returning the module angle in getRotation()

-I’m not seeing anywhere in your code where you set the incremental encoder to be the value of the absolute encoder.

If these observations are correct, your modules are reporting incorrect angles from getRotation, as whatever angle they’re at during startup will become 0. You can quickly verify this by checking not only your individual module distances, but also their angles. If the angles are different, they’re gonna combine or cancel out in weird ways.

(Why are you using both encoders in the first place?)

1 Like

This probably explains it? It working today, but it could be that the wheels happens to power cycle correctly. Will update and see.

We had both encoders because last year we used a mag encoder to the roborio and did the PID on the neo encoder. Must have overlooked that method when updating.

1 Like

That makes sense. The normal reason for using both is due to it being easier to use the relative encoder for a motor controller’s built-in PID, depending on the setup. I don’t think I’ve ever seen PID on the absolute and relative for odometry, hence my confusion. But carry over explains it.

And yeah, the margin of error will theoretically change and potentially even be negligible with every full power cycle if my diagnosis is correct. Manually turning the wheels to random positions before startup should reliably reproduce the issue (though remember, the SPARK MAX retains its sensor values through a RIO code restart, so you’ll have to fully power cycle to truly get the startup behavior).

We are pretty sure this was/is the issue. Looking back at our testing we had 2 modules 180 degrees out from our others. We tried rotating the modules but didn’t power cycle, just code deploy. Our test robot had the same encoder config as before which explains why that one worked.

1 Like

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