Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use the MomentumVelocityControl block and functions when whole-body-controllers is installed #140

Closed
traversaro opened this issue Dec 14, 2021 · 2 comments · Fixed by #141

Comments

@traversaro
Copy link
Member

traversaro commented Dec 14, 2021

Hi everyone, I was trying to take an internal downstream project that depends on whole-body-controllers and make sure that it was only using the the installed version of whole-body-controllers, to make sure that it can eventually work fine with binary distribution of the install of whole-body-controllers, such as a .zip of the <build>/install directory of the robotology-superbuild, or via the conda package of whole-body-controllers.

However, I am encountering several issues due to the different structure between how the whole-body-controllers files are organized in the source directory, and how they are organized when they are installed.

In particular, this project is currently adding to the MATLAB's path a lot of directories of the source repo of whole-body-controllers, via a snippet of code like:

robotology_source=getenv('ROBOTOLOGY_SUPERBUILD_SOURCE_DIR');
wbd_libraryPath=[robotology_source,'/src/whole-body-controllers/library/'];
if exist(wbd_libraryPath, 'dir')==7
    addpath(genpath(wbd_libraryPath));
    disp('Added whole-body controllers library');
else
    error([wbd_libraryPath,': Path directory non existent!']);
end

The Simulink controller of this repo then use directly MATLAB functions contained in library/simulink-library/MomentumVelocityControl/src, such as:

  • ComputeContactJacobianWithFeetContactFCN
  • centroidalConversion
  • ComputeReferences

The problem is that this functions are installed (due to the logic in https://github.com/robotology/whole-body-controllers/blob/v2.5.5/library/simulink-library/CMakeLists.txt#L27) in the <install_prefix>/mex/+wbc directory, and this is particularly problematic because if you try to add this directory to the MATLAB's path, you get an error:

>> addpath('/home/traversaro/cool_project_ws_2021/robotology-superbuild/build/install/mex/+wbc')
Warning: Package directories not allowed in MATLAB path: /home/traversaro/isaac_ws_2021/robotology-superbuild/build/install/mex/+wbc 
> In path (line 109)
In addpath (line 86) 

So it is impossible to call directly this functions. One could modify all the uses of this functions to contain the wbc. prefix, but this will not work as well as the function have internal references that do not use the wbc. prefix, so for example any use of wbc.centroidalConversion will fail with error:

The error was thrown from '
 '/home/traversaro/cool_project_ws_2021/robotology-superbuild/build/install/mex/+wbc/centroidalConversion.m' at line 33
 '/home/traversaro/cool_project_ws_2021/cool_projet/cool_controller.m' at line 347'. 
Undefined function 'centroidalTransformationT_TDot' for input arguments of type 'double'. 

Because centroidalConversion calls centroidalTransformationT_TDot directly.

In this form, this internal project can't be migrated to just use the installed version of whole-body-controllers. There could several strategies to fix this, but probably it could be a good idea to have a quick chat on this. @CarlottaSartore @gabrielenava

fyi @VenusPasandi @Andrea8Testa @valentino-razza @fdinatale

@traversaro
Copy link
Member Author

traversaro commented Dec 14, 2021

Note for the future: these kind of issues could be prevented by having the source structure corresponding exactly to the install structure, and just having a simple CMake code to install:

install(DIRECTORY <directory_containing_the_files_to_install> DESTINATION mex)

This should prevent from the structual point of view issue of these kind from happening again, and would drastically reduce the amount of CMake logic to mantain (and nobody likes complex CMake logic : ) ).

@traversaro
Copy link
Member Author

We had a meeting today on these, with this outcome:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants