Re: [eigen] Creating a EulerAngle object

[Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>]

On 20.02.2012 21:08, hamelin.philippe@xxxxxxx wrote:
> However, I have so much place in my GUIs and configuration files that user can input angles using the well-known roll-pitch-yaw representation.

In which of the 12 well-known Euler representations? I find one of the 
most annoying things about using Euler angles as interface is that you 
always need to specify how exactly angles are interpreted.

>  Currently, I must use a Vector3d to store these angles, and then as soon as I can I convert them in a more programmatically convenient representation (e.g. quaternion). However, in the glue code between the configuration object and the actual algorithm, I always have to explicitely use angleVector[0], angleVector[1] and angleVector[2] to respectively access to roll, pitch and yaw. I would like to create a new EulerAngle (or more precisely RollPitchYaw) object to make this less error prone. My requirements are:
>
> 1. Create a EulerAngle object from scalars Roll, Pitch and Yaw, or any other rotation object (Matrix3d, Quaternion, AngleAxis, ...);

Well, you can create a Vector3d from three scalars, and there is a 
method eulerAngles() to convert a 3x3 matrix to Euler angles:
http://eigen.tuxfamily.org/dox-devel/group__Geometry__Module.html#gad118fececd448d7485ffea4858775e5a

I would say that placing that into MatrixBase and not into RotationBase 
might not be the best idea. And for any representation except 3x3 
matrices, one could easily implement some glue-code first transforming 
it via a 3x3 matrix until someone bothers to implement a direct 
conversion (I guess speed is not the matter for situations where Euler 
angles are used).

> 2. Convert the EulerAngle to any other rotation object;

Yes, it would definitely be more convienent to have a method for that 
instead of handcoding something like this every time:
http://eigen.tuxfamily.org/dox-devel/TutorialGeometry.html#TutorialGeoEulerAngles

> 3. Access to internal angles with named method such as: roll(), pitch() and yaw(), or maybe rx(), ry(), rz();

You can access the elements of a Vector3d via .x() .y() and .z() already 
-- I wouldn't say that the additional r adds much clarity.

> 4. (Nice to have) Be able to use the EulerAngle in any rotation arithmetic (e.g. result = quaterion1 * eulerAngle * affine3d);

I guess this more or less can be solved by solving 2, i.e. just convert 
to a 3x3 matrix (or whatever) temporarily.

> Looking the at the page "Extending Eigen" (http://eigen.tuxfamily.org/dox-devel/TopicCustomizingEigen.html<http://eigen.tuxfamily.org/dox-devel/TopicCustomizingEigen.html>  ), i'm not really sure that I want to inherit directly from Matrix and then re-implement everything. I guess the good way is to inherit from RotationBase much the same way as the Quaternion object. Am I wrong?

I agree that inheriting from RotationBase is better. I think beneath the 
scalar type you should encode the axis-order using three template 
parameters (maybe defaulting to "the most common" convention).


Christoph



--
----------------------------------------------
Dipl.-Inf. Christoph Hertzberg
Cartesium 0.051
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: (+49) 421-218-64252
----------------------------------------------