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.
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.
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.
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.
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.
-- GitLab Migration Automatic Message --
This bug has been migrated to gitlab.com'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: https://gitlab.com/libeigen/eigen/issues/1715.