Mon, 04/11/2016 - 14:52
From the release notes/upgrade guide of OpenCASCADE 7.0.0:
http://dev.opencascade.org/doc/overview/html/occt_dev_guides__upgrade.html
Correction of interpretation of Euler angles in gp_Quaternion
Conversion of gp_Quaternion to and from intrinsic Tait-Bryan angles (including gp_YawPitchRoll) is fixed.
Before that fix the sequence of rotation axes was opposite to the intended; e.g. gp_YawPitchRoll (equivalent to gp_Intrinsic_ZYX) actually defined intrinsic rotations around X, then Y, then Z. Now the rotations are made in correct order.
Applications that use gp_Quaternion to convert Yaw-Pitch-Roll angles (or other intrinsic Tait-Bryan sequences) may need to be updated to take this change into account.
What does this exactly mean? What do I have to do if I am using the methods "GetEulerAngles" and "SetEulerAngles" from gp_Quaternion when I am upgrading from 6.9.1 to 7.0.0? I am always using "gp_Intrinsic_XYZ", do I have to change this (to what?) to achieve the same results as in 6.9.1?
Regards
Thorsten
Tue, 04/12/2016 - 12:09
Dear Thorsten,
You have two options:
1. If you prefer to keep the old behavior, just replace gp_Intrinsic_XYZ by gp_Intrinsic_ZYX (which is the same as gp_YawPitchRoll) in your code (and convert value of this enum if it is stored in your data models).
You might also want to update your UI to show correct name or description of the Euler angles sequence to the user.
2. If you are bound to use of particular sequence of rotations (intrinsic XYZ) and need to be consistent with that sequence, keep using gp_Intrinsic_XYZ but revert the sequence of angles if it is stored in your data models (swap X and Z angles).
Best regards
FSR
Fri, 04/15/2016 - 09:34
I am calculating Euler Angles for a Kuka Robot (ABC). From the robot point of view the angles were "correctly" calculated with 6.9.1 and gp_Intrinsic_XYZ. Because of this I changed the sequence to gp_Intrinsic_ZYX in 7.0.0 (first case). The angles did not change and the robot is moving again.
Thank you for the clarification :-)
Thorsten
Fri, 04/15/2016 - 10:22
Hi Thorsten,
I had reported the bug, because KUKA robots use ZX'Y'' (intrinsic) Euler Angles, but gp_Intrinsic_ZYX did not give the right results. Now we can use the Euler Angles that fit to the KUKA documentations. :-)
Benjamin