0:00

So now that we have a model, we need some way of knowing where the robot is because

the state of the robot is xy and fine, meaning the position xy and it's heading,

fine. Odometry is the means by which we can obtain this pose information and the

question is, how do we actually get the state or the pose of the robot? Well,

there are a number of different ways of doing it, but at the end of the day, we

absolutely need sensors . Well, there are two possibilities here. One is we can use

some kind of external sensors. So, an external sensor would be a sensor that's

measuring something in the environment. So, for instance, you pretend that you can

see a, A landmark. Let's say I can see the Eiffel Tower. And

now I start moving around, if I keep track of the Eiffel Tower I should be able to at

least know where I am relative to the Eiffel Tower. Right.

That seem to make some sense. So the external sensors. Ultrasound, infrared,

cameras, laser scanners, these are sensors that tell us something externally about

where we are. There is another type of external sensor that one can use, of

course, which would be GPS and it's external because we're not measuring it

internally, we're getting information from Outside, and the GPS immediately would

give us things like position and so forth. However, when you're running robots

indoors, you certainly don't have GPS signals, And a lot of times GPS alone is

not enough to know x, y, and phi to any high level of, of fidelity. So what you do

is you typically couple the external sensors with internal. Sensors.

So the internal sensors are sensors that are sitting in the robot. And they are

helping you know where you are. So, for instance, you could use a compass to,

figure out which way the, the robot is heading. So this would be orientation. Of

course, in every self respecting robot, there are accelerometers, and gyroscopes

for finding out. And how far you've traveled and so forth. So position and

orientation can both be derived from accelerometers and gyroscopes to certain

degree. another useful way is Wheel encoders. So typically you have tick

counts, you can tick and count how many. Basically, how many revolutions the wheels

are doing in a certain amount of time, and from that you can actually figure out

things about where the robot is. And, I would like to discuss a little bit with

you about Wheel Encoders. And the reason for that is, that if we are indeed now

working with the referential drive robots for awhile, lets see, if we can find out a

little bit of how we can get position information. And more importantly, how

much can, Can be trusted. So, a wheel encoder gives the distance moved by each

wheel. So, we have left and right wheels here. And here's the following assumption

we're going to make. We're going to assume that each wheel is following an arc, which

means that it's turning at a constant rate and driving at a constant velocity,

basically. So, v and Ohm r are constant. What this means is, on short time scales

that's, That's correct. And if we do that, well, let's say that D

3:08

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