This bugzilla service is closed. All entries have been migrated to
Bug 1715 - Specifying angle ranges for euler angles from Matrix3
Summary: Specifying angle ranges for euler angles from Matrix3
Alias: None
Product: Eigen
Classification: Unclassified
Component: Geometry (show other bugs)
Version: 3.2
Hardware: All All
: Normal Wrong Result
Assignee: Nobody
Depends on:
Reported: 2019-05-16 01:25 UTC by Peter Milani
Modified: 2019-12-04 18:38 UTC (History)
5 users (show)

Gtest based source comparing outputs from eigen versus tf2::LinearMath. (2.13 KB, text/x-c++src)
2019-05-16 01:25 UTC, Peter Milani
no flags Details

Description Peter Milani 2019-05-16 01:25:01 UTC
Created attachment 940 [details]
Gtest based source comparing outputs from eigen versus tf2::LinearMath.

bug 947 Highlighted a problem with the angle ranges output from the Matrix3 ::eulerAngles being [0:pi]x[-pi:pi]x[-pi:pi].

My multiplication order is ZYX for a yaw, pitch, roll, however whilst it seems correct except for the limitation of my yaw to [0:pi] where I would have preferred [-pi:pi]. This has been explained in bug 947. 

I'm just wondering if a fix has be integrated outside of the unsupported libraries. Or indeed if there is a work around for older releases. 
I've tried to change the angle order to align with the ranges output, but that produces mostly wrong angles: compared to ros::tf2::LinearMath::Matrix3x3::getRPY.

My test code for ros Kinetic is attached.
Comment 1 Christoph Hertzberg 2019-05-16 15:09:06 UTC
I encourage you to try out the unsupported EulerAngles module (it is part of Eigen 3.3)
Any feedback on that module will help moving it from the unsupported to the (stable) Geometry module.

Once we integrate the EulerAngles module, we can deprecate the current eulerAngles method. As said before, I don't like changing the behavior of the existing method, since it may break existing code.
Comment 2 Gael Guennebaud 2019-05-16 15:24:08 UTC
Still same opinion on my side. If the EulerAngles module satisfies your needs, then just close this entry. Otherwise let us know how to improve it.
Comment 3 Peter Milani 2019-05-17 00:37:08 UTC
Sorry, got my versioning wrong,  I am using 3.2.94. I think its the standard ubuntu 16.04 packages.

Couldn't the just overload the existing eulerAngles with the additional functionality to specify the ranges for the different angles, (perhaps through a vector of enums, the enum being a specification of angle ranges), the default being the current functionality? That shouldn't break existing code. 

I looked through the Pull request for unsupported EulerAngles (v3.2.94 doesn't have this in unsupported). I don't particularly like the fact that a new class has been created to handle this. As stated in the comments for the PR, the angles themselves do not provide an absolute orientation in themselves but have to include a axis ordering to determine a rotation. As a result as a class EulerAngles really shouldn't sit beside Matrix3 or Quaternion types. 

I like the existing API to have extraction of EulerAngles from a Rotation Matrix, which contains the absolute orientation. It would be handy to also have extraction from a Quaternion as well. 

Thanks, its a great library except for this issue. If there's no workaround, I'll just have to keep using something else if I need euler angles.
Comment 4 Christoph Hertzberg 2019-05-17 08:05:52 UTC
Version 3.2.94 is a beta version of 3.3. If you want to stay on Ubuntu 16.04, you need to manually download/install a newer version of Eigen (we have no influence on that).

The EulerAngles class encodes the Axis-order in a template parameter which has the additional advantage of checking the validity at compile-time (I can't find which comment you are referring to).
This means, you can directly re-assign an EulerAngles object back 

Regarding extraction from a Quaternion: This is possible with the EulerAngles module in a much cleaner way. There is some unnecessary work done, but this has a much cleaner API than adding a method to every class that could be converted to EulerAngles, and if necessary, this can be optimized without any API changes.
Comment 5 Nobody 2019-12-04 18:38:50 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Note You need to log in before you can comment on or make changes to this bug.