Error loading meshes from a relative folder for urdf models
osrf-migration opened this issue · 5 comments
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 ofSDF_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
meshessubfolder of the model’s directory). - A
model.configfile 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
Original comment by Diego Ferigo (Bitbucket: dgferigo).
- Edited issue description* set version to "1.5"
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.
I have been encountering this issue when trying to load URDF/SDF files. The parser should simply ignore these tags in that case?
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.
Is this fixed by #1213 ?