MPC Design Parameters | Understanding Model Predictive Control, Part 3
From the series: Understanding Model Predictive Control
Melda Ulusoy, MathWorks
To successfully control a system using an MPC controller, you need to carefully select its design parameters. This video provides recommendations for choosing the controller sample time, prediction and control horizons, and constraints and weights.
Published: 3 Jul 2018
In this video, we’ll talk about MPC design parameters. Choosing proper values for these parameters is important as they affect not only the controller performance but also the computational complexity of the MPC algorithm that solves an online optimization problem at each time step. Here, we’ll give you some recommendations on how to choose the controller sample time, prediction and control horizons, constraints, and weights. By choosing the sample time, we determine the rate at which the controller executes the control algorithm. If it’s too big, when a disturbance comes in, the controller won’t be able to react to the disturbance fast enough. On the contrary, if the sample time is too small, the controller can react much faster to disturbances and setpoint changes, but this causes an excessive computational load. To find the right balance between performance and computational effort, the recommendation is to fit 10 to 20 samples within the rise time of the open-loop system response.
As we’ve discussed previously, at each time step, the MPC controller makes predictions about the future plant output, and the optimizer finds the optimal sequence of control inputs that drives the predicted plant output as close to the setpoint as possible. The number of predicted future time steps is called the prediction horizon and shows how far the controller predicts into the future. What happens if it’s too short? Think of the following example. While going at 50 mph, you know that it will take your car 5 seconds to stop if you press on the brake pedal. If your prediction horizon is 2 seconds, by the time you see the traffic lights, it will be too late to apply the brakes. The car will only be able to stop after passing the traffic lights. So, we should choose a prediction horizon that will cover the significant dynamics of the system. Why don’t we select a much longer prediction horizon, then? Say you’ve predicted your speed far into the future in order to try to get to your destination on time. Unexpected things can happen, such as boxes falling from the back of a truck, pedestrians crossing the road, or a change in the road profile; these all may affect your speed and you may need to throw away a significant part of your planning, wasting your computations. Assuming the sample time is chosen based on what we’ve discussed before, the recommendation for choosing the prediction horizon is to have 20 to 30 samples covering the open-loop transient system response.
Another design parameter is the control horizon. If this is the set of future control actions leading to this predicted plant output, the number of control moves to time step m are called the control horizon. The rest of the inputs are held constant. Each control move in the control horizon can be thought of as a free variable that needs to be computed by the optimizer. So, the smaller the control horizon, the fewer the computations. Why don’t we always choose a control horizon of 1 then? We can, but it might not give us the best possible maneuver. And by increasing the control horizon, we can get better predictions but at the cost of increasing the complexity. We can even choose to make the control horizon the same as the prediction horizon. However, note that usually only the first couple of control moves have a significant effect on the predicted output behavior, while the remaining moves have only a minor effect. Therefore, choosing a really large control horizon only increases computational complexity. A good rule of thumb for choosing the control horizon is setting it to 10 to 20% of the prediction horizon and having minimum 2-3 steps.
MPC can incorporate constraints on the inputs, the rate of change of inputs, and the outputs. These can be either soft or hard constraints. Hard constraints cannot be violated, whereas soft constraints can be violated. Let’s say that an MPC controller controls the speed of this car by adjusting the gas pedal. Since there’s a physical limit on how much the gas pedal can be moved, we want to have a hard constraint so that the gas pedal position stays within this range. We may also want to enforce the speed to stay between certain values. However, having hard constraints on both inputs and outputs is not a good idea because these constraints may conflict with each other, leading to an unfeasible solution for the optimization problem. Here’s a scenario to demonstrate such a situation. Assume that the car is going 50 mph on the highway, where the speed limits are as shown. When the car starts climbing a hill, its speed will decrease. The controller will apply more throttle to increase the speed. But due to the heavy load on top of the car, the speed will keep decreasing even though the controller applies full throttle. So, if the speed constraint is hard, the optimizer won’t be able to find a feasible solution that meets both input and output constraints. However, if the speed constraint is soft, the controller will allow violating it until the car overcomes the hill and the conflict won’t occur. Note that to keep the violation of the soft constraint small, it is being minimized by the optimization problem. The recommendation is to set output constraints as soft and avoid having hard constraints both on the inputs and the rate of change of the inputs.
We have multiple goals in life. Some of them might be sleeping, eating, hanging out with friends, and earning money. How would do you manage your time to complete all these goals? You can assign weights. If, for example, sleeping is more important to you than eating, then you would weigh sleeping higher against eating. Similarly, MPC has multiple goals. We want the outputs to track as close as possible to their setpoints, but at the same time we want to have smooth control moves to avoid aggressive control maneuvers. The way to achieve a balanced performance between these competing goals is to weigh the input rates and outputs relative to each other. We not only weigh these two groups relative to each other but we also adjust relative weights within the groups as well. For example, if, in this 2x2 system, it is more critical to perform reference tracking of the first output than the second output, we assign a larger weight to the first output and the ratio between the outputs is greater than 1.
In this video, we’ve explained the parameters that need to be selected for designing MPC controllers. For more information, you can check out Professor Bemporad’s video on how to design model predictive controllers and the links given in the video descriptions. In the next video, we’ll discuss what methods you can use when you’re dealing with nonlinearity either in the plant or the constraints, and the cost function.