[Rock-dev] Change in Eigen 3.2 which breaks the base types (and maybe other packages like orientation estimator)

Alexander Duda Alexander.Duda at dfki.de
Wed Nov 27 17:22:03 CET 2013


On 11/27/2013 02:17 PM, Matthias Goldhoorn wrote:
> On 25.11.2013 11:19, Sylvain Joyeux wrote:
>> On 11/23/2013 05:07 PM, Javier Hidalgo Carrió wrote:
>>> I did not fully get the point. What is the problem of using
>>> toEulerAngles(a0, a1, a2) from Eigen?
>>> The new euler helper (base::getEuler) only computes the euler angles in
>>> ZYX in this order.
>>> There are multiple conventions for proper Euler angles.
>> Yes, and in most cases they are equivalent. We decided, once upon a time
>> to "freeze" one as the default representation so that people that "just"
>> want angles don't have to pick one.
>>
>
> @Alex: i think you are right, the result will ( and is already) 
> yaw[2]:(-pi,pi), pitch[1]:(-pi,pi), roll[0]:(-pi/2,pi/2).
> @Javier: for simplification i only choose the one we are decided in 
> rock for decomposition.
This is what I do not like about the fix. It is changing a public API 
without having a good reason. Everyone using toEuler on the ruby side 
has now to change his code.

> @Alex (regarding gimbal lock)
> The current implementation is equivalent to the old eigen 
> implementation. To be sure i don't do something else there. I would 
> simply recover the old behavior. If you know a better solution feel 
> free to add this. But nevertheless i don't know how the gimbal-lock 
> problem yould appear for a quaternion->euler, if you have a counter 
> example feel free to add it to the test suite and maybe improve the 
> current implementation. If we could go back to the eigen 
> implementation i would agree, but i don't like to "check if a axis is 
> ontop and turn every-other one", then we could really do the 
> calculation by our own...
You copied the code from eigen 3.1? If so you have to check that you 
meet their requirements for their license in the first place (there are 
no grants, etc...). Furthermore, I guess there was a good reason to 
change the behavior in 3.2. Therefore, we should also use the new 
version and only fix the output for raw,yaw,pitch.

Alex

>
> P.S. @Javier, please do not git pull if the remote i's newer, there 
> are uneeded merges in base/types...
>

-- 
Dipl.-Ing. Alexander Duda
Unterwasserrobotik

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3



More information about the Rock-dev mailing list