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.
