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

Correctly process meshes in URDF models #28

Closed
traversaro opened this issue Aug 20, 2016 · 3 comments · Fixed by #47
Closed

Correctly process meshes in URDF models #28

traversaro opened this issue Aug 20, 2016 · 3 comments · Fixed by #47

Comments

@traversaro
Copy link
Member

We need to correctly process meshes of generated URDF models.

One of the problems to solve is that the URDF format [1] does not describe the semantics of the filename attribute, that is used to specify external meshes in Collada or STL format.
In practice, most URDF released as part of ROS packages specify the meshes location using the package:// URI, that are resolved to absolute filenames using ROS' resource_retriever.

Clearly this is not a viable strategy for libraries that do not depend on ROS, and want to load arbitrary URDF files. Unfortunatly mesh handling without using ROS is not uniform across different libraries.
Some (such as Google's Bullet ) just support meshes specified w.r.t to the model subdirectory using the format filename="meshes/mesh.dae", but I guess a model of that kind would not be supported by ROS tools.

Another problem is if we want to share the same meshes among the different models of if we want to duplicate them by copying them in each robot directory.

[1] : http://wiki.ros.org/urdf/XML/link

@traversaro
Copy link
Member Author

This is a problem blocking the use of iCub's models for several workflows.

I tried to investigate a bit and I found several approaches handling this problem, both in libraries consuming URDF files and in people distributing URDF models outside ROS packages .

  • Bullet : meshes are specified w.r.t to the model subdirectory using the format filename="meshes/mesh.dae" .
  • TODO

@traversaro
Copy link
Member Author

Due to this, we are duplicating the meshes of the iCub in several places:

  • mex-wholebodymodel
  • Dani's secret project

Keeping track here of all the repo that we need to clean once this is fixed.

@traversaro
Copy link
Member Author

I think I converged to a solution that I found reasonable, and should be compatible with ROS and its package:// URI:

  • For each YARP_ROBOT_NAME, the appropriate model is installed in <prefix>/share/iCub/robots/${YARP_ROBOT_NAME}, consistently with the specifications for robot-specific configuration files in YARP : http://www.yarp.it/yarp_data_dirs.html#datafiles_contextsrobots . Note that we use the location share/iCub consistently with the configuration files installed by https://github.saobby.my.eu.org8 /robotology/robots-configuration .
  • We install a package.xml file in <prefix>/share/iCub, and we document that after the installation you need to add <prefix>/share/iCub to the ROS_PACKAGE_PATH env variable, so that the iCub directory is recognized as a ROS Package. Note that in theory it should be sufficient to make sure that .catkin file is present in <prefix>/share/iCub and that belongs to CMAKE_PREFIX_PATH (see https://github.com/gerkey/ros1_external_use#installing-for-use-by-tools-like-roslaunch) but I was unable to get rospack to work without the ROS_PACKAGE_PATH env variable set.
  • We install the meshes in <prefix>/share/iCub/meshes/upmc/<..>.dae for the meshes generated by UPMC, and in <prefix>/share/iCub/meshes/simmechanics/<..>.stl for the meshes generated by simmechanics. The meshes will be then referred in URDF using the URI package://iCub/meshes/upmc/<..>.dae for upmc meshes and using the URI <prefix>/share/iCub/meshes/simmechanics/<..>.stl for simmechanics meshes. This will permit to keep only a copy of the meshes for all the models. Furthermore, we need to modify iDynTree to resolve package:// URIs using the ROS_PACKAGE_PATH env variable.

traversaro added a commit that referenced this issue Mar 21, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Meshes are being properly processed for years: #28 .
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant