Automate the update of the iCub model

[fiorisi]

Dear all,
Thanks for sharing the iCub package.
We started to have a look at the files and we noticed that there are more than one iCub model. The icubGeonva03, the x-backward and the icub.sdf models probably are old models that were used to perform the preliminary walking simulations 3 years ago. If I am correct, now we only need the iCubGenova04.urdf and the iCubGenova04.sdf.

Since we store all the URDF models of our iCub robots in a repository named icub-models, we were wondering if you think that it is possible (and not too complicated) to have a script that automatically copies the model. This should avoid any manual copy-paste operation, that could introduce errors and lead to different versions of the model.

Possible issues to be discussed:

• write a script that copies the model (URDF and meshes) from the icub-models to the resources folder
• currently in the icub-models repository we only have the URDF models

@dljsjr, @georgwi, @traversaro, @DanielePucci, @francesco-romano, @pattacini, @diegoferigo, @gabrielenava

[dljsjr]

Sounds good to me. We usually use scripts that run xacro and gz sdf to do the conversion from .xacro -> .urdf -> .sdf for us. Setting up a system that runs these scripts automatically shouldn't be too difficult.

[dljsjr]

After looking at the repo that @fiorisi linked, my proposal for this is to add the icub-models repository as a submodule to this repository.

Because our sims run on platforms outside of Ubuntu 14.04 we have to vendor not only the .urdf/.sdf but the meshes as well so that we can load them on systems where ROS, Gazebo and GAZEBO_MODEL_PATH/ROS_PACKAGE_PATH don't exist. We have mechanisms for this but it just means we need to vendor more than just the model file.

Then we can periodically update the sudmodule to the latest version of the model and regenerate the .sdf in a well-defined way that puts all of the meshes and XML files in the correct locations for our model loaders.

[dljsjr]

Actually an even better solution would be to add icub-models as a submodule then have Gradle treat the submodule as a resource directory. Then we wouldn't have to explicitly vendor the meshes, we'd just vendor the generated .sdf and have everything else be tracked by the submodule.

[georgwi]

Just a heads up: I am cleaning up the package right now and I have removed the old models.

[traversaro]

Because our sims run on platforms outside of Ubuntu 14.04 we have to vendor not only the .urdf/.sdf but the meshes as well so that we can load them on systems where ROS, Gazebo and GAZEBO_MODEL_PATH/ROS_PACKAGE_PATH don't exist. We have mechanisms for this but it just means we need to vendor more than just the model file.

What is your logic for finding the meshes without the GAZEBO_MODEL_PATH/ROS_PACKAGE_PATH env variables?
Unfortunately the URDF/SDF spec is not really flexible from this point of view (no way of specifying the resources as a relative path w.r.t. to the model location, but perhaps this is also related to eventual problem in sym-links, see robotology/icub-models-generator#28). Knowing your logic would simplify the job of getting icub-models in the proper shape to be used directly from ihmcrobotics/iCub. Related to that, unfortunately we recently (in https://github.com/robotology-playground/icub-models/pull/3/files) removed the support for using the models directly from the repo, and we now require the user to build or install the repository using the embedded CMake logic, but I guess this is in conflict with using the models directly from the repo cloned as a submodule. @diegoferigo can provide more details on this.

[diegoferigo]

The changes @traversaro mentioned introduced a seamless way for generating the model.config file though a CMake template (before we didn't ship it). The README explains how to use this repo without the need of installing it. I never used gradle, but having CMake installed in the system, I imagine including those commands in the configuring step should be straightforward.

[dljsjr]

@traversaro We vendor the ROS Package and preserve its directory structure in a resource directory that gets added to the Java classpath at runtime and then register "roots" with our model loader that correspond to the roots of the vendored packages. When our loader encounters a model:// URI in the .sdf we just attempt to resolve the URI against the various package roots that are registered, using whichever one succeeds first.

You can see this in action in the existing iCub repo by looking at the resources directory.

[dljsjr]

I'll start looking in to the stuff that @diegoferigo posted and try to have the latest model generated and vendored in some way today.