tesseract-robotics / tesseract

Motion Planning Environment
http://tesseract-docs.rtfd.io
Other
264 stars 89 forks source link

SDF Loader #175

Closed johnwason closed 2 years ago

johnwason commented 4 years ago

I have started investigating loading SDF robot definition files and have found that the standard sdformat library that comes with Xenial and Bionic is very primitive and does not provide functionality beyond @Levi-Armstrong 's URDF parser. My suggestion is that we modify the URDF parser to be able to parse both URDF and SDF files since there is a lot of overlap. I will talk to RPI about assigning a student to this task. @Levi-Armstrong do you agree with this approach?

johnwason commented 4 years ago

Looping in @wlawler45 and @controlguy168

Levi-Armstrong commented 4 years ago

I think this is a good approach to support both for now. We did have a discussion at ROSCon about the future of URDF and should we migrate to SDF or and standard format like STEP, etc.. Based on the discussion I believe it maybe leaning toward SDF, but there is still more discussions to be hade, but for the sake of Tesseract I am on board with supporting both.

johnwason commented 4 years ago

After doing more research on SDF, it looks like there are some compatibility issues.

The first issue is the "world" and "model" concept used by SDF. SDF breaks up the scene into hierarchical units, with namespaces. For instance, the ljoint of a joint would be "my_robot::joint1" instead of a global name as in URDF. Models can contain models, allowing for nested designs. This is a cleaner design, but this model hierarchy is separate from the link/joint graph. Joints can jump across models, for instance attaching a gripper to a robot: http://gazebosim.org/tutorials/?tut=attach_gripper . In this example, the following joint jumps between models:

<joint name="hokuyo_joint" type="fixed">
  <child>hokuyo::link</child>
  <parent>simple_gripper::palm</parent>
</joint>

This format breaks the current scene graph design, and it doesn't look like subgraphs will help. (There is no way to attach properties to subgraphs, or query which subgraphs a vertex belongs to.)

The second issue is the frame semantics as described here: http://sdformat.org/tutorials?tut=pose_frame_semantics . (Note that the "frame" attribute and "frame" tag are not currently supported.) Frames are currently always defined in relation to the parent "model", not to the parent link/joint. This makes loading into tesseract more difficult.

Is SDF still the frontrunner for replacing URDF?

gavanderhoorn commented 4 years ago

The second issue is the frame semantics as described here: http://sdformat.org/tutorials?tut=pose_frame_semantics . (Note that the "frame" attribute and "frame" tag are not currently supported.) Frames are currently always defined in relation to the parent "model", not to the parent link/joint. This makes loading into tesseract more difficult.

I'm not entirely sure, but I believe (at least some of) this is being looked at: Pose frame semantics: proposed behavior (Discourse post here).

Levi-Armstrong commented 4 years ago

I looked into boost subgraph and it is just another adjacency list so is support its own subgraph properties. For example the subgraph name property could be the namespace. I think between the main SceneGraph and the addition of the SubSceneGraph we could accomplish the support for SDF. @johnwason If you kinda outline how you think a user need to interact with the main SceneGraph, example getSubGraphLinks, getSubGraphLinkName, ect. I will try and mock up another version of the SceneGraph that leverages boost subgraph.

johnwason commented 4 years ago

Because of the way the models and frames work, there are 2-3 overlapping graphs that describe the joint/link topology, model topology, and frame topology. I am not sure how we can capture that using subgraphs.

Levi-Armstrong commented 4 years ago

Do you know if there is a good diagram showing the structure of the different components for SDF?

johnwason commented 4 years ago

No, not that I have found. The functionality of SDF seems to be a work in progress. I am planning on writing a simple importer using Python for our use, so that may proved some insight. It will manage the models and frames outside of tesseract.

johnwason commented 4 years ago

Another possibility is to use boost::variant or have nullable properties attached to the vertex/edges in the graph, then filter for the scenario we care about. For instance, if we just want the joint/link graph we would filter out any vertex/edge that has null link/joint.

Levi-Armstrong commented 4 years ago

Are you planning to write your own parser or use the sdf library?

johnwason commented 4 years ago

The SDF library would be preferable, but we would need at least version 1.8. Version 1.6 which comes with Ubuntu doesn't really do much more than a typical XML library. Version 1.8 and higher fully parses the scene but will need to be built from source or use the OSRF APT repo.

If I write a parser in Python it will probably be custom.

johnwason commented 4 years ago

I have been looking into this again recently. @Levi-Armstrong do you mind if we add a newer version of libsdformat to tesseract_ext? Version 6 (included with ROS) is very limited, it doesn't parse out all the various elements. The current Version 9 parses the entire scene and would be relatively easy to load into tesseract.

https://bitbucket.org/osrf/sdformat/src/sdformat9_9.1.0/

Levi-Armstrong commented 4 years ago

I do not have an issue.