URDF / SDF in 2.0

[Shawn Schaerer]

Hi,

Are there any plans on changing the URDF format or perhaps migrating to Gazebo's SDF?

It would be great to understand what the plans are for URDF.

Thanks

[William Woodall]

That's an open question, but there is no plan as part of ROS 2 right now. I've not found the time to champion this discussion, but it is certainly something we need to figure out as a community. And the proposition of changing away from URDF to something like SDF or something else really makes the current migration concerns look like small potatoes in my opinion. Realistically a change in URDF needs to happen in ROS 1 as well as ROS 2, so that there can be some opportunity to change robot descriptions separately from changes related to ROS 2.

In addition to SDFormat (http://sdformat.org/) there's also SRDF: http://wiki.ros.org/srdf

As well as SMURF: https://github.com/rock-simulation/smurf_parser

And I'm not sure it's ready for public comment, but I know Sachin Chitta has been thinking about changes that might be made to URDF: http://sachinchitta.github.io/urdf2/

I think there's clearly a need to move towards a consensus and now is as good of a time to start the discussion.

--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/

[Jon Binney]

+1 for having this discussion.  My personal view is that having a single format is more important than any particular feature of a particular format, and so I'd be happy to see us converge to any of these. That said, we should put some serious thought into it.

Some folks from the gazebo side will need to be involved in this discussion too, I imagine. Whatever  format is chosen, it will be important that both ROS and Gazebo commit to continuing to use that same format, and being backwards compatible.

Jon

[Shawn Schaerer]

William,  thanks for the SMURF link.

Yes, I agree that there should be one format.  I have reached out to the ROS-I community to see what their plans are as well.

Hopefully we can move this forward!

Shawn

[Robert Dean]

somewhat ironically, I am about to add loading of a URDF type file into our R&D architecture(s).  so a quick outcome of this discussion is obviously of interest to me.  from the links provided it seems that SDF is the format that i want due to support for sensors. The urdf2 link says that sensors are not supported by URDF, but there seems to be a non-maintained sensor extension. recommendations?

are there converters to and from the formats listed above? or do i need to whip up my own with ruby?

In theory i could implement a version of URDF2 as described.  this would allow leverage of the existing .urdf formats.

on another note, opening the sdfformat.org link works, but when clicking through to the final tutorial or api page they seem to all refer to links such as http://sdf.com/wiki/tutorials which returns a server not found error.

[William Woodall]

Robert,

I believe it's sdformat.org (not sdfformat.org), and I'm not sure what link you're talking about, as I cannot find the page which links to sdf.com as you've described (we don't have sdf.com). Can you link to the page which has the broken link?

Thanks,

[Robert Dean]

you are correct i typo'd an extra f in. 

sdformat.org > API > dev > tutorials  results in a page not found error.

-Bob

[Shawn Schaerer]

I am also looking at using Collada (openRave) as a format for our system.  There is a Collada to URDF converter (seems broken) which would work.

Alternatively we could write a SDF to URDF package.

I don't think that there will be a quick outcome to this conversation.  William pointed out that this would be a large effort.

I hope that we could quickly move this from conversation into actionable tasks.

Shawn

[David Lu]

For completeness, there is some discussion on slack as well. 

https://rosorg.slack.com/messages/robot-description/

[Shawn Schaerer]

is this an open discussion on Slack?

--
You received this message because you are subscribed to a topic in the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ros-sig-ng-ros/nUvtYnTRQGg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ros-sig-ng-ro...@googlegroups.com.

[Brian Gerkey]

<rant>
Closed proprietary communication systems are the tool of the devil.
Did we learn nothing from the failed walled gardens of AOL and
friends?
</rant>

[David Lu!!]

if(open==(unfinished or welcoming_participants))
return yes
else if(open==viewable_without_slack_account)
return no
else
return maybe

On Thu, Dec 10, 2015 at 12:35 PM, Shawn Schaerer

[Shawn Schaerer]

For completeness it would be great for someone to repost the discussion on here :)

[Jackie Kay]

yeah, we (I) set up a portal for auto-registering yourself for the Slack, which you have to go through as a first time user.

https://ros-org-slack.herokuapp.com/

but, as Brian warns, you must hand over your soul and freedom to the demonic corporate overlords by creating a Slack account first!

If you don't want to do that, here's my summary of the discussion:

l0gix: Why do URDF and SDF both exist?

David Lu: "My dream has always been for a single format with multiple levels of compliance"

both: we need to support kinematic loops in URDF because of 4 bar linkages!

me: Pixar has a thing they want to open source: http://tech.slashdot.org/story/15/08/10/2212214/pixars-universal-scene-description-to-be-open-sourced

Ian McMahon: we want to dynamically reload robot_description, there are various issues ticketed for this: https://github.com/ros/robot_state_publisher/issues/29

my addendum (not on slack): dynamically reloading the robot description is an implementation detail of the surrounding tools for managing the robot description, but not inherent in the format itself

[Jackie Kay]

Shawn, I think we sent our emails at the same time; let me know if you want more detail than what I provided above.

Since Tully is working on porting tf to ROS 2 in the upcoming release cycle, I think it's the appropriate time to start the discussion about this, since tf is a dependency for robot model parsing tools.

The robot description format is orthogonal to the core communication components that we are focusing on right now. So these areas can be worked on in parallel. ROS 2 could be an opportunity to migrate to a new, better format, but we can also write tools for backwards compatibility to URDF.

It would be great if someone from the community could volunteer to write an in-depth article on the direction we should go with robot description formats in ROS 2 and make a pull request to the design repo, similar to what Geoff did for node lifecycle: https://github.com/ros2/design/pull/34

Such an article would probably include a comparison of the features, pros and cons of URDF, SDF, existing extensions such as SMURF, mention Collada and other CAD export formats. It would also answer questions such as:

1. Do we have to roll a completely new format?

2. Or should we instead make major improvements to an existing thing (i.e. URDF2?)

3. Should we make a full switch to an existing alternative?

4. What are some implementation details? How would xacro 2.0 be implemented in light of the changes the description formats?

5. What are some requirements of the tools for parsing the new/improved description format? How does the robot description behave as a parameter; how do nodes process changes to the robot description? (Could be another article in itself.)

Are there any takers for this task?

We should also engage Sachin, Kai, and the Gazebo folks (Nate, John Hsu, and/or Steve, who I believe is on this list), in the discussion.

[Shawn Schaerer]

Hi Jacky,

Thanks for the link,  I have given my data away to the corporate overlords ;)

