Different odometry implementations

I’ve been looking into doing odometry this year, and all the odometry docs I’ve looked at pretend like the robot travels along an arc, even an infinitely big one. I do t know a lot of trig, but what if we always assume the robot is traveling straight, use sine and cosine to calculate position. Is there a reason one is preferred over another? This may be a totally stupid question, but I feel it is worth asking

You can do it that way too. I think most people use the arc approximation because Pilons popularized it, but try both and see what you like. It’s only like three extra lines of code to do the arc approximation.

3 Likes

Yeah that’s how we did it last year, just adding up a lot of small vectors. Worked well for us :+1:

2 Likes

Using arc reduced the number of stop-and-turn” that the robot needs to take to go from point A to B.

And every time the robot needs to stop, turn and move again, it will slow the robot down.

3 Likes

This is how I implemented odometry on my robots. They are both making assumptions/approximations, and It’s not entirely clear if there is a noticeable accuracy difference. I always wanted to do some comparisons in simulation and using a vision based motion capture system, but never had the time.

This robot is running odometry using that approximation.

3 Likes