[fixed] Possible small bug in Rotation::getYawPitchRoll(...) code

[FCuser2019]

Hello, I am studying the theory of quaternions applied to 3D rotations. In order to better understand the problems related to the gimbal lock management I did some calculations manually, then I looked in the FC code to see how the gimbal lock management is implemented in the conversion from quaternions to angles and I saw that in the case pitch=-90° there is a difference of sign in the roll angle expression.
If my calculations are correct (see the attached file), the roll angle expression for pitch=-90° should be:

r = +2.0 * atan2(quat[0],quat[3]);

instead in Rotation::getYawPitchRoll(double& y, double& p, double& r) , (see https://github.com/FreeCAD/FreeCAD/blob ... tation.cpp)
there is:

Code: Select all

 else if (fabs(qd2+1.0) < DBL_EPSILON) {
        // south pole
        y = 0.0;
        p = -D_PI/2.0;
        r = -2.0 * atan2(quat[0],quat[3]);
    }

In the case of pitch=+90° the result of my calculations coincides with the expression in the Rotation::getYawPitchRoll(...) code.

what do you think about it?

Thanks for your attention.

P.S. the rotation implemented in the FC code is the intrinsic rotation zy'x'' (or equivalently the extrinsic rotation XYZ), however, both in the Placement window and in the comment in the Rotation::setYawPitchRoll(...) code there is "Euler angles xy'z'' ". The correct string should be zy'x'' or equivalently XYZ.

[openBrain]

I already discussed that in the past but using "yaw-pitch-roll" in FreeCAD is a bit inappropriate.
Actually, this term should be specifically used for intrinsic ZY'X'' angles, while FreeCAD uses intrinsic XY'Z'' for Euler representation. This may explain a computation difference in what is called "yaw-pitch-roll".

[openBrain]

P.S. the rotation implemented in the FC code is the intrinsic rotation zy'x'' (or equivalently the extrinsic rotation XYZ), however, both in the Placement window and in the comment in the Rotation::setYawPitchRoll(...) code there is "Euler angles xy'z'' ". The correct string should be zy'x'' or equivalently XYZ.

I didn't have a look for a while and indeed it's now a ZY'X'' representation. I don't know when it changed (or even maybe it didn't changed and I had wrong memories).
The good news is that given that, it's fully correct to use the Yaw/Pitch/Roll terms. We should indeed fix the presentation string.

[FCuser2019]

openBrain, thanks for your answers

[FCuser2019]

Here is a practical example of the problem described:

1) open the attached bigLCS.FCStd file;

2) Open the Placement window of Body:

0_0_0.png (111.87 KiB) Viewed 2286 times

3) set the rotation angles visible in the following image:

10_-90_20.png (108.95 KiB) Viewed 2286 times

4) press OK, the Body is rotated correctly;

5) reopen the Body Placement window:

-30_-90_0.png (109.78 KiB) Viewed 2286 times

FC uses Rotation::getYawPitchRoll(...) to get the values of the angles to be displayed in the fields Around x-axis, Around y-axis and Around z-axis, but the roll angle (Around x-axis) has the opposite sign to the one it should have according to my calculations. In fact, pressing OK without changing any values rotates the body:

-30_-90_0_afterOK.png (84.31 KiB) Viewed 2286 times

if (yaw=20° , pitch=-90° , roll=10°) were equivalent to (yaw=0° , pitch=-90° , roll=-30°) the body should not rotate after pressing OK. In order for the body not to rotate after pressing OK, it is necessary to change the sign of the roll angle (Around x-axis from -30° to +30°).


OS: Linux Mint 19.3 (MATE/mate)
Word size of FreeCAD: 64-bit
Version: 0.20.25566 (Git) AppImage
Build type: Release
Branch: master
Hash: 8c361dd3fc83840a911da950a845eb9f9342a0b6
Python version: 3.9.6
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2
Locale: Italian/Italy (it_IT)

[openBrain]

My guess is that there is an inconsistency between 'getYawPitchRoll' and 'setYawPitchRoll'. Looks like both don't use the same system.
Will have a look later. You can have a look too, both functions are in the same file.

[openBrain]

OK it seems this is more or less related to gimbal lock as there seems to be no problem if no angle is set to 90°...

[GeneFC]

pressing OK without changing any values rotates the body:

Curious.

I followed the script exactly and saw exactly the same behavior until this step. In my case the body did not rotate when Ok was pressed.

OS: Windows 7 Version 6.1 (Build 7601: SP 1)
Word size of FreeCAD: 64-bit
Version: 0.20.25645 (Git)
Build type: Release
Branch: master
Hash: 37d9757399b4c2ec30318eb88d7cd7c508246345
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)


[EDIT]

Even more curious. The rotation *does* occur when using the Conda version. The FreeCAD commit number is exactly the same.

OS: Windows 7 SP 1 (6.1)
Word size of FreeCAD: 64-bit
Version: 0.20.25645 (Git)
Build type: Release
Branch: master
Hash: 37d9757399b4c2ec30318eb88d7cd7c508246345
Python version: 3.8.10
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2
Locale: English/United States (en_US)

Gene

[openBrain]

I can reproduce with :

Code: Select all

OS: Ubuntu 21.04 (KDE/plasma)
Word size of FreeCAD: 64-bit
Version: 0.20.25672
Build type: Release
Branch: master
Hash: 64775bf91f2ccd162b0994e50db7bd1bba02151b
Python version: 3.9.5
Qt version: 5.15.2
Coin version: 4.0.0
OCC version: 7.5.2
Locale: French/France (fr_FR)

[FCuser2019]

Curious.
I followed the script exactly and saw exactly the same behavior until this step. In my case the body did not rotate when Ok was pressed.

Hello, GeneFC
Was the body still selected before pressing OK?