Need help with DH parameters setting up KDL chain

Having trouble setting up a KDL chain from DH parameters. Couldn't find any documentation or examples in the code. Can't get KDL forward kinematics results to match up with the robot's answers.

We are using the following to set a chain for a Mitsubishi PA10-7, a RPRPRPR redundant manipulator. Comparing the forward kinematic results from "ChainFkSolverPos_recursive" to the internal data from the PA10, _seems_ to show that the KDL chain is providing data in a left-handed coordinate system. I doubt this is the case (is it?), so figured that we're doing something wrong.

We aren't at all sure what the Joint::RotN are really choosing, in terms of what the chain ends up doing. I can't find any documentation that helps with this unfortunately. Following the Kuka and Staubili sample code, it seems that you use RotZ for roll joints, and RotX for pitch? If anyone can provide an explanation on what this means, I would really appreciate it. I have another robot project coming up that has some very funky offset joint axes, so I'm going to need a pretty good understanding of how to correctly setup the kinematics.

Any help appreciated!
S

{{{
// using DH
kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, 0, 0.317, 0)));
kinematics.addSegment(Segment(Joint(Joint::RotX),Frame::DH(0, M_PI/2, 0, 0)));
kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, -M_PI/2, 0.450, 0)));
kinematics.addSegment(Segment(Joint(Joint::RotX),Frame::DH(0, M_PI/2, 0, 0)));
kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, -M_PI/2, 0.480, 0)));
kinematics.addSegment(Segment(Joint(Joint::RotX),Frame::DH(0, M_PI/2, 0, 0)));
kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, -M_PI/2, 0.070, 0)));
}}}

Need help with DH parameters setting up KDL chain

On Wed, 7 May 2008, snrkiwi wrote:

> Having trouble setting up a KDL chain from DH parameters. Couldn't find any
> documentation or examples in the code. Can't get KDL forward kinematics
> results to match up with the robot's answers.
>
> We are using the following to set a chain for a Mitsubishi PA10-7, a RPRPRPR
> redundant manipulator. Comparing the forward kinematic results from
> "ChainFkSolverPos_recursive" to the internal data from the PA10, _seems_ to
> show that the KDL chain is providing data in a left-handed coordinate system.
> I doubt this is the case (is it?), so figured that we're doing something
> wrong.
We definitely use _right-handed_ frames :-)

> We aren't at all sure what the Joint::RotN are really choosing, in terms of
> what the chain ends up doing. I can't find any documentation that helps with
> this unfortunately. Following the Kuka and Staubili sample code, it seems
> that you use RotZ for roll joints, and RotX for pitch? If anyone can provide
> an explanation on what this means, I would really appreciate it.

RotZ means: the motion degree of freedom is along the (local) Z axis
following the right-hand rule.
TransX means: the motion degree of freedom is along the (local) X axis.
RotX and RotY are simuilar, but then about X and Y axes. Etc.
The nomenclature "roll" and "pitch" and "DH parameters" is TOO AMBIGUOUS
(I've seen many different semantics for these same names over the last 20
years...), and leads time and again to errors. (Your questions prove this
once more :-)) So, KDL uses transformation matrices (possibly built from
elementary ones such as RotX etc.) as its basic building blocks.

> I have
> another robot project coming up that has some very funky offset joint axes,
> so I'm going to need a pretty good understanding of how to correctly setup
> the kinematics.
Use homogeneous transformation matrices! Non-minimal in its representation
but completely unambiguous. (Up to the choice of "right-handedness" :-) )

> Any help appreciated!
IHTH

Herman
> S
>
> {{{
> // using DH
> kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, 0,
> 0.317, 0)));
> kinematics.addSegment(Segment(Joint(Joint::RotX),Frame::DH(0, M_PI/2,
> 0, 0)));
> kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, -M_PI/2,
> 0.450, 0)));
> kinematics.addSegment(Segment(Joint(Joint::RotX),Frame::DH(0, M_PI/2,
> 0, 0)));
> kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, -M_PI/2,
> 0.480, 0)));
> kinematics.addSegment(Segment(Joint(Joint::RotX),Frame::DH(0, M_PI/2,
> 0, 0)));
> kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame::DH(0, -M_PI/2,
> 0.070, 0)));
> }}}

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Need help with DH parameters setting up KDL chain

>> We aren't at all sure what the Joint::RotN are really choosing, in
>> terms of what the chain ends up doing. I can't find any
>> documentation that helps with this unfortunately. Following the
>> Kuka and Staubili sample code, it seems that you use RotZ for roll
>> joints, and RotX for pitch? If anyone can provide an explanation on
>> what this means, I would really appreciate it.
>
> RotZ means: the motion degree of freedom is along the (local) Z axis
> following the right-hand rule.
> TransX means: the motion degree of freedom is along the (local) X
> axis.
> RotX and RotY are simuilar, but then about X and Y axes. Etc.
> The nomenclature "roll" and "pitch" and "DH parameters" is TOO
> AMBIGUOUS
> (I've seen many different semantics for these same names over the
> last 20
> years...), and leads time and again to errors. (Your questions prove
> this
> once more :-)) So, KDL uses transformation matrices (possibly built
> from
> elementary ones such as RotX etc.) as its basic building blocks.

