Turn on/off Control Variables and Manipulated Variables

[caxelrud]

[franckgaga]

First time I'm hearing about this functionality, seems indeed very useful in practice!

I'm not sure at all how I could integrate this in the package since the dimensions of the manipulated input vector $\mathbf{u}$ and measured disturbance vector $\mathbf{d}$ cannot change after construction (since I use immuatable struct, for the performance).

Some MPC toolbox e.g. MATLAB treats $\mathbf{u}$ and $\mathbf{d}$ very similarly in the code. That's not the case for this package. I purposefully separated manipulated inputs from measured distubances in two distinct vectors since they are fundamentally different in typical control problems. Indeed, $\mathbf{d}$ are generally continuous measurements sampled through some kind of analog-to-digital converter (ADC), whereas $\mathbf{u}$ are discrete signals followed by some kind of DAC and a zero-order hold. It means that plant model will have a direct feedthrough with $\mathbf{d}$ but not $\mathbf{u}$. The closed-loop performance is slightly improved if we do not neglect this direct feedthrough.

I will need to think on a way to integrate that feature in the package.

[baggepinnen]

It might be possible to just add constraints on u saying that it must be constant, and equal to the value of the manually set u?

[franckgaga]

Yes that would be a way I think. With the assumption that that this constraint will still be there in the future, over the prediction horizon.

And maybe two new arguments to moveinput!:

• i_uf=Int[] for the indexes in $\mathbf{u}$ that are forced/fixed at $\mathbf{u^f}$
• uf=Float64[] for $\mathbf{u^f}$ value

a bit like $\mathbf{y^m}$ and $\mathbf{y^u}$ behavior but at runtime (I could call also it $\mathbf{u^m}$ but I think "measured" would be a bit of a misnomer here, no ?).

What's the intended behavior when a Control Variable is turned off ? The associated setpoint tracking weight become zero ? I will allow online modification of the weights soon.

[franckgaga]

BTW, with @baggepinnen idea, we could even say that it's already supported (but it's not trivial how):

setconstraint! can be called at runtime for online modifications of the inequality constraints. For example, if the second manipulated input is disabled and it's value is externally set to 10 at specific time step, we can call setconstraint!(mpc, umin=[-Inf, 10], umax=[Inf, 10]) before solving the mpc problem with moveinput!. Note that Inf bounds cannot be modified at runtime. Large enough bounds can be set after mpc construction to modify them at runtime e.g.: setconstraint!(mpc, umin=[-Inf, -1e6], umax=[Inf, 1e6])

It's an equality constraint, strictly speaking. But most quadratic programming solvers (e.g. OSQP, DAQP, etc.) does not directly support them. From my understanding, JuMP.jl would automatically transform them into inequality constraints using the approach above and its bridge system.