ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange

# some precise definition or URDF's origin/rpy attribute?

Hello,

I'm looking for a precise definition of the roll-pitch-yaw attribute and how to compute change of reference with it.

I found these pages, but there is too much space for interpretation to my taste:

Is there some other source I missed? If not, I'm planning to propose the following for inclusion in http://wiki.ros.org/urdf/XML/ .

<origin> (optional: defaults to identity if not specified)

This is the transform from the parent link to the child link. The joint is located at the origin of the child link, as shown in the figure above.

xyz (optional: defaults to zero vector)

Represents the $$x,y,z$$ offset.

rpy (optional: defaults 'to zero vector 'if not specified)

Represents the rotation around fixed axis: first roll around x, then pitch around y and finally yaw around z. All angles are specified in radians.

combining the xyz and rpy attributes, here is how one can change the coordinates of a point "p" from the child frame to the parent frame:

p_parent = [x;y;z] + Rz(yaw)*Ry(pith)*Rx(roll)*p_child
Rx(a) = [1, 0, 0;  0, cos(a), -sin(a);  0, sin(a), cos(a)]
Ry(a) = [cos(a), 0, sin(a);  0, 1, 0;  -sin(a), 0, cos(a)]
Rz(a) = [cos(a), -sin(a), 0;  sin(a), cos(a) 0;  0, 0, 1]


thanks!

edit retag close merge delete

1

hi @barthelemy, i like your idea to contribute those new details on URDF origin calculations - were they correct and could you still do that?

Sort by » oldest newest most voted

Hi,

John an Ioan, thank you a lot for the answers, and sorry for replying myself so late.

@john: yes the new addition was just the small section. I do prefer my version, which I do find more explicit. Thus it's clear we're not using fixed axis rotations or so.

I'm digging into this because I got inconsistent results while using the urdfdom library to generate urdf xmls, which I first attributed to a misunderstanding of the convention used.

Now, I think I've nailed it to a bug in urdfdom quaternion/rpy conversion code (so, Ioan, pasting the code as a reference did not help much :-), thank you for the effort nonetheless)

the test demonstration the issue is there https://github.com/ros/urdfdom/pull/51 (I hoped github would kind of merge the two.)

more

thanks! moving on to github

This is the code used to parse origin tags, in the urdf parser: https://github.com/ros/urdfdom/blob/m...

And this is code from MoveIt, for converting that pose to Eigen transforms. I did not verify this is equivalent to the transform matrix you show.

static inline Eigen::Affine3d urdfPose2Affine3d(const urdf::Pose &pose)
{
Eigen::Quaterniond q(pose.rotation.w, pose.rotation.x, pose.rotation.y, pose.rotation.z);
Eigen::Affine3d af(Eigen::Translation3d(pose.position.x, pose.position.y, pose.position.z)*q.toRotationMatrix());
return af;
}

more

Hi barthelemy,

Is the new addition proposed the section below?

combining the xyz and rpy attributes, here is how one can change the coordinates of a point "p" from the child frame to the parent frame:

p_parent = [x;y;z] + Rz(yaw)*Ry(pith)*Rx(roll)*p_child
Rx(a) = [1, 0, 0;  0, cos(a), -sin(a);  0, sin(a), cos(a)]
Ry(a) = [cos(a), 0, sin(a);  0, 1, 0;  -sin(a), 0, cos(a)]
Rz(a) = [cos(a), -sin(a), 0;  sin(a), cos(a) 0;  0, 0, 1]


Is it sufficient to mention just text below instead?

When combining xyz and rpy attributes, translation is applied first, followed by fixed-axis rotations.


or am I missing something?

Thanks,

-John

more