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?
The advantage of quaternions over matrices is not only faster computation, but mostly because a matrix representation of successive rotations around arbitrary angles eventually give in to dreadful floating-point round-off errors and no longer represent proper, affine rotations.
For quaternions versus a 3x3 rotation matrix, the quaternion has the advantage in size (4 scalars vs. 9) and speed (quaternion multiplication is much faster than 3x3 matrix multiplication). Note that all of these representations of rotations are used in practice.
The only way to avoid gimbal lock is to use quaternion instead of euler to represent rotations. In this specific situation, unless both rotate manip and direction manip use quaternion, the gimbal lock behavior can NOT be avoided.
Quaternions consume less memory and are faster to compute than matrices.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With