# 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?

- Login to post comments

## Bug in Rotation::GetRot in KDL?

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?

bruynincwrote:> 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.

bruynincwrote: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.