Yes, DH param's are nice and simple but _definitely_ not unambiguous.
For the new robot I'm working with the existing team has two distinct
sets of DH parameters, which give different results from both the
Orocos and ROBoop packages. And none of these combinations agree with
whatever the manufacturer put inside the robot!! UGH!

>> I have another robot project coming up that has some very funky
>> offset joint axes, so I'm going to need a pretty good understanding
>> of how to correctly setup the kinematics.
> Use homogeneous transformation matrices! Non-minimal in its
> representation
> but completely unambiguous. (Up to the choice of "right-
> handedness" :-) )

I presume you're using T matrices to specify link end relative to link
start and then chaining these, right? Is there a given procedure to
assigning axes to each DOF (like with DH param's), or are you just
doing what makes sense? This appears to be the method used for the
Kuka and Staubili robots within OCL. Correct?

To test my understanding of how KDL::Segments are setup, the following
segment has motion around the local Z axis, with the end of the
segment 1.02m along the local Z axis?

kinematics
.addSegment(Segment(Joint(Joint::RotZ),Frame(Vector(0.0,0.0,1.020))));

Whereas this one is similar, except the link ends ~0.7m along Z and
the next frame is rotated 90 degrees (presuming that is PI/2) around
the local Z?

kinematics
.addSegment
(Segment
(Joint
(Joint
::RotZ),Frame(Rotation::RotZ(M_PI_2),Vector(0.0,0.0,0.2075+0.550))));

>> Any help appreciated!
> IHTH

Just gives me material for more questions ... ;-)
S

Ruben Smits's picture

Need help with DH parameters setting up KDL chain

On Thursday May 8 2008 14:14:31 Stephen Roderick wrote:
> >> We aren't at all sure what the Joint::RotN are really choosing, in
> >> terms of what the chain ends up doing. I can't find any
> >> documentation that helps with this unfortunately. Following the
> >> Kuka and Staubili sample code, it seems that you use RotZ for roll
> >> joints, and RotX for pitch? If anyone can provide an explanation on
> >> what this means, I would really appreciate it.
> >
> > RotZ means: the motion degree of freedom is along the (local) Z axis
> > following the right-hand rule.
> > TransX means: the motion degree of freedom is along the (local) X
> > axis.
> > RotX and RotY are simuilar, but then about X and Y axes. Etc.
> > The nomenclature "roll" and "pitch" and "DH parameters" is TOO
> > AMBIGUOUS
> > (I've seen many different semantics for these same names over the
> > last 20
> > years...), and leads time and again to errors. (Your questions prove
> > this
> > once more :-)) So, KDL uses transformation matrices (possibly built
> > from
> > elementary ones such as RotX etc.) as its basic building blocks.
>
> Yes, DH param's are nice and simple but _definitely_ not unambiguous.
> For the new robot I'm working with the existing team has two distinct
> sets of DH parameters, which give different results from both the
> Orocos and ROBoop packages. And none of these combinations agree with
> whatever the manufacturer put inside the robot!! UGH!
>
> >> I have another robot project coming up that has some very funky
> >> offset joint axes, so I'm going to need a pretty good understanding
> >> of how to correctly setup the kinematics.
> >
> > Use homogeneous transformation matrices! Non-minimal in its
> > representation
> > but completely unambiguous. (Up to the choice of "right-
> > handedness" :-) )
>
> I presume you're using T matrices to specify link end relative to link
> start and then chaining these, right?

Yes

> Is there a given procedure to
> assigning axes to each DOF (like with DH param's), or are you just
> doing what makes sense? This appears to be the method used for the
> Kuka and Staubili robots within OCL. Correct?

Indeed, we defined a reference-frame at the base of our robot, and then put
the robot in it's zero position, the axes are then chosen as easy as
possible.

> To test my understanding of how KDL::Segments are setup, the following
> segment has motion around the local Z axis, with the end of the
> segment 1.02m along the local Z axis?
>
> kinematics
> .addSegment(Segment(Joint(Joint::RotZ),Frame(Vector(0.0,0.0,1.020))));

correct

> Whereas this one is similar, except the link ends ~0.7m along Z and
> the next frame is rotated 90 degrees (presuming that is PI/2) around
> the local Z?
>
>
kinematics.addSegment(Segment(Joint(Joint::RotZ),Frame(Rotation::RotZ(M_PI_2),Vector(0.0,0.0,0.2075+0.550))));

yes

> >> Any help appreciated!
> >
> > IHTH
>
> Just gives me material for more questions ... ;-)
> S

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm