What Is Feedforward Control? | Control Systems in Practice

When you design a control system you have two main goals: get the system to track a setpoint or command that you’ve given it and reject any disturbances into the system. Really though, it’s the same goal, you are trying to get the system to do what you want while the environment is throwing you off course. In addition to disturbances, there’s noise in your system that makes it difficult to figure out whether the system is actually off course or not.  We spend a lot of time touting the benefits of a feedback control system to handle these very things. They can track a setpoint, reject disturbances, and, if the noise is high enough frequency then the feedback controller can filter it out or ignore it completely. Feedback control is pretty powerful. In practice, however, a feedback-only controller is not necessarily the best architecture. In this video, I want to explain some of the benefits of pairing your feedback controller with one or more feedforward controllers. I’m Brian, and welcome to a MATLAB Tech Talk.

To begin, let’s look at how set point changes, disturbances, and noise are handled in a feedback controller. Remember our controller works off error, that’s the difference between the set point and the measured state of the system.  So anything that produces error, our controller will see. 

When the set point changes, the state of the system hasn’t had a chance to respond and so that directly affects the error term. When disturbances act on a system, they affect the output of the system, which is measured by the sensor as a change in state, and that causes error. And finally, noise in the sensor, effects the measured state of the system, which again is fed back and causes error.

The set point change and disturbance is error is what we want the controller to actually respond to and correct, the noise, however, is error that we want the controller to ignore because it’s not real state error. But, here’s the problem, since all of the error is combined before the controller, it can’t tell the difference between them. So what can we do?

Well, let’s take a look at these sources of error in the frequency domain. Perhaps the set point changes you’re commanding are relatively slow, and therefore low frequency. Maybe the disturbances are a little faster, but still much slower than the high frequency noise in the system. 

In this case, a common way to remove the noise is to set your controller bandwidth (or range of frequencies it’ll respond to) low enough that it doesn’t react to noise but fast enough that it will respond to disturbances and set point changes. 

Let’s try to understand this in a more intuitive way by trying to follow this red dot with your eyes. Keep your eyes on it.  When you track a moving object with your eyes, you are the controller and your eyes are the sensors and your eye muscles are the actuators.  This is a feedback control system and it has a certain bandwidth, that is, there is a frequency of motion that your eye muscles can keep up with and some motion that is so fast that you can’t possibly follow it.

Therefore, if the changes to the setpoint and the disturbances into your system are both rather slow and the noise in your system is rather fast, then your controller (or your eyes) will follow the set point and correct for the disturbances, but not be able to follow the noise.

This is great, but what happens if the noise in your system overlaps the set point change frequency or the disturbance frequency and you are unable to filter out that noise in some other way?  Then your feedback controller will react to the noise unless you lower the bandwidth even more, slowing the controller down.  In this way, it won’t react to the noise, but you’ve also reduced it’s ability to quickly follow the set point or respond to disturbances.  Not great. This is one scenario in which a feedforward component can help. 

Feedforward can be used to remove a lot of the setpoint and disturbance error before it ever gets to the controller.  With these errors removed, then all that is left is the noise error and at this point you can set the bandwidth as needed to ignore the noise. This is of course an ideal situation that’s tough to get exactly perfect in real life. But to understand what feedforward is doing and how it can help our feedback controller, let’s start by focusing on how feedforward can remove the bulk of the error created by a changing setpoint. 

The set point can change, for sure, but usually it’s not a surprise when it happens because you or some process you wrote requested that change.  And if you know that a change is about to occur, why let it create error in the system first and then have the feedback controller respond and generate the necessary control output second?  Why not predict ahead of time what controller output is required based on your knowledge of the set point change?  What other information would be needed to accomplish this?  

Let’s see, if we play a signal, U(s), through the plant, G(s), then it will generate the output Y(s).  And if this output is the state we’re trying to control, that is, we are measuring the state of the system directly, then Y(s) should be equal to our set point, R(s).  That’s the goal, if they are one and the same, then the system is behaving the way we want. Well, Y(s) is equal to U times G. So what input, U will generate the set point that we want? Well, it’s simply R, times G inverse.  Where R is the setpoint, and G inverse, or the inverse dynamics of our system, is our feedforward controller. If have a perfect model of our system, and that model is invertable, then we can adjust the output of the controller with our perfect feedforward term. And since that will create an output that perfectly follows the setpoint, then there will be no contribution to the error term from the set point change.  Effectively, removing that error from the problem.

But there are two issues with this statement.  First, with Model-Based Design you already have a good model of your system and so you have something that you can invert.  That’s good. However, as you can imagine, no model is perfect, and therefore G inverse isn’t perfect.  Which means the output of our system isn’t the set point R but something close to it. So while the bulk behavior of the system may be accounted for with this method, there will always be some residual error due to the process dynamics that aren’t perfectly understood.  

