View Issue Details
ID  Project  Category  View Status  Date Submitted  Last Update 

0025574  Community  OCCT:Foundation Classes  public  20141209 14:12  20160420 15:49 
Reporter  BenjaminBihler  Assigned To  abv  
Priority  normal  Severity  major  
Status  closed  Resolution  fixed  
Platform  Linux  OS  Debian 6.0  
Product Version  6.8.0  
Target Version  7.0.0  Fixed in Version  7.0.0  
Summary  0025574: gp_YawPitchRoll Euler Angle computation gives wrong results  
Description  If I perform a YPR rotation by hand and afterwards create a displacement transformation from the origin to the target of the rotation, I would expect it to give me the Euler angles that I have used for the rotation. It doesn't. The values differ. Please see the code below.  
Steps To Reproduce  #include <gp_Quaternion.hxx> #include <gp_Ax2.hxx> #include <gp_Ax3.hxx> void testEulerAngleRotation() { // Start with world coordinate system gp_Ax2 world; // Perform three rotations using the yawpitchroll convention. // This means: rotate around the original z axis with angle alpha, // then rotate around the new y axis with angle beta, // then rotate around the new x axis with angle gamma. Standard_Real alpha = 0.0 / 180.0 * M_PI; Standard_Real beta = 35.0 / 180.0 * M_PI; Standard_Real gamma = 90.0 / 180.0 * M_PI; const gp_Quaternion rotationZ(world.Direction(), alpha); const gp_Vec rotY = rotationZ.Multiply(world.YDirection()); const gp_Vec rotX = rotationZ.Multiply(world.XDirection()); const gp_Quaternion rotationY(rotY, beta); const gp_Vec rotZ = rotationY.Multiply(world.Direction()); const gp_Vec rotRotX = rotationY.Multiply(rotX); const gp_Quaternion rotationX(rotRotX, gamma); const gp_Vec rotRotZ = rotationX.Multiply(rotZ); gp_Ax2 result(gp_Pnt(0.0, 0.0, 0.0), rotRotZ, rotRotX); // Now compute the Euler angles gp_Trsf transformation; transformation.SetDisplacement(gp_Ax2(), result); Standard_Real computedAlpha; Standard_Real computedBeta; Standard_Real computedGamma; transformation.GetRotation().GetEulerAngles(gp_YawPitchRoll, computedAlpha, computedBeta, computedGamma); // We expect now to get the same angles as we have used for our rotations std::cout << "alpha: " << alpha / M_PI * 180.0 << " and computed alpha: " << computedAlpha / M_PI * 180.0 << std::endl; std::cout << "beta: " << beta / M_PI * 180.0 << " and computed beta: " << computedBeta / M_PI * 180.0 << std::endl; std::cout << "gamma: " << gamma / M_PI * 180.0 << " and computed gamma: " << computedGamma / M_PI * 180.0 << std::endl; }  
Tags  No tags attached.  
Test case number  bugs fclasses bug25574  

Standard_Real gamma = 90.0 / 180.0 * M_PI; using 90° in Eulerian angles sounds like a bad idea to me. Are you sure that you did not hit a Gimbal lock? 

