First, I would like to thank you for such an amazing solver.
I am trying to formulate and solve an MPC problem (different from the one posted on the solver examples page) where there are output and control rate cost together with slew rate constraint. I think it is a very common linear MPC problem where you can find in many traditional textbooks such as Prof. Maciejowski’s book. For your reference, you can find a sample formulation of this problem under Lund MPC tools, pp 9-12.
I put my problem into the format required by the OSQP solver but I could never get a viable/stable result from that even for a simple 2nd order system. It seems the solver does not fail but maybe the problem formulation is not correct or cannot be captured by OSQP. I do not expect any stability issues with a simple linear system and also with the existence of terminal cost/constraint. I would appreciate it if you take a look into the sample implementation (mpcQuestion) and let me know what I am missing.
Also, that would if you could provide more insight into the matrix updates Px, Px_idx, Ax, and Ax_idx in addition to what explained on the solver page. From my understanding if P is not sparse these updates make no sense, right?
I haven’t tried your code yet but have you tried to formulate it with YALMIP first? Stacking MPC matrices can be buggy and using a parser like YALMIP is a good way to prototype it and reduce the bugs before constructing directly the QP matrices. In the MPC example docs we have the MPC problem also in YALMIP format.
Regarding the matrix updates, I believe that for linear MPC problems your matrices A and P should not change. So, you should only need to update the vectors q, l and u.
I did not look into your code in detail, but it seems that you are using a dense MPC formulation, i.e. eliminating state variables so that many of your problem’s matrices are dense in the lower triangle. This is generally worse than keeping the states as decision variables, which will result in your problem’s matrices being mostly banded and sparse (the exception would be if you had a really large state dimension or a very short horizon).
I would also suggest using Yalmip as in the example on the OSQP website and just modifying the example there to include different constraints as a starting point.
Note that it is not clear what you mean by ‘instability’, but I assume that you mean that your closed-loop system is unstable (and not, for example, that the solver is not-converging to a solution at any time-step). Possible reasons (non-exhaustive) are:
Your terminal cost and / or constraint is not constructed correctly to ensure stability;
Your A matrix is unstable, which will cause problems in the dense MPC form since you take powers up to A^(N-1) for horizon N
Thank you Bartolomeo & Paul for your quick response and nice ideas. No I did not try YALMIP and I am not sure how I can extract the QP matrices (P,A,q,l,u) from that for my intended problem. I would like to only use OSQP to solve my problem as the core engine, thus I need to define and provide the design matrices externally. So that’s why I am implementation these matrices in a general format to be able to use them for any problem of interest.
Yes, that’s true. For linear MPC I do not need to update A and P but I think for an adaptive/gain scheduled MPC which I am considering I need to update A and P (depending on the formulation) as well.
The problem that I am dealing includes control rates (u(k)-u(k-1)) in the cost function and constraints. As far as I know, the common approach for solving and formulating this type of MPC problem is to utilize the linear system description and an augmented plant model (where u(k-1) is the augmented state) and reduce the decision variables to only u(k)-u(k-1), ie, express everything else as a function of control rate. I think this simplifies and reduces the order of the QP problem significantly. So yes, as Paul mentioned this formulates a dense MPC.
I am not very familiar with YALMIP and how I can construct the OSQP matrices using that but I will give it a try. Any hint is really appreciated.
By instability, I meant closed loop stability and not the solver non-convergence as you mentioned. In this sample example I sent you, the open loop system is marginally stable but I have seen the same issue with open-loop stable systems. I have also used and verified my QP formulation from the textbooks.
It seems the main issue is the dense MPC formulation. So can I conclude that I have to avoid variable elimination and dense matrices when trying to solve this MPC problem?
Having a rate constraint does not mean that the problem must be dense. You can do one of two things:
Augment the state dimension and then take \delta u as your input in an augmented model, or
Just impose constraints on the successive differences between inputs, keeping the state space model the same.
Which you pick depends mostly on whether you want to directly penalise the \delta u terms (a bit easier if those are inputs in an augmented model), and also on how you want to define your terminal conditions. I don’t think it will make much difference to the OQSP solve time.
There is no need to eliminate variables, and reducing the problem dimension by variable elimination will make your solve time worse (see Rao et.al, JOTA vol. 99, pp. 723–757, 1998. Discusses interior point methods but the basic reason is the same). Just keep all of the states as variables, it will be much faster.
With Yalmip, you can formulate the problem using OSQP for the solver and then ask it to supply you with the inputs as OSQP would receive them. See here.
Hi Paul, I followed your suggestion by not eliminating the variable. Now the closed loop system is stable but the solver does not seem to respect the control rate constraints and the violation is not minor. I tried different options from using tighter tolerances set for eps_rel and turn polishing on, etc but none could help me.
Do you know what is causing this issue for me? I saw similar questions about some constraint violation using OSQP here and on the github page but none could help with this case.
Note: The problem was formulated with YALMIP and solved via OSQP as per your suggestion. So I do not expect any issue in the formulation.