-
Notifications
You must be signed in to change notification settings - Fork 7
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
Deploy (some of) the models to Fuel #34
Comments
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
Thanks! |
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 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 |
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. |
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. |
Uploading the models to Fuel is relatively easy with the
ign fuel
command line provided byignitionrobotics/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.The text was updated successfully, but these errors were encountered: