I'm learning about unit quaternions and how to use them to represent and compose rotations. Wikipedia says they are more numerically stable than matrix representations, but doesn't give a reference. Can anyone explain to me (preferably with some mathematical reasoning) why it is more numerically stable to use unit quaternions to deal with rotations (e.g. for an OpenGL application) rather than rotation matrices? Is it just because gimbal lock is avoided?
Asked
Active
Viewed 5,825 times
12
5 Answers
9
That Wikipedia article is biased. From
as of Apr 18, 2014:
When composing several rotations on a computer, rounding errors necessarily accumulate. A quaternion that’s slightly off still represents a rotation after being normalised: a matrix that’s slightly off may not be orthogonal anymore and is harder to convert back to a proper orthogonal matrix.
This is biased. There is nothing hard about re-orthogonalizing a rotation matrix, see for example:
and Quaternions have to be re-normalized too: "A quaternion that’s slightly off still represents a rotation after being normalised". Quaternions don't have a significant advantage here.
I will try to fix that in Wikipedia. This biased opinion shows up in Wikipedia at other places as well... :(
That answers your question.
UPDATE: I have forgotten to mention: gimbal lock doesn't play a role here; neither quaternions, nor rotation matrices suffer from this.
Some side notes. Even though quaternions are more compact than rotation matrices, it is not at all a clear cut that using quaternions will result in less numerical computation in your application as a whole, see:
Just for the record: rotation matrices have been used with great success on resource constrained micro-controllers to track orientation, see Direction Cosine Matrix IMU: Theory by William Premerlani and Paul Bizard. I also have first-hand experience in tracking orientation on a micro-controller (MSP430) and I can only second that rotation matrices are fast and stable for tracking orientation.
My point is: there is no significant difference between rotation matrices and quaternions when used to track orientation.
If you already have a library that uses quaternions to represent rotations then stick with quaternions; if your library already uses rotation matrices, then use rotation matrices. Even if one representation would save you some floating-point operation here and there, there is no point in changing your application / library to use the other representation; even on resource-constrained micro-controllers, the savings would be insignificant.
The only true advantage of quaternions that I see is that quaternions can be used for interpolation. Neither rotation matrices, nor Euler angles can do that.
-
1It's funny that you mention bias. It's much more difficult to reorthogonalize a drifted rotation matrix without introducing bias. QR decomposition privileges lower-numbered axes over higher-numbered ones, boosting rotation about those axes while sapping it from the others and causing the overall axis of rotation to drift. Quaternion normalization is more effective at maintaining the axis of rotation over repeated projections onto the rotation space. – Sneftel Apr 18 '14 at 10:08
-
1@Sneftel I used the orthogonalization procedure detailed [here](http://stackoverflow.com/q/23080791/341970) in my orientation tracking application and the application was accurate. I didn't experience the *"much more difficult to reorthogonalize a drifted rotation matrix"* you claim and I am talking about first-hand experience here. Do *you* have first-hand experience in re-orthogonalizing rotation matrices in applications for tracking orientation? – Ali Apr 18 '14 at 10:14
-
2Your technique does look reasonable, and I'd have to puzzle through it to figure out what the semantics of the bias would be. Note, however, that you're throwing out all information contained in the old Z-vector, but not in the old X- and Y-vectors, so there's still bias there. And yes, I do have experience in the area. – Sneftel Apr 18 '14 at 10:23
-
1@Sneftel Correct, but that loss of information doesn't matter. Based on ground truth experiments, the application was found to be accurate *and* the dominant source of errors was the temperature-dependent offset error of the accelerometers and gyros. In other words, there is no point is worrying about the tiny inaccuracies of the orthogonalization procedure; the hardware errors were at least an order of magnitude higher, totally dominating the overall error. – Ali Apr 18 '14 at 10:41
-
3Well, sure, if you've got integration drift to worry about then numerical stability is the least of your concerns. There's no reason to think that that's the OP's application, though. – Sneftel Apr 18 '14 at 10:47
-
1@Sneftel OK. Although, in simulations, I didn't notice that the orthogonalization procedure I link to had any noticeable defect. Let's close this discussion here; we indeed do not know what the OP's application is. – Ali Apr 18 '14 at 10:54
5
Not sure if this will be mathematical enough for your taste, but I'll give it a shot anyway: The problem with a rotation matrix is that it contains redundant information. You have 9 values that encode a transformation with only 3 degrees of freedom.
Due to this redundancy, there are constraints on the 9 values in a matrix to form a valid rotation matrix. The matrix has to be orthogonal, meaning that the row vectors need to be orthonormal (each vector has length 1, and the scalar product of each pair is 0).
As you update the rotation matrix, typically by concatenating it with incremental rotation matrices, numerical errors get introduced. These errors accumulate with each update. Unless you do something about it, the row vectors go farther and farther away from being orthonormal. Once the matrix is far enough away from being orthogonal, it can start to visibly deform the geometry that it's applied to (skew, scaling, etc).
You can avoid these problems when using rotation matrices by periodically orthonormalizing the row vectors. It just takes some simple vector operations to do that, so it's no big deal.
Reto Koradi
- 53,228
- 8
- 93
- 133
2
"Gimbal lock" is a red herring -- neither matrices nor unit quaternions are inherently subject to gimbal lock.
Matrices actually have a small advantage over quaternions in maintaining numerical stability over a sequence of rotations, since fewer FP operations are required to produce each element in the matrix product. Quaternions have a slight advantage in the ease of correcting numerical drift (to really do a good job of it for matrices, you need to do a SVD).
Honestly, though, it's unlikely to make a big difference for your application, and the theory behind the numerical stability stuff gets pretty hairy. If you're really interested in the area, I can recommend Higham's Accuracy and Stability of Numerical Algorithms.
Sneftel
- 40,271
- 12
- 71
- 104
-
*"to really do a good job of it for matrices, you need to do a SVD"* No, you don't. That would be indeed expensive. In my first-hand experience, the orthogonalization procedure I link to in my answer is already pretty good in practical applications. No doubt, not as accurate as SVD but I claim (from first-hand experience) that the sensor reading errors totally dominate the overall error in an orientation tracking application. There is no point in making the orthogonalization more precise with SVD or QR, it won't make the application more accurate. – Ali Apr 18 '14 at 10:50
0
I have an application where I have a "car" following a spline. I compute the derivative of the spline to define a forward vector, then I compute left and up vectors to create an orientation matrix. Then I decompose it into a quaternion.
When I turn these quaternions into keyframes in the animation, there are some turns where the Q_z flops from -1 to 1. I have not yet researched how to get blender's python library to give me a decomposition that is stable over small changes.
Mutant Bob
- 3,121
- 2
- 27
- 52
-2
Use of unit quaternions can be numerical unstable more than matrixes.
1. If you convert unit quaternion and assume it is unit (not weighting coeficients by squared magnitude) than you can get dramatical error. And if you convert from broken matrix back to quaternion and vise versa, you can reach unstable rotation very quickly.
- Sequential multiply of quaternions, drift them to nonunit length. And as previous can produce broken matrix.
To avoid this errors, you should normalize quaternions after every operation producing roundoff errors. Or assume your quaternions as nonunit, and convert to matrix with weighting (about additional 8flops ).
NOTE: many operations are performed faster that with unit, for example convertion from matrix.
minorlogic
- 1,872
- 1
- 17
- 24