ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

The many origins of URDF

There are a lot of origins in URDF, making them bit confusing for me.

Before I decided to ask this question, I've done research on the forum and wiki post, including these posts: URDF and frames of reference URDF wiki

I've also tried to alter code from this tutorial to see how the alteration will change the pose of the robots. I drew couple of conclusions, but still not really sure about them

1. Every link has a reference of frame (and including with it an origin). By default the frame's origin of the link is located at the origin of the world.
2. We can custom the frame's origin of each link using the <origin> tag inside <joint> element. For example:

<joint name="joint1" type="continuous">
<origin xyz="0 ${width}${height1 - axel_offset}" rpy="0 0 0"/>
<axis xyz="0 1 0"/>
<dynamics damping="0.7"/>


</joint>

The code above will position the frame's origin of link2(child) at the location and orientation specified by xyz and rpy components with respect to the link1(parent).

1. This frame's origin of each link is used as a reference for each link. The visual's ,collision's, and inertial's origins of the link will be defined with respect to the link's reference frame.

2. VISUAL's origin. This is to position the visual of a link w.r.t to the link's reference frame. The link's visual origin is attached to its center of shape (not center of mass, but mid of the link) -> I drew this conclusion from playing with this tutorial ,but I'm still not sure. The center of link is easily interpreted when the links are simple shapes like box or ball. But, what if the shape is an arbitrary shape? Where is the center of the shape that is attached with the visual's origin in this case?

3. COLLISION's origin. I think this is pretty much the same with visual's origin with the only difference that this is for the collision shape(collision shape can be different from visual shape). Collision's origin is attached to its center of the collision shape? Same question like before, what if the shape is arbitrary? where will the mid of shape be?

4. INERTIAL's origin. This is to specify the location of the center of mass , which depends on the mass distribution,of the link. Like the rest, intertial's origin is defined w.r.t the link's frame. Changing inertial's origin will not affect robot's appearance. for example, if we have a ball, to place the ball above the ground, what is required is to specify the visual's z origin = radius value. If the ball is homogeneous, then the inertial's z origin is also the radius. Otherwise, we can change the inertial's origin, and it will not affect the location of the ...

edit retag close merge delete

You may find these tutorials more helpful than the gazebo-based ones: http://wiki.ros.org/urdf/Tutorials/

( 2017-08-28 10:54:38 -0500 )edit
1

@David Lu Thanks for your suggestion.I actually just did those tutorials couple days ago. It seems to me that they confirm the statements I wrote in this post. However, it still doesn't answer some of my questions like on point 2 and 3.

( 2017-08-28 11:15:28 -0500 )edit

Sort by » oldest newest most voted

2a: Yes, for simple shapes, the origin specifies the location of shape's center relative to the link's frame.

2b: Not sure, but I suspect that the URDF parser will read the mesh file, generate a bounding box, and use the center of the bounding box.

3: Same as above.

4: Exactly.

more

1

Not sure, but I suspect that the URDF parser will read the mesh file, generate a bounding box, and use the center of the bounding box.

The URDF parser only reads the xml that is the urdf proper. The mesh loader(s) will load the mesh data, and will use whatever point is the origin of the mesh ..

( 2017-11-11 01:56:55 -0500 )edit
1

.. when it was exported from or saved with the tool that created it.

So that origin will have to be correctly encoded in the mesh binary itself. If it isn't, you can use the origin tag of the visual and collison elements to offset it, but I'd recommend giving the mesh a proper origin already.

( 2017-11-11 01:58:46 -0500 )edit