Hi Thomas,

Thank you for your feedback.  I just want to clarify things a bit and reassure you that existing URDF API will not change (with exceptions of minor tweaks presented on the API review page).   I do understand the gravity of changing something as low level as the URDF, and have been working hard on keeping it consistent and simple.  The ROS URDF stack will continue to exist as it is, our goal is that if changes happen, they will be transparent to current users.

As we are trying to figure out if expanding the scope of URDF is the right thing to do, the proposed extensions will be kept separate from the existing URDF API.

The suggested extensions in this API review is motivated by needs and wishes that's been brought up (to me) repetitively by other URDF users over the past couple of years, and we are doing our best to push back on anything that will violate the simpleness-principle the URDF is based on, while staying as general as possible.

Regarding your proposal, I'll try to comment on them inline, but these are relevant and valuable inputs to the review, I feel they could be added to the API review page?


My proposal:
- keep URDF as simple as possible

Couldn't agree more!
 
- go toward making sure that URDF is a subset of SDF
- do not redefine what already exists in SDF, use it. 

I am also trying to avoid having to maintain two formats and converters between formats :)  This is the reason we've stripped ROS dependency from URDF, creating urdfdom, down the road, allowing urdfdom to be an optional system dependency and parsed directly inside of Gazebo if detected.

On the subject of looking for a way to find a common ground for URDF and SDF in the long run; there are many overlapping concepts highly desirable in both URDF and SDF, but the intersection and coverage between SDF and URDF is complicated, and this review is targeted at simply extending URDF.  Hopefully as a side benefit, we'll find ways to converge model/state descriptions between robotics and simulation.

- write a spec file or a REP for URDF and SDF so that it can stay a
coherent entity (i really don't want to maintain one SDF
and one URDF for the same robot!)

noted, will start a rep.

 
- be nice with the other parsers: if you change the format, you break
our code. At least, it would be nice to have a DTD, an
XML scheme or a version tag somewhere in the file so that we can
properly refuse too recent or too old URDF versions.
Of course, this makes only sense if there is a spec, first.

I do agree having a DTD or version tag will be great, these suggestions should be added to the API review page :)

Thanks,
John
 





On Wed, Jun 13, 2012 at 3:02 AM, Thomas Moulard <thomas.moulard@gmail.com> wrote:
On Wed, Jun 13, 2012 at 3:52 AM, John Hsu <johnhsu@willowgarage.com> wrote:
> Hi All,
>
> A couple of extensions to the urdf have been proposed and are on the
> horizon.  Please review and add your comments to the API Review page.

Hi,
first thanks for proposing an API review and providing efforts in
developing urdf.
I think this is a very crucial tool for us, ROS users, especially in
combination with tf.

However, as this is a crucial tool, I also feel quite worried about
the turn of even that
is suggested by this proposal.

IMHO, we do not need an API review without having a _clear_ view on
what we (users) and WG
wants to do with the URDF format, how we can make so that it stays
compatible with the Gazebo
SDF format, whether it is possible, in long term, to get rid of the
PR-2 extensions and propose something
for a broader range of robots (read here: closed chains, sensor fields, etc.)

Particularly, it seems to me that this particular effort is very
redundant to what have been done when SDF
has been defined.

The URDF format is one of the core part of the ROS ecosystem, we all
build on top of it or use it but, AFAIK, there
has been no effort so far to try to write specs for this format. To
use a metaphor, I feel like you're trying to build webkit
before writing down the HTML specifications and as you do that, I see
a fragmentation of this "unified" robot modeling
format that worries me.

My proposal:
- keep URDF as simple as possible
- go toward making sure that URDF is a subset of SDF
- do not redefine what already exists in SDF, use it.
- write a spec file or a REP for URDF and SDF so that it can stay a
coherent entity (i really don't want to maintain one SDF
and one URDF for the same robot!)
- be nice with the other parsers: if you change the format, you break
our code. At least, it would be nice to have a DTD, an
XML scheme or a version tag somewhere in the file so that we can
properly refuse too recent or too old URDF versions.
Of course, this makes only sense if there is a spec, first.

Again, I did not put that on the wiki because this mail is about the
format and not about the format implementation.

What do you think?
--
Thomas Moulard
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users