On Wed, Jun 13, 2012 at 3:52 AM, John Hsu <firstname.lastname@example.org> 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.
first thanks for proposing an API review and providing efforts in
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.
- 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?
This message was posted to the following mailing lists: