What Is Gain Scheduling? | Control Systems in Practice

Let’s continue our discussion on control systems in practice by talking about a form of nonlinear control: gain scheduling. I had this notion when I graduated from university that I would be spending a lot of time applying state of the art nonlinear control theory and building really fancy controllers. But I found that, for the most part, you’re trying to get away with the simplest design possible because these are typically cheaper to design and easier to implement, understand and troubleshoot. There are some simple nonlinear controllers, the on-off controller of a house thermostat is one of them, but generally the mathematics behind nonlinear control is more complicated and can only be applied to narrow categories of systems.  Therefore, sometimes, the best solution is just to stick with the tried and true linear controller, even for highly nonlinear systems. And that’s what we’re going to do with gain scheduling. I’m Brian, and welcome to a MATLAB Tech Talk.

Imagine you’ve been asked to develop a pitch controller for the autopilot on a commercial aircraft. When the autopilot requests a certain pitch angle, your controller needs to compare that command against the current pitch angle and then drive the elevator control surface to adjust the pitch accordingly.  You’ve already derived a linear transfer function for the plant and verified that the system behaves linearly enough that you can use this model to design and tune your controller.  If all you need to do is design your system to work when the plane is at cruise altitude and flying at a maintained speed, then you can probably design a linear controller that will work just fine.

But, there’s a catch.  This model only represents the dynamics of the airplane at a single operating condition.  Planes don’t fly in just a single operating condition.  The Mach number changes, dynamic pressure, flaps positions, the center of gravity and mass changes as fuel is consumed, the angle of attack changes and so on.  The operating conditions are always changing. And each operating condition has its own set of parameters, and therefore a different instance of the linear model.  This is type of nonlinear system is called a linear parameter varying system (LPV). Where the model itself is linear, but the parameters change over time, or over operating condition. So your linear controller that works so well with a single operating condition, probably work very well at the other operating conditions with the different instances of the model.

So what can we do? We can attempt to design a complex nonlinear controller that will work over the entire operating range, we could try to design robust linear controller that will work - although this will almost certainly be a drop in performance and may not even be possible,  we could just limit the crew to only engage autopilot in cruise under very strict conditions, or we can use one linear controller and change the gains of that controller based on a schedule that we define. Let’s go with that option.

Let’s look more closely at the simplified block diagram for our feedback pitch control system.  For this thought exercise, we’re using a PID controller, but any gain-based control architecture will work. A PID controller has 3 tunable gains, Kp, Ki, and Kd, and let’s say we’ve developed a set of gains for a given Mach number. Maybe a lower Mach number like around 0.3.

Let’s assume these are the gains we came up with. At this point we’ve determined that when the aircraft speeds up to a higher Mach number, these gains are no longer sufficient for the performance we want, and we retune the PID for this new operating condition. Now we have another set of gains.

We have two separate sets of gains and so intuitively it would make sense to measure the speed of the airplane real time, and select one set of gains when it’s flying slowly and another set of gains when it’s flying fast. This is a very simple gain schedule. We’ve selected gain based on the scheduling variable, in our case Mach number.

Once we’ve selected the gains that we want, we need to be able to update the controller with these new gains.  That’s what the arrow coming in from the top of the PID controller is intended to represent.  Within Simulink, there are a number of controller blocks that allow you to define the gain as an external input for this very reason. I’ve left a link to more information on this in the description below if you want to check it out and practice developing your own gain scheduler.

OK, so far we only have a single scheduling variable, Mach number. But now let’s look at the operating envelope, or the ranger over which the airplane can fly for two scheduling variables: Mach number and dynamic pressure, our gain schedule map would look like this - split in half with two different gain sets still. However, we may find that are gains don’t work across the entire range of dynamic pressure and we want to add a new schedule based on this variable as well.  Now we have four gain sets with each set consisting of the three gains of the PID controller.  In this way, we can divide up the operating envelope and conquer each condition separately, jumping between gain sets as Mach number and dynamic pressure change.  And we can add a third scheduling variable, CG location, and make a three dimensional map.  And a forth dimension with angle of attack and so on.  You can see how quickly the variable matrix grows and this is one of the draw backs of gain scheduling.  You want to divide up the operating envelope enough to get good performance everywhere, but not so much that you have a monumental tuning task ahead of you.

Another drawback of really large gain matrices is that you have to store them and then efficiently search for the controller values in them.b So there’s some desire to keep them as small as possible.

On a side note: this graphic is a good demonstration of the term corner case.  When you have multiple conditions operating at their extreme, graphically it’s up in the corner of the envelope.  Typically, these corner cases are the outliers in your design because you have to account for two or more extreme conditions.  So when you’re tuning your controller, you may find that it’s relatively easy and quick in the middle of the operating envelope, whereas, you’re spending more time and energy getting the corner cases to work.

So now that we have an explanation of what gain scheduling is, let talk about how to go about implementing it. There are, in general, four steps and the first two steps I think you may have already guessed by now: 