Second, not all process dynamics are invertable. In fact, most of them aren’t.  

It’s easy to imagine this for the case where the system has delay. That means that when you command an input it takes a certain amount of time for the system to even begin to respond. So when you apply U, Y does begin to move until some delay time later. Now let’s look at the inverse of this by thinking about how you would go about building a feedforward controller for this system. At time equals 10 seconds the set point begins to change and you want the system to follow along.  Basically, you want the output Y to lie directly on top of the green set point line. In this case, you would have had to start the command, U, earlier than the set point change so that when the delay occurs the output would start to change right when you changed the set point. Unless you absolutely knew exactly how the set point was going to change in the future, then this prediction is not possible.

So rather than invert the dynamics exactly, we usually try to fit a causal and realizable model to the inverse dynamics as best as we can.  So, with both of these modeling limitations, it’s impossible to completely remove the set point change error, but usually we can reduce it a lot.  In this way, the feedforward controller takes care of the bulk behavior, and the feedback controller corrects for the modeling errors. The goal is that these modeling errors can be corrected by a low bandwidth feedback controller, one that will still ignore the higher frequency noise.

So we’ve taken care of the set point changes, now let’s focus on the disturbance error.  And, for the moment, let’s assume that we know the disturbances to the system perfectly because we’re able to measure them.  If this is the case, then we can treat them in the same way we did the set point changes and design a disturbance feedforward controller.  But what is the perfect feedforward controller transfer function, is it the inverse dynamics again?

Well, our plant now has two different inputs, the controlled inputs, U, from the controller, and the disturbance inputs that are acting on various parts of the system.  Both inputs, however, affect the output Y(s).  Therefore, there are two different transfer functions, the disturbance path, Gd, and the process path, Gp, and the output, Y(s) is the summation of the two. 

(write equation)

Here’s the thing, when there is a disturbance on the system, it will affect the output and so if we can adjust the process input U(s) at the same time so that the Gp path perfect cancels out Gd path, then there will be no change to the output of the system, and therefore, no error will result. To solve for this, we set Y(s) to 0, which means we don’t want any change to the output, and then solve for the necessary U(s), we get D(s) times the ratio of Gd and Gp.  So, our perfect disturbance feedforward controller is the disturbance transfer function divided by the process transfer function.

But as you can imagine, this feedforward controller has the same problems as the other one. One, we won’t know the process and disturbance transfer functions perfectly, and two, we still need to invert the process dynamics for this to work.  But, in addition to these two problems, we now have also need to find a way to measure the disturbance. 

Some disturbances lend themselves well to a feedforward controller. For example, imagine a system that is trying to maintain the temperature of an object.  If it’s too cold the feedback controller adds heat, and if it’s too hot it removes heat. The heat loss of the object is dependent on the ambient air temperature.  The colder the ambient air, the faster heat leaves the object and therefore it takes more energy for the controller’s heating element. If this system had an ambient air temperature sensor, then you could predict how much heat is being lost to the environment and feed that control forward into to the heater to automatically bias the base heating amount accordingly. This would work nicely, especially if the ambient temperature changes quickly, like someone opened a door to the outside and let a bunch of cold air in.

But some disturbances are a bit trickier like trying to measure and predict the effect of wind gusts on a car.  These would be hard to measure and in this case, it might not make sense to try to build a feedforward controller.

So next time you’re struggling will trying to get your feedback controller to respond quickly set point changes or disturbances, it’s worth investigating whether adding one or more feedforward controllers will help your situation.  

If you were only watching this video to get a general idea of feedforward and why it’s used, that’s awesome! But I think this will all make a lot more sense if you implement your own feedforward controller and practice adjusting it to see how it impacts the system. In Simulink you can do just this and in this graphical environment, it allows you to think about the control architecture in block diagram form, just like how I drew it out in this video. Specifically, there is a good tutorial that I linked to in the description that covers designing a system to control temperature in a heat exchanger.  

If you follow along with this tutorial it goes through developing a model for the heat exchanger process dynamics and for the disturbance dynamics.  You can then design a feedback only controller and see how the disturbances impact the system and your ability to control it. Then you develop a feedforward controller based on the measured disturbances and add it to the feedback architecture. 

It’s a great way to see how the feedback and feedforward controllers work together to reject disturbances better than the feedback controller alone.  Plus, there’s an interactive GUI that allows you to quickly select the control type and slide the gains around so you can see realtime how the system is changing. So I think it’s worthwhile checking out.

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.