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
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
EmoticonEmoticon