added: MovingHorizonEstimator support for direct=true, initialized with P̂(-1|-1)

[franckgaga]

Following discussion at #95, I'm implementing the simple solution of initializing the MHE in the current/filter formulation with $P̂_{-1}(-1)$ instead of $P̂_{-1}(0)$

[franckgaga]

@baggepinnen Ok the current/filter formulation of the MHE is finished (that was hard!). As mentioned above, I assumed that the initial estimate is x̂(-1|-1) and covariance P̂(-1|-1) to simplify the implementation.

I added some additional tests with direct=true, including comparisons with the current formulation of the KalmanFilter and UnscentedKalmanFilter. The results are practically identical when there is no constraint on the MHE. It's a good indication that my simplification above does not impact much the results. For sure, there is mathematically no impact on the results when the windows are filled (if $N_k = H_e$).

There are MANY modifications in the code, clearly almost impossible for you to review the whole PR. I would ask to take a look at the MHE documentation (incl. the Extended Help) here:

https://juliacontrol.github.io/ModelPredictiveControl.jl/previews/PR96/public/state_estim/#MovingHorizonEstimator

and the MHE prediction matrices (for linear models) here:

https://juliacontrol.github.io/ModelPredictiveControl.jl/previews/PR96/internals/state_estim/#ModelPredictiveControl.init_predmat_mhe

Does it seems clear enough to you ?

Thanks!

[baggepinnen]

Very cool, nice job!

The results are practically identical when there is no constraint on the MHE. It's a good indication that my simplification above does not impact much the results.

That sounds like a good indication!

I would ask to take a look at the MHE documentation (incl. the Extended Help) here:

It looks like some of the matrices aren't defined, like E. Related, a nice feature of using JuMP is that you don't have to go through the tedious and error prone assembly of matrices like these, and instead formulate the problems in a way that feel natural to you, using loops or otherwise, and have JuMP assemble these matrices for you. I've found this to be much less error prone, especially getting the indices around boundaries correct.

The current documentation includes a very detailed description exactly of how the method works. This is nice for developers, and very advanced users. I would guess that an ordinary user is primarily interested in learning how to use the estimator. Right now, there is less guidance on how to pick the weights, or even what keyword arguments are available, they have to look at both of these links as well?

A description like this

while precise and correct, may be hard for a user to parse. Does it mean "covariance of the estimate of the current state"? For example,a user might want to know how to make the estimator "faster" or "slower", i.e., more or less filtering? I (as in Fredrik) can figure that out, but a random user might appreciate and indication of what all these matrices mean for the practical performance of their estimator.

[franckgaga]

Thanks for your comments @baggepinnen! I applied most of them in the new documentation. The state estimator page is now way longer when nothing is collapsed, but that's the price to pay to be more explicit. There is also some explanations on Kalman filter and MHE tuning in the manual (both in the Linear and Nonlinear design sections)

[franckgaga]

Also, about JuMP: Yes I did know that, but I was a bit skeptical that it would work well for problem as complex as MPC and MHE. My other concern was the model generation time: since a good part of this job is done by me instead of the computer, we can expect that it's faster to generate the optimization model this way (allowing stuff like successive linearization MPC/MHE)