So now that we have a way of describing
dynamical systems with differential
equations in continuous time. Or
difference equations in, discrete time.
Let's, see if we can actually use this, to
do something interesting with, with
robots. And, let's start with. Building a
cruise controller for a, for a car. And
the, the cruise controller. I mean it's
job is to make the car drive at the
desired reference speed. And if you
recall, we're going to use r to describe
the reference. So someone You, in the car,
have set the reference speed to, to 65
miles per hour, or whatever you desire.
Now, we want to somehow understand how we
should model the car so that we can make
it go the reference speed. Well, like I
said last time, the laws of physics
ultimately will dictate how Objects in the
world, like robots or cars, behave. And
Newton's second law says that the force is
= to the mass * the acceleration. Now,
this is what we're going to have to start
with. There's nothing we can do about
this. It is what it is. Now, what is the
state of the system? because we need to
somehow relate Newton's Second Law to the
state. Well, in this case, since what
we're going to do is try to make the
velocity do the right thing, we can say
that, let's say that the velocity of this,
the car is the state. So x is going to be
The speed at which the carrist is driving.
Now acceleration a appear, this, a is
simply dv dt and its the time derivative
of the velocity or the change in velocity
as a function of time. So what we get from
that of course is that we can relate the
velocity to the acceleration. Now we're
also going to have to have an input, and
when you're driving a car, the input, if
you're dealing with, with speeds rather
than which direction the car is going is,
you press the gas pedal or the brake. And
we are going to be rather cruder and say,
you know what? Somehow we're mapping
stepping on the gas or the brake onto a
force that's applied To the car. And this
is done through some linear relationship,
where we h as some coefficient c, which is
an electric mechanical transmission
coefficient, and I'm going to go out on a
limb and say, we don't know what this is.
And, I control this sign cannot rely on us
knowing c, because we're not going to know
exactly what it is. But, let's at least
for now, go with this, and hope That
that's good enough to give us the design
we want. So now we know that the force is
c times u, but it's the mass time the
acceleration. Right.
So x dot, which is the same as dv, dt,
which we had up there. Well, that's A
which means that mass times the
acceleration which is mx dot is equal to
the force, but the force is c times u. So,
that tells me directly that x dot is c
over m times u. So, this, this sweet heart
equation here is an equation that
describes how my input maps on to. The
state of the system. It's a differential
equation. But it's an equation that tells
us something about how my choice of input
affects the system. Okay.
This is, in fact, a rather good model. And
I want to show a little video. I was
involved in one of the, the DARPA. grand
challenges.
This was an urban challenge. Where we were
supposed to build self-driving cars and we
use almost exactly this model for, for our
car. So I want to talk a little bit about
how one would do this. So here is the
front, a spinning thing, that's a laser
scanner. On the side here, is another
laser scanner sitting on top of a radar.
These were what we used to get
measurements. Now what we see on the
inside is our instrumented car, which
translated ultimately input voltages onto
mechanically things that push down the gas
pedal. So this is how we actually affected
it with the same coefficient. And now,
look at this video. The car gets around
obstacles, and then it gets out of bounds,
and it starts oscillating. So, I'm showing
this. A, because I think the car is
awesome. But, B, because there are, even
though we didn't crash into things, we
were oscillating a little bit. so there is
something not perfect about this control
design. See how we get out of the lane,
we're oscillating too much. If you look at
the steering wheel, see that this is a
little skittish. and that's another
indication that maybe the control design
here wasn't perfect, but the velocity
controller was based on a model that's
very similar to, to what we just wrote
down. here's another example of obstacle
avoidance where. We're actually trying to
avoid another car, but the point being is
that, this very, very, very simple model
that we wrote down is actually applicable
to real systems. And this is part of the
miracle of abstractions, that you're that
you're able to get simple things that you
then can apply for real. Now, I want to
point out that we did real well In this
competition up to a point, these were
actually the semifinals before the finals.
So let me show you what happened at the
end. This breaks my heart to show you but
I'm going to show it to you anyway. Here
comes our car. Sting racing.
It's slowing down, it's slowing down and
then ow. It drives straight into a k rail,
which is this concrete railing. What
happened was that we got some measurement
errors, a lot of measurement errors
actually from the GPS. But I wanted to
show you this because it was the outcome
of it. regardless of which, this was
still. A very complicated system. A very
complicated robot, a car, and the model we
came up with was very simple, and the
point is that simple models a lot of times
get you very far. So, let's see how we
should actually do, do the control design
here. let's assume that we can measure
directly the velocity, and record, recall
that the state. X is the velocity the
measurement or the output is what we
called y, so y is actually directly equal
to x in this case, so we have a some way
of measuring velocities which you know
typically have a, you have a speedometer
in your car so we know roughly what the
velocity is and now their control signals
should be a function of R-y, where r is
the desired velocity and y is the actual
velocity. And, I'm going to call this e,
which stands for error. And our job, as
control designers, is to make the error
disappear, drive the error down to zero.
So let's, before we do the actual design
discuss a little bit about what are The
properties that a useful controller could
have. Well 1 property is that the
controller should not overreact. If the
error is tiny, we're almost perfect in
terms of the velocity of the car, we
should not have a large control signal.
The control signal should not be
aggressive when we're close to being done,
it's like. Lets say that you're trying to
thread a, a thread through a needle. Well,
when you're really, really close you
shouldn't just jam the thread in there.
You should take it nice and slow when
you're close. So, no overreactions. That's
important, because when you start
overreacting, you start responding very
Quickly and aggressively to measurement of
noise, for instance. So, a small error
should give a small control input. U
should not be jerky. And jerky, here. All
I mean with that is that, it shouldn't
vary too rapidly all the time. Because if
it does, then we're going to be sitting in
this car. With our cruise controller,
we're going be having a cup of coffee with
us. And, now the cruise controller is
smacking us around all over, because it's
jerking, we're going to spill our coffee.
And, in fact for auto pilot's on
airplanes, there are limits on their
accep, acceptable accelerations That are
directly related to cups of coffees
standing on the, the tray tables in the
aircraft. so you should be, not
overreacting. It should not be jerky. And
the, it should not depend on us knowing c
and m. So, m is the mass of the car. C is
this semi-magical transmission
coefficient. The mass of the car is
changing depending on what luggage we
have. It's changing depending on how many
passengers we have. We should not have to
Redesign our controller just because a new
person entered the car. We shouldn't have
to weigh everyone and enter how much we
weigh to, for it to work. And in fact
elevators have bounds on how many people
can be in the elevators. This is import,
related to the fact that they design
controllers that are robust to Variations
in mass across a certain spectrum. Same
thing for cars. The cruise controller
should work no matter how many people are
in the car and we don't want to know c.
What this means is that controller can not
be allowed to depend exactly on the values
of c and m. So these are the 3 properties,
high level properties that we have to
insist on our control signal to have. So
having said that, in the next lecture
we're going to see how we can actually
take these high level objectives and turn
em into actual controllers and see what
constitutes a good control design and.
Conversely, it would constitute a bad
control design.
EmoticonEmoticon