QPOASES fails on first iteration

Christian · March 13, 2020, 9:49am

Hi,

I am doing a python simulation very similar to the racecar example. My setup works nicely with PARTIAL_CONDENSING_HPIPM. When I try to run it with FULL_CONDENSING_QPOASES I immediately get “QP solver returned error status 37” in closed loop iteration 1. I feel like I forgot to set something. Any ideas what the issue might be?

zanellia · March 13, 2020, 10:20am

Hi Christian,

Error 37 corresponds to ‘RET_INIT_FAILED_INFEASIBILITY’ (you can check here https://github.com/acados/qpOASES/blob/77ce8944825d6857c606655ed60ced5ea30017a5/include/qpOASES_e/MessageHandling.h#L106 what the qpOASES errors mean). It might actually be that HPIPM is able to solve the QP, while qpOASES not. Is there any chance that your QP is particularly ill-conditioned? Also, condensing can sometimes make things worse. What happens if you solve with FULL_CONDESING_HPIPM?

Christian · March 13, 2020, 10:50am

Hi zanellia,

FULL_CONDENSING_HPIPM and PARTIAL_CONDENSING_HPIPM look very similar. If the error code 37 means infeasible initially, should I try to set up some slack variables on my hard constraints? I am surprised that it works with HPIPM and not with qpOASES though. How do you quantify ill-conditioned? The highest cost is about 1000 more than the lowest cost in my cost function.

zanellia · March 22, 2020, 10:44am

Hi Christian,

Sorry for the loose response. In general it’s hard to tell. If you send your code over we can have a look. Sometimes HPIPM can solve QPs that qpOASES fails to solve and viceversa - the solvers use very different methods.

Christian · March 22, 2020, 12:26pm

Hi zanellia,

thanks a lot for coming back to me.

Here is the code. Just run main.py. I am implementing Model Predictive Contouring Control (MPCC). I know for a fact, from a different implementation using a different solver framework, that the cost and algorithm as such works.

I have made some different observations, which are rather worrying regarding the correctness of my implementation in acados:

The external cost function doesn’t do anything, if I multiply it with 0 I get the exact same result
even though the cost function doesn’t do anything, the car still drives laps (probably in the nature of MPCC)

Can you please check out what I am doing wrong regarding the parametrized cost function I am using? I am pretty sure the crux in qpOases not working lies in my wrong implementation of the external cost function.The cost function is parametrized by the cost weights and by track linearization parameters, necessary for MPCC.

FreyJo · March 25, 2020, 3:15pm

Hi Christian,

there was a bug in the acados template, the parameters of the external cost function were not updated correctly.
I just fixed that, please check out this branch:
https://github.com/FreyJo/acados/tree/python_detect_dims

There was a minor modification I made to your code, which is due to a change in the interface, please check this out:
https://github.com/FreyJo/discourse_example_christian

I think the behavior the main has now is still not as you wish, but at least the influence of the external cost is visible now.
Maybe you have to adjust the scaling of your cost function, since acados uses a continuous time formulation.

Best,
Jonathan

Christian · March 25, 2020, 5:20pm

Hi Jonathan,

Thank you so much for your help. After tuning the cost function I got the desired behavior with your changes. How frequently are these fixes adopted into the acados master?

Cheers,
Christian

FreyJo · March 25, 2020, 5:33pm

Hi Christian,

great to hear that!
There is an open PR with the branch I pointed you to.
I am waiting for some feedback and hope it can be merged this week.

Cheers,
Jonathan

Christian · March 25, 2020, 5:46pm

Hi Jonathan,

That is fantastic. I hate to bother you again, though. I have a c++ implementation of the same problem, where the .c files are generated from the same acados_settings.py and bycicle_model.py that you already saw. The c++ implementation was doing the same as the python implementation before you fixed it. Now that the python implementation is fixed I get the following error, when writing parameters:

Screenshot from 2020-03-26 04-44-47

Here is the code snippet, where the error is thrown:

Has the writing of parameters with your changes, changed in c?

FreyJo · March 25, 2020, 7:01pm

Hi Christian,

I am not sure what the issue is in your C++ implementation.
Did you regenerate the C Code with the version I pointed to?

I guess your c++ implementation uses the rendered acados_solver*.c file.
For setting the parameters of the external functions you could call the equivalent of this function in the generated file, instead of doing for every external function separately.
This is where the external cost function was missing.

github.com

FreyJo/acados/blob/e2cf2920bf9856daf484c9f5b77768df51647efb/interfaces/acados_template/acados_template/c_templates_tera/acados_solver.in.c#L1547




    if (status != ACADOS_SUCCESS)
    {
        printf("\nocp_precompute failed!\n\n");
    }


    return status;
}




int acados_update_params(int stage, double *p, int np)
{
    int solver_status = 0;
    int casadi_np = 0;


{%- if dims.np > 0 %}
    if (stage < {{ dims.N }})
    {
    {%- if solver_options.integrator_type == "IRK" %}
        casadi_np = (impl_dae_fun+stage)->np;
        if (casadi_np != np) {

If that doesnt work, please tell me where exactly it is failing, i.e. for which external function & index.

Cheers,
Jonathan

Christian · March 25, 2020, 7:10pm

Hi Jonathan,

It looks like the error I was getting is gone, using the suggested function. There are other errors now, which do not seem to be related to acados. I’ll keep you updated once I know more. Thanks a lot for your help.

Cheers,
Christian

Christian · March 26, 2020, 12:53pm

Hi Jonathan,

everything works perfectly now. I really appreciate the speedy help you provide.

Cheers,
Christian