Odometry when wheels off ground

We have utilized odometry in our turret so that it knows where to go until the vision can see it.
We ran into the problem that if a wheel comes off the ground by either going over the cable bump or getting hit pretty hard, the odometry starts to get inaccurate, and the positioning gets worse and worse. (Odometry works fine in auto because we aren’t going over pipe or facing defense)

Has anyone experienced this problem? If so, do you have any suggestions to mitigate it?

One solution we thought of was using our NavX to check if we are actually moving as much as the wheels say we are, for when wheels spin not in contact with the ground.

Has anyone used IMU or IMU assist odometry?

Thanks very much.

While I’m not an expert in this, from what I have been told a lot of teams reset their odometry when they look at the vision target. This updates their position on the field because the target is in a known location. Now how does that work with this year? Someone smarter than me will have to go further into it.

1 Like

We did try resetting the odometry at the launchpad. The problem is it can be a waste of time to go all that distance to use an extra feature. In that time we can toggle off the odometry and have the turret default to center. I don’t think we could do it with vision because we can only get distance and angle from vision as it is a round target.

This is exactly what we did. We considered using the WPILib pose estimator, but we found it wasn’t documented well enough to jump straight in. We decided to try just resetting our pose, and found that it worked very well.

If I may ask, how did you do it in the 2022 game?

1 Like

I thought the same thing, but someone else on CD pointed out that you know your field-relative angle from your gyro. You can estimate your pose from the gyro angle and the distance to the target.

 ​  ​private​ ​void​ ​resetRobotPose​(​final​ ​double​ ​targetX​) { 
 ​    ​final​ ​var​ ​gyroAngle​ = ​driveTrainSubsystem​.​getCurrentPose​().​getRotation​().​getDegrees​(); 
 ​    ​final​ ​var​ ​turretAngle​ = ​turretSubsystem​.​getAngleToRobot​(); 
 ​    ​final​ ​var​ ​distanceToTargetCenter​ = ​lastTargetDistance​ + ​AimConstants​.​HUB_TARGET_RADIUS​; 
 ​    ​var​ ​newPose​ = ​new​ ​Pose2d​( 
 ​      ​distanceToTargetCenter​ * ​Math​.​cos​(​Units​.​degreesToRadians​(​gyroAngle​ + ​turretAngle​ - ​targetX​ - ​180​)), 
 ​      ​distanceToTargetCenter​ * ​Math​.​sin​(​Units​.​degreesToRadians​(​gyroAngle​ + ​turretAngle​ - ​targetX​ - ​180​)), 
 ​      ​Rotation2d​.​fromDegrees​(​gyroAngle​)); 
 ​    ​driveTrainSubsystem​.​setCurrentPose​(​newPose​.​relativeTo​(​fieldOriginOnHubPlane​)); 
 ​  }

Here it is on GitHub

6 Likes

Very cool, thank you so much! I will be sure to try this soon.

1 Like

This thread is where @FRC6302 helped me out with the strategy:

1 Like

We tried the algorithm and it worked kinda. The problem was, that every time we would use it we got around ±.1m of error, which compounded and defeated the point. I think our distance calculation is not very good, and am going to test that. Do you know if there are any things we should check for that caused you issues? Thanks for the help!

Are you calculating distance through area of target or trig? If not trig you should definitely try that. Limelight docs has a pretty good guide on it if you need.

2 Likes

We use trig. It has worked well enough to make a shooter regression.

We put the calculated distance on the dashboard, then lay a tape measure on the floor and roll our robot over it. We usually have to adjust the angle of the limelight in the calculation. We are calculating the distance within 1-2 inches.

Why is your error compounding over time? Are you sure it’s not gyro drift?

It compounds over multiple shots, so it’s just the inaccuracy adding up. I am going to test the distance finding soon, just depends on when we get enough time. If we are more than a couple of inches off that should explain the error. I may check the gyro drift aswell, but I don’t think that would be an issue because the field-oriented controls still work well throughout the match. I really appreciate the help.

If you’re recalculating your pose when the target is visible, there cannot be any compounding of error over time. The inputs to the calculation are the distance to the target and the gyro angle, neither of which would compound any previous calculation errors.

1 Like

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