Terminal Weights and Constraints

Terminal weights are the quadratic weights Wy on y(t+p) and Wu on u(t + p – 1). The variable p is the prediction horizon. You apply the quadratic weights at time k +p only, such as the prediction horizon's final step. Using terminal weights, you can achieve infinite horizon control that guarantees closed-loop stability. However, before using terminal weights, you must distinguish between problems with and without constraints.

Terminal constraints are the constraints on y(t + p) and u(t + p – 1), where p is the prediction horizon. You can use terminal constraints as an alternative way to achieve closed-loop stability by defining a terminal region.

    Note:   You can use terminal weights and constraints only at the command-line. See setterminal.

For the relatively simple unconstrained case, a terminal weight can make the finite-horizon Model Predictive Controller behave as if its prediction horizon were infinite. For example, the MPC controller behavior is identical to a linear-quadratic regulator (LQR). The standard LQR derives from the cost function:

J(u)=i=1x(k+i)TQx(k+i)+u(k+i1)TRu(k+i1)(2-6)

where x is the vector of plant states in the standard state-space form:

x(k + 1) = Ax + Bu(k)(2-7)

The LQR provides nominal stability provided matrices Q and R meet certain conditions. You can convert the LQR to a finite-horizon form as follows:

J(u)=i=1p1[x(k+i)TQx(k+i)+u(k+i1)TRu(k+i1)]+x(k+p)TQpx(k+p)(2-8)

where Qp , the terminal penalty matrix, is the solution of the Riccati equation:

Qp=ATQpAATQpB(BTQpB+R)1BTQpA+Q(2-9)

You can obtain this solution using the lqr command in Control System Toolbox™ software.

In general, Qp is a full (symmetric) matrix. You cannot use the Standard Cost Function to implement the LQR cost function. The only exception is for the first p – 1 steps if Q and R are diagonal matrices. Also, you cannot use the alternative cost function because it employs identical weights at each step in the horizon. Thus, by definition, the terminal weight differs from those in steps 1 to p – 1. Instead, use the following steps:

  1. Augment the model (Equation 2-7) to include the weighted terminal states as auxiliary outputs:

    yaug(k) = Qcx(k)

    where Qc is the Cholesky factorization of Qp such that Qp = QcTQc.

  2. Define the auxiliary outputs yaug as unmeasured, and specify zero weight to them.

  3. Specify unity weight on yaug at the last step in the prediction horizon using setterminal.

To make the Model Predictive Controller entirely equivalent to the LQR, use a control horizon equal to the prediction horizon. In an unconstrained application, you can use a short horizon and still achieve nominal stability. Thus, the horizon is no longer a parameter to be tuned.

When the application includes constraints, the horizon selection becomes important. The constraints, which are usually softened, represent factors not considered in the LQR cost function. If a constraint becomes active, the control action deviates from the LQR (state feedback) behavior. If this behavior is not handled correctly in the controller design, the controller may destabilize the plant.

For an in-depth discussion of design issues for constrained systems see [2]. Depending on the situation, you might need to include terminal constraints to force the plant states into a defined region at the end of the horizon, after which the LQR can drive the plant signals to their targets. Use setterminal to add such constraints to the controller definition.

The standard (finite-horizon) Model Predictive Controller provides comparable performance, if the prediction horizon is long. You must tune the other controller parameters (weights, constraint softening, and control horizon) to achieve this performance.

    Tip   Robustness to inaccurate model predictions is usually a more important factor than nominal performance in applications.

Was this topic helpful?