coin-or / qpOASES

Open-source C++ implementation of the recently proposed online active set strategy
GNU Lesser General Public License v2.1
376 stars 127 forks source link

Solving an LP via Simulink interface #28

Closed svigerske closed 4 years ago

svigerske commented 4 years ago

Issue created by migration from Trac.

Original creator: mgulan

Original creation time: 2014-11-17 19:16:51

Assignee: ferreau

Version: 3.0.0

Dear qpOASES team;

I am attempting to solve a (parametric) LP problem (nV=2,nC=~550) via the Simulink interface in simulation mode in order to deploy the in real time afterwards. I would like to ask how to setup the LP in Simulink if it does not comprise neither any bounds (lb,ub) nor the lower constraint bound (lbA) in its formulation, and of course a zero hessian (H).

In the Matlab interface I happened to solve the OCP easily by calling qpOASES function while leaving the aforementioned input arguments empty (..,[],[],[],..). Since I cannot use a similar approach in Simulink I had to replace these with -inf/inf inputs of appropriate size, as well as a zero hessian matrix.

Here, my first question is if the abovementioned procedure is a valid and "optimal" way to achieve the desired result. Reason for my hesitation is that the obtained LP optimizer in Simulink does not coincide with the (correct) one obtained via Matlab qpOASES function call, which I have not encountered so far when solving the QPs using qpOASES. In short, solving the LP with "qpOASES()" in Matlab does not yield the same result as "qpOASES_QProblem" via Simulink. Printed info did not shed much light, it only says the latter required more working set recalculations/iterations. Is there a recommended way to do this - solving LP with qpOASES via Simulink interface? Also maybe another way to leave out the three unused types of bounds/constraints?

The second question relates to setting options for LP, which I suppose is done inside "qpOASES_QProblem.cpp" where I edit line257 to "problem = new Qproblem(nV,nC,HST_ZERO)" and pass a null pointer for Hessian inside "init" function calls. Are there any other hints or recommendations for avoinding computational overhead when solving an LP with qpOASES, please?

I would appreciate any reply or hint om this topic. Unless there is a simple explanation to the first question, I might attach the necessary data.

Thank you for your attention,

martin


I am using the latest qpOASES release within Matlab R2014a(x64,8.3.0.532), on a Windows 7(x64,SP1) machine with the Microsoft Visual C++ 2012 set in "mex -setup".

svigerske commented 4 years ago

Attachment data.mat by mgulan created at 2014-11-18 10:32:03

svigerske commented 4 years ago

Attachment qpOASES_QProblem.cpp by mgulan created at 2014-11-18 10:33:34

svigerske commented 4 years ago

Comment by mgulan created at 2014-11-18 11:48:40

I attached the problem data (OCP matrices data.mat, simulink model simLP.slx) as well. The structure of the pLP is as follows:

min  Fx
s.t. Gx<=W+E*state

what corresponds to qpOASES OCP notation of

min  x'g(w0)
s.t. Ax<=ubA(w0)

where w0 stands for the parameter, in my case the the actual state of the system.

I obtained the correct optimizer (x=[0.0000;-0.1209]) via:

[x,fval,exitflag,iter,~,auxOutput]=qpOASES(zeros(2,2),data.F',data.G,[],[],[],data.W+data.E*data.state,qpOASES_options('MPC'))

or

[x,fval,exitflag,iter,~,auxOutput]=qpOASES(zeros(2,2),data.F',data.G,-inf*ones(2,1),inf*ones(2,1),-inf*ones(118,1),data.W+data.E*data.state,qpOASES_options('MPC'))

I also attached the correspoding Simulink model, which does not yield the same expected result; along with "qpOASES_QProblem". I also remark that it does not include any zero hessian info, null pointers or any other hints to make the computation faster. Feel free to advise here too (cutting down the code/model to only what is really neccessary, or avoiding certain overhead). Help will be appreciated.

Best,

martin

svigerske commented 4 years ago

Attachment simLP.slx by mgulan created at 2014-11-18 12:00:40

svigerske commented 4 years ago

Comment by ferreau created at 2014-11-21 15:46:02

Dear Martin,

thanks a lot for providing all the details and sorry for not answering earlier. Let me address your questions one by one:

1) For historical reasons, the Simulink interface expects H and A as vectors, which often causes user confusion. qpOASES expects the matrix data to be stacked row-wise, while the default way of Matlab is column-wise (in order to be compatible with FORTRAN/LAPACK/BLAS). This does not matter for H as it needs to be symmetric anyway, but stacking A in a wrong way causes trouble (typically infeasible QPs). In your case, when I feed data.G' instead of data.G, I obtain the same solution as you reported for the Matlab interface.

2) The Simulink interface has not been tailored to LPs. So, you need to pass a zero H matrix and infinite vectors in your case. (We might provide the possibility to leave these arguments empty in future releases, see Ticket #29, but currently this is not possible!) Your idea of "hacking" the Simulink interface and hard-coding HST_ZERO in the QP object constructor is indeed a good way to skip the initial test for zero Hessian. Apart from that, there is not much you could do to speed-up LP solution.

Best regards, Joachim

svigerske commented 4 years ago

Comment by ferreau created at 2014-11-21 15:50:12

Resolution: fixed

svigerske commented 4 years ago

Comment by mgulan created at 2014-11-21 21:38:43

Many thanks Joachim for pointing out the problem, providing valuable information, and creating the new ticket as well.

Best regards,

martin