Why does everybody seem to model the robot as a bunch of infinitesimal arcs in odometry?

So in the Pilons odometry doc they do a bunch of trigonometry to model the robot as moving on a bunch of tiny arcs, but why don’t teams just model the bot as moving on a bunch of straight lines? Has anybody tried this before? Is the error that much worse than modelling on an arc? I’m just asking before I try and implement this.

Think about what you’re asking: Mathematically, you want to assume the robot has first driven straight for a given distance and then turned to match the measured turn OR you’re assuming the robot first turns and then drives the remaining distance. These are not the same! I urge you to get some paper and draw it out: these situations give you very different end points for your robot depending on the order you do these steps in.
In fact, the most likely scenario through any snapshot in time is that all rotation and movement has been constant throughout the time interval. This is why we approximate the robot’s motion as an arc rather than a straight line. If you have the time lying around, I urge you to implement your straight line odometry and share how it goes.

8 Likes

I second the above, draw or write out the math you’re thinking of. Does it make sense conceptually.

From a math perspective, it does not make much sense.

2 Likes

I think my math makes sense conceptually I’d just do thisimage

and then for the strafe encoder I’d just use robot_angle + pi/2 or - pi/2 depending on what coordinate system I choose.

That’s where it gets a little funky: you have two robot angles, one that you start with and one you end with. Do you use the starting angle, the ending angle, their average, or some other number?

2 Likes

Right now I think I’ll use the starting angle and assume the angle doesn’t change during the 15 millisecond interval, although I’ll report how it works when I try it out this week. Thanks for answering btw :slight_smile:

2 Likes