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