Closed gavanderhoorn closed 8 years ago
@phvass: is having to place packages containing URDFs on the package path / in the same workspace as the editor an acceptable restriction for M1?
That seems reasonable to me. Thanks! PH
Ok. We'll have to document this clearly then.
Then I'll leave this assigned to milestone Untargeted for now.
A possible solution might be to (temporarily) change the ROS_PACKAGE_PATH
environment variable for the process (or at the least for the RobotStateDisplay
instance used internally). If it includes the location(s) of the needed package(s), loading should work.
This will probably require parsing the urdf/xacro before it is loaded by the rest of the application, as all packages referenced by the model would need to be added to the lookup path.
An alternative would be to replace / augment the way the used ROS components interact with the resource retrieval system, or provide an alternative implementation that does not require a (complete) catkin workspace.
I'm going to close this for now, as it is a limitation that is acceptable for this Milestone.
We can re-open if/when this can be addressed in a future Milestone.
For urdfs: none of the geometry will be loaded (and loads of error messages will be produced), resulting in empty visualizer (though the kinematic structure is there, as can be seen in the tree widget).
For xacros:
include
tags would not work, leading toxacro
failures and no urdf output.Essentially anything starting with
package://
will fail to resolve, as rospack will not know where to find packages, unless they are on theROS_PACKAGE_PATH
.This is not necessarily a bug, but it is something that is definitely a limitation of the current implementation.
I have labelled it as a bug though, as loading arbitrary urdfs would be something I can see users expecting to work, regardless of their location.