[Rock-dev] Change in Eigen 3.2 which breaks the base types (and maybe other packages like orientation estimator)
Javier Hidalgo Carrió
javier.hidalgo_carrio at dfki.de
Thu Nov 28 10:05:22 CET 2013
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
>
>
More information about the Rock-dev
mailing list