Problem running casadi-based controllers for whole-body-controllers when installing whole-body-controllers from conda binary packages

[traversaro]

When whole-body-controllers is installed from conda binary packages (so following the instructions in https://github.com/robotology/robotology-superbuild/blob/master/doc/conda-forge.md#binary-installation), the casadi package is installed via the casadi conda-forge binary available in https://github.com/conda-forge/casadi-feedstock . However, osqp is not enabled in that build, so some controllers that use casadi+osqp would fail at runtime.

[traversaro]

Actually, looking directly in the whole-body-controllers code, it seems that the QP solver used there is qpoases (see https://github.com/robotology/whole-body-controllers/blob/6e9a67623642d190427bace17d0b439bd2a13e8d/library/simulink-library/MomentumVelocityControl/src/casadi_block.m#L226). This means that even the usual installation process is broken, as qpOASES is not enabled in the casadi build of the robotology-superbuild (see https://github.com/robotology/robotology-superbuild/blob/master/cmake/Buildcasadi.cmake#L22).

@CarlottaSartore @gabrielenava do you think we can switch to use osqp in https://github.com/robotology/whole-body-controllers/blob/6e9a67623642d190427bace17d0b439bd2a13e8d/library/simulink-library/MomentumVelocityControl/src/casadi_block.m#L226 ? Otherwise, we need to add qpOASES support both in the robotology-superbuild build of casadi, and in the conda-forge build ( https://github.com/conda-forge/casadi-feedstock ). Obviously if we can avoid that additional work and just use osqp it would be great!

[traversaro]

Related issues: conda-forge/casadi-feedstock#51 .

[CarlottaSartore]

Ciao @traversaro ! Actually, the velocity controller version we are currently using has osqp as a solver (see https://github.com/robotology/whole-body-controllers/blob/258bced9cdb74a8c745ca3548c4c60ee85f295aa/library/simulink-library/MomentumVelocityControl/src/casadi_block.m#L251) but it is in devel and has not been merged yet into master.

@gabrielenava if we merge devel into master we should resolve the problem, what do you think?

[traversaro]

Perfect! No hurry, it is not urgent. I just wanted to make sure that we eventually fix it.

[traversaro]

The conda-forge part of the problem was fixed in conda-forge/casadi-feedstock#52 .

[gabrielenava]

@gabrielenava if we merge devel into master we should resolve the problem, what do you think?

yes, we will open a dedicated PR then

[traversaro]

wbc master and the latest release still uses qpoases (see https://github.com/robotology/whole-body-controllers/blob/master/library/simulink-library/MomentumVelocityControl/src/casadi_block.m#L226), that is not enabled in most of our casadi builds.

@gabrielenava if we merge devel into master we should resolve the problem, what do you think?

yes, we will open a dedicated PR then

Any update on this that should solve the issue?

[gabrielenava]

I tried to open a PR from devel to master branch in whole-body-controller, but after a quick check I realized the devel branch is currently broken - see robotology/whole-body-controllers#130 (comment)

I will bump back the modification that broke the controllers, then it should be possible to proceed with merging.

[gabrielenava]

I fixed devel branch in whole-body-controllers - see robotology/whole-body-controllers#130 (comment)

I merged the PR and now no controllers should use qpOASES anymore even in master branch @traversaro

[traversaro]

I fixed devel branch in whole-body-controllers - see robotology/whole-body-controllers#130 (comment)

I merged the PR and now no controllers should use qpOASES anymore even in master branch @traversaro

Great, thanks!