10.1. Configuration of a custom linear MPC controller using the FORCESPRO Simulink® GUI

The Simulink® GUI for FORCESPRO is an easy and intuitive way to design model-based optimal controllers that can take decisions considering future information and system constraints. The general supported problem formulation is as follows:

Given a measurement or estimate of the current state of the system, \(x\), and possibly:

• an estimate for an additive disturbance, \(w_k\)

• the previous control command, \(u_{prev}\),

• the output reference to track, \(y_{ref,k}\)

the controller decides the future control actions \(u_0,u_1,…,u_{N−1}\), and the resulting predicted state trajectory \(x_1,x_2,…,x_N\), over the prediction horizon, \(N\), in order to optimize the control objectives

\[\sum_{k=0}^{N-1} (x_{k+1}-x_{ss,k})^T Q_k (x_{k+1}-x_{ss,k}) + (u_{k+1}-u_{ss,k})^T Q_k (u_{k+1}-u_{ss,k}) + \Delta u_k^T T_k \Delta u_k\]

where

\[ \begin{align}\begin{aligned}\begin{split}\begin{pmatrix} A_k-I & B_k \\ C & 0 \end{pmatrix}& \begin{pmatrix} x_{ss,k} \\ u_{ss,k} \end{pmatrix}= \begin{pmatrix} 0 \\ y_{ref,k} \end{pmatrix} \\\end{split}\\\begin{split}\Delta u_0 &= u_0-u_{prev}, \\\end{split}\\\Delta u_0 &= u_k-u_{k-1}, \quad k=1,...,N-1\end{aligned}\end{align} \]

subject to a linear mode of the system

\[ \begin{align}\begin{aligned}\begin{split}x_1 = A_0x + B_0 u_0 + w_0 & \\\end{split}\\x_{k+1} = A_k x_k + B_k u_k + w_k, & \quad \text{for all } k=1,…,N−1\\y_k = Cx_k, & \quad \text{for all } k=1,…,N\end{aligned}\end{align} \]

and satisfying the system constraints

\[ \begin{align}\begin{aligned}\begin{split}y_k \in \mathbb{Y}_k, \quad &\text{for all } k=1,2,…,N \\\end{split}\\\begin{split}u_k \in \mathbb{U}_k, \quad &\text{for all } k=0,1,…,N−1 \\\end{split}\\\Delta u_k \in \mathbb{V}_k, \quad &\text{for all } k=0,1,…,N−1\end{aligned}\end{align} \]

The settings for your particular controller can be specified by editing the mask of the FORCESPRO Simulink block. To start a new controller design copy the block in LTI_MPC_lib.mdl to your Simulink diagram and give a name to your controller. Double click on the new block and configure the different parameters as described here:

10.1.1. Model

Describe your linear state-space model of the system.

• Time : Choose whether your state-space model is described using differential equations or using a discrete update equation.

• Type : Choose whether your model has an extra affine term, i.e. is w present?

• Sampling time : If you are loading a continuous-time model specify the sampling time in seconds.

• System matrices : Specify the workspace variables describing the different system matrices A,B,C, and , if present, vector w.

• Parameters : Some variables are allowed to be parameters at design time, i.e. they can change dynamically during runtime. To allow this feature mark the appropriate check boxes to determine whether the parameter changes over the prediction horizon.

• System dimensions : If one or more system matrices are parameters you might need to specify any unresolved system dimensions.

10.1.2. Control Objectives

The control objectives are typically a trade-off between how well the controller tracks the output reference and how much input action it uses.

• Tracking options: Check if the controller is tracking an output reference or leave unchecked if the controller is regulating to the origin. If the controller is tracking a reference, specify whether the output reference \(y_{ref}\) will be provided, or whether the steady-state offset-free state and input references, \(x_{ss}\) and \(u_{ss}\), have already been calculated. Also specify if the reference is changing over time and whether the changes are known ahead of time or not (\(y_{ref,k}=y_{ref}\)). If reference changes are known ahead of time, the controller can use this preview information to improve the control performance.