I am up for this task.  I have reached out to William about championing it and Sachin and Jonathan M fro SWR ROS-I 

This is part of what I am doing right now for the system I am working on, so it seems like a fit.

Shawn

[Steven Peters]

One fundamental difference between URDF and SDF is the data structure.

URDF models a single robot as a tree
* there are planning and control algorithms that benefit from robots in a tree structure
* it can't do closed kinematic chains (like 4-bar linkages)

SDF models one or more robots as a graph
* so it can do closed kinematic chains
* if your robot is tree-like, then storing it in SDF makes it lose information

There's other issues as well that Sachin has summarized on his urdf2 page: http://sachinchitta.github.io/urdf2/

I think the data structure deserves a prominent place in the discussion.

Steve

[Steven Peters]

Thanks Bob, I just forwarded it to internal list and we will fix sdformat.org
Steve

[Sachin Chitta]

Sorry - this is not to the point of this thread but could not let this slide - why is TF a dependency for robot model parsing tools? It should not be. The only reason it seems to be is the use of tf::Transform in collada_to_urdf.cpp. That should probably just be done with Eigen or even urdf::Pose if it even needs to be there. 

Architecturally - that just feels wrong. robot model should be at the bottom of the stack with minimal dependencies on other stuff. In MoveIt!, we worked hard to move away from using TF everywhere.

Sachin

