The Limitations of URDF

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

The Limitations of URDF

David Lu!!-2
Hey ROS-community,
I've been working with URDF extensively for awhile, and am wondering what the future is for its development. Specifically, whether the format will be extended at all to address what I perceive to be some of its limitations. 

I think the biggest limitation is the lack of graph support, which relates a link to two or more parent links (as opposed to the current tree structure). I believe this problem stems from KDL supporting only chains, and not graphs, but there are a number of situations where a graph structure is called for. The simplest example is a four bar linkage, which, as it stands, cannot be easily model led in URDF. 

One step toward fixing the problem could involve making some joints dependent on other joints. For the case of a parallelogram-shaped 4 bar, three of the joints could depend on one joint, but there is currently no support for that either. A similar situation involves gears/pulleys and other motion transferring mechanisms, i.e. two gears, each connected to a base with a continuous joint, and the angle of joint for the second gear is 4 times the angle for the first. 

Having now tried to get collision detection working as well, it seems odd to have three different structures to specify the hierarchy of the machine. Its specified once in the URDF, and then separate groups are defined via parameters to define groups. Some of these groups coincide with whole xacro macros too. While I see that these distinctions may often need to be customized, it seems like it would be easier to do the customization via parameter, and not use the parameters to redefine everything again. 

The last thing that concerns me is the PR2 specific extensions. I'm not exactly clear what they lend to the PR2, but I'm also not clear why they wouldn't apply to other robots. 

