0:00

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.

Â