When working with robots it is quite usual to use 90° in Euler angles. But I have changed the values in the given code to 10°, 20° and 30°. It is the same: the computed values differ from the actual rotation angles. Another case: If I set alpha = 0° beta = 0° gamma = 10°, I get computed alpha = 10° computed beta = 0° computed gamma = 0°. Such things (same values but other order) happen normally, when using wrong Euler sequences. According to my understanding, I am using the correct sequence for YPR rotations (Z, Y', X''). If I was right, the OCC computation would be wrong  probably not wrong at all, but somehow using the wrong Euler sequence... 

Branch CR25574 has been created by abv. SHA1: 8f92b6612f59e0e615bb12c911a70d910da7121a Detailed log of new commits: Author: abv Date: Wed May 6 11:26:03 2015 +0300 0025574: gp_YawPitchRoll Euler Angle computation gives wrong results DRAW command CR25574 added for testing Euler angles sequences in gp_Quaternion 

I confirm that, according to my testing, Euler sequences are not correctly applied in gp_Quaternion, alas. Have a look at DRAW command OCC25574 in the branch CR25574. It implements two checks:  For each Euler sequence, convert some quaternion (currently taken from description of 0025946) to Euler angles and back, then check that resulting transformation is the same. This check seems to pass.  For each Euler sequence, check that rotation by each single angle does not affect vector located on corresponding axis. This check fails for most sequences, however gp_YawPitchRoll (gp_Intrinsic_ZYX) is among the few looking fine... This is to be further investigated, any comments are welcome. Note that patch on 0025946 proposed by shoogen does not help. 

Since this issue has been open for half a year now, I would like to share my workaround with you. Orocos KDL (http://www.orocos.org/kdl) also has an implementation of Euler ZYX and Euler ZYZ rotations which are the most important ones when using robots. Since I have been using Orocos KDL anyway, I have switched to their implementation which works correctly. So for me it is not necessary anymore that this bug is fixed in OCC. Still I would very much appreciate if at least the functionality was removed. Then there is no danger anymore that anyone spends as much time as I did trying to use buggy methods. 

Benjamin, we will address the issue and correct OCCT code as soon as we have time. Note that you can contribute the fix if you know how this should be corrected. 

Branch CR25574_1 has been created by akz. SHA1: 9f11ec99741a0ad5d6a7dea9936969d8aefcfcda Detailed log of new commits: Author: akz Date: Tue Oct 13 10:30:52 2015 +0300 0025574: gp_YawPitchRoll Euler Angle computation gives wrong results Fixes incorrect parametrization for Quaterion <> Euler angles conversion. Cause we use 3x3 rotation matrix as a middle step of conversion, we operate with fixed coordinate system, so all Intrinsic rotation should be converted to Extrinsic rotations. 

Branch CR25574_1 is ready to review. Also, this fix resolves 0025946 bug. 

Anton, please add a test for Euler angles to ensure that calculations are correct (you can use command I pushed to branch CR25574 some time ago as starting point) 

Branch CR25574_2 has been created by akz. SHA1: 825aeb2639bc79f056baf76599895a61eddb281b Detailed log of new commits: Author: akz Date: Tue Oct 13 10:30:52 2015 +0300 0025574: gp_YawPitchRoll Euler Angle computation gives wrong results Fixes incorrect parametrization for Quaterion <> Euler angles conversion. Cause we use 3x3 rotation matrix as a middle step of conversion, we operate with fixed coordinate system, so all Intrinsic rotation should be converted to Extrinsic rotations. 

Andrey, I've added tests in QA command OCC25574. Please review branch CR25574_2. 

Branch CR25574_4 has been created by abv. SHA1: bd7cee22d738e30f579c4fc6836ae7837254b5a3 Detailed log of new commits: Author: akz Date: Tue Oct 13 10:30:52 2015 +0300 0025574: gp_YawPitchRoll Euler Angle computation gives wrong results Conversion of gp_Quaternion to and from intrinsic TaitBryan angles (including gp_YawPitchRoll) is fixed. Before that fix the sequence of rotation axes was opposite to intended; e.g. gp_YawPitchRoll (equivalent to gp_Intrinsic_ZYX) actually was defining intrinsic rotations around X, then Y, then Z. Now this is fixed, and rotations are made in correct order. Comments to gp_EulerSequence enumeration are restored (lost due to CDL extraction). Test bugs fclasses bug25574 is added to check correctness of Euler sequences, including cases from 0025574 and 0025946. 

Fix reviewed and completed (added more details in description, note in upgrade documentation, test case, restored comments to gp_EulerSequence enum). Please check compilation and new test case (bugs fclasses bug25574). Note that overall testing is not needed, since gp_Quaternion is not (yet) used in other OCCT components. 

Dear BugMaster, Branch CR25574_4 from occt gitrepository (and master from products gitrepository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode. SHA1: bd7cee22d738e30f579c4fc6836ae7837254b5a3 Number of compiler warnings: occt component : Linux: 0 (0 on master) Windows: 0 (0 on master) MacOS : 1 (1 on master) products component : Linux: 36 (36 on master) Windows: 0 (0 on master) Regressions/Differences/Improvements: No regressions/differences Testing cases: http://occttests/CR255744masterocct64/Debian7064/bugs/fclasses/bug25574.html http://occttests/CR255744masterocct64/Windows64VC10/bugs/fclasses/bug25574.html bugs fclasses bug25574: OK Testing on Linux: occt component : Total MEMORY difference: 89634546 / 89612607 [+0.02%] Total CPU difference: 19100.99999999999 / 19155.6700000001 [0.29%] products component : Total MEMORY difference: 25648679 / 25586674 [+0.24%] Total CPU difference: 8391.089999999984 / 8527.089999999978 [1.59%] Testing on Windows: occt component : Total MEMORY difference: 57244699 / 57250493 [0.01%] Total CPU difference: 17808.294154998952 / 18418.882068999024 [3.32%] products component : Total MEMORY difference: 17257139 / 17270013 [0.07%] Total CPU difference: 5751.959671299985 / 6201.835355099963 [7.25%] There are no differences in images found by testdiff. 

Dear BugMaster, Branch CR25574_4 is TESTED. 

Branch CR25574 has been deleted by kgv. SHA1: 8f92b6612f59e0e615bb12c911a70d910da7121a 

Branch CR25574_1 has been deleted by kgv. SHA1: 9f11ec99741a0ad5d6a7dea9936969d8aefcfcda 

Branch CR25574_2 has been deleted by kgv. SHA1: 825aeb2639bc79f056baf76599895a61eddb281b 

Branch CR25574_4 has been deleted by kgv. SHA1: bd7cee22d738e30f579c4fc6836ae7837254b5a3 
occt: master 4f5ad416 20151013 07:30:52
Committer: bugmaster Details Diff 
0025574: gp_YawPitchRoll Euler Angle computation gives wrong results Conversion of gp_Quaternion to and from intrinsic TaitBryan angles (including gp_YawPitchRoll) is fixed. Before that fix the sequence of rotation axes was opposite to intended; e.g. gp_YawPitchRoll (equivalent to gp_Intrinsic_ZYX) actually was defining intrinsic rotations around X, then Y, then Z. Now this is fixed, and rotations are made in correct order. Comments to gp_EulerSequence enumeration are restored (lost due to CDL extraction). Test bugs fclasses bug25574 is added to check correctness of Euler sequences, including cases from 0025574 and 0025946. 
Affected Issues 0025574 

mod  dox/dev_guides/upgrade/upgrade.md  Diff File  
mod  src/gp/gp_EulerSequence.hxx  Diff File  
mod  src/gp/gp_Quaternion.cxx  Diff File  
mod  src/IVtkOCC/IVtkOCC_ViewerSelector.cxx  Diff File  
mod  src/QABugs/QABugs_19.cxx  Diff File  
add  tests/bugs/fclasses/bug25574  Diff File  
occt: master 917cae00 20160205 08:14:03 Committer: abv Details Diff 
0025574: gp_YawPitchRoll Euler Angle computation gives wrong results  warnings Eliminate VC14 compiler warnings 
Affected Issues 0025574 

mod  src/BOPDS/BOPDS_Iterator.cxx  Diff File  
mod  src/QABugs/QABugs_19.cxx  Diff File 
Date Modified  Username  Field  Change 

20141209 14:12  BenjaminBihler  New Issue  
20141209 14:12  BenjaminBihler  Assigned To  => abv 
20141209 17:09  shoogen  Note Added: 0035226  
20141209 17:50  BenjaminBihler  Note Added: 0035229  
20141209 17:50  BenjaminBihler  Note Edited: 0035229  
20150319 22:05  kgv  Relationship added  related to 0025946 
20150419 19:11  abv  Target Version  => 6.9.0 
20150506 13:40  git  Note Added: 0040615  
20150506 13:47  abv  Note Added: 0040618  
20150506 13:48  abv  Target Version  6.9.0 => 7.0.0 
20150611 10:54  BenjaminBihler  Note Added: 0042102  
20150611 11:06  abv  Note Added: 0042103  
20150925 01:00  abv  Assigned To  abv => akz 
20150925 01:00  abv  Status  new => assigned 
20151013 10:34  git  Note Added: 0046687  
20151013 10:36 

Note Added: 0046688  
20151013 10:36 

Assigned To  akz => abv 
20151013 10:36 

Status  assigned => resolved 
20151013 10:36 

Note Edited: 0046688  
20151013 10:36 

Note Edited: 0046688  
20151013 12:20  abv  Note Added: 0046695  
20151013 12:20  abv  Assigned To  abv => akz 
20151013 12:20  abv  Status  resolved => assigned 
20151013 17:02  git  Note Added: 0046709  
20151013 17:04 

Note Added: 0046710  
20151013 17:04 

Assigned To  akz => abv 
20151013 17:04 

Status  assigned => resolved 
20151013 17:04 

Note Edited: 0046710  
20160122 13:06  git  Note Added: 0050048  
20160122 13:45  abv  Note Added: 0050050  
20160122 13:45  abv  Assigned To  abv => bugmaster 
20160122 13:45  abv  Status  resolved => reviewed 
20160122 15:04 

Assigned To  bugmaster => mkv 
20160125 17:55 

Note Added: 0050105  
20160125 17:55 

Test case number  => bugs fclasses bug25574 
20160125 17:56 

Note Added: 0050106  
20160125 17:56 

Assigned To  mkv => bugmaster 
20160125 17:56 

Status  reviewed => tested 
20160129 12:32  bugmaster  Changeset attached  => occt master 4f5ad416 
20160129 12:32  bugmaster  Status  tested => verified 
20160129 12:32  bugmaster  Resolution  open => fixed 
20160205 12:49  abv  Changeset attached  => occt master 917cae00 
20160205 12:49  abv  Assigned To  bugmaster => abv 
20160417 13:18  git  Note Added: 0052829  
20160417 13:18  git  Note Added: 0052830  
20160417 13:18  git  Note Added: 0052831  
20160417 13:18  git  Note Added: 0052832  
20160420 15:43 

Fixed in Version  => 7.0.0 
20160420 15:49 

Status  verified => closed 