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

[Javier Hidalgo Carrió]

On 11/28/2013 08:31 AM, Matthias Goldhoorn wrote:
> 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 Since Eigen is the main algebra library in rock. We should play nice 
with it.
Please, remember that we never agreed that Euler angles is the main 
convention to propagate rotations. As far as I know quaternions is the 
convention for that. Therefore, it is not a big deal. The rock 
convention (yaw, pitch and roll with [-pi, pi] [-pi/2, pi/2] [-pi,pi]) 
would only apply when displaying rotations (i.e: ruby plotting and 
orientation vizkit plugin). Suggestion: Why we do not make this getEuler 
in the ruby side and no as C++ method?

Javier.
> -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
>