is the distance the left wheel has turned, and D[UNKNOWN] is the , distance the right
wheel has turned. So in this case, the right wheel is turning quicker than the
left wheel because it's turned, turned more. Well, I'm interested in x, y, and
phi. Which is not where the wheels are, but where the center of the robot is. This
is where I'm interested in. So DC is the distance the center has turned and that's
the thing that I'm interested in. Now luckily, the center is simply DL + DR / 2.
I am not going to be particularly Picky in showing where the geometry of this comes
from. Instead, these are things that are readily available if you want to look up
things, like how wheel encoders work. But I want to connect a little bit with the
mobile robot model to the wheel encoders, just to see how we reason about things,
and in fact, if we are measuring how far. The road the wheels have moved over a time
interval. So let's say that we start at x and after the time interval , well we know
Dc because Dc is this thing then we can actually compute the new x primes, the new
x position of the robot. We can similarly compute the new y position of the robot.
Which is the same as the x update, but has sine instead of a cosine term. And, we can
even compute, the, the new orientation. So this is a way of knowing how to go from,
how far the wheels have turned. Into what are the new positions of the robot. And,
in fact, we're going to be running quite a few experiments, where the only
information the robot has. Is where it is, based on the wheel encoders. So but how do
we know Dr and Dl, thought? This is what we need to know in order to find out where
the robot is. Well, assume that each wheel has N ticks per revolution. So 2 pi
degrees is N ticks. So most wheel encoders actually give the total tick counts as to.
The beginning, so what you measure is how many ticks since, since you start the
system up. So, the updates I am writing here for both wheels. This is for the left
wheel and the right wheel, so you could write the you know.
Delta tick r or r or but for both of these wheels you take the old total tick count.
And subtract it away from the new total trick, tick count. So this tells me,
what's the tick count during the time interval you just looked at. And then
based on that, you can very easily compute what the distance that wheel has, turned.
So this d here, this d could either be d's of l or d's of r, so it's simply 2 pi r
delta tick over n. So this actually gives as a way of mapping ticks on to distances
traveled, and as we saw in the previous, previous slide distance traveled we can
then map into new position and orientation of the , Fair enough.
There is one major disclaimer I must make, though. And that is, ta-daa, drift. A
system like this, drift. It's very imprecise. And, if your using only real
encoders as your source of odometry, your probably going to run into a little bit of
trouble. So, here, I want to show a video. This was from one of the. Cou rses I
taught recently where you have now two robots competing against each other. It
looks like they're following lines but all they're doing is following wave points
that laid down, and they're using a PDA regulator to get through wave points. And
what you can see is that they're getting a little but out of whack, and the
interesting thing here is one robot gets up on top of the other robot and as a
consequence the wheel is spinning without it's actually touching the ground. and as
you can see The robot then has a completely confused idea of where it is in
the world. So this would be an example of were drifts its rather severe the robot is
going in way wrong direction because of the fact that the real encoders no longer
correspond to what's happening on the ground. So we're going to use real
encoders a lot. They're used a lot in robotics, but we always need to be aware
of the fact that themselves, by themselves, wheel encoders do not tell the
full story or a particularly robust
