I use Matlab for developing and testing an acados-based trajectory planner with “external” costs (some custom casadi expression) and nonlinear constraints. Now, as it is working quite well, I want to use the solver in a C++ environment.
As a starting point I tried to run the file examples/acados_matlab_octave/test/test_template_pendulum_exact_hess.m, but I get the following error:
Invalid MEX-file '/home/martin/Programs/acados/examples/acados_matlab_octave/test/c_generated_code/acados_mex_create_pendulum_12.mexa64':
libacados_solver_pendulum_12.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
Error in pendulum_12_mex_solver (line 49)
[obj.C_ocp, obj.C_ocp_ext_fun] = acados_mex_create_pendulum_12();
Error in test_template_pendulum_exact_hess (line 230)
eval( command );
The library “libacados_solver_pendulum_12.so” exists and “env.sh” has been sourced.
The script also creates an executable “main_pendulum_12”. Executing it on the Linux terminal shows a message that the solver failed:
does ocp.generate_c_code only work for least squares cost functions? Whenever I add some expressions to expr_ext_cost of the “pendulum_on_cart_model” and set cost_type to ext_cost or auto the code generation fails.
P.S.: I don’t need support for the other 2 issues in my last post any more
for me it is essential to get the solver running in C++ as soon as possible. I understand if you do not have the time to solve this immediately. So could you please give me some hints in which files I have to add what?
At the moment I really don’t know where to start and what to do.
Regarding the problems in my initial post:
1st issue: Invalid MEX-File error
In Linux (Ubuntu 18.04) the current Matlab (R2019b) working directory seems to be not considered as runtime search path for libraries. However, it uses the environment variable LD_RUN_PATH. Therefore, adding export LD_RUN_PATH="$(pwd)"/c_generated_code to “env.sh” solves this problem on my machine.
2nd issue: solver in “main_pendulum_12” fails
In file “main_pendulum_12.c” one can see that the initial guess of the x-trajectory is set to zero. If it is set to the same value as in the Matlab script (“test_template_pendulum_exact_hess.m”) the solver succeeds.
thank you for the quick extensions. Your example test_template_pendulum_ocp('ext_cost') works now. Unfortunately this is not the case for my own project. After calling ocp.generate_c_code I get the following output:
Warning: model parameters value cannot be defined (yet) for ocp json.
Using zeros(np,1) by default.
You can update them later using the solver object.
> In set_up_acados_ocp_nlp_json (line 161)
In acados_ocp/generate_c_code (line 168)
In main (line 182)
Reference to non-existent field 'dyn_expr_f'.
Error in set_up_acados_ocp_nlp_json (line 385)
ocp_json.model.f_impl_expr = model.dyn_expr_f;
Error in acados_ocp/generate_c_code (line 168)
obj.acados_ocp_nlp_json = set_up_acados_ocp_nlp_json(obj);
Error in main (line 182)
ocp.generate_c_code
The warning at the top seems to be related to the fact that I use parameters. Is that a problem?
The error comes from using a discrete-time model. This is what I do before creating the OCP-object:
unfortunately, discrete time formulations are not yet supported by the template based workflow.
Adding support for this will take a bit more time then for the external cost.
If you want to help, you can add a test in Matlab that first runs the native Matlab code with discrete dynamics and then tries to do the same with the template based workflow.
One will have to add some checks on the dyn_type, such that dyn_expr_f is not needed, modify the Python templates in https://github.com/acados/acados/tree/master/interfaces/acados_template/acados_template/c_templates_tera
and do some more modifications.
I will not have time for this very soon.
But if you can prepare a branch doing this as far as you get, it might speed up the process.
I’ve started to work on the test script in Matlab in a new local git branch. How can I share this with you?
I have no permissions to push this branch on the acados repo.
I wanted to switch back from my fork to the master branch of the official acados repo. Executing the test script “test_template_disc_dyn_ocp_linear.m” generates the following error:
Error using mex
/home/martin/Programs/acados/examples/acados_matlab_octave/test/c_generated_code/acados_mex_create_lin_mass.c: In function ‘mexFunction’:
/home/martin/Programs/acados/examples/acados_matlab_octave/test/c_generated_code/acados_mex_create_lin_mass.c:211:28: error: ‘phi_fun’
undeclared (first use in this function)
l_ptr[0] = (long long) phi_fun;
^~~~~~~
/home/martin/Programs/acados/examples/acados_matlab_octave/test/c_generated_code/acados_mex_create_lin_mass.c:211:28: note: each undeclared
identifier is reported only once for each function it appears in
/home/martin/Programs/acados/examples/acados_matlab_octave/test/c_generated_code/acados_mex_create_lin_mass.c:213:28: error: ‘phi_fun_jac_ut_xt’
undeclared (first use in this function); did you mean ‘disc_phi_fun_jac_mat’?
l_ptr[0] = (long long) phi_fun_jac_ut_xt;
^~~~~~~~~~~~~~~~~
disc_phi_fun_jac_mat
/home/martin/Programs/acados/examples/acados_matlab_octave/test/c_generated_code/acados_mex_create_lin_mass.c:216:28: error:
‘phi_fun_jac_ut_xt_hess’ undeclared (first use in this function); did you mean ‘phi_fun_jac_ut_xt’?
l_ptr[0] = (long long) phi_fun_jac_ut_xt_hess;
^~~~~~~~~~~~~~~~~~~~~~
phi_fun_jac_ut_xt
Error in make_mex_lin_mass (line 101)
mex(FLAGS, acados_include, template_lib_include, external_include, blasfeo_include, hpipm_include,...
Error in lin_mass_mex_solver (line 48)
make_mex_lin_mass();
Error in test_template_disc_dyn_ocp_linear (line 310)
t_ocp = lin_mass_mex_solver;
in Matlab in order to see whether the templated version behaves roughly the same. Fortunately, the interface for setting parameters and constraints at runtime and retrieving results is identical for ocp and t_ocp and so I use exactly the same code for calling both solvers in my simulation loop. Therefore, both of them have the same constraints, weights, parameters, initial values, etc. …
I expected some minor deviations between them, since the underlying code is not exactly the same. However, I get quite different results from them. The following screenshot shows the inputs of a bicycle model from the ocp object (this is the desired behavior):
So there must be a difference between ocp and t_ocp which I am not aware of. Of course analyzing the problem just with two screenshots is difficult. Do you have an assumption what I’ve forgotten here or what the reason could be?
Indeed both solvers should behave the same, but are using different interfaces that were developed separately initially.
I made a few tests, that check both solvers have the same behavior up to some precision, for some test problems.
Unfortunately, I cannot say much just based on the plots.
You can explicitly initialize everything and double check, but it really seems like something else is different.
If you can share the example code with me, I am willing to look into it.
I’ve noticed in the generated C-code from the template (acados_solver_MYSOLVERNAME.c) that not all QP-solver options are set. In my fork I’ve made a branch template_mod where I changed the Matlab template workflow such that the QP solver tolerances are set correctly.
This does not reduce the deviation between the two solver results as described above, but using the same options maybe helps to isolate the problem.
The parameters qp_solver_warm_start, qp_solver_cond_ric_alg and nlp_solver_warm_start_first_qp are also missing I think. But those require changes in the template too.
What is the meaning of the parameters initialize_t_slacks and cost_numerical_hessian which are set to 0 by default?
cost_numerical_hessian: is an option to use a numerical hessian inside a cost module (instead of evaluating a CasADi/external function). initialize_t_slacks: these are internal slack variables corresponding to evaluation of all inequalities (at the solution). If this option is set they are initialized by evaluating the constraints.
I think that none of these options should make a big difference in the behavior of the solver.
I would try to print the qp_in, qp_out of one problem instance into a file and have a look at the diff of these.
The input and output of the QP solver should be printed if opts->print_level > sqp_iter + 1.
Just to be sure: In both cases the solver always exits with status SUCCESS, right?
Ok, I will try to get that “debug output” working.
Above plots are the result from calling the solvers 280 times, from those calls in both cases (for ocp and t_ocp) about 270 exit with SUCCESS and 10 with MAX_ITER.
I wrote the debug outputs of ocp and t_ocp into two files for the first time-step of the simulation. Both files contain a huge amount of data and I cannot interpret most of it since I do not know enough about your solver internals.
So I used a diff-tool do find the first deviation. It is the last value of rq which is “-1” for ocp and “0” for t_ocp. Can you conclude anything from that?
For me this rq output seems to be generated before the 1st iteration of the solver. I suppose the solver starts after the lines
# it stat eq ineq comp
0 2.000000e+02 4.000000e-01 9.999964e+05 0.000000e+00.
Up to this point everything except that single rq-value is identical. After that already the 2nd line of BAbt shows small differences and from that point on pretty much everything is slightly different.
