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: [email protected] Weitere Informationen: http://www.informatik.uni-bremen.de/robotik _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
