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.