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