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.