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

URDF parsing support for ROS 'package:/' semantics #271

Closed
mxgrey opened this issue Nov 23, 2014 · 3 comments
Closed

URDF parsing support for ROS 'package:/' semantics #271

mxgrey opened this issue Nov 23, 2014 · 3 comments
Milestone

Comments

@mxgrey
Copy link
Member

mxgrey commented Nov 23, 2014

URDF files tend to use a "package:/" keyword in file names to indicate that the path is relative to the current package directory. This is tied into ROS's catkin packaging system.

Currently, DART's urdf parsing utility does not support any files that use this method for describing file names. Presumably the "best" way to handle the "package:/" keyword would be to do whatever ROS does to resolve package names. However, I have no idea what exactly that would entail. I would guess it might require a ROS master to be running or to attempt to parse the user's filesystem for a package.xml and try to figure out packaging information by reading those metafiles. Whatever the case, it's currently a mystery and probably not worth solving at the moment.

As a stopgap solution, I've added a function to the dart::utils::DartLoader for URDFs that allows the user to manually specify the package directory path. If the "package:/" keyword is found in a filename, it will be replaced with the user-specified directory path. Otherwise, it will behave as it used to. If a URDF uses the "package:/" keyword but the user has not specified a package directory, a warning will be printed (and the program will most likely segfault).

The commit with these changes is available here: 9900053

Also note that this commit will print out a warning if assimp failed to load a file. Previous behavior was to simply segfault with no indication of why.

I tested the operationalSpaceControl app with this commit (because it uses URDFs), and it is still loading URDFs without a problem.

@jslee02
Copy link
Member

jslee02 commented Nov 23, 2014

The stopgap solution looks good to me. Actually, I've just removed all the package:// suffix in the mesh file paths.

Could you create a separate pull request for this (not included the previous changes pertain to the name manager) ?

@jslee02
Copy link
Member

jslee02 commented Nov 23, 2014

SDF parser also have similar problem. SDF has <model> tag and the path includes model:// suffix.

As a long term plan, it would be good to have a path manager like gazebo has.

jslee02 added a commit that referenced this issue Nov 24, 2014
stopgap measure for handling use of 'package:/' in URDFs for #271
@jslee02
Copy link
Member

jslee02 commented Nov 25, 2014

Fixed by #273

@jslee02 jslee02 closed this as completed Nov 25, 2014
@jslee02 jslee02 added this to the Release DART 5.0 milestone May 23, 2015
@jslee02 jslee02 modified the milestones: Release DART 4.3, Release DART 5.0 Jun 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants