Added direct quaternion to euler transformation and solved issue #53#54
Added direct quaternion to euler transformation and solved issue #53#54evbernardes wants to merge 2 commits intomatthew-brett:mainfrom
Conversation
|
Thanks for this. Yes, in general, that sounds like a good idea. Could you say more about what you mean for the axes checking functions? Sorry to be slow - I haven't touched this code in a long time. |
Thanks for your reply! It's a very silly thing at the beginning: the test to check if the input For example, |
|
I think that would just be a case of checking |
Alright, just changed it! It just tries to access it to have a Also, sorry if the code looks too much like the one from SciPy, it's because I wrote both! |
| if symmetric: | ||
| k = 6 - i - j # get third axis | ||
|
|
||
| # Step 0 |
There was a problem hiding this comment.
Forgive my ignorance, but is this the same as the parity check returned from _AXES2TUPLE?
There was a problem hiding this comment.
No, this is to get the third axis for symmetric sequences.
For example, for the sequence 'zyz', at first we have i, j, k == 3, 2, 3.
The third axis (the axis we don't have) is 1. Since i, j, k can only be 1, 2 or 3, we know that i + j + k_new == 6.
So: k_new = 6 - i - j gets this other axis.
|
@evbernardes did you take a look into the ROS Stack ROS used in robotics? Its |
Hey there! I didnt yet, but I am planing to! Are you familiar with where exactly it's implemented in the Ros stack? |
You transform a quarternion The implementation is in |
Brief description
I recently published an article about a direct formula for the conversion between a quaternion variable to Euler angles in any sequence, which can be read here (Open Access).
Compared to either having 12 separate formulas (or 24, taking into account both intrinsic and extrinsic rotations) or using the well known quaternion-to-matrix-to-euler method, this has 3 main advantages:
SciPyand intransforms3d, for example).Because of points 1 and 2, it has already been merged into Scipy. Because point 3, it has also been merged into SymPy.
I truly believe it's the best possible way to do this conversion, so I'm trying to contribute it to as many open source projects I can!
Other comments
Apart from the execution time advantages, this also has other numerical advantages. The main one is that the only inverse trigonometric function used is
arctan2instead ofarccosandasin, which is always preferred when bothsinandcosare known (arccos, for example, can give much higher errors near0).It also fixes issue #53.
I left the other method (plus a correction as explained in #53) for testing purposes, but I'd argue that in the future this should be removed.
What is not implemented
I don't know exactly how to to use the axes checking functions already existing in
transforms3d, so if someone helps me with that, we could also add that at the beginning!