[Rock-dev] Change in Eigen 3.2 which breaks the base types (and maybe other packages like orientation estimator)
Matthias Goldhoorn
matthias.goldhoorn at dfki.de
Thu Nov 28 08:31:28 CET 2013
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
More information about the Rock-dev
mailing list