Deploy (some of) the models to Fuel

[diegoferigo]

Uploading the models to Fuel is relatively easy with the ign fuel command line provided by ignitionrobotics/ign-fuel-tools. The big advantage of doing so is that SDF worlds with, say, iCub can be distributed without the need to distribute also the urdf and, more importantly, meshes. The resources are downloaded automatically the first time the world is loaded in the simulator.

Practically, we can extend the PyPI deployment to also deploy to Fuel. I'm not sure urdf models are supported. For sure a model.config must be present and must fix the minimum sdf version. I fear that gazebosim/sdformat#227 will hit us back. In case of problems, we can take advantage of the URDF -> SDF conversion logic implemented in #32.

I created the robotology organization, @traversaro let me know if you want to create an account and become owner (to minimize bus effect).

On the long run, it would be nice moving the iCub model to the official robotology/icub-models, but it is currently blocked by robotology/icub-models#33.

[traversaro]

I personally prefer to avoid having iCub models on Fuel, unless we have a strong reason for doing that. The main problem that I see is that for actually using the iCub models you also need some plugins (depend on which software you are using) and with Fuel that is not possible to express this information. Even worse, sometimes there is a strong coupling between a given icub-models version and the relative gazebo-yarp-plugins version (for example, a new version of icub-models may require a specific version of gazebo-yarp-plugins, and this can't be encoded on Fuel). For this reason and for avoiding confusing users on the "single source of truth" for iCub models (that is https://github.com/robotology/icub-models, there has been confusion on this in the past, see robotology/icub-models-generator#29 (comment)) I would prefer to avoid having iCub models on Fuel, unless there is a specific use case for that.

I created the robotology organization, @traversaro let me know if you want to create an account and become owner (to minimize bus effect).

Thanks!

[diegoferigo]

While I agree that uploading iCub models to Fuel needs discussion and we can omit it from the deployment for the moment, I don't entirely agree that we should not do it because YARP users cannot directly use them in their simulations.

I think that, as you already summarized time ago in robotology/icub-models#33, we should have composable models. The base model should be what comes out from the automatic generation from the CAD model (matching the real robot). Then, if we can make a single SimulatedICubV2_5 with modified inertias and contacts workarounds that works on our supported simulators (AFAIK only Gazebo Classic, but it could be extended to Ignition Gazebo and pybullet) would be ideal. Then, the final Gazebo Classic model could add the plugins.

The main problem I see is that, for Gazebo Classic, the context of the yarp plugins is very big, and plugins need to know the location of all the sensors from the CAD. This means that this peace of information should come from out from the pipeline. It is a big task and I think that icub-tech should get deeply involved. For this reason, I agree to postpone it to a later moment.

This does not mean that a plain iCub model cannot be uploaded to Fuel. Other users may want to use it in their preferred simulator and extend it with their plugins, that could be ROS based or whatever. If we want to make this deployment unofficial waiting to clear our minds about how we want to proceed with iCub, we can agree that I can use my personal account instead of robotology. Does it sound good? We can even discuss it in the next periodic update meeting.

[traversaro]

This does not mean that a plain iCub model cannot be uploaded to Fuel. Other users may want to use it in their preferred simulator and extend it with their plugins, that could be ROS based or whatever.

Yes, the problem here is composability. If you have base model without plugins and then two or more composite models (let's say iCub+Ignition Gazebo+ROS and iCub+Gazebo Classic+YARP) you will have basically this dependency structure:

(source: icub_models_dependency_examples.pptx )

All this software and assets packages can be distributed as you may prefer (apt, conda, superbuild, spack, nix, whatever). What I think instead is tricky to maintain, confusing for users and error-prone is to have some components of this dependency tree distributed with another custom distribution mechanism (Fuel), as I think there is the high risk that users will mix the two (even because "Fuel installation" is not an explicit action of the user, but rather an implicit side-effect of loading a model or a world.

However, if there are specific use cases, I think we can discuss face2face.

[diegoferigo]

Right now I don't personally have the need of having the iCub model on Fuel, and this is also the reason why I opened an issue instead of a PR :) We can leave it here in the backlog until a real use case emerges.