Idyntree: Include high-level Matlab wrappers in the iDyntree repo

[gabrielenava]

I wrote a collection of high-level wrappers for simplifying the usage of iDyntree inside Matlab. I would like to move the wrappers inside iDyntree. I also designed a matlab test to verify if the wrappers are correctly working.

This issue is for discussing how to properly integrate the wrappers and their test inside iDyntree.

cc @S-Dafarra @traversaro @fjandrad @claudia-lat

[traversaro]

As discussed on Telegram:

• Some docs on them and how they are different from the bindings as directly generated by iDynTree should be added/adapter from the existing docs
• A good location for them could src/bindings/matlab/high-level
• The binding should be installed in ${CMAKE_INSTALL_PREFIX}/${IDYNTREE_INSTALL_MATLAB_MFILESDIR} and should be usable as soon as the user have ${CMAKE_INSTALL_PREFIX}/${IDYNTREE_INSTALL_MATLAB_MFILESDIR} in his/her MATLAB path. Perhaps a good idea could be to add an additional nested package inside the +iDynTree package created by SWIG, but perhaps instead this is a bad idea, because it could conflict with SWIG stuff.

[traversaro]

For tests, what needs to be integrated in our test suite that runs with CTest is any kind of (terminal) command that can be launched by the command line that (quickly) returns with 0 if the test is successful, and with any other value if it fails. In particular, we are using the exit command of MATLAB, and we are launching the matlab test scripts via MATLAB with the following flags: ${Matlab_MAIN_PROGRAM} -nodisplay -nodesktop -nojvm -r. See https://github.com/robotology/idyntree/blob/master/bindings/matlab/tests/CMakeLists.txt#L11 for more info.

Any other script that needs to be inspected by a human to understand if everything went fine or not is not suitable to be used in the testing infrastructure, and is probably more useful as an example or something similar.

For matlab tests we are currently using MOxUnit, but it would not be a problem to have some tests that are instead standalone, as long as they are not interactive and return 0 for success and non-0 for failure.

[traversaro]

For automatic testing we actually use Octave, so it would be ideal if the new high-level wrappers would be compatible with Octave. However, there is no need to check that yourself, as this is automatically tested by the CI system if you add tests for your classes.

[gabrielenava]

Perhaps a good idea could be to add an additional nested package inside the +iDynTree package created by SWIG, but perhaps instead this is a bad idea, because it could conflict with SWIG stuff.

All the functions follows a naming convention for the form idyn_nameOfTheCorrespondingiDyntreeMethod which is quite a unique name, so I think for the moment the package is not required, but rather we can install the functions in a normal folder. Also, all the functions are expecting as argument the iDyntree KinDynModel object, and in case of clashing names with other user-defined functions there will be an error (thus avoiding hidden bugs due to a wrong function call).

[gabrielenava]

In the end, I am going to create the package anyways so that it won't be necessary to modify any path-setup function, as the path to build/install/mex is already required in order to be able to use the +iDynTree package.

I will simply create another package named +iDynTreeWrappers which is installed inside the build/install/mex folder. When the user sets up the matlab path for the bindings, also the wrappers will become available.

In order to use the wrappers, the user must specify the namespace iDynTreeWrappers as a prefix for the functions call, e.g. iDynTreeWrappers.getRobotState(). All the functions have the same name of the corresponding iDynTree methods, that are mainly (but not only) the ones inside the KinDynComputation class.

[gabrielenava]

I've opened a PR: https://github.com/robotology/idyntree/pull/530

[gabrielenava]

PR has been merged. Closing the issue.