<p>I am learning about euler angles, and read about gimbal lock. I read that representing rotations with euler angles can always cause gimbal lock. All the examples that I saw on the internet show an example of physical gimbal mechanism. I understand how gimbal lock occurs in that mechanism. For example, if you pitch up along the Y axis 90 degrees, your X axis of rotation is aligned with Z axis or rotation which causes to lose one degree of freedom. I understand all of that in the context of that physical mechanism, however how does it relate to representing orientation of a rigid body with euler angles in general.
For example, I can always chose my rotations in the body frame (local frame). So three angles <code>alpha</code>, <code>beta</code> and <code>gamma</code> may represent a sequense of rotations - rotate by angle <code>alpha</code> along <code>X</code> axis of the body, then rotate by angle <code>beta</code> along the <code>Y</code> axis of the body, and finally rotate by angle <code>gamma</code> along the <code>Z</code> axis of the body. In that case even if you happen to rotate initially by 90 degrees and one of the body axis coincides with the global frame axis, it does not matter, because you always rotate along the local body axes, and the body frame will always be orthogonal, so you never lose a degree of freedom, hence gimbal lock never occurs. Same will work vice versa, if you always choose to rotate along global axes which remain static all the time.</p>
<p>Can someone please clarify this confusion. Is gimbal lock indeed only relevant to mechanichal gimbal or it may occur under the conditions I described above?</p>
<p>Another thing that confuses me is why these gimbal like rotations used in graphics software, like Blender, for example. In virtual environmnet like Blender, you could choose to represent the rotations in the body frame always or in the global frame always, which will again prevent gimbal lock from occuring. So why do they do it that way?</p>

CC BY-SA 4.0
2024-04-18T20:10:16.557Z
Yes, gimbal lock occurs only for gimbals. If you were to update your rotation matrix as $R' = R_z(\Delta_c) R_y(\Delta_b) R_z(\Delta_a) R$, where $R_x, R_y, R_z$ are rotation matrices along the three axes, and $\Delta_c, \Delta_b, \Delta_a$ are the angles by which you want to rotate, then you're not modeling gimbals. The "problem" is that people set $R = R_z(c) R_y(b) R_x(a)$ and perform incremental updates $(a',b',c') = (a,b,c) + (\Delta_a, \Delta_b, \Delta_c)$ which models gimbals. A common misconception is that quaternions avoid this, but you can code the same thing above with quaternions.
lightxbulb
CC BY-SA 4.0
2024-04-22T13:51:56.213Z
_A common misconception is that quaternions avoid this, but you can code the same thing above with quaternions._ But only, if you effectively still use euler angles (by calculating your quaternions on the basis of euler angles). Or maybe I'm missing something. But in general, you can avoid gimbal locks when basing your rotations on quaternions. See also [here](https://stackoverflow.com/a/30967230/6584985).
Tare
CC BY-SA 4.0
2024-04-24T12:51:34.117Z
@Tare The point was that the representation, i.e., quaternions, rotation matrices, rotors, or w/e is not the thing that causes Gimbal lock. It is the fact that one models a gimbal, by storing a triplet of angles and by incrementing those, that causes Gimbal lock. In fact Euler angles by themselves do not cause Gimbal lock - you can take any rotation matrix/quaternion/rotor and encode it in terms of Euler angles. It's the specific update rule of $(a',b',c') = (a,b,c) + (\Delta_a, \Delta_b, \Delta_c)$ that causes Gimbal lock. But that is expected as you are modeling a gimbal with the above.
lightxbulb
<transformations>
Do Euler Angles always cause Gimbal Lock?
Mykhailo Seniutovych
# Do Euler Angles always cause Gimbal Lock?

(Asked by: username_0 on 2024-04-18)

I am learning about euler angles, and read about gimbal lock. I read that representing rotations with euler angles can always cause gimbal lock. All the examples that I saw on the internet show an example of physical gimbal mechanism. I understand how gimbal lock occurs in that mechanism. For example, if you pitch up along the Y axis 90 degrees, your X axis of rotation is aligned with Z axis or rotation which causes to lose one degree of freedom. I understand all of that in the context of that physical mechanism, however how does it relate to representing orientation of a rigid body with euler angles in general.
For example, I can always chose my rotations in the body frame (local frame). So three angles `alpha`, `beta` and `gamma` may represent a sequense of rotations - rotate by angle `alpha` along `X` axis of the body, then rotate by angle `beta` along the `Y` axis of the body, and finally rotate by angle `gamma` along the `Z` axis of the body. In that case even if you happen to rotate initially by 90 degrees and one of the body axis coincides with the global frame axis, it does not matter, because you always rotate along the local body axes, and the body frame will always be orthogonal, so you never lose a degree of freedom, hence gimbal lock never occurs. Same will work vice versa, if you always choose to rotate along global axes which remain static all the time.

Can someone please clarify this confusion. Is gimbal lock indeed only relevant to mechanichal gimbal or it may occur under the conditions I described above?

Another thing that confuses me is why these gimbal like rotations used in graphics software, like Blender, for example. In virtual environmnet like Blender, you could choose to represent the rotations in the body frame always or in the global frame always, which will again prevent gimbal lock from occuring. So why do they do it that way?

**Tags:** transformations

> **Comments:**
> **username_1**: Yes, gimbal lock occurs only for gimbals. If you were to update your rotation matrix as $R' = R_z(\Delta_c) R_y(\Delta_b) R_z(\Delta_a) R$, where $R_x, R_y, R_z$ are rotation matrices along the three axes, and $\Delta_c, \Delta_b, \Delta_a$ are the angles by which you want to rotate, then you're not modeling gimbals. The "problem" is that people set $R = R_z(c) R_y(b) R_x(a)$ and perform incremental updates $(a',b',c') = (a,b,c) + (\Delta_a, \Delta_b, \Delta_c)$ which models gimbals. A common misconception is that quaternions avoid this, but you can code the same thing above with quaternions.  
> **username_2**: _A common misconception is that quaternions avoid this, but you can code the same thing above with quaternions._ But only, if you effectively still use euler angles (by calculating your quaternions on the basis of euler angles). Or maybe I'm missing something. But in general, you can avoid gimbal locks when basing your rotations on quaternions. See also [here](https://stackoverflow.com/a/30967230/6584985).  
> **username_1**: @username_2 The point was that the representation, i.e., quaternions, rotation matrices, rotors, or w/e is not the thing that causes Gimbal lock. It is the fact that one models a gimbal, by storing a triplet of angles and by incrementing those, that causes Gimbal lock. In fact Euler angles by themselves do not cause Gimbal lock - you can take any rotation matrix/quaternion/rotor and encode it in terms of Euler angles. It's the specific update rule of $(a',b',c') = (a,b,c) + (\Delta_a, \Delta_b, \Delta_c)$ that causes Gimbal lock. But that is expected as you are modeling a gimbal with the above.  

---

## 0 answers

