Hope you guys doing fine!
During the past months, I successfully updated my library so it can be used natively with CasADi. Therefore, we are now able to use acados as our front-end for our optimal control problem (I am still working on the violin stuff ).
I however have a problem when compiling using the CasADi provided with acados. I have a linking problem that says that inv function is not defined for MX which is used in my library. This problem doesn’t come up when compiling from CasADi provided on GitHub.
When we look at the Python interface, casadi.MX.inv is indeed not defined which makes me think that you somehow not compile that part of the MX functions in the CasADi provided by pip. Does it make sense?
If so, would this be possible to provide the definition of MX functions in the compiled version of CasADi? I tried to override the CasADi with the version from GitHub, but (of course) I get SegFault as acados.
We are doing fine in Freiburg!
Nice to hear you made some progress towards acados with your violin application
I have some questions to understand the problem better.
acados does not provide/compile CasADi, the Python interface requires that some CasADi is available and it can be automatically downloaded when installing the acados python interface with pip.
More precisely: this file specifies the pip requirements, so we currently use the latest version 3.5.1
Did you check the casadi versions of your different workflows?
Which version does provide MX.inv?
How/ Where did you try to do this? Which version do you want to use?
Thanks for your fast answer! Hopefully we be able to create a violin problem in acados as fast! haha!
When I said “provided” I meant indeed downloaded by the setup install. This version, which is a priori the same as the one I am using (3.5.1) seems to have missing references.
In the C++ side of my library, all the calculations are made in the background via CasADi matrices. Therefore, when I spit an answer, it is a casadi::MX. In the Python side, I can wrap it using swig which makes a nice bridge between my C++ functions and the Python interface of acados. It works actually fine, we tried with a minimal example!
The problem comes at the compilation time. When I use a CasADi version (3.5.1) that I compiled myself, I can link everything just fine. So in python I can import my library using import biorbd command. However, if I compile using the library downloaded from the setup.py (using pip install .), there are references missing, in particular, casadi::MX::inv (and some other that I tried, such as pinv in MX namespace). So when I try to import my library, these are references are missing and the library cannot be loaded.
It seems that the wheel version of casadi 3.5.1 that we download has reference missing. That would make senses that these reference were not compiled in the first place since in the python interface casadi.MX.inv is not available anyway (so it doesn’t throw the missing reference error)
But you only compile it into a shared library and can link it with your C++ library, right?
Or can you also compile a Python interface that has casadi::MX::inv?
In the latter case you could probably just remove the 3.5.1 requirement if the CasADi lib you compiled yourself is available in Python.
This is quite weird. I think there are some functions that they do not want to expose in the interface, but this one should be available…
But you only compile it into a shared library and can link it with your C++ library, right?
That’s right, the casadi::MX::inv that I am using is in the C++ side, not in Python side.
In the latter case you could probably just remove the 3.5.1 requirement if the CasADi lib you compiled yourself is available in Python.
I tried this, when it works for loading and using my library, it actually fails when using acados (it SegFaults). I assumed this is because acados (in the C++ side) expects a specific version of CasADi, so if the MX is created in Python using a version of CasADi, and used in C++ by acados using another version of CasADi, it will indeed segfault
Is this after the Code generation and rendering, when calling AcadosOcpSolver?
To clarify:
acados has no C++ side, just C.
There will be no MX anymore after the CasADi functions are exported, it is just C Code.
So, you also compiled the CasADi Python interface?
If there is this difference (with references being available) between the CasADi Python provided online compared to the version you compiled, you should probably ask the CasADi developers, how they build the Python interface.
Thats right, so acados just works with the compiled version of the MX graph… I have to look again when it fails (I’ll have access to my computer tomorrow). I assume this is during the code generation, but I am not sure.
So, you also compiled the CasADi Python interface?
Not exactly, I only compiled the C++ side, and the Python wrapper is the one I provide with my library of the functions that returns MX (since my wrapper and the one from CasADi are both made using swig, then they are fully compatible).
If there is this difference (with references being available) between the CasADi Python provided online compared to the version you compiled, you should probably ask the CasADi developers, how they build the Python interface.
Yep… In all cases, this is the bottom line, even though this is not the python side that I am using, this is the right way. Hopefully they will answer faster than on the other thread…
Thanks for your help (we were actually hope that the CasADi version that downloads using pip was hosted (and therefore compiled) by you!
Great, that would be interesting!
If it fails in the generated Code, maybe there are some options for the code export set in the version they provide online that your lib is missing.
Yes, since this is not the case, it is really more CasADi responsibility
Just so you know, we actually managed to use our own compiled version of CasADi.
I don’t fully understand why it didn’t work the first time though… Maybe we had more *.so that were lying around. In any case, it actually works now
