Use solver in C++ environment

Hi Jonathan,

I just created the debug output for another (simpler) test case of my application. Again, two values in the last line of rq are the first differences. With respect to the number of lines and columns of rq this seems to be related to the terminal stage i guess.

After that it is also similar to the previous case: Until the 1st iteration the output is the same, after that it is starts to diverge more and more.

BR
Martin

Hi Martin,

Just for reference, the output corresponds to the vectors and matrices in the OCP QP notation in this PDF:

Each line of rq, represents one stage of the OCP QP costs.
Since you write that the first difference is in the last line of rq, my guess is that there is a difference in the terminal cost.

acados is an SQP type solver, thus the OCP-NLP is linearized before solving the first OCP-QP.

I guess, for now it is really enough to look at the first linearization and resolve this difference.
Please, let me know if you find the issue.
If you can share this simple test example with me, I can also try to look for it.

Best,
Jonathan

Hi Jonathan,

with “look at the first linearization” you mean the result of the linearization and not the code right? Because I suppose the linearization routines to be part of the acados “core” and so I hope ocp and t_ocp use the same code here. Is this correct?

Therefore, the deviation must come from differences between acados_create() in acados_solver_MYSOLVERNAME.c and the mexFunction(...) in interfaces/acados_matlab_octave/ocp_create.c in my opinion. Are there any other files which you would investigate?

BR
Martin

Hi Martin,

First, I would look at the results of the linearization, which you did :ok_hand:
Since you write there is a difference in the last line of rq, and this is part of the cost function, I would investigate that more closely.

This is still the case?

These are good candidates to look for the bug.
I would check everything corresponding to the terminal cost module in them.

Moreover, you could try to look into this function:

Maybe you can use the external cost function only for the terminal cost to test this.
So you can just add some prints in this function and not get the output for the nonterminal stages.
I would definitely check model->scaling and the vector memory->grad in this function, which should correspond to rq.

Cheers!

Hi Jonathan,

I’ve finally found the bug. It looks like a copy & paste error from adding nonlinear_ls and external costs to the template:


Now the results from ocp and t_ocp are very similar. Thanks, for the support!

Two final questions:

  1. In case of “NONLINEAR_LS” costs C_ocp_ext_fun contains fields for the pointers to cost function, the Jacobian, and the Hessian. For the EXTERNAL costs it contains only fields for the cost function and for the Hessian. Why is there no field for the Jacobian?

  2. Why do you maintain these two workflows: ocp (Matlab only) and t_ocp (Matlab and C++ environment)? Wouldn’t it make more sense to focus on the templates, which can be used for multiple purposes?

BR
Martin

Hi @martk,

I am glad you found it, good job! :pray:

It should be added, it is an artifact of the option cost_numerical_hessian only being implemented in Python.

I also think it would be desirable to only have one backend.
I made this layer to create a MEX solver based on the templates quickly to have a possibility to compare the workflows systematically, the layer you found the bug in.
Before that, both interfaces MEX & Matlab were completely separate.
The next step would be to refactor the constructor of ocp to directly use the template based backend.
This will take quite some work and also break some existing examples/syntax, respectively they need to be adapted to the changes of the interface and one should make sure the behavior does not change.
So, in summary, it would take quite a bit of time, contain breaking changes and should be done carefully.

I will wrap up your PR later.
If you have something else to add there, let me know.

Best,
Jonathan