Support circular joint chains in spec

[gkjohnson]

As I mentioned in my other issue, if this isn't the right place for this type of discussion, let me know!

The spec at the moment explicitly forbids the description of parallel kinematics ("The main limitation at this point is that only tree structures can be represented, ruling out all parallel robots"). However, there's nothing about the current format that inherently prevents closed loops links and joints:

<link name="link1" />
<link name="link2" />
<link name="link3" />

<joint name="1to2">
  <parent name="link1" />
  <child name="link2" />
</joint>

<joint name="2to3">
  <parent name="link2" />
  <child name="link3" />
</joint>

<joint name="3to1">
  <parent name="link3" />
  <child name="link1" />
</joint>

This write up on URDF 2.0 states as much, as well. Of course, the burden falls onto the consuming system to properly support the closed loop kinematics.

Would it be possible to just remove this restriction in the spec? Or is there a timeline for when a new revision might support this? I recognize the SDF supports these types of descriptions, but I appreciate the relative simplicity of URDF as opposed to the all-encompassing scene / world description that SDF requires.

Thank you very much!

[carlosjoserg]

Not sure if it is the right place for discussion either, however, you are right about that point: The spec does not actually prevent closed kinematic loops to be written, as you can build your joints and links as desired.

It is how this file is consumed by basic tools like the robot_state_publisher, which uses the KDL forward kinematic solver for trees, in order to know where your links are everytime, given that the joints are being measured or estimated.

I think that SDF accept such description because the default engine in gazebo is ODE, which treats your robot as a multi-body system and applies joint kinematic constraints to each body's 6 degrees of freedom, which makes it independent of the actual kinematic topology, at the cost of having more variables and equations to deal with. I'm not familiar with other engines, but according to these roscon slides by scpeters, in the 10th slide, DART and Simbody (Bullet as well, but not supported in gazebo at that moment), work with generalized coordinates (which reduces variables and equations to deal with, as you can read form the article as well), but unfortunately not that easy in parallel robots (typical case of closed kinematic loops with not-measured passive joints).

Having said that, you can always write your own robot state publisher, for instance, take a look at this 4-legged delta robot, if you haven't already, where they wrote their own state publisher for inter-linked floating joints.

[ghost]

You can refer to：https://github.com/wojiaojiao/pegasus_gazebo_plugins
or http://wiki.ros.org/Angel_jj/closed_loop_plugin
It can help you to solve the issue that URDF not support Closed loop chains.

[gkjohnson]

@wojiaojiao
Thanks for the links!

I'm actually using the URDF format in web applications that often don't rely Gazebo or ROS at all -- I'm just using the existing format to load the kinematic model into custom operations and engineering tooling. It's currently impossible to properly and completely describe a lot of our systems without support for closed loop links in the format.

I'm a huge fan of standards and love the contained scope and usability of URDF so I'd like to see it support these types of features in the spec and be considered useful outside of the ROS infrastructure.

For a little more context here's the loader I've built for THREE.js to import URDF files into the browser which I'm using to support a variety of robotics projects at the moment. I'd really like to be able to load and constrain our robots that have close loop systems using this:

https://github.com/gkjohnson/urdf-loaders/tree/master/javascript

As it is I'm considering supporting something like a custom <ClosedLink> node in order describe these systems until URDF adds the feature to the spec. Support for such a feature would naturally vary from application to application. I'd be happy if it were even just considered an "extension" to the current URDF spec -- I just want a standardized way to describe it.

Thanks!