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

Error loading meshes from a relative folder for urdf models #227

Open
osrf-migration opened this issue Feb 3, 2020 · 5 comments
Open

Error loading meshes from a relative folder for urdf models #227

osrf-migration opened this issue Feb 3, 2020 · 5 comments
Labels
1.5 bug Something isn't working major URDF URDF parsing

Comments

@osrf-migration
Copy link

Original report (archived issue) by Diego Ferigo (Bitbucket: dgferigo).


Description

If an urdf file has meshes defined with relative path wrt the model file (support introduced in sdformat#558), the meshes are not found.

The setup is the following:

  • A world file with a ground plane and an <include><uri> of the model file (the model’s parent folder is part of SDF_PATH). The world file is in an external folder far away from the model / mesh files.
  • A urdf model that uses relative path to the mesh files (mesh files are inside a meshes subfolder of the model’s directory).
  • A model.config file in the same folder of the urdf model that loads the urdf with: <sdf>icub.urdf</sdf>.

Opening the world with ign gazebo /path/to/include_model.world fails producing errors about meshes not found:

[Err] [SystemPaths.cc:428] Could not resolve file [urdf file/meshes/simmechanics/sim_sea_2-5_root_link_prt-binary.stl]
[Err] [MeshManager.cc:172] Unable to find file[urdf file/meshes/simmechanics/sim_sea_2-5_root_link_prt-binary.stl]
[...]
[GUI] [Err] [SystemPaths.cc:428] Could not resolve file [urdf file/meshes/simmechanics/sim_sea_2-5_root_link_prt-binary.stl]
[GUI] [Err] [MeshManager.cc:172] Unable to find file[urdf file/meshes/simmechanics/sim_sea_2-5_root_link_prt-binary.stl]
[GUI] [Err] [MeshDescriptor.cc:56] Mesh manager can't find mesh named [urdf file/meshes/simmechanics/sim_sea_2-5_root_link_prt-binary.stl]
[GUI] [Err] [OgreMeshFactory.cc:422] Cannot load null mesh
[GUI] [Err] [SceneManager.cc:290] Failed to load geometry for visual: base_link_fixed_joint_lump__root_link_visual
[...]

However, if I convert the urdf to sdf with ign sdf -p model.urdf > model.sdf, and modify the model.config to load the sdf, the meshes are found correctly.

Versions

I’m on ubuntu 18.04 with sdformat and ign-gazebo compiled from sources.

Additional Information

The meshes folder is not on purpose inside IGN_FILE_PATH. If I add the folder to the env variable, meshes are found also in the urdf case (but the main point is that is should work also without this env var).

It seems to me that the relative path support for meshes works only if the model is already a sdf model. If, instead, the model is an urdf that needs to be converted, the link to the meshes cannot be resolved. I suspect that, since the conversion happens inside sdformat code, the folder where the original urdf code is located is somehow ignored and it is not included in the search path for meshes.

cc @chapulina

@osrf-migration
Copy link
Author

Original comment by Diego Ferigo (Bitbucket: dgferigo).


  • Edited issue description* set version to "1.5"

@osrf-migration
Copy link
Author

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).


suspect that, since the conversion happens inside sdformat code, the folder where the original urdf code is located is somehow ignored and it is not included in the search path for meshes.

That is correct. The URDF is first converted into a string and then passed to the SDF parser, so we lose it's file location on the way. Supporting relative paths inside URDF files would require propagating that file location somehow.

@varunagrawal
Copy link
Contributor

I have been encountering this issue when trying to load URDF/SDF files. The parser should simply ignore these tags in that case?

@FirefoxMetzger
Copy link
Contributor

The parser should simply ignore these tags in that case?

This sounds dangerous; it seems non-trivial to predict what will be lost in the process (it would depend on the model), and silently ignoring tags with paths that can't be resolved may yield very unpredictable and surprising behavior on the user side.

Would adding a new attribute called source="" that is added to <include>-ed tags help? This way, there would always be a reference to where the tag originated from, which can be used downstream to resolve relative paths.

@traversaro
Copy link
Contributor

Is this fixed by #1213 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.5 bug Something isn't working major URDF URDF parsing
Projects
None yet
Development

No branches or pull requests

5 participants