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.

That seemed simple enough and it appears to work - in theory at least. But there are a few problems that a PID controller introduces in practice, and in this video, we’ll focus on how the integral path 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 examples 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 any arbitrary command given to them. There’s backlash, rate constraints, and saturation to name just a few. 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 non-zero error.  When that error goes through the integrator, the output will continue to rise over time.  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.

It’s not just motors that experience saturation, it’s all real actuators.  For example, a battery can supply only 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 systems 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 a hundred rpm, a thousand, 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 sums together to get the 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 only 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 to 50 meters, we don’t let go. We continue to hold onto it for a little while, keeping it near the ground. 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 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. 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 1000 RPM but we’ve held onto the drone until the output from the integrator is requesting 2000 RPM.  The motors are only spinning at 1000 since that’s as fast as they can go. At this point, we let go of the drone and it rockets up toward the commanded altitude and the error begins to decrease.  Once 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 2000 RPM, so when it’s at 1900 the motors are still spinning at 1000, when the command is 1500 the motors are still spinning at 1000. We have to wait until the integral unwinds back to 1000 RPM before the propellers actually start slowing down.  And during that entire time, the drone is skyrocketing upward 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 and 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 a popular method 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 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 wind up problem 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 are 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 the integrator is still adding to the output to make it more positive, and if they are both negative then we know 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 making 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 zero, effectively shutting down integration. 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.

1. The output is saturating, and
2. The error is the same sign as the controller output

If we had an anti windup method on the drone that we were holding in saturation, 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. That’s pretty awesome.

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 1000 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 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.

Overall, clamping is a relatively lightweight anti-windup method that can improve the performance of your PID controller when it’s controlling a system that is operating outside of its linear region, or when it’s saturated.

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, I’ll see you next time.