Quaternions and numerical stability

Question

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?

Answer 1

If the (direction, angle) representation of the 3D rotation is extensively used, then the conversion from the rotation matrix needs a search for the eigenvalues for the symmetric matrices, while getting the same from the quaternion is simple. It may make a lot of sense when using Kalman Filters, that exploit SO3 manifold, like Unscented Kalman Filter on Manifolds, or other algorithms that use SO3 tangent space (so3).

https://www.researchgate.net/publication/51915120_Integrating_Generic_Sensor_Fusion_Algorithms_with_Sound_StateRepresentations_through_Encapsulation_of_Manifolds

Answer 2

That Wikipedia article is biased. From

• http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Advantages_of_quaternions

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:

• Eigen - Re-orthogonalization of Rotation Matrix

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:

• http://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation#Performance_comparisons

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.

• Interpolating between rotation matrices

Answer 3

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.

Answer 4

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.

1. 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.

Answer 5

"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.

Answer 6

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.