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

Â