[Bob Dean]

+1 for dependency reduction.

Sent from my iPhone

[Jon Binney]

Steve,

Good point about it being important to decide whether or not to model things as a tree. Most discussions I've had with people about SDF vs. URDF have focused on this. Sachin's website that you link to suggests using a tree but allowing nodes to have multiple parents - are there any major downsides to that?

Jon

[Steven Peters]

Is it still a tree if a node has multiple parents?

[Jackie Kay]

definition of a tree: a directed, acyclic graph. https://en.wikipedia.org/wiki/Directed_acyclic_graph

As you can see in the illustration on that page, there are several nodes with multiple parents (e.g. node 10, node 9)

but after speaking with John Hsu briefly and confirming with the current implementation, a link is not allowed to have multiple parents in URDF.

Allowing nodes with multiple parents would indeed enable the implementation of kinematic loops (e.g. 4 bar linkages).

However this will still make writing kinematic/dynamic solver software complicated. I have very little experience with this myself, so I'm speaking purely out of intuition here. But allowing links with multiple parents allows the number of joints is allowed to be equal to or greater than the number of links, whereas the current situation in URDF when there are no kinematic loops means that there is always one more link than joint. Thus it changes the solution space of inverse kinematics solver algorithms.

I believe the is the historical reason why URDF does not allow kinematic loops is because KDL doesn't support them, and I believe KDL doesn't support them because of the reason I described above, but I could be wrong. Please, someone with more experience with KDL or motion planning theory than me, correct me if I'm wrong.

Not to say that solving these kinds of problems is impossible, after all, ODE can handle solving 4-bar linkages.

[Jon Binney]

Yes, I shouldn't have said "tree", but instead "directed graph". I think the majority of use cases will still be true trees (as all URDFs currently are) so we could have a fast default kinematics solver for trees, but require people to use something a bit more complex if they really need loops in their model.

If I understand correctly, in addition to allowing loops, SDF defines coordinates in the root frame for each link, right? Whereas URDF defines coordinates relative to the parent link. (Someone correct me if I'm wrong, I haven't looked deeply at SDF). This is slightly different than the tree vs. directed graph distinction. If URDF allowed multiple parents for a single link, what coordinate system would that child link be defined in?

Jon

[Jackie Kay]

That is correct, although SDF recently added a feature to specify a "frame" attribute in a "pose" element, which specifies the reference frame of the pose.

https://bitbucket.org/osrf/gazebo_design/pull-requests/23/sdf_reference_geometry/diff
https://bitbucket.org/osrf/sdformat/pull-requests/237/support-frame-specification-in-sdf/diff

I like this more generalized approach myself.

[Jon Binney]

Yeah, that does sound like a nice way to combine the benefits of both approaches.

[Jackie Kay]

On a different topic, here's my musing on the architecture of robot model tools...

here's an outline of the stack as it exists right now (kinda):

Robot description schema: describes the elements, hierarchy and behavior of the format.

Schema parser: converts the description file into data accessible by a C++, Python or other API. Example: urdfdom

External formats parser/converter: convert the description file into another format, or convert it to an external API representation. Example: collada_parser, kdl_parser
State publisher: Combines information about the robot's kinematic state with its static description for forward kinematics and publishes that over the network. Example: joint_state_publisher and robot_state_publisher.

and more...

The guidelines for writing these tools in ROS 2 should be (these may seem like no-brainers, but as Sachin pointed out they are not followed in the robot_model repository currently):

We should stick to one internal API representation used by ROS-specific tools such as the ROS 2 equivalents of Rviz, MoveIt, state_publisher. Let's call that the URDF 2 API for now.

Compatibility libraries with other standards like URDF 1.0, SDF, etc. should convert from these external formats to the URDF2 API. They should not have ROS communication-specific dependencies anywhere in the dependency tree.

Similarly, tools higher in the stack should not have knowledge of external parser libraries (e.g. collada_parser). The URDF 2 API should be general/powerful enough to represent the other supported formats, so parsing the raw representation of another format should not be necessary.

