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.