Different behavior in acados_ocp and code generation

francesco · January 15, 2022, 12:04pm

Hi

I am trying to use the Matlab interface of acados to implement a simple mpc controller in a closed-loop simulation. I noticed that if I create the solver as ocp = acados_ocp(ocp_model, ocp_opts); it fails several times during a simulation with status 4 (SQP_RTI: QP solver returned error status 3 QP iteration 44. in the terminal).

On the other hand if I generate the code with ocp.generate_c_code; and create the solver by typing ocp = my_model_mex_solver; It never fails in the same simulation setup.

Why do they behave differently? Shouldn’t they be equivalent?
Maybe the code generation introduces some default solver setup that I am missing in the other case?

I experience the same problem in both MacOs and Ubuntu.
Thanks for any suggestion.

FreyJo · January 20, 2022, 12:19pm

Hi Francesco,

these solvers use different interfaces.
I tried to describe this here:
https://docs.acados.org/matlab_octave_interface/index.html#interface-structure

In general equivalence of the two interfaces is not guarenteed.
However, it is ensured for a few for a few test examples.
See here for example.

github.com

acados/acados/blob/master/examples/acados_matlab_octave/test/test_template_pendulum_exact_hess.m

%
% Copyright 2019 Gianluca Frison, Dimitris Kouzoupis, Robin Verschueren,
% Andrea Zanelli, Niels van Duijkeren, Jonathan Frey, Tommaso Sartor,
% Branimir Novoselnik, Rien Quirynen, Rezart Qelibari, Dang Doan,
% Jonas Koenemann, Yutao Chen, Tobias Schöls, Jonas Schlagenhauf, Moritz Diehl
%
% This file is part of acados.
%
% The 2-Clause BSD License
%
% Redistribution and use in source and binary forms, with or without
% modification, are permitted provided that the following conditions are met:
%
% 1. Redistributions of source code must retain the above copyright notice,
% this list of conditions and the following disclaimer.
%
% 2. Redistributions in binary form must reproduce the above copyright notice,
% this list of conditions and the following disclaimer in the documentation
% and/or other materials provided with the distribution.
%

This file has been truncated. show original

Maybe you can make a similar minimal example to show the different behavior, both solvers should be initialized in the same way.

Not sure when I will have time to look into it though…

Cheers!

francesco · January 21, 2022, 10:48pm

I loaded the simple test code in this repo. As I said what is weird is that the native MEX interface fails several time whereas the code generation never fail, despite the simulation setup is exactly the same. Thus I was wondering if the two interfaces introduce different settings (possibly not voluntarily) and, if this is the case, which are these settings.

Thanks again.

FreyJo · April 4, 2022, 10:22am

Hi Francesco,

I finally found some time to look into your problem.
I found that some settings were not the same in the template based interface:

But the main issue with that problem seems to be that the conditioning of the problem gets too bad for the HPIPM solver used, when condensing the horizon from 100 to 5.
Switching either

qp_solver_cond_N to >= 20
or
qp_solver to full_condensing_qpoases
makes both solvers equivalent.

I made a PR to your repository to compare the results a bit more systematically

I think as soon as the solver fails once / doesn’t fail comparing closed loop simulations does not make much sense anymore, since the errors just accumulate.

Best,
Jonathan

francesco · April 10, 2022, 11:14am

Hi Jonathan,
Thank you for your support. This is what I was looking for, now I get the same behavior: indeed if the solver fails using the native interface then it fails also using the template based interface and viceversa.

Thanks also for your suggestion about the choice of the condensing factor.

Regards,
Francesco