Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set/expose qpOASES's setToReliable option? #202

Open
traversaro opened this issue Feb 15, 2021 · 16 comments
Open

Set/expose qpOASES's setToReliable option? #202

traversaro opened this issue Feb 15, 2021 · 16 comments

Comments

@traversaro
Copy link
Member

Summary

The qpOASES QP solver with default options sometimes mark as unfeasible problems that are feasible, see coin-or/qpOASES#85 . However, from coin-or/qpOASES#85 (comment) and https://raw.githubusercontent.com/coin-or/qpOASES/master/doc/manual.pdf page 30, it seems that there is a setToReliable option that should make the QP solver more reliable and the expense of computational speed.

Motivation

If this option is present, could it make sense to set them in https://github.com/robotology/wb-toolbox/blob/master/toolbox/library/src/QpOases.cpp#L320 or expose them?

Additional context

Related issues:

@traversaro
Copy link
Member Author

This issue may be interesting for anyone using the WB-Toolbox for solving QP problems.
cc @nunoguedelha @diegoferigo @gabrielenava @Giulero @lrapetti @Yeshasvitvs

@diegoferigo
Copy link
Member

From my side this sounds good. I'd recommend current users that have the qpOASES block in their Simulink Models to try this change. The modification should be straightforward as @traversaro pointed out:

qpOASES::Options problemOptions;
problemOptions.setToDefault();
pImpl->sqProblem->setOptions(problemOptions);

qpOASES::Options problemOptions; 
problemOptions.setToReliable();  // < -- HERE
pImpl->sqProblem->setOptions(problemOptions); 

@traversaro
Copy link
Member Author

This issue may be interesting for anyone using the WB-Toolbox for solving QP problems.
cc @nunoguedelha @diegoferigo @gabrielenava @Giulero @lrapetti @Yeshasvitvs

I think I forgot @CarlottaSartore @VenusPasandi @valentino-razza in this list, sorry for that.

For avoiding that, let's tag @robotology/iit-dynamic-interaction-control : if anyone arrived here with this mention and never had to solve a Quadratic Programming problem in Simulink using WB-Toolbox's QpOases block, feel free to ignore this mention. If instead you are using that block and you are experiencing strange QP failures, this may be due to the options that we are using for the qpOASES solver, and fixing them may be relatively easy, just trying the modification suggested by @diegoferigo in #202 (comment) .

Note that it probably still make sense to eventually investigate #180, but this modification of qpOASES is probably much faster (it can be done in ~10 minutes).

@lrapetti
Copy link
Member

I did a preliminary test switching to this option, everything compiled fine and the following is the output of the profiler:

QP not failing

In this case the QP is not failing with Default option, and it is not failing as well with Reliable:

  • Default
    Screenshot from 2021-02-23 09-26-21
    time = 0.224/2106 = 0.00010636277
  • Reliable
    Screenshot from 2021-02-23 09-30-52
    time = 0.230/2156 = 0.00010667903

As computational time, the difference seems to be small

QP failing

I tested also in a configuration where the QP was failing with Default option, and it was failing with Reliable as well (note that I am not sure in this specific case a solution is feasible)

  • Default
    Screenshot from 2021-02-22 17-58-56
    time = 0.449/2090 = 0.00021483253
  • Reliable
    Screenshot from 2021-02-22 18-02-35
    time = 0.485/2118 = 0.00022898961

@traversaro
Copy link
Member Author

Thanks @lrapetti ! What is the size of the QP problem in your case? For a problem that in the past we found that it was not working in qpOASES even if it was feasible, you can find it in the .mat file attached to the failing example in coin-or/qpOASES#85 (comment) .

@lrapetti
Copy link
Member

Thanks @lrapetti ! What is the size of the QP problem in your case?

Hessian: 48x48
Inequality constraint matrix: 76x48

@traversaro
Copy link
Member Author

Cool, I think that is definitely is "big" w.r.t. to classical uses of the QpOases block in WB-Toolbox. At this point, if there is no particular performance problems, I think it make sense to enable the setReliable mode by default.

@lrapetti
Copy link
Member

Inequality constraint matrix: 76x48

Actually 152x48, but with half dummy lines 0≤0

@S-Dafarra
Copy link
Collaborator

Inequality constraint matrix: 76x48

Actually 152x48, but with half dummy lines 0≤0

I would remove those. It screws up the detection of the active contacts and the constraint matrix gets singular.

@lrapetti
Copy link
Member

Inequality constraint matrix: 76x48

Actually 152x48, but with half dummy lines 0≤0

I would remove those. It screws up the detection of the active contacts and the constraint matrix gets singular.

sure, I was forced to do it in order to have fixed-size signals entering the block (alternative would be instantiating multiple QP blocks, but for the time being I was not experiencing particular problems with the dummy constraints).

Cool, I think that is definitely is "big" w.r.t. to classical uses of the QpOases block in WB-Toolbox. At this point, if there is no particular performance problems, I think it make sense to enable the setReliable mode by default.

Anyway, I know what I will say is a bit vague, but today I saw some "strange" and "jumpy" output from the QP when setReliable was used, on some other code (i.e. not the one I was refering to in #202 (comment)). Switching back to setToDefault() changed the behaviour back to a normal one.

I will try to document more this observation repeating the same scenario, but I just want to say we probably should test further before enabling setReliable as default.

@traversaro
Copy link
Member Author

Thanks @lrapetti ! If you are able to log the time series of QP instances (i.e. cost matrices and constraint matrices) it would be useful also for testing them on OSQP.

@nunoguedelha
Copy link
Collaborator

Side note: on this simulation with feet contact handling, having dummy lines with zeros was causing the QP to fail. For handling toggling contact constraints (feet touching or not the ground), I had to toggle the boundaries of the QP problem variable.

@nunoguedelha
Copy link
Collaborator

This problem was not occurring with the OSQP (bindings).

@traversaro
Copy link
Member Author

cc @CarlottaSartore another quick check that we could do is enable this option. @lrapetti do you happen to still have around the branch with the option changed?

@lrapetti
Copy link
Member

cc @CarlottaSartore another quick check that we could do is enable this option. @lrapetti do you happen to still have around the branch with the option changed?

No, but it was set just by adding one line as @diegoferigo was pointing above (#202 (comment))

@lrapetti
Copy link
Member

Today, I have tried again to set that option (moving to the branch in #208) on a "stable" simulink model, and I didn't encounter any problem.

In particular, I have tested again a "big" model with 3 qpOASES blocks (two solving the same problem, and one solving a larger problem), and there seems to be no computational time increase (it is actually taking less time on reliable option).
Here are the statistics (qpOASES blocks are those named QP solver)

Default

not_reliable

Reliable

set_reliable
reliable_2 (2)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants