Flash and JavaScript are required for this feature.
Download the video from iTunes U or the Internet Archive.
Instructor: Russ Tedrake
Description: Prof. Tedrake introduces the power and complexity of modern control systems, which use feedback to stabilize and compensate for delays and other errors. Examples are taken from his research into perching planes and other high-performance aircraft.
Lecture 10: Feedback and Co...
The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation, or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.
PROFESSOR: I wanted to give a lecture, because as I told you in presentations, I love feedback. In fact, I love it so much, that I think the examples we're going to do, we can do analytically are not maybe sufficiently compelling for you to believe how exciting control can be. So let me just start by giving a few minutes of a research result we had a few years ago.
That's why you've got color images-- everybody noticed the color images on the slides. I brought this robot in to the first recitation of [INAUDIBLE]. It's a big 2 meter wing span ornithopter, and in my case, we've been trying to design control systems to make airplanes move more like birds. Here's one example of that. One thing birds do that planes don't do very well is land on a perch. So we asked the question, can we take a simple airplane with fixed wings, no flapping allowed, and make it land on a perch-- UAV stands for unmanned aerial vehicle-- land on a perch like a bird.
The story I want to tell you is that with feedback design, you can.
Here's why it's interesting and hard. The reason airplanes don't land on a perch is because, when your wing is at a low angle, which a plane normally is when it's flying, the air flow around the wing is relatively easy to model. It's easy to write a block diagram description of. But if you go to moderate angles, that's still true. The air stays attached to the wings and everything-- [INAUDIBLE]
At a low angle, the air is still attached to the wing, and so we have very good models of the airflow around here, and the lift and drag forces that you get when you're flying in these regimes. But if you go up too far, like this, then everything changes. So you think, the air can't quite stay around the wing. You get separation. You get big vortices pulling off the back. It's very nonlinear, very unsteady. Very complicated flight regime. And as such, our best aircrafts to date mostly stay down in this regime where we have good models and we can design conventional control systems for.
But birds don't do that at all. So birds are, often, when they're landing on a perch, they're up even far beyond this. Maybe even 90 degrees. "Angle of attack", it's called. They're way into this deep stall regime-- that's called stalling your wings when that happens. And it seems like they're doing a lot better landing on a perch because we don't see our airplanes do it.
But you can actually try to quantify that. So if you want to compare the performance of a bird landing versus a plane landing, the first thing you have to do is you have to take out the differences in mass and wing area and all these things. But you can do that. And a fair comparison is the distance averaged drag coefficient, which is just a way to scale out the effects that you'd expect from having a bigger wing or a bigger mass. You can plot this drag coefficient for a few different vehicles.
This is a standard runway landing of a 747, would get the drag coefficient, just so you have some calibration, of about a 0.16. The X-31 was a super maneuverable research vehicle. It was designed to do super short runway landings, and it got a drag coefficient during those landings of about 0.3. There's a few other projects out there about trying to make perching planes that were getting similar numbers.
But then we went out and looked at nature. I have some collaborators at Harvard that work with real birds. It turns out-- I wanted him to tell me the numbers from some really elite bird, like at least a hawk or something like this. But they work on pigeons. So that was the only number we could get, was a pigeon. They actually convinced me by the end that pigeons are really good. The way they can sort of dive through the fence and get your lunch by the food trucks? I mean, that's actually-- they're seriously skilled birds.
We even had-- one of the fun things about doing this kind of research is you get visitors. We had will.i.am from the Black Eyed Peas come to the lab. And he said-- after we told him the story, he said pigeons are ghetto birds. They got mad stop. That sort of summarizes it.
You already know the answer. But if you look at the drag coefficient that a bird gets when it's landing, they get a 10. So they're doing orders of magnitude better than our best planes in terms of stopping. If you just want to be fun about it, you could say, what would it take for a 747 to get a 10 to impress will.i.am. And it turns out that 747 would have to go-- they fly at about 450 miles an hour cruise speed. It would have to stop in 40 meters to do what a bird's doing. The wings would probably pop off. There's problems with that. But the dynamics are impressive, of the birds.
And what's more, when they're doing that, they're getting incredible accuracy. This is one of my favorite videos of a perching owl. If you watch really closely, you can see the airflow get complicated on his wings. You can see his leading edge feathers start to flip over. Boom. The way you do that is you put food by the camera.
We tried to build these simple planes and ask if could they do what the owls are doing, what the pigeons are doing. Very simple planes. We did them in an indoor environment. We made it so it was basically a boring plane, but it can do very interesting things in pitch, up and down.
Then we spent some time trying to build a dynamical systems representation of the plane. And how do you do that? Well, you shoot the plane a bunch of times into a fishing net. And you collect a bunch of data. And like we talked about in recitation, you can potentially get from that data a model of the dynamics. And turns out, we had to do a nonlinear dynamical model for the vehicle, but we could do a linear actuator model plus delays and everything. We built a pretty good model of the plane, which is sort of-- for an aerodynamics crowd, this would tell you that this is a surprisingly good fit to the lift and drag forces over a very large range of angles.
Then we had a 6003 problem, basically. The nonlinear terms make it a little different. And what we did as a group was we innovated a way to design a feedback controller that could make this thing very accurate during very high performance maneuvers. And a long story short, we can now shoot an airplane into a motion capture arena. This is slowed down about 11 times. It's this airplane right here. And it goes into a very deep stall. And we can land with an accuracy, enough accuracy to land on a perch.
It turns out if you can build a good enough control system that can handle the complexity of the dynamics, then you can make these things happen. This is just-- to convince you that the dynamics are complicated, this is the flow visualization. We built a wind tunnel releasing smoke from the leading edge and took a picture of it to show you how complicated the dynamics were.
So control is potentially an incredibly powerful idea. You can make-- we try to make robots that run like ostriches. We try to make all kinds of things happen. You could imagine improving wind energy. You could imagine all kinds of things where control is an integral part of it.
The feedback in there was absolutely essential. If I took the same plane and thought about the model a lot and then designed a controller, just a set of commands to the elevator, to try to make it land on the perch, it misses the perch every single time. And with feedback, we can hit-- it's only with feedback that we can hit the perch every single time. And there's a reason for that.
You guys probably heard the idea that fighter jets are unstable without the control system, right? Fighter jets are-- a lot of times, the systems that have peak maneuverability, that's often at odds with stability. In fact, when you try to make a very high performance fighter jet, and you want to be able to turn, you actually-- if the control system is off, this thing should be unstable. It's not a complete pathology, but that's pretty true, because what you want, you can elicit a very fast turn if you basically let the system go unstable. Then you can let the unstable dynamics of the system make a very rapid turn. In fact, it's common to build a system that is unstable, and it's only stable when there's feedback in the loop so that you can have very high maneuverability when you need it.
You've already done feedback if you took 601, right? So what I want to do today is-- I taught 601 when some of you were in there. I want to go through the example that you already worked through in the 601 lab for those of you that took it. I think it's sufficiently complete here if you didn't take it. But we want to use that-- I'm going to use that as an example to build on what you already know and to show us with the new tools how far you can get in thinking about what that robot did for you last year. Do you remember this example of the little pioneer robot that had to go to the wall, the foam wall, using the noisy sonar sensor? And we wanted to get a desired distance from the wall? And by the end, you guys were moving the board around and it was trying to track the wall?
In that exercise, in the 601 lab, you guys tried a bunch of different gains. For some gains, we saw responses that sort of looked like this. If you gave a desired distance to a wall, it would go up to that desired distance. For other gains, you saw some oscillation. You saw some big oscillations if you tried all the gains we recommended. Now you guys have a deep understanding of what kind of things can cause that type of response.
The way we told you to think about it in 601 is actually the way that we often think about control systems. Typically, we have something called the plant, which describes the dynamics of the robot or the thing we're trying to care about. You guys know why it's called the plant often? What would be the history of calling it "plant"? It's a weird name for it, right? Actually, some of this stuff grew up in the chemical industry, in chemical plants. Is that what you said? No? It's actually-- it has a history in chemical plants. But now everybody calls their robot plants.
The plant is the dynamics of our robot, for instance. You've got some output of that. In this case, it's the position to the wall. A sensor that reads it. It may have its own dynamics. And your goal is to take some reference command, a position you want to go to, let's say, compare it with what the sensor is saying and build a controller that takes that error and makes the robot or control system do what you want it to do.
In this example, the one you studied in 601, the plant was a very simple model of the dynamics of the robot. It was just a first-order model. We said that the output, the distance from the wall, the distance in front of the wall, at time n was just the distance in front of the wall time minus-- because, you remember the frustration of the flipped sign, too? But I kept it consistent here. So it's T times the velocity, just happens that since the velocity is going this way and the distance is getting smaller, you get a minus T. This looks almost like the first-order approximation of a CT system, right? So that's the dynamics of the vehicle.
The sensor, we're going to assume for now, is just perfect, that it just immediately tells me the distance to the wall and gives the perfect feedback. And then we designed a controller, which just takes the error, the difference between the desired position and the actual position, multiplies it by a constant K and comes up with a velocity command that goes to the motors.
You can visualize that as a block diagram, of course. You get that this plant model here-- it's got a minus one here and a minus one here, so that's equivalent having a delay in the forward path. And then it's got feedback, because the previous signal was directly put around to the feedback. So this part here is the model of the plant. Then we put the T in, with a gain here, so I guess this part here is the plant. Here's our simple controller and our sensor is perfect. So that's our block diagram. We've just turned our robot into a block diagram. And we know everything about how to analyze those things. You can use the operator notation. You could think of it as a system function, too.
This guy here you know is-- you guys can do this in your sleep now, almost? But if I just take that by itself, what does that come out to? It's a plus here. This is x and y. So I get y is R x plus y. Or y over x is R over 1 minus R. Then I multiply that by K and a negative t. And then I do the exact same computation again to get this loop around. And this is our input output system function. Simplify it a little bit, I get this. Simplify it a little bit more to identify the pole, and you can see that the pole now looks like 1 plus KT. T represents the time step between updates, K is our feedback gain.
Now, we can start thinking about what happens if we choose different-- let's just lump K and T together, because the K you choose is going to be intimately connected to time. In this system, there's no point in separating them. So we just talk about KT as a system. If we chose KT-- KT is almost always going to be negative. You want negative feedback, in general, for making things stable. If we choose KT equals 0.5, then with that system function, there's a delay in the forward path, so it's going to be offset by one and then it's just got the simple single pole response. The unit step response similarly looks like this. So the question is, what determines the speed of that response?
Here you go. I have to get you to talk to your neighbor the way Denny always seems to get you to talk to your neighbor. Take a minute. Figure out which of these or none of them do you think would give you the best response for this simple block diagram system. Talk out loud to your neighbor.
OK. Show of fingers, what do you think it is? OK. A lot of right answers. Let's just do it real quick. The fastest possible convergence is going to be at the pole zero. Pole zero, what's it going to look like? It's going to give you-- the best you can do if you zero this out, you get the impulse response. The unit sample response would just be R. You're going to have a delay of 1, that's inevitable. You get one non-zero entry and then zeroes everywhere else. In discrete time systems, you can actually kill things in a single step. You can set a pole at 0 that's the fastest possible response.
But if you think about the different responses for different values of K, you can use the pole zero diagrams to pretty much understand everything there is to know about it. For KT less than 0 to negative 1-- like I said, we want to think about negative feedback-- that's going to take us from out here on the unit circle back towards the origin. If I keep making KT more negative, it's going to go out here. If I make KT too negative, bad things are going to happen again. The poles are going to go outside the unit circle and will actually have alternating diverging responses. The answer is negative 1. Negative 1 puts you at a pole of 0.
Here's to think about it physically. If I choose K correctly, since KT was negative 1, that means K's going to be negative 10. That's going to be commanding exactly the right speed so that the robot, after the one tenth of a second, let's say, it gets you exactly to the right position. Unit sample response in this case would be saying, the robot's at zero, I want it to be at 1, and then I want it to be back at zero. The command is going 0, 1, 0. And the robot is going to be almost doing exactly that. It's going to go from 0 to 1 in a single step. And then back to 0 in a single step. It's just going to be delayed by one. So you give it a command saying, go here, go here, go back. And it's going to do exactly the right thing-- boom, boom, except for one step delayed, because you can't get rid of that R.
So if I plot it-- let me draw a stem diagram, but coming down in time so that I can line up with the axes up here. If I start with an initial position here, and I command it to go to the desired front position, it's going to go boom right to that front position with one unit of delay. And then it's going to stay there for the rest of the time. It would be a unit step response.
But that's not what we got to see on the robots in 601, right? The real robot didn't work like that. And the way we made the robot model more realistic was we said, OK, but your sensor's got some delay. And actually, if you knew what was going on behind those 601 robots, it's actually had a lot of delay. There's Python running serial interfaces to over the serial link to the fairly old controller in the pioneer robot. So the delay is real. There's a delay of about 1/10 of a second in the sensor.
If I take that exact same controller, exact same gain that I already did, now put it in this new system that has an extra delay, then what happens? I get a velocity of 10 after one step, looks good. But then, uh-oh, there was some delay in the sensor I didn't realize was here, so I'm still going to take corrective action trying to get me there. It's going to move me all the way to the wall, smash into the wall, and then it's going to realize it was zero. It's going to-- there's some delay in seeing that. It's going to move me back. And you're going to get oscillations.
You can see that now by just adding the model to our block diagram. If we put the delay now in the feedback path, otherwise, keep the block diagram exactly the same. Now, you can write the system function. What's the resulting system function given that this thing is in the feedback path?
Go ahead and put your fingers up when you think you've got it. All right. Fantastic.
Just like I did here, you can just quickly replace the accumulator there with the equivalent block diagram. Do the loop again. It's going to be exactly what we did before, but it's got a new R in the feedback path. Giving us the R-squared here, just on the feedback path. It's exactly the same otherwise except for that R, and that simplifies out to this. So the answer was 4. That's just operator notation, polynomial algebra.
If we want to find the poles of that system, we can just go ahead and factor the quadratic form in the denominator. The roots of the denominator look something like this, which is a little ugly to think about. But we can think it through. For general KT-- when KT's small, KT's about zero, then I'll go ahead and simplify that a little bit to say, KT could sneak inside the-- KT and KT-squared aren't so different. We're going to sneak it inside here. And then you can see that the poles end up at-- around K equal to zero you get a pole at the origin. But you also get a pole up by the unit circle. Around 1 and around 0.
Remember, when you've got multiple poles in the system, the total response is going to be dominated by whatever is the slower pole. The total system response is going to be dominated by the slower pole. In this case, the slower pole's the one closer to the unit circle.
What about if KT equals negative 0.25? We can pop that in and solve it. Exactly-- math works out nicely. We get poles at a half, two poles at a half. And in fact, there's a smooth transition between-- if you look at the numbers between KT equals zero and KT equals 0.25, you'll see as you vary that gain, the poles move together along the real axis until they come together at a half. So here, you've got a purely real response dominated by these poles at a half. System's stable. If you keep changing K though, the poles came together and then they split off and start going this way. And in fact, if you look at negative 1, which is the one that was the best response, it put a pole exactly at 0, for the system with no delay. If you put it at the system with delay, they land exactly on the unit circle. Right there. Complex poles on the unit circle. You're going to get a stable oscillation. Which is exactly what we saw there.
Just a quick-- you know this like the back of your hand now, but what's the period of that oscillation? You've got two poles on the unit circle right there. What's the period of oscillation? Put your fingers up when you think you know. Yep. Good. Most people got it. This thing was a half, so it's 1/2 square root of 3 over 2. So that thing had to be at pi over 3. It's actually the same pole that I was using in recitation yesterday. So if you have a pole at pi over 3, it makes it around in six steps. The period of the oscillation is six.
This is generally true, that if you put a controlled gain, a feedback gain, into the closed loop dynamics, then even a simple gain can allow you to really shift around the poles of the system. And since we know the response of the system, the zeros matter, but for convergence, for the rate of convergence, it's the biggest pole that dominates. It's very nice to understand how those poles move with K. If you change the system, the way they move with K is different. And you can just change K to tune the response to be what you want, from KT equals 0 to infinity, the poles go towards here and then off in both directions, actually, to infinity.
So, KT equals negative 1 was the fastest possible response for the system without any delay in the sensor. What's the fastest possible response for this one?
Oscillations are allowed. I just want the fastest possible response.
Yeah. Looks good. So where do I want the poles to be for the fastest possible response?
These poles are still stable and oscillations are fine, but the absolute-- the magnitude of those poles is larger when they're out here in the complex. When I'm down here, I have got a pole over by one, that's going to dominate. So the best I can do is if I put the poles at a half. That gives us the largest pole, the smallest possible magnitude. And that happened if the poles-- the double poles at a half happened when KT was negative 0.25. Most of you said, the answer is 2.
In general, delay is a bad thing. In DT systems, we have good representations of delay. It's even worse in continuous time. Delay is a bad thing. It tends to make control systems not work as well. If you just took the ideal sensor, we had a K equals 1, we had a response that started here, we could put it anywhere we wanted along the real axis. As far negative as we wanted, of course, what we chose was to put it right at the origin. But as soon as we just added that one piece of delay, the things we could do with proportional feedback changed completely, and ultimately, got worse because I have two poles now, first of all, and I can't simultaneously get both of those poles to go to zero. In fact, as I change them, they go off into complex. The fact that it's complex isn't bad. But the fact that there's two of them, and the best I can do now is get to a half, which is a much slower response, the best possible response.
If I added even more delay, things get even worse. If I had two units of delay and I went through the same exercise, what you'd see is that the poles would start in the same place. They'd come together and go there, and there's another pole that goes off. Just because there are three poles in that system. Two poles come together and split off this way. And this one goes off this way. And the place you probably want, depending on how fast this one splits off, but the place you probably want to put it is when the two poles are together right there. That's going to give you the fastest response. But that fastest response is still slower than what we had-- it's a bigger number than a half. It's 0.682. It's going to be a worse response than when I had a delay of one, which is intuitive.
That's a quick reminder of something you already did in 601, of using feedback and the tools we've already got, which is poles and zeros and everything, to understand how to design feedback gains. We're going to get more into it in the next couple of lectures. But let me just convince you that this stuff is real. And I showed this diagram once in 601, but it probably means even more to you now. This is an F-14. It's one of the best modern engineering control systems ever built. It was built for this F-14. They got more research money and modeling this vehicle, designing ultimate gains for it. It's such a success story that you can actually, if you're in MATLAB, you can open up the F-14 demo and see what a flight control system for an F-14 looks like.
MATLAB-- I don't know if you've played with Simulink-- MATLAB has a language called Simulink, a graphical language that allows you to draw the block diagrams and simulate them and even design controllers for them. And it turns out you can make a block diagram description of an F-14 using only tools from 601 and 6003. You can see all the same adders and gains, transfer functions, system functions like this. The only essential difference is that in some of the diagrams, you see multiple inputs coming in. In this class, we've restricted ourselves so far to thinking about single input, single output systems, which keeps everything clean. All the intuition scales to multiple inputs and multiple outputs. But that's sort of the only big addition of complexity when you go to this model from what we've done before.
If you zoom in onto the controller here, you can-- these block diagrams in this language allow you to abstract away a bunch of hidden things with a single transfer function. If I zoom in, then you can see things you recognize. It's got a low-pass filter, which is just a system with a pole at negative 1, exactly what we did in recitation the other day. This is what people-- this is what MATLAB uses on an F-14. I guess it might not be what the military uses. But it's modeled after what the unclassified documents say is happening on an F-14.
Everything here, you understand, right? A proportional controller in the end. One difference in F-14s is that-- and in general for these more complicated systems-- they'll design slightly different controllers given the situation. So if you have an altimeter on there and pressure sensors, an inclinometer will tell you the angle of the plane-- given those sensors, they'll pick a different K for a proportional controller out of a pot of a library of controllers they've already designed. So it's called gain scheduled control. But the analysis and design of each K is a linear systems design and analysis.
This is super powerful stuff. I think-- signal processing is good, too, but control is where it's at. I guess I went a little fast, but that's your introduction to feedback. We'll do DT and CT feedback in the next couple of lectures. And if anybody hasn't picked up their exams, we have them over here. And we'll see you in recitation tomorrow.