Let's talk about PID control. Chances are you've interacted with something that uses a form of this control law even if you weren't aware of it. And so it's worth learning a bit more about what this control law is actually doing and how it helps us.
However, often when we're learning something new in control theory, it's easy to get bogged down in the detailed mathematics of the problem. So, in this video, we're going to skip most of the math and instead focus on building a good intuitive foundation. So I hope you stick around for it.
I'm Brian and welcome to a MATLAB Tech Talk. We start with a plant. This is what we call the system that we want to control, or the system whose behavior we want to affect.
The input into the plant is the actuated signal and the output is the controlled variable. Different industries refer to these signals by various names, so you might hear them called something else like plant input and plant output. But regardless of the names, the basic idea of a control system is to figure out how to generate the appropriate actuated signal, the input, so that our system will produce the desired controlled variable, the output.
And that's basically the job of the control engineer: produce the right input into the system to get the output that you want. And just like before, the output you want also goes by various names. Here I call it the command or the commanded variable, but you might also hear it as the setpoint, the reference, or the desired value.
And in feedback control, the output of the system is fed back -- hence, the name and compared to the command to see how far off the system is from where we want it to be. This difference between the two is the error term. If the output was exactly what we commanded it to be, then the error would go to zero and that is what we want zero error.
So the question is how do we take this error term and convert it into suitable actuator commands so that over time the error is driven to zero. And the answer is with a controller. Let's illustrate this with an example.
Imagine you are standing on the goal line of a soccer field and you want to walk to the half field line 50 meters away in this case. You are the plant the actuated signal is the speed and the direction that you walk and your current location on the field is the output variable or 0 meters to start and then 50 meters is the command Therefore at the beginning your position error is 50 meters or 50 minus zero You still have a ways to go. Your brain being the controller tells your legs how fast to walk and One way your brain can do this is to use the error at the present moment to decide your walking speed Here I've set our controller to the value of 0.
1. This means that if we take the error in our system and multiply it by 0. 1.
We'll get our walking speed. So if our error is 50 meters like it is at the beginning, then we'll start off walking at 5 meters per second. With a proportional controller like this, We start reducing the error quickly since we're far away and then gradually slow down as we get closer and closer to our goal.
In this way we would eventually and asymptotically reach the half-field line, at which time the error would be zero and our proportional controller would multiply that by 0. 1, which would generate a walking speed of zero. Stopping us right where we want to be.
If we wanted to adjust the amount of time it took us to get to the goal, we could increase or decrease the multiplier term. Regardless of the game value chosen, this type of controller will eventually cause us to stop right on the goal line. So this proportional controller seems great.
I mean, just multiplying the present error by a number seems to work. Well, let's try it again on a different system and see if it performs the same way. In this second example, you want to design An altitude controller for a quadcopter drone.
The drone has four propellers and when they all spin up together they produce a force that lifts the drone up into the air. This is similar to our walking example, in that we're trying to get to a specific location. But this time we want to get our system to hover at an altitude of 50 meters.
Our plant the drone and the output of this system is altitude. Now the input of the system is not walking speed but propeller speed and all in all it seems like a pretty similar problem. So how well does a proportional controller work in this case?
Well, when the drone is on the ground there's an error of 50 meters, which would generate a large propeller speed, causing the drone to lift off and start to rise, Reducing the error. So far so good. But let's imagine the drone was able to rise all the way to 50 meters.
What would happen now? Well, the error would drop to zero since the command and the output are both 50 meters. This would then shut off the propellers.
Lift would stop, and the drone would fall back to earth. Now when that happens the propeller speed would start to increase again as the error grew. There is a certain propeller speed where the lifting force is exactly equal to the weight of the drone, and at that speed the drone will hover.
So where would our proportional controller hover this drone? Well that depends on the controller gained. Now let's assume for the moment that the propellers need to spin at 100 rpm in order for the drone to hover.
If Our proportional gain was 2, then the drone would hover right at ground level. Since an error of 50 times 2 is 100 rpm However, if we increased the gain to 5 the drone would rise at first but then stop at 30 metres since the error at that point would be 20 meters and 20 times 5 is 100 rpm. A gain of 10 would produce an error of 10 meters and a gain of 100 would produce an error of 1 meter.
And no matter how high we increased the gain, the error won't go away, It'll just get smaller and smaller with this system and a proportional controller. So we can see that a simple proportional controller doesn't work in every situation. It works with our walking example, but for our drone, it created this constant error -- this error is also called steady-state error.
So, how can we tweak our controller to get rid of this steady-state error? We can do that by letting our controller use past information, specifically adding an integrator path in our controller that's added alongside the proportional path. An integrator sums up the input signal over time keeping a running total.
Therefore, it has this memory of what has happened before. Basically, it's keeping track of the past. Now if the drone gets to steady-state below the desired altitude The error term is nonzero and when a nonzero value is integrated, the output will increase.
Now as long as there's error in our system, the integral output will continue to change, and this increased value from the integrator path will increase the speed of the propellers and the drone will continue to rise. These two paths, the proportional and the integral path, work with each other to drive the error down to zero. And with this controller, when the drone is hovering at the desired altitude of 50 meters, the Proportional path is doing nothing since the error is zero.
But the integral path has been summing and subtracting values until it came to rest at 100 rpm. Remember, this is what we said was needed for the drone to hover and that output from our integrator will not change since the input to the integrator at this point is zero. All right This proportional integral controller is it.
This is what we want, right, something that understands the present and has memory of the past. Well, looking at the past and present error will get us to our goal in this situation. However, the path the drone takes to get there might not be ideal.
Imagine this situation Right before we get to 50 meters, there's an interesting situation that can occur. The proportional path is basically zero since at this point the error is so small. But depending on how the drone got to this height the integrator may have summed to a value over 100 rpm.
This would cause the drone to keep rising, which is what we want since we're below the 50 meters. However, to remove that excess propeller speed the drone will have to go higher than our goal to create a negative error. This negative error when summed lowers the output of the integrator and slows the propellers down.
This overshooting of the goal might not be desired. Luckily, there is a simple way around this problem and that is by adding a path to our controller that can predict the future and respond to how fast we're closing in on our goal. And we do that with a derivative.
A derivative produces a measure of the rate of change of the error that is how fast the error is growing or shrinking. For example, if our drone is rising quickly and fast approaching our goal, this means that the error is quickly decreasing. That decreasing error has a negative rate of change, which will produce a negative value through our derivative path.
That negative value will be added to our controllers output. Therefore lowering the propeller speed. Basically, our controller is using changing error to determine that we are closing in on our goal way too fast and then prematurely slowing down the propeller speed, preventing the drone from overshooting.
And just like that, we've created a PID controller proportional integral derivative. This is a versatile controller that uses the present error, the past error, and a prediction of the future error to calculate the appropriate actuator commands. These three branches each contribute some amount to the overall output of the controller.
And as the designer, you get to decide how to weigh each contribution. You do this by adjusting the game term in each branch. This is called tuning the controller.
Now if your controller contains all three branches, it's called a PID controller. Now if the gain of one or more branch is set to zero taking it out of the equation, then we typically refer to that controller with the letters of the remaining paths. For example API or AP controller.
PID is just one form of a feedback controller, but they're pretty easy to understand and implement They are the simplest controller you can have that uses the past present and future error. And it's these primary features that are needed to satisfy most control problems. Not all but a lot of them.
That's why PID is the most prevalent form of feedback control for a wide range of real physical applications. Now there's a lot more to learn on this topic and if you stick with this series we're going to explore PID controllers in more detail. Now that we have a general understanding of what PID control is we'll move on to how we implement one, how we tune it to do what we want, and we'll watch it in action on some real hardware.
So if you don't want to miss these future Tech Talk videos, don't forget to subscribe to this channel Also, if you want to check out my channel control system lectures, I cover more control theory topics there as well. Thanks for watching and I'll see you next time.
