Support direct transmission from manipulated inputs ?

[franckgaga]

You are of course correct in what you say, but I still wouldn't be so quick in dismissing the direct feedthrough use case. You are not considering the following

Not all systems that are controlled by mpc are purely physical systems. A very common case that isn't is when an mpc controller is used in a slower outer loop, and a much faster inner controller is tracking references provided by mpc. In this case, you cannot form any reasonable model of the inner closed loop without direct feedthrough. The inner loop in this case will interpolate between the samples in the reference trajectory in a non causal way, and the inner loop is in this case best discretized using a Tustin or FOH discretization which introduces nonzero D matrices.

You can of course add a one sample delay, but if you're using a cascade controller because it's too slow to run mpc at the faster rate, an additional sample delay at the slow rate is a very poor solution to an artificial problem introduced by the MPC tool.

Originally posted by @baggepinnen in https://github.com/JuliaControl/ModelPredictiveControl.jl/issues/106#issuecomment-2380865481

[franckgaga]

@baggepinnen

This is indeed a very common case. A cascade structure is almost always used, at least for process control.

Now, If I want to incorporate this feature (still not sure TBH), comes the question of how. It's not obvious to me at all in the MPC framework. I think JuliaSimControl support non-strickly proper plant model ? How did you implement that ? Something like this (Maciejowski, p37) ?

edit: it seems that we cannot do the approach above on nonlinear equations. Do you know an approach that would be universal (both linear and nonlinear systems) ?

[baggepinnen]

In JSC, the user can either write a stage cost where the cost at time step k is any function c(x(k), u(k)), or the user can write cost functions and constraints that depend acausally on the entire optimization trajectory, with such an approach, your are not limited even to direct feedthrough, your "output" at one time step can depend arbitrarily on what you think will happen in the future. The controller is of still causal in the relationship between the control output and what actually does happen in reality, it's unfortunately not magic :) For the linear MPC functionality, I do have the same distinction between measured outputs $y$ and performance outputs $z$ as the text above, but I do not perform the transformation in eq. 2.5,

[franckgaga]

I continued my reflection on this recently, and it really does not make sense to me. As I said earlier, the typical implementation of a discrete-time MPC controller (disregard of state estimation) is to:

1. sample a measurement $\mathbf{y^m}(k)$ from the plant
2. computes an action $\mathbf{u}(k)$ and
3. apply the action on the plant.

There is a causality paradox in the implementation if $\mathbf{u}(k)$ impacts $\mathbf{y^m}(k)$ even before computing it. I acknowledge that a non-strictly proper plant model can be "more realistic" in some cases like cascade control, but I'm not convinced that the control loop as implemented above would be able to leverage the direct transmission. It would need a drastically different implementation.

Note that the acausality mentioned above is different from the mathematical defintion of causality. For exemple, the closed-loop response of the controller $C(z)=0.5$ with the plant $G(z)=2$ (a plant with a direct transmission) is well-defined and mathematically causal. We can analytically compute "in advance" with $CG/(1+CG)=0.5$. But, because of what MATLAB calls the algebraic loop, implementing it like the control loop above would not work, except if we "break" the algebraic loop by substituting the $\mathbf{u}$ dependency with a $\mathbf{r}$ dependency:

1. $y(k) = 2u(k)=(2)(0.5)(r(k)-y(k)) = r(k) - y(k) \implies 2 y(k) = r(k) \implies y(k) = 0.5r(k)$
2. $u(k) = 0.5(r(k)-y(k))$
3. apply the action on the plant (nothing to do here)

This explicit substitution trick is applicable only when we know the static gain of the controller, which is never the case for constrained MPC or NMPC.

Another even worse problem with a direct transmission is with the state estimators in the direct form. They would also needs $\mathbf{u}(k)$ before it is computed by the MPC. It can also be substituted with the setpoint when the static gain of the controller is known, which is generally not the case for MPC.

I will close the issue but feel free to continue the discussion.