Anti-windup for PID control | Understanding PID Control, Part 2

625.17k views1909 WordsCopy TextShare
MATLAB
The first video in this series described a PID controller, and it showed how each of the three branc...
Video Transcript:
In the last video, we described the PID controller and how each of the three branches contribute to controlling your system. We started with a simple proportional controller and then added an integral to remove the steady-state error and then a derivative to increase performance and to keep the system from overshooting. And that seemed simple enough, and it appeared to work, in theory at least.
But there are a few problems that a PID controller introduces in practice, and, in this video, we're going to focus on how the integral path, in particular, can get us into trouble. To start we need to expand the system we call the plant. The plant can be thought of as two separate systems.
The first is the actuator or actuators. These are the devices that are generating the force or energy to change the system. A motor or a heater are example of actuators.
The second system is the process or the thing that the actuator is pushing against or trying to affect in some way. If your actuator is a heater, then the thing you are heating up is the process. So here's the problem.
In real life, actuators aren't linear systems. They can't perfectly follow any arbitrary command given to them. There's backlash and rate constraints and saturation to name just a few.
And these limitations can wreak havoc through an ideal PID controller like the one we described in the last video. So, if you stick around, we're going to expand beyond a simple integral and make a few changes that will protect your system against one of the more common nonlinear problems found in real-life situations. I'm Brian, and welcome to a MATLAB Tech Talk.
We begin by looking at the path the error takes through the integral to generate an actuator command and then through an actuator to get its response. Imagine a scenario where the actuator can saturate or, another way of putting it, where the actuator is not able to follow the command it's given. Picture this.
A system is subjected to some continuous nonzero error. When that error goes through the integrator, the output will continue to rise over time. And if our actuator is, say, a motor, then we can think of this value as the commanded RPM.
If we command a motor with this ever-increasing request, it will spin up and follow the command at first, but, eventually, it will hit its maximum RPM and won't go any faster, even if the actuator is being commanded to do so. This is saturation. The motor can't run any faster.
And it's not just motors that experienced saturation. It's all real actuators. For example, a battery can only supply so much current, and a speaker can only produce a sound so loudly.
When you are developing your PID controller, if all you interact with are linear models of your system, you might not think this is a big deal. After all, there is no such thing as saturation in a linear system. Any output value is achievable.
So you'll never come across this situation. You want to spin a motor at 100 RPM, 1,000, a million? This is possible in a linear system.
But real-life systems are not linear, and, if you only think about how your PID controller will behave in this sense, that can get you into trouble. We can figure out why by asking the question how does our PID integral handle an actuator that saturates. Assume we have the drone from the last video, and we're trying to control its altitude with a PID control law.
The altitude error goes through the three PID branches and then sum together to get a propeller command. The propellers are the actuators, and they react to that command and spin up or down to some speed. The propellers generate a force that lifts the drone, the process, into the air and changes its altitude.
Again, for this example, we're going to see what happens only within the integral path, but there's a catch. After we turn on the drone and tell it to fly up to 50 meters, we don't let go. We continue to hold on to it for a little while, keeping it near the ground.
I don't know. Maybe we wanted to inspect the operation before letting it go, or maybe this was a test of a construction drone that attempted to lift something heavier than it can handle. Either way, there is a constant error of 50 meters in the control loop, and this will enter the integral and start adding up, increasing the command to the propellers, telling them to spin faster because the system needs more force to take off.
The propellers will keep up with the command, spinning faster to fight against you at first, but you're strong and holding it down. And, since the drone isn't rising, the error is still there. Eventually, the integral will request a speed that is faster than the propeller motors are able to spin, and they will stop accelerating.
However, the integral, not knowing that the propellers have given up, will continue to increase the command. You might think this isn't much of a problem since the motors themselves are, essentially, ignoring the command. So it's not like something will break if you command too high a value, but winding up the integral command in this way or commanding a value over the saturation limit isn't the problem.
The problem comes from trying to remove or unwind the excess command from the integral. Let's imagine this situation. The maximum motor speed for this drone is 1,000 RPM, but we've held onto the drone until the output of the integrator is requesting 2,000 RPM.
The motors are only spinning at 1,000 since that's the fastest that they can go. At this point, we let go of the drone, and it rockets up towards the commanded altitude, and the error begins to decrease. Once the drone gets above the command, the error term becomes negative, and the integral output starts to decrease.
However, it's coming down from a value of 2,000 RPM. So, when it's at 1,900, the motors are still spinning at 1,000. When the command is 1,500, the motors are still spinning at 1,000.
We have to wait until the integral unwinds back to 1,000 RPM before the propellers actually start slowing down. And, during that entire time, the drone is skyrocketing upwards and out of your sight. This is called integral windup, and it's something we need to protect against in our PID controller because you never know if you're going to get into a situation where an actuator saturates.
And, when something does saturate, we want to minimize the time it takes to reverse the command when the error changes signs. So we need to implement some kind of anti-windup method. There are multiple ways to implement integrator anti-windup, but the idea in each of them is to keep the integrated value from increasing past some specified limit so that it will immediately respond in the opposite direction when the error changes sign.
Clamping can, basically, be thought of as turning the integrator off whenever you don't want it integrating anymore. And I'm going to talk about this method in more detail because it's popular, and I think it will help you visualize how anti-windup can be accomplished in general. We'll start with our familiar PID control law that acts on the loop error and generates an actuator command.
But, as we just learned, sometimes, an actuator can't follow the given command, and it saturates. So, even if a large actuator command comes in, the output will be capped at some value. So the first thing we want to do with our PID controller is make sure that it doesn't output a value outside of what the actuator can handle.
We can do that by simply limiting the output of the controller with its own saturation check. Now we know the actuator command won't be too high, but we haven't removed the windup problem just yet. The clamping method has two separate checks that it's doing.
The first is to compare the output of the PID controller before and after the saturation check. If the values are equal, then no saturation took place, and this block outputs a 0. If they're not equal, then we are in saturation, and the block outputs a 1.
The second check is to compare the sign of the controller output with the sign of the error. If both the error and the controller output are positive, then we know that the integrator is still adding to the output to make it more positive. And, if they're both negative, then we know that the integrator is trying to make it more negative.
So we're looking to see if the output is currently saturating, and the integrator is attempting to make things worse. From this, we can tell whether to clamp or not to clamp. If the decision is to clamp-- that is the output of the AND gate is a 1-- then a switch is triggered, and the error term in just the integral path is set to 0, effectively, shutting down integration.
And, once the error changes sign or the controller is no longer in saturation, the input into the integral is restored, and the value immediately begins to decrease. This is also referred to as conditional integration because our controller will shut down the integrator if it meets certain conditions. One, the output is saturating, and, two, the error is the same sign of the controller output.
If we had an anti-windup method on the drone that we were holding in saturation, then, as soon as the drone got to the commanded altitude, the error would switch signs and the integral path would immediately start to decrease the propeller speed, limiting the overshoot. And that's pretty awesome. All right, one quick side note before we wrap up here, when setting the saturation limit for your anti-windup algorithm, you have to be a little conservative.
For example, you wouldn't want to set the clamping limit to exactly 1,000 RPM because that is way too close to the physical limit of the actuator. If the motor temperature changes, the motors slow down with age, or if the propellers get dented or bent, then that might limit the maximum motor speed to a lower RPM. And then our clamping algorithm will still allow some integrator windup.
So it's a good idea to set the controller limit to a value lower than the physical limit. How much lower? Well, that depends on how well you know your system and how much you trust your modeling of it.
But, overall, clamping is a relatively lightweight, anti-windup method that can improve performance of your PID controller when it's controlling a system that is operating outside of its linear region or when it's saturated. OK, in the next video, we're going to focus on the derivative path and how non-perfect sensors can impact our ideal PID controller. So, if you don't want to miss the next Tech Talk video, 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.
Copyright © 2024. Made with ♥ in London by YTScribe.com