Convergence failure on embedded platform

I’ve been experimenting with running Acados on an old Nvidia TK1 board using the ‘getting_started/minimal_example_ocp.m’ script. I compiled and ran the Matlab generated C code on my desktop, and that seemed to work fine, the solution reported successful. I ran make clean, and then transferred the C code to the TK1 board, where I previously compiled Acados using the GENERIC target. However, when I compile and run ./main_pendulum, I get the return “acados_solve() failed with status 2.”

Is this expected behavior? Is the difference just from compiling Acados with different targets? My understanding was that compiling for the GENERIC target would reduce solution speed, but I didn’t think it would change the solution. Or are there other settings or factors that I am missing?

Hi @aknight0,

this should not happen.
I just tried to run the main_pendulum generated from getting_started/minimal_example_ocp.m with target GENERIC and it works fine.
Is the compiled binary on your board from the same acados version?

I found that the board is 64bit too, so there shouldnt be an issue.

Compiler flags for HPIPM and BLASFEO can make small differences, but it should definitely not make the solver fail for such a simple problem.

Can you try to give more clear instructions how to reproduce the behavior?


Interesting. I copied the c code from the TK1 board over to a Raspberry Pi, compiled it there, and it runs fine, main_pendulum solves successfully, just as it does on the desktop. To double check, I deleted acados from both boards, pulled a fresh version from the master branch, and recompiled on both using the commands

git clone
cd acados
git submodule update --recursive --init
mkdir -p build
cd build
cmake .. 
make install
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ubuntu/acados/lib
export ACADOS_INSTALL_DIR=/home/ubuntu/acados/

Cmake reported Detected target GENERIC in both cases. Then I went back to my generated c code folder, and used make clean. In the Makefile I set

INCLUDE_PATH = /home/ubuntu/acados//include                                                                             
LIB_PATH = /home/ubuntu/acados//lib   

on the TK1, and

INCLUDE_PATH = /home/pi/acados//include                                                                             
LIB_PATH = /home/pi/acados//lib  

on the Pi.

The other change I made to the Makefiles on both platforms is to add -std=c99 to the ACADOS_FLAGS at the top. Otherwise I got the error

main_pendulum.c: In function ‘main’: main_pendulum.c:107:5: error: ‘for’ loop initial declarations are only allowed in C99 mode

Then I ran make, ./main_pendulum, and got the same outputs described above.
acados_solve(): SUCCESS! on the Pi.
acados_solve() failed with status 2. on the TK1

Both boards return armv7l to uname -i, which I believe is 32 bit.

The Pi 3 is running Raspian jessie, cmake 3.6.2, and gcc 4.9.2

The TK1 is running Ubuntu 14.04.6, cmake 3.17.0, and gcc 4.8.4

It’s not essential that it works on the TK1, it was just the first board I had around to test on. However, I am still curious why it would work on one and not the other? It would be good to know for future reference if there are limitations on what I can run this on.

Hi @aknight0,

thanks for the description!

There are definitely problems in acados with 32 Bit architectures, see issues on Github and this should for now be regarded as a limitation.

I read a bit about the Pi 3, it has a 64-bit CPU but is typically running a 32-bit OS.

I am not sure about the details, but from what you describe, it seems like acados is running there just like on a 64 Bit architecture.

I was able to reproduce the behavior that you observed on your TK1 board on a Raspberry Pi 2 (which is real 32-bit).
I will look a bit more into this, but I cannot promise a quick fix.

I hope you can use your RPI3 or another board with 64-bit CPU for now.


Thank you Jonathan, that’s useful to know. I’ll move towards a 64 bit board.

I can confirm that this does indeed work on an Nvidia TX2, which is 64 bit.