gazebosim / sdformat

Simulation Description Format (SDFormat) parser and description files.
http://sdformat.org
Apache License 2.0
162 stars 91 forks source link

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

Open osrf-migration opened 4 years ago

osrf-migration commented 4 years ago

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:

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 commented 4 years ago

Original comment by Diego Ferigo (Bitbucket: dgferigo).


osrf-migration commented 4 years ago

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 commented 3 years ago

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

FirefoxMetzger commented 3 years ago

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 commented 1 year ago

Is this fixed by https://github.com/gazebosim/sdformat/pull/1213 ?