Odometry with non-level surfaces, e.g. ramps like the charge station

[FoYVUptqkzaW]

So when updating odometry, the update function takes in a rotation2d gyro heading and the positions of the swerve modules. This seems to imply that odometry is calculated assuming that everything scales directly with distance (the field is flat).

Wouldn’t this be a problem with slanted surfaces? The differential between the swerve module encoders (current and prev) would be greater per unit of field distance (hypotenuse of triangle is greater than base), introducing a small amount of drift. Is there anything to correct for this in the code besides vision? Have any teams found solutions for this in any past games?

This seems to be important in Charged Up gameplay on the charge station ramp. The up/down ramps would induce an extra amount of calculated distance vs actual distance, which seems like it would introduce a large amount of drift during the match, especially if teams consistently go over the station to access the community. I’m curious whether this could turn out to be an issue or not in the season, any thoughts?

[duckduckgogogo]

You gonna have error when using odometry anyways so it is necessary that you need something that reset position like apriltag or limelight. Odometry is only for estimation I guess.

[Tom_Line]

You COULD get creative. If you know the angle your robot is tilted at, then you know how far you’ve traveled with respect to the floor using some simple trig.

On the other hand, you may just decide that you’re ‘close enough’ until you can get an april tag fix and reset your localization.

[mdurrani834]

AprilTag return the 3D pose of your robot. It should theoretically reflect your new elevation when if you see tags when on the platform.