[As an aside, does anyone know where the xml schema are for urdf? The PR2 file links to http://playerstage.sourceforge.net/gazebo/xmlschema/, but there's nothing there.]

What I'm wondering is whether any of these issues are currently being addressed, or whether I should work around them (either in my own code or in the ROS repository). Hopefully this will spark a discussion on any other hurdles people are having with URDF. 

Thanks,
David!!


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: The Limitations of URDF

John Hsu
Hi David!!!
I've answered inline:

On Fri, Aug 6, 2010 at 11:44 AM, David Lu!! <[hidden email]> wrote:
Hey ROS-community,
I've been working with URDF extensively for awhile, and am wondering what the future is for its development. Specifically, whether the format will be extended at all to address what I perceive to be some of its limitations. 

I think the biggest limitation is the lack of graph support, which relates a link to two or more parent links (as opposed to the current tree structure). I believe this problem stems from KDL supporting only chains, and not graphs, but there are a number of situations where a graph structure is called for. The simplest example is a four bar linkage, which, as it stands, cannot be easily model led in URDF. 


Thanks for the feedback.  We have started thinking about some of the potential improvements to URDF and ticketed them on trac
https://code.ros.org/trac/ros-pkg/search?q=urdf-2.0
please feel free to contribute your comments there.  When creating additional feature requests please put "urdf-2.0" in the "Keywords" field for now.

One step toward fixing the problem could involve making some joints dependent on other joints. For the case of a parallelogram-shaped 4 bar, three of the joints could depend on one joint, but there is currently no support for that either. A similar situation involves gears/pulleys and other motion transferring mechanisms, i.e. two gears, each connected to a base with a continuous joint, and the angle of joint for the second gear is 4 times the angle for the first. 
 
I've added your comments to this ticket
 
Having now tried to get collision detection working as well, it seems odd to have three different structures to specify the hierarchy of the machine. Its specified once in the URDF, and then separate groups are defined via parameters to define groups. Some of these groups coincide with whole xacro macros too. While I see that these distinctions may often need to be customized, it seems like it would be easier to do the customization via parameter, and not use the parameters to redefine everything again. 

Maybe someone more familiar with the collision groups can answer this one?
 

The last thing that concerns me is the PR2 specific extensions. I'm not exactly clear what they lend to the PR2, but I'm also not clear why they wouldn't apply to other robots. 

can you please clarify your concern?  (e.g. package/stack names? etc.)
In general, a lot of the software packages may work their way into non-PR2-specific status after proving its usefulness first as a PR2 specific utility.
 

[As an aside, does anyone know where the xml schema are for urdf? The PR2 file links to http://playerstage.sourceforge.net/gazebo/xmlschema/, but there's nothing there.]
 

What I'm wondering is whether any of these issues are currently being addressed, or whether I should work around them (either in my own code or in the ROS repository). Hopefully this will spark a discussion on any other hurdles people are having with URDF.

Thanks again for the feedbacks!
John

 
 

Thanks,
David!!


_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users



_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
dlu
Reply | Threaded
Open this post in threaded view
|

Re: The Limitations of URDF

dlu
Thanks for the reply John. Clarification inline...

The last thing that concerns me is the PR2 specific extensions. I'm not exactly clear what they lend to the PR2, but I'm also not clear why they wouldn't apply to other robots. 

can you please clarify your concern?  (e.g. package/stack names? etc.)
In general, a lot of the software packages may work their way into non-PR2-specific status after proving its usefulness first as a PR2 specific utility.
   

Basically, I was trying to figure out whether I could/should use them in my model, but I was unsure how to use it due to the lack of documentation, and wasn't sure why it was PR2 only, but you just clarified that part. I guess that's just the nature of the developing packages. 

Thanks again,
David!! 

_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: The Limitations of URDF

Herman Bruyninckx
In reply to this post by David Lu!!-2
On Fri, 6 Aug 2010, David Lu!! wrote:

> Hey ROS-community,I've been working with URDF extensively for awhile, and am
> wondering what the future is for its development. Specifically, whether the
> format will be extended at all to address what I perceive to be some of its
> limitations. 
>
> I think the biggest limitation is the lack of graph support, which relates a
> link to two or more parent links (as opposed to the current tree structure). I
> believe this problem stems from KDL supporting only chains, and not graphs, but
> there are a number of situations where a graph structure is called for. The
> simplest example is a four bar linkage, which, as it stands, cannot be
> easily model led in URDF. 
COLLADA seems to be the future: it allows to model graphs, for example; it
is a real international standard; there are already ROS initiatives working
in this direction.

KDL is also going to adopt COLLADA, in the coming year or so.

Best regards,

Herman Bruyninckx

>
> One step toward fixing the problem could involve making some joints dependent on
> other joints. For the case of a parallelogram-shaped 4 bar, three of the joints
> could depend on one joint, but there is currently no support for that either. A
> similar situation involves gears/pulleys and other motion transferring
> mechanisms, i.e. two gears, each connected to a base with a continuous joint,
> and the angle of joint for the second gear is 4 times the angle for the first. 
>
> Having now tried to get collision detection working as well, it seems odd to
> have three different structures to specify the hierarchy of the machine. Its
> specified once in the URDF, and then separate groups are defined via parameters
> to define groups. Some of these groups coincide with whole xacro macros too.
> While I see that these distinctions may often need to be customized, it seems
> like it would be easier to do the customization via parameter, and not use the
> parameters to redefine everything again. 
>
> The last thing that concerns me is the PR2 specific extensions. I'm not exactly
> clear what they lend to the PR2, but I'm also not clear why they wouldn't apply
> to other robots. 
>
> [As an aside, does anyone know where the xml schema are for urdf? The PR2 file
> links to http://playerstage.sourceforge.net/gazebo/xmlschema/, but there's
> nothing there.]
>
> What I'm wondering is whether any of these issues are currently being addressed,
> or whether I should work around them (either in my own code or in the ROS
> repository). Hopefully this will spark a discussion on any other hurdles people
> are having with URDF. 
>
> Thanks,
> David!!
>
>
>
--
   K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
   EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
   Open Realtime Control Services <http://www.orocos.org>
   Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: The Limitations of URDF

Rosen Diankov
This is a great point Herman. Although there is a urdf2collada tool,
most of the tools developed by Willow Garage in ROS directly use URDF.
We're hoping to eventually have a collada2urdf tool to resolve these
issues so that a robot's data can be natively stored in collada.
rosen,

2010/8/7 Herman Bruyninckx <[hidden email]>:

> On Fri, 6 Aug 2010, David Lu!! wrote:
>
>> Hey ROS-community,I've been working with URDF extensively for awhile, and
>> am
>> wondering what the future is for its development. Specifically, whether
>> the
>> format will be extended at all to address what I perceive to be some of
>> its
>> limitations.
>>
>> I think the biggest limitation is the lack of graph support, which relates
>> a
>> link to two or more parent links (as opposed to the current tree
>> structure). I
>> believe this problem stems from KDL supporting only chains, and not
>> graphs, but
>> there are a number of situations where a graph structure is called for.
>> The
>> simplest example is a four bar linkage, which, as it stands, cannot be
>> easily model led in URDF.
>
> COLLADA seems to be the future: it allows to model graphs, for example; it
> is a real international standard; there are already ROS initiatives working
> in this direction.
>
> KDL is also going to adopt COLLADA, in the coming year or so.
>
> Best regards,
>
> Herman Bruyninckx
>
>>
>> One step toward fixing the problem could involve making some joints
>> dependent on
>> other joints. For the case of a parallelogram-shaped 4 bar, three of the
>> joints
>> could depend on one joint, but there is currently no support for that
>> either. A
>> similar situation involves gears/pulleys and other motion transferring
>> mechanisms, i.e. two gears, each connected to a base with a continuous
>> joint,
>> and the angle of joint for the second gear is 4 times the angle for the
>> first.
>>
>> Having now tried to get collision detection working as well, it seems odd
>> to
>> have three different structures to specify the hierarchy of the machine.
>> Its
>> specified once in the URDF, and then separate groups are defined via
>> parameters
>> to define groups. Some of these groups coincide with whole xacro macros
>> too.
>> While I see that these distinctions may often need to be customized, it
>> seems
>> like it would be easier to do the customization via parameter, and not use
>> the
>> parameters to redefine everything again.
>>
>> The last thing that concerns me is the PR2 specific extensions. I'm not
>> exactly
>> clear what they lend to the PR2, but I'm also not clear why they wouldn't
>> apply
>> to other robots.
>>
>> [As an aside, does anyone know where the xml schema are for urdf? The PR2
>> file
>> links to http://playerstage.sourceforge.net/gazebo/xmlschema/, but there's
>> nothing there.]
>>
>> What I'm wondering is whether any of these issues are currently being
>> addressed,
>> or whether I should work around them (either in my own code or in the ROS
>> repository). Hopefully this will spark a discussion on any other hurdles
>> people
>> are having with URDF.
>>
>> Thanks,
>> David!!
>>
>>
>>
>
> --
>  K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
>    <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>  EURON Coordinator (European Robotics Research Network)
> <http://www.euron.org>
>  Open Realtime Control Services <http://www.orocos.org>
>  Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
> _______________________________________________
> ros-users mailing list
> [hidden email]
> https://code.ros.org/mailman/listinfo/ros-users
>
>
_______________________________________________
ros-users mailing list
[hidden email]
https://code.ros.org/mailman/listinfo/ros-users