^ The argument against this is when there is a library that does not use the URDF 2 API but is necessary for higher-level calculations, such as needing KDL in MoveIt. But KDL is not a description format, it is another API. kdl_parser is a package for parsing URDF and converting it into a KDL representation. I think the reduce redundancy kdl_parser should just be kdl_converter, and is simply a shim that converts a URDF API representation to KDL (and vice versa).

(this idea is a bit crazier)

Tools up in the stack can parse the robot description from a parameter in xml format, ROS-1 style, OR they can use intra-process communication (probably an intra-process service) to access a unique_ptr to the API representation of a robot model to skip the parsing step (useful if there are several nodes in the same process sharing a robot description, so that each of those nodes doesn't have to duplicate the parsing step). Using this intra-process access trick, you could inject one of the external parsing libraries into the same process as one of your tools and share it without that tool having any knowledge of collada, SDF, etc.

[Steven Peters]

The sdf "frame" attribute will allow allow sdformat to look more like URDF in terms of how links and joints are defined.

After learning some vocabulary on wikipedia, I will disagree slightly with Jackie, in that I think URDF is currently using "directed rooted trees" ( https://en.wikipedia.org/wiki/Tree_(graph_theory) ) and not directed acyclic graphs.

I think the preference for a specific data structure may depend on the application (motion planning vs simulation). Perhaps a more general format would be a graph with sub-elements that are marked as trees?

[Jon Binney]

Would it be necessary to explicitly mark sub-elements as trees? This could be detected on the fly pretty easily. A naive algorithm would traverse the graph depth first, storing a set of all visited nodes. If a node showed up a second time, then it isn't a tree. Should be O(n^2) for n nodes even with a naive set implementation that does a linear search for a node.

[Steven Peters]

I think it could be optional to make sub-elements as trees, depending on the application. For example, for simulation with maximal coordinates, tree information is not used, so it would be easier to just define the model as a graph (similar to how SDF is currently implemented).

Also, there could be some tools that try to find sub-trees within a graph. Currently, we have some parsing like that in Gazebo's simbody interface that is used to break kinematic loops. It would be nice to write a library that could do this parsing so it doesn't get re-implemented frequently. Or, some offline URDF processing tools could be used for tools that don't want to do online URDF massaging.

[Daniel Stonier]

On 11 December 2015 at 04:25, Steven Peters <scpe...@osrfoundation.org> wrote:

One fundamental difference between URDF and SDF is the data structure.

URDF models a single robot as a tree
* there are planning and control algorithms that benefit from robots in a tree structure
* it can't do closed kinematic chains (like 4-bar linkages)

SDF models one or more robots as a graph
* so it can do closed kinematic chains
* if your robot is tree-like, then storing it in SDF makes it lose information

 

What does it lose?

--

Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/

Yujin Inno: http://inno.yujinrobot.com/

[Jon Binney]

The coordinate-frames-not-relative-to-parent thing was my main gripe with SDF; I'm glad to hear that there's a way to handle that now. I think I'd be pretty happy if ROS2 just adopted SDF it was tweaked in small (hopefully in backwards compatible) ways as needed. I would be extremely happy to have a single format and not have to convert back and forth.

As for semantic information such as "what groups of joints are commonly motion-planned as a group", that seems like it belongs in a separate file (like the SRDF), but that's just a gut feeling.

[Daniel Stonier]

On 11 December 2015 at 11:15, Jon Binney <jon.b...@gmail.com> wrote:

The coordinate-frames-not-relative-to-parent thing was my main gripe with SDF; I'm glad to hear that there's a way to handle that now. I think I'd be pretty happy if ROS2 just adopted SDF it was tweaked in small (hopefully in backwards compatible) ways as needed. I would be extremely happy to have a single format and not have to convert back and forth.

This is similar to what I feel. A single format, or at least a very good conversion process so that moving between robot and simulation is as productive as possible rather than, at times, painful.

Is there a fundamental reason that robot simulation and robot runtimes need a different specification?

If there isn't, I don't see any practical reason that we might not achieve this goal. The usual stumbling blocks are because of collaboration difficulties or unaligned goals. However both groups - Gazebo and ROS should not have any significant problems here. If this is to go forward, we need the Gazebo guys active in this discussion. Can we get them in here, or move this discussion to a place where they can become actively involved?

As for semantic information such as "what groups of joints are commonly motion-planned as a group", that seems like it belongs in a separate file (like the SRDF), but that's just a gut feeling.

+1 - I have the same feeling. I worry that this specification which hopes to be compatible with all other formats might become a borg.

Daniel.

--

[Shawn Schaerer]

We also have the same thoughts on this, and would like to have one format for everything.  I do not see a reason that we need to have two different formats for sim and real robots, but maybe I am missing something?

I think we should try and have consensus from as many of the groups as possible.  We should get the ROS, Gazebo, ROS-I and MoveIt groups involved.

Shawn

[Nikolaus Demmel]

One more point on the tree vs graph discussion: The current implementation of TF, in particular the algorithm for lookups, relies on the fact that the TF tree is actually a directed tree with all nodes pointing towards a single root. If in the robot description format this is weakened to a directed acyclic graph or even a cyclic graph, either tools like robot_state_publisher need to (deterministically?) convert the graph structure, or the TF implementation will need to be changed (which apparently had been considered and rejected before, AFAIK for reasons of a simple and fast implementation).

So I guess the problematic part of the robot-model and tf interdependencies is not so much how the current parser uses (apparently) some part of the TF library, but rather that the data structures and algorithms in TF (currently) rely on properties of the robot description.

Some links:

http://wiki.ros.org/tf2/Design#The_system_doesn.27t_need_to_know_about_the_configuration_before_hand_and_can_handle_reconfiguring_on_the_fly
http://wiki.ros.org/tf2/Design#The_direction_of_the_graph_can_be_confusing
http://article.gmane.org/gmane.science.robotics.ros.user/430/match=directed+graphs+and+tf+frames

[Steven Peters]

I'm one of the Gazebo developers at OSRF, and I've forwarded this thread to our internal sim mailing list. We are paying attention. John Hsu and Nate Koenig (cc'd) have some thoughts and may chime in at some point.

[Steven Peters]

On Thu, Dec 10, 2015 at 6:15 PM, Daniel Stonier <d.st...@gmail.com> wrote:

On 11 December 2015 at 04:25, Steven Peters <scpe...@osrfoundation.org> wrote:

One fundamental difference between URDF and SDF is the data structure.

URDF models a single robot as a tree
* there are planning and control algorithms that benefit from robots in a tree structure
* it can't do closed kinematic chains (like 4-bar linkages)

SDF models one or more robots as a graph
* so it can do closed kinematic chains
* if your robot is tree-like, then storing it in SDF makes it lose information

 

What does it lose?

Expressing a directed tree as a graph loses specificity about the structure. As noted by Nicholas Demmel later in this thread, this can be problematic for tf and other code that needs a directed tree to function. So your robot may still be a directed tree and tf-compatible, but if it's stored in a graph data structure, then it won't be usable.

[Nate Koenig]

URDF and SDF are very similar, and a single format would be useful for everyone involved. 

SDF shameless plug follows:

1. Support for closed loops. With the addition of reference frames, you can create models in a very flexible manner.

2. A rich set of parameters (sensors, surface properties, materials)

3. A complete environment (world) can be represented, in addition to individual robots.

4. Old versions of SDF are automatically converted. For example, a model represented using SDF 1.0 will work with a program that use SDF 2.0.

5. It's terribly easy to add new elements to SDF without breaking API/ABI

6. Conversion of URDF to SDF exists in libsdformat, and a bit of development code exists for the reverse operation.

I was looking at the URDF2 site (http://sachinchitta.github.io/urdf2/) to see what is lacking in SDF. I'll respond to the list of cons on that site:

1. The SDF has several simulation specific parameters.

    True. If an application doesn't need the parameters, then it is safe to ignore them.

2. It does not support groups.

    I'm not a URDF expert, but my understanding is that this is meta-information about collections of elements. It might be useful to keep this in a separate file.

3. The SDF is designed to support simulation worlds. The URDF was designed to support a single robot.

    An individual model, in a stand-alone file, can be represented in SDF. Gazebo's model database relies on this.

4. The SDF has no support for specifying hardware parameters.

    Great, let's add it to SDF.

5. The SDF cannot be exported from any CAD software today (AFAIK).

    A solidworks to SDF exporter exists: http://wpilib.screenstepslive.com/s/4485/m/23353/l/349026-exporting-a-solidworks-model

    We are also developing a graphical SDF model builder.

A migration path *mostly* exists for URDF->SDF. There would be some pain transitioning, but it could happen slowly. I imagine there would be an equivalent amount of pain moving to URDF2, which looks like it'll bring in most of the features in SDF.

-nate

[Bill Morris]

On 12/11/2015 04:51 PM, Steven Peters wrote:
> Expressing a directed tree as a graph loses specificity about the
> structure. As noted by Nicholas Demmel later in this thread, this can
> be problematic for tf and other code that needs a directed tree to
> function. So your robot may still be a directed tree and
> tf-compatible, but if it's stored in a graph data structure, then it
> won't be usable.

Can't a directed tree be stored as a directed graph?
Would it be possible use something like an alt tag/element to provide an
directed tree version of a kinematic loop, for read-only things like TF?

Given ROS 2.0 support for multiple robots, it seems to me that we are
going to need at least some support for graphs.

[Steven Peters]

I think subsets of a directed graph could be marked as directed trees (and a validator could easily detect if this was incorrect). I think this would keep the status quo functionality for TF without too much extra work. Though it seems simple, I mention it because sdf doesn't yet have an annotation for directed tree subsets of a graph.

Handling robots with kinematic loops in TF and MoveIt is a little more complicated since that will require algorithmic changes or approximations. I think the `mimic` tag was related to handling loops?

[Bill Morris]

I was thinking it could actually work the other way.
Subsets could be marked as a directed graph/kinematic loop, but the
default would be to consider it a directed tree stored inside a directed
graph.

[Shawn Schaerer]

Nate,  Thank you for the response to the SDF deficiencies.

Ideally, I would like to see only two file types, SDF(or what ever format is agreed upon) and Launch files.

It would be great if we could put the YAML configuration data in SDF.

Is there any work on an SDF to URDF right now?

[Paul Hvass]

Hi Nate,

Can you point us to any documentation/progress on the SDF model builder?

Thanks!

Paul Hvass

On Friday, December 11, 2015 at 6:00:49 PM UTC-6, Nate Koenig wrote:

[Paul Hvass]

Nate,

Do you mind if I use your "SDF shameless plug" text (with attribution) in a ROS-I blog post?

Thanks!

Paul Hvass

On Friday, December 11, 2015 at 6:00:49 PM UTC-6, Nate Koenig wrote:

[Nate Koenig]

Hi Paul,

Feel free to use anything I say on a blog post. Thanks for asking.

Here is the SDF model editor design:

https://bitbucket.org/osrf/gazebo_design/src/default/model_editor/model_editor.md

The model editor is currently built into Gazebo, in order to allow a designer to create/edit a model and easily try it. Here are a few videos that show the editor in action:

https://www.youtube.com/watch?v=P_kBFYr7xZg

https://www.youtube.com/watch?v=JAMdLo0CadU

Gazebo 6 has a prototype version of the model editor, and Gazebo 7 (Jan 2015) will have a much improved version. As you can imagine, this is a non-trivial interface and improvements will likely span many more releases.

The work on SDF to URDF is in this branch:

https://bitbucket.org/osrf/sdformat/branch/sdf_to_urdf

-nate