There appears to be a change in behavior in how MatrixBase::eulerAngles(..) handles parameters in Eigen v3.2.0 from Eigen v3.1 and v3.0 and I'm not fully understanding what is going on. I think this is related to a change introduced with Bug 609. Is there an angle normalization of the inputs/outputs that I'm missing?

I have the following code converting a rotation matrix to Tait-Bryan angles.

Code: Select all

Matrix3d dcm;
dcm = AngleAxis(h, Vector3d::UnitZ()) // Heading
  * AngleAxis(p, Vector3d::UnitY()) // Pitch
  * AngleAxis(r, Vector3d::UnitX()); // Roll

Vector3d ea = dcm.eulerAngles(2, 1, 0);


In Eigen v3.0 and v3.1, changing h from -pi to pi and ea(0) will match it. In Eigen v3.2 though, it works for h being 0 to pi, but ea(0) and ea(2) off by pi and ea(1) is off by pi/2 when h is -pi to 0.

Examples input/output from v314 and v32 (showing degrees instead of radians for clarity)-

Code: Select all

             h  p  r
Input:       15 45 0
Output v314: 15 45 0
Output v32:  15 45 0

Input:       60 45 0
Output v314: 60 45 0
Output v32:  60 45 0

Input:       90 45 0
Output v314: 90 45 0
Output v32:  90 45 0

Input:        180 45 0
Output v314:  180 45 0
Output v32:   180 45 0

Input:       -15  45 0
Output v314: -15  45 0
Output v32:  165 135 -180

Input:       -60  45 0
Output v314: -60  45 0
Output v32:  120 135 180

Input:       -90  45  0
Output v314: -90  45  0
Output v32:   90 135 -180

Input:       -180 45  0
Output v314: -180 45  0
Output v32:    0 135 180


In eigen 3.1, eulerAngles was not consistent. Now, as explain in the doc, the angles are guaranteed to be in the range [0:pi]x[0:pi]x[-pi:pi].

I guess this is better, but I was using eulers in an optimisation around 0,0,0. The new normalisation is not nice to optimise over. I guess I'll have to use a different representation of angle and do it properly.