You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Assume piecewise linear measured disturbances for RungeKutta(4) in MPC/MHE ? #469
The simple evaloutput and updatestate! API is not able to handle anything else than ZOH inputs (since the inputs of the next time step cannot be fed to updatestate! right now). But the internal MPC and MHE predictions are able to. The RungeKutta(4) solver is the only case in which the measured disturbances are not discretized using first-order hold (FOH). It is well known that FOH is more adequate for sampled continuous signal in MPC, which is usually the case for measured disturbances. Right now, in the package:
Continuous linear model are discretized using Tustin method for the measured disturbances (similar to FOH)
TrapezoidalCollocation discretizes the measured disturbances with FOH
OrthogonalCollocation discretizes the measured disturbances with FOH
but:
MPC/MHE with SingleShooting or MultipleShooting and RungeKutta(4) solver discretizes the measured disturbances with ZOH.
In comparison to other MPC packages, 99.9% of times they just assume ZOH for all the inputs with classical explicit RK4. But it is still an inconsistency in MPC.jl in comparison to other discretization methods, and FOH can theoretically improve the rejection of measured disturbances for MPC. If I change this in the package it comes with two caveats:
It will still be ZOH discretization for the plant model simulation (see first sentence), so a small plant-model mismatch during simulations
It won't be applicable to UKF and EKF, because of the simple evaloutput and updatestate! API
About point 1: we can clearly see the effect of the plant-model mismatch around t=10 h in the plot here (the MHE+MPC internally use FOH but the plant model is simulated with ZOH for the measured disturbance).
One possible solution to solve the majority of these issues is to add two new optional arguments to updatestate! methods:
updatestate!(model::SimModel, u, d=[]; unext=u, dnext=d) -> xnext
updatestate!(estim::StateEstimator, u, ym, d=[]; unext=u, dnext=d) -> x̂next
updatestate!(mpc::PredictiveController, u, ym, d=[]; unext=u, dnext=d) -> x̂next
Making them keyword arguments would be coherent with R̂y keyword argument of moveinput! function, that is, it's information about the future. It would solve these issues:
No longer an unintentional plant-model mismatch when simulating the plant (if the user carefully set unext and dnext arguments)
All the nonlinear state estimators could support FOH inputs easily (tho unext and dnext are typically not available on real physical plant)
Adding the support for FOH inputs in MHE/MPC predictions based on RungeKutta(4) would be straightforward since the functionality would be already implemented.
Activity
franckgaga commentedon Oct 22, 2026
One possible solution to solve the majority of these issues is to add two new optional arguments to
updatestate!methods:Making them keyword arguments would be coherent with
R̂ykeyword argument ofmoveinput!function, that is, it's information about the future. It would solve these issues:unextanddnextarguments)unextanddnextare typically not available on real physical plant)RungeKutta(4)would be straightforward since the functionality would be already implemented.