I've got an app that uses quaternions, and I'd like to convert each quaternion to the corresponding Euler angles. The issue is, when I convert them, the roll and yaw are bounded within 360 degrees (i.e, when the previous Euler angle was at 179.9, the next one jumps to -179.9).
I'd like to figure out a way to avoid this jump, and I was wondering if a single quaternion stores the cumulative rotation when converting. i.e, I would calculate the "remainder" angle the way I am currently, and I would use another function to calculate how many 360 degree rotations to offset it by.
I've done some quick experiments, and it seems rotating a quaternion by 360, 720, and 1080 about an arbitrary R3 axis yields distinct quaternions, except for the case of a scalar quaternion.
Can anyone point me in the right direction?
No, a quaternion doesn't store the cumulative rotation. There is a subtlety here, in that a quaternion can tell the difference between $0^\circ$ and $360^\circ$ in principle, and that might give you some false hope! However, as Muphrid points out, a quaternion can't tell the difference between $0^\circ$ and $720^\circ$. Moreover, depending on your software library, you can't necessarily count on the ability to distinguish between $0^\circ$ and $360^\circ$ in practice either.
If you absolutely must avoid the jumps, you can try phase unwrapping. This is straightforward for 2D rotations: just get the current angle, and then add or subtract $360^\circ$ in order to minimize the distance to the previous angle. For 3D Euler angles, it gets trickier, since you have to deal with additional identities like $(180^\circ,180^\circ,180^\circ)=(0^\circ,0^\circ,0^\circ)$, and there may be problems near gimbal lock. I'm not sure how to implement this, but I hope that helps!