Step one, linearize the plant at each design operating condition.  Basically, we want to develop a linear controller, we need to make sure we have a linear plant. Let’s refer back to our simple schedule that only had two gain sets: one for high Mach numbers and one for low Mach numbers.  In this case, you would pick two operating points, one in each area.  You’ll want to find a point that sort of averages the plant variations over the entire area, that way when you tune your controller, it has the best chance of still producing adequate performance over the whole region.  Later on, if you find that there is an area where the performance isn’t as good, you can just slice that off a new region with a gain set that works for it.

The important part here is that at least you cover the critical operating points.  This might be the steady state operating points of your system as well as places where the structure or stability of the model changes. Understanding your system will help you determine where these critical points are.

For an LPV system like we have, you already have a linear model.  Then for this step you just need to select the design points and find the associated parameters.

Now that we have our linear models, step 2 is to tune the controller gains for each one. Basically, instead of a single design problem, we’ve expended it in to as many design problems as there are design operating points. For our example, we’re using a PID controller so we would tune each one in the same way we’d tune any other PID controller.  The nice part about having many different smaller control problems is that the requirements do not need to be the same for each design point.  You may choose different requirements because of feasibility concerns or just because you want the behavior to be different.

Something that is worth mentioning here is that with this method, we can only guarantee performance, and in same cases stability, at the design points.  I’ll show you in a bit that we’re either using a single set of gains over the whole area, or we’re interpolating the gains between points.  Either way, we’re only actually tuning at a handful of spots and expecting that the performance will be adequate for the whole envelop. So you may take this into account when setting the controller requirements by increasing the design margins or some other technique to make the controller more robust so that it has the best chance of working with a large area of the operating envelop.  You’ll assess performance in step four, so you should be able to catch any outliers and either change the gains to work or split it into two smaller areas.

At this point, we have a handful of design operating points and their associated gain sets and so the fun part begins. Step three is to implement an architecture that switches between those gain sets based on the scheduling variables. A dead simple approach here would be to implement a simple switch.  If the scheduling variable is less than some value, use gain set A, if it is greater or equal to that value, then use gain set B.  This is an attractive architecture because of how simple it is to think about and implement, however, it produces some unintended transients when the switch occurs.

To understand how this can happen, imagine the following situation.  Instead of a PID controller, let’s say we can get away with just a proportional controller, that way there is only one gain value.  We have two design points in our gain schedule, a gain of 3 when the mach number is above or equal to 0.5 and a gain of 2 when the Mach number is below 0.5.  Initially, the aircraft is at a zero degree pitch and we command the autopilot to pitch up to 10 degrees. The aircraft is flying at Mach 0.6 and as the aircraft starts to pitch up, it’s using a gain of 3 accordingly.  As the plane continues pitching up, the speed starts to drop. Right at Mach 0.5, we’ll say the pitch error is 5 degrees, we’re not at 10 degrees yet, and so the output of the controller is 15 since there is a gain of 3.  At the next time step, the Mach number is 0.499, the gain set switches instantly to 2.  The error hasn’t changed much in this amount of time and so it’s still about 5 degrees, therefore the output of the controller jumps down to 10.  This would cause a quick motion of the elevator and the aircraft would change its pitch quickly at that point, startling the passengers and spilling their drinks. Not a great design.

One way to get around this problem is by implementing a transient-free switch.  This type of switch doesn’t jump the output of the controller instantly because it generates a smooth transition between the two gain sets, for example, smoothly ramping from 3 down to 2 over some specified time period.  This will remove that sudden transient, but it might be a bit tricky to set up.  This is because you need to set the transition time long enough so that the transient is smoothed out, but not so long that the gain can’t transition fast enough.

Another way, and arguably a better way of removing the transients is to do away with the switch all together.  Rather than two distinct gain sets, we could develop a curve that smoothly changes from one operating point to another.  For our single scheduling variable example this could mean the gain at low Mach numbers set to 2, and the the gain is gradually increased as the speed increases.  This curve could be defined as an equation, or just a series of points in a look up table that you interpolate between. But since the gain is always changing smoothly, and as quickly as the scheduling variable changes, then there are no sudden transients.

If you have two scheduling variables then you’d come up with a gain surface that interpolates between each of the specified design operating points.  With this method you can still have as many scheduling variables as you want, it just makes the surface that describes the gains a higher order.

Something that you might not know about that is kind of cool are the tools Systune and Control System Tuner within MATLAB and Simulink. With these tools you can choose your design operating points, define the gain surface as a polynomial as an equation, and tune the gains of the polynomial automatically.  So it takes a lot of the leg work out for you.  I’ve left an example of how to do this in the description below.

Regardless of the architecture chosen, step four is critical: assess the control performance across the whole operating envelope - this is often done with models and simulations because of the huge number of test conditions you need to run. It’s much faster if it’s simulated. And since you can’t guarantee performance away from the design operating points, choosing your test conditions (what you simulate and what you don’t) is very important.  You need to make sure all of the critical transitions and every potential corner case is covered.

Despite what seems like an unnecessary amount of work for this method, gain scheduling is used often in practical situations so it’s worth learning in more detail and practicing on your own.

If you were only watching this video to learn a bit about the concept of gain scheduling, that’s awesome! But if you want to practice what I just covered or learn how to implement these in MATLAB and Simulink definitely check out all of the examples and tutorials I linked to in the description.

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.