• Input slew rate penalty : Check if the controller should also attempt to minimize the actuator changes between control samples. If the checkbox is left unmarked, the weight matrix \(T\) is set to zero.

• Terminal cost : If the checkbox is marked the state penalty matrix for the last stage becomes \(Q_N:=P\), where \(P\) is the solution of the discrete-time Ricatti equation. Note that the matrix \(P\) can only be computed when matrices \(A\), \(B\), \(C\), and \(R\) are known at design time, i.e. they are not runtime parameters. In general, having a terminal cost allows for a reduced prediction horizon but imposes certain restrictions on the optimization methods that can be used.

• Control horizon : Specify the number of samples that the controller looks into the future. In general, a longer control horizon can improve control performance but leads to longer computation times.

• Weighting matrices : Check if the weighting matrices on the outputs, \(Q\), on the inputs, \(R\), and on the input rates, \(T\), are available and specify the corresponding workspace variables. If no weighting matrices are available specify the relative importance for tracking/regulation of the different outputs, inputs and slew rates. A high weight on an output tells the controller to focus on improving the tracking performance on that output. A high weight on an input tells the controller to use less of that input.

• Parameters : The penalty matrices can also be parameters at design time and change dynamically at runtime. To allow this feature mark the appropriate check boxes to determine whether the parameter changes over the prediction horizon.

10.1.3. System Constraints

Describe system limits that cannot be exceeded due to physical, safety, economic or regulatory reasons.

• Constraint list : Check which output, input, and slew rate constraints are present. For each constraint specify the upper and lower bounds. Note that an empty bound implies a one-sided constraint, e.g. \(0 \leq u_1\).

• Soft constraints : Output constraints can be specified to be soft to prevent infeasible problems. In this case a slack variable, \(\delta\), is introduced resulting in the constraint.

\[ \begin{align}\begin{aligned}-23 \delta \leq &y_2 \leq 23+\delta ,\\\delta &\geq 0.\end{aligned}\end{align} \]

• Parameters : Upper and lower bounds can also be defined as runtime parameters. To allow this feature mark the appropriate check boxes to determine whether the parameter changes over the prediction horizon.

10.1.4. Estimator Settings

Describe additional characteristics for your customized solver.

• Data type : Choose the data type used by the solver. For some embedded platforms, floating-point computations (specially double precision) will incur significant computational delays. In the standard and premium versions of FORCESPRO fixed-point data types can lead to reduced computation times depending on the platform, but this imposes certain restrictions on the optimization methods that can be used.

• Optimization method : The basic version of FORCESPRO always uses a Primal-Dual Interior-Point (PDIP) method to implement the optimal controller. In the standard and premium versions of FORCESPRO one can select other alternative methods, such as ADMM and DFGM, that can lead to reduced computation times. One can also let FORCESPRO choose the most appropriate optimization method for your problem.

• Number of iterations : Specify the maximum number of iterations used in the optimization algorithm. One can also let FORCESPRO determine the number of iterations for your problem.

• Method-specific options : For some methods the user can choose values for certain parameters to tune the performance of the method.

• Platform : In the standard and premium versions of FORCESPRO one can choose the platform that the solver will run on to obtain customized code for the particular platform. For desktop based platforms, choose ‘x86_64’ for 64-bit platforms and ‘x86’ for 32-bit platforms. For embedded platforms, choose between ‘x86’, ‘ARM Cortex M3 and M4’, ‘ARM Cortex A9’, ‘Tricore’, ‘PowerPC’, or get a customized circuit design described in VHDL. Note that additional add-ons for FORCESPRO are required to generate code for different target platforms.

• Description : Add an optional description for your controller that can be used later to identify the settings for a particular controller instance in your web workspace.

• Solve information : Mark this check box to obtain runtime information from the solver that can be used to diagnose problems.

Once all the necessary solver options have been specified a custom solver for your controller can be built by executing the command configure_block. The command returns an error if any essential information is missing or if the license type is not valid. Note that this command transforms the block to make it ready for simulation. Once a controller has been generated you can change the configuration by double clicking the block and running configure_block again.

Several instance of the FORCESPRO block can exist in the same Simulink® diagram.