Bug in Rotation::GetRot in KDL?

Submitted by miguel on Tue, 2011-12-13 14:09

I've been noticing weird behaviour when using the

IMETHOD Twist diff(const Frame& F_a_b1,const Frame& F_a_b2,double dt=1);

method provided by KDL, and I nailed it down to occurring when the two frames are rotated by an angle of pi. This error is caused by Rotation::GetRot() function, which miscalculates the rotation Vector in that case.

Note that given the implementation of Rotation::GetRot (line 325 in frames.cpp in the version included in ROS Electric) whenever the sinus of the rotated angle is very low, it is assumed that the angle is close to zero, instead of checking if the angle is indeed close to zero or if it is close to pi instead.

GetRotAngle does fail too depending on the rotation axis. I've been able to try with a rotation of pi around the three main axes and it only succeeds when the rotation is around Z. This is probably due to the convention it uses to choose the rotation axis. I still need to check the case of an arbitrary axis, but my instinct says that as long as there's a non-zero component of the rotation axis in the Z direction this will probably work as expected.

If it is a bug indeed, where should I file a ticket for this?

‹ Problem getting itasc_examples segmentation fault in itasc ›
»

Bug in Rotation::GetRot in KDL?

Submitted by bruyninc on Wed, 2011-12-14 13:00.

On Tue, 13 Dec 2011, miguel [dot] prada [dot] sarasola [..] ... wrote:

> I've been noticing weird behaviour when using the
>
> IMETHOD Twist diff(const Frame& F_a_b1,const Frame& F_a_b2,double dt=1);
>
> method provided by KDL, and I nailed it down to occurring when the two frames
> are rotated by an angle of pi. This error is caused by Rotation::GetRot()
> function, which miscalculates the rotation Vector in that case.
>
> Note that given the implementation of Rotation::GetRot (line 325 in
> frames.cpp in the version included in ROS Electric) whenever the sinus of the
> rotated angle is very low, it is assumed that the angle is close to zero,
> instead of checking if the angle is indeed close to zero or if it is close to
> pi instead.
>
> GetRotAngle does fail too depending on the rotation axis. I've been able to
> try with a rotation of pi around the three main axes and it only succeeds
> when the rotation is around Z. This is probably due to the convention it uses
> to choose the rotation axis. I still need to check the case of an arbitrary
> axis, but my instinct says that as long as there's a non-zero component of
> the rotation axis in the Z direction this will probably work as expected.
>
> If it is a bug indeed, where should I file a ticket for this?

It is not just/really a bug: the current implementation has the
representation singularities that are rather well-known. Well-known in the
sense that no 3-parameter representation of rotation is without such
representation singularities, sigh...

I know that we have to redesign this part of the Frame and Twist
implementations, not just because of the mentioned representation
singularities, but also because the concept of a "difference" between two
Frames (in the semantic meaning of an "error") is not physically
well-defined...

For the time being, "just" use the code within its valid domain.

Best regards,

Herman

»

Bug in Rotation::GetRot in KDL?

Submitted by miguel on Wed, 2011-12-14 13:41.

bruyninc wrote:
On Tue, 13 Dec 2011, miguel [dot] prada [dot] sarasola [..] ... wrote:

> I've been noticing weird behaviour when using the >> IMETHOD Twist diff(const Frame& F_a_b1,const Frame& F_a_b2,double dt=1); >> method provided by KDL, and I nailed it down to occurring when the two frames > are rotated by an angle of pi. This error is caused by Rotation::GetRot() > function, which miscalculates the rotation Vector in that case. >> Note that given the implementation of Rotation::GetRot (line 325 in > frames.cpp in the version included in ROS Electric) whenever the sinus of the > rotated angle is very low, it is assumed that the angle is close to zero, > instead of checking if the angle is indeed close to zero or if it is close to > pi instead. >> GetRotAngle does fail too depending on the rotation axis. I've been able to > try with a rotation of pi around the three main axes and it only succeeds > when the rotation is around Z. This is probably due to the convention it uses > to choose the rotation axis. I still need to check the case of an arbitrary > axis, but my instinct says that as long as there's a non-zero component of > the rotation axis in the Z direction this will probably work as expected. >

> If it is a bug indeed, where should I file a ticket for this?

It is not just/really a bug: the current implementation has the representation singularities that are rather well-known. Well-known in the sense that no 3-parameter representation of rotation is without such representation singularities, sigh...

I know about the representation singularities but, if I'm not mistaken, the axis-angle representation has its only singularity at the null rotation, where the rotation axis becomes meaningless. However, the case where the rotation angle is pi is not such a singularity and I think it can be properly handled. Please correct me if I'm wrong.

bruyninc wrote:
I know that we have to redesign this part of the Frame and Twist implementations, not just because of the mentioned representation singularities, but also because the concept of a "difference" between two Frames (in the semantic meaning of an "error") is not physically well-defined...

For the time being, "just" use the code within its valid domain.

Best regards,

Herman

I will probably use the code as it is and hope that chance saves me from having such a difference to compute. If I happen to encounter this while running my experiments and I generate a patch for the implementation of GetRot and/or GetRotAngle, where should I post it?

Best regards,

Miguel.

»