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

[Matthias Goldhoorn]

On 27.11.2013 17:22, Alexander Duda wrote:
> 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.
Unfortunalty yes, but noone used ever another order (yould youe exlain 
my why another decomposition order might be useful?)


>
>> @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? 
No the mathematics is the same, but it's not a copy...
> 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.
-1 for doing later conversion. Maybe the function could directly used, 
but i'm not sure about this.
If you propose another solution we could discuss this, but i'm against a 
"after eigen computes this we invert again all axis" solution.


Matthias

-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4193
  Zentrale: +49 421 178 45-6550
  Fax:      +49 421 178 45-4150
  E-Mail:   matthias.goldhoorn at uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik