Question about Odometrys accuracy with an offensive strategy

I know that Odometry inevitably grows a little bit off overtime. However, I believed that while I couldn’t do anything about that, it would be fine in the end because our offensive strategy of just bullying our opponents wouldn’t interfere with it. The “under control” part is what scares me about quejtys response to the question asked in another thread. If we are very offensive, will Odometry become off by anything more than 1 inch? we are doing a turret design and Odometry is key to the code.

So with 3 wheel odometry as long as any of your 2 Heading tracking wheels arnt off the ground while the robot heading is changing (a change in heading the wheels will not be able to read) you should be ok

With 2 wheel and IMU (inertial sensor) you only have to worry about violent bumps that move the robot exceeding more than 4gs or 1000dps (off the top of my head) although that happens more offen than one would think

When the heading is thrown off the data from odometry becomes more and more useless over time as finding X and Y is dependent on an accurate heading

Edit: grammar :skull:

from what I’ve heard and tested, odometry will probably become inaccurate during the driver control period with violent and sudden interactions. But it may be possible to make to good enough. Try making very stable and sturdy tracking wheel mounts with very little slop, try banding the wheels into the ground with good enough force that even violent impacts don’t cause them to jump up, and maybe it will retain enough accuracy? but as @MobGoblin_70291E said, if anything with your heading gets messed up even slightly it will quickly throw the whole thing way off.

Best way to know if this can work though is to try and find out, if it does then great, if it doesn’t, at least you have an odom setup you can use in auton and skills.


Normally odometry is not used for driver control.
Many reasons for this:

  1. generally robots move faster during driver control - might exceed the response times of the sensors used
  2. all the interactions and collisions will definitely cause the robots to skid or slide, etc. So unless you have a crash recovery function built inside your odometry, then it is impossible for the robots to continue to accurately track its location.

Another option is to have a “reset” function - you press one of the button to get the robot to initiate resetting of its location after a crash. But this will mean there must be enough sensors or maybe at least a GPS sensor (assuming the GPS stripes are on the fields) to re-determine its location.

But if you are gonna use this resetting function, then might as well just have a button to initiate the GPS sensors to determine location and then fire off immediately. So again, not much point having odometry for driver control.


I thought that the whole point of 3 wheel odom was to take that into account. Is this not the case?

Just adding 3 tracking wheels do not automatically resolve the issue.
3 tracking wheels give you triangulation of data, but it does not automatically track all the sliding, etc due to collisions.


If you’re doing odometry it actually does, the whole point is to figure out where you are completely independently of what your drive is doing. The main issues that cause drift over time are quantization errors in your encoders, the tracking wheels not having a consistent contact point with the ground, ie. they have width, and the general assumption that’s made in deriving the math which is that over very small time slices you move in a perfect arc.


You have just explained why having 3 wheels will still not resolve the issue of crash collision.
There is just no guarantee that the robot will not be lifted off the ground during collision.

So this is what I mean when I say just having 3 tracking wheels will not automatically means it will resolve issues due to collisions.

Inaccuracy due to collisions is not due to drift (which is mainly due to the uncertainty of sensors. All sensors come with uncertainties. There is no stopping that, and that’s the reason drift can only be minimised, but never totally prevented.

Normally for crash correction, it is either the robot remembers its last known location and then make use of the tracking wheels data to try to estimate the after crash location, or just simply use reset points.


Generally tracking wheels are mounted on a pivot and sprung into the ground such that even if the robot lifts off the ground, the tracking wheels do not. Obviously this only works so well and if the robot lifts too much you’ve just lost your position, but lifting that much due to the actions of another robot is relatively rare in a game like spin up.

With that said, yes, I wouldn’t rely on odom during driver control without some fast method to reset it. Even ignoring the tracking wheels lifting, the position will drift far more than an inch over the driver control period as demonstrated by the need to periodically reset during autonomous skills. GPS would be a great option if it was guaranteed to be available during a match, but it isn’t so I can’t suggest using it in this context. And even though it’s rare, if your tracking wheels do lift you need to be able to recover (but in this game with no vertical expansion and a relatively low COG it really should be quite rare).


you say that the position will drift more than an inch, even if we weren’t lifting up. Im thinking we can just drive into the corner and reset there. However, since we’re not doing X drive, we’re gonna have to do some good parallel parking or I can tie it to a button in code or something and it’ll automatically get there. Do you think that I can use ultrasonic sensors to try to guesstimate where the robot is on the field, and if it’s too far off compared to Odometry, it lets the driver know that it needs to reset? I don’t think the ultrasonics are that accurate (I’ll look up a graph or something to see) but maybe they’re good enough to do that.

That’s good. Maybe this isn’t as absolutely horrible as I thought it could be. Ill try to code what I can as a fail safe, but maybe I’ll only need to use it once a match? We’ll see. Thanks

1 Like

If you have access to distance sensors you can use them to update your odometry wile not being perfectly in the corner

Back up against the south wall update your heading when the robot is perpendicular with the wall and coordinates using a distance sensor reading off the east or west wall

1 Like

If you are doing all omni wheels, you can use a taper on the front of your base and drive into the corner and it should align itself perfectly.
See an example here:


365X used “wings” which allowed them to perfectly align with mobile goals during ITZ. They popularized them for use in VRC. I remember some teams using them in Change Up as well


We are using all Omni wheels, luckily. I’ll forward the video to our team leader, see what he thinks.

2011D did it too, you can find a video in their public google photos album:

Of course, not really an option this year because of no expansion, but the principle should work.


Not sure I will agree to this. At least I foresee a lot more aggressive defensive plays to happen for this season.
And looking at the past 2 seasons that we had a shooting game, i.e. NBN and TP, I would certainly expect the same amount of defensive plays to happen for this season.

This is something that both of us can agree to.
Even if the tracking wheels come with “suspension” system to counter the effect of robot lifting off the ground, I would still go for a reset instead of trying to figure out whether the tracking wheels are still tracking well.

And yes - in summary, i will not use odometry for driver control. It is just not going to be effective.
Even with a fast method for reset, don’t think the opponent will give you the time to reset and aim. At least, I know my teams wouldn’t be giving the opponents this luxury of time (to aim).


You should not rely on tracking wheel odometry during opcontrol if that is all you have. Something FRC teams did last season was that they constantly updated tracking wheel odometry with vision measurements. If you can think of a way to “double check” tracking wheel odom with stuff like distance sensor odom or vision odom, then your tracking would be much better