[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 09:26 AM, Matthias Goldhoorn wrote:
> On 28.11.2013 09:19, Javier Hidalgo Carrió wrote:
>>>> 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?
> Also you using the extraction (not from base types) to get eulers 
> within your filter code.
This is a different thing. As long as they use the same order and 
convention within the library. It should be fine.
> Of course the way to represent orientations are quaternions. But 
> sometimes you need euler as you already know. So from my point, if 
> someone would again refractor this method it should be done in c++ and 
> there should be a ruby binding for this.
>
> Maybe some of you could propose a solution that uses eigen for doing 
> the conversion, so that we then discuss this solution?
@Matthias. Don't misunderstand me. The solution you proposed is 
perfectly valid. Thanks for reporting the change in Eigen.
The suggestion was: Do you think it should be in the C++ or in the ruby 
side? Your answer is both sides. I wasn't sure.

Javier.

>
> Matthias
>>
>> 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
>
>