<p>Gimbal lock is your item 1. It is the situation where we have rotated our 2nd axis (in the order of application of the three axes) by ±90 degrees, which aligns the 1st axis and the 3rd axis together, so that rotating either one of them does the same thing. From that position, there are some directions we cannot rotate in.</p>
<p>For a concrete example, let's say we apply rotations in the order of roll, pitch, yaw. If I have pitched up by 90 degrees, so that my aircraft (or whatever) is pointing straight up, then rolling will rotate about the global vertical axis (because I'm pitched straight up), and yawing will also rotate around the global vertical axis (as it always does). From this position I am able to roll and pitch, but what I <em>can't</em> do is tilt the aircraft to its local left or right. I would have to pitch away from that 90 degree position by some distance, and then &quot;circle around&quot; so to speak in order to get to the left- or right-tilted position. (This is the situation represented in the .gif that lightxbulb posted.)</p>
<p>Item 2 isn't the same thing as gimbal lock, but is affected by it. It is a property of interpolating in Euler angles in general. If you move from your initial to your target rotation by, say, linearly interpolating each of the three Euler angles individually from its initial value to its target value, then in general the path taken will not be the shortest path through the space of rotations to the target—and it may look odd to the eye, perhaps appearing to rotate in the &quot;wrong&quot; direction at first and then circle around to come at the desired target orientation from a different angle.</p>
<p>This happens to some extent for almost any choice of initial and target orientations, but it gets worse if the path taken approaches close to a gimbal lock configuration. This can happen if the initial or target orientation is a gimbal lock configuration, or if we happen to pass through a gimbal lock configuration (or close to it) in the middle of the interpolation. When that happens, we will get particularly strange-looking &quot;wrong&quot; rotation paths. If we don't happen to get near a gimbal lock configuration, then the &quot;wrongness&quot; won't be so clearly visible, or may go unnoticed entirely.</p>
<p>An analogy that may help is to think about the Earth's surface with latitude and longitude coordinates, and what happens if you generate a path between two points on Earth by interpolating the latitude and longitude individually. You can see that things may get weird if the path gets close to the poles, where the coordinate system has a singularity. That is very analogous to how gimbal lock configurations are singularities in the Euler angle coordinate system. These singularities can be resolved by using quaternions, which would be analogous to representing points on the Earth's surface using Cartesian xyz vectors instead of latitude/longitude.</p>

CC BY-SA 4.0
2021-10-25T06:08:23.327Z
Yes this is a good answer you should just stress that it only affects you if you interpolate in euler angles. None of the tasks op says indicate that he is interpolating in euler angles.
joojaa
CC BY-SA 4.0
2021-10-25T06:17:11.797Z
Can i insert images from [this post](https://computergraphics.stackexchange.com/questions/4436/how-to-achieve-gimbal-lock-with-euler-angles/4438#4438) here? They seem appropriate
joojaa
CC BY-SA 4.0
2021-10-25T16:32:48.463Z
@joojaa Sure, go for it!
Nathan Reed
CC BY-SA 4.0
2024-04-18T15:47:13.333Z
Sorry maybe you can clarify this - "and yawing will also rotate around the global vertical axis (as it always does)`" - what if I choose to always rotate in the body frame, I pitch 90 degrees, than rolling will rotate along global Z axis and yaw will rotate along global X axis (this is because I chose to always represent my rotations in local or body frame). Is my understanding correct that gimbal lock will never occur with this convention?
Mykhailo Seniutovych
CC BY-SA 4.0
2024-04-18T23:46:52.377Z
@MykhailoSeniutovych, sure, but then you are not really using Euler angles. You would need to represent the rotation in some other way (e.g. quaternion) and then accumulate rotations by multiplying onto the quaternion; multiplying in one order would make the rotations always in body frame, and the other order would make them always in global frame.
Nathan Reed
CC BY-SA 4.0
2024-04-19T06:37:49.230Z
@NathanReed thanks for the response. I'm still a bit confused. How come what I described is not Euler Angles? From what I read everywhere on the internet Euler Angles is about rotating three times along three axis around local or body frame, and you can choose different sequences (XYZ, ZYX, ZXZ, etc.) in which sequence you rotate, even Wikipedia says it here
https://en.wikipedia.org/wiki/Euler_angles
So if I choose XYZ convention - rotating along X, Y and Z axes of a body frame, by three angles, gimbal lock will never occur, because I always rotate in local frame.
Mykhailo Seniutovych
CC BY-SA 4.0
2024-04-19T06:44:13.663Z
So it seems to me gimbal lock is only relevant when you model your rotations similar to a real physical gimbal mechanism. But why would you do it this way? You can just model it as three angles in the body or global frame, convert it to three rotation matrices, then compose a single transformation matrix from them. And then you can use it instead of quternion and avoid gimbal lock. I asked this question separetely already, if you want to answer I will vote you up
https://computergraphics.stackexchange.com/questions/14020/do-euler-angles-always-cause-gimbal-lock?noredirect=1#comment21906_14020
Mykhailo Seniutovych
CC BY-SA 4.0
2024-04-27T06:02:20.687Z
@MykhailoSeniutovych With Euler angles you have three angles that you're always applying in a fixed order, like XYZ. You pick one order and stick with it. If you always rotate in local frame then you accumulate more axes onto the list, like XYXZYZX...etc depending on what rotations you did. You can't trivially collapse that back down into just XYZ again.
Nathan Reed
CC BY-SA 4.0
2024-04-27T06:04:46.427Z
"Model your rotations similar to a real physical gimbal" is exactly what Euler angles is. As for "why would you do it this way", well, it's a good representation for some things and not a good representation for other things.
Nathan Reed
CC BY-SA 4.0
2021-10-24T21:20:52.330Z
2021-10-24T21:28:13.243Z
2021-10-24T21:28:13.243Z
Nathan Reed
<p>Maybe it's also worth considering why people find gimbal lock &quot;wrong&quot; even when they do not know what gimbal lock is. This suggests some intuitive expectation that doesn't align with what Euler angles do (i.e. they actually do not want to work with gimbals). It begs the question how this natural expectation may be fulfilled instead.</p>
<p>Assume you are given a joystick to control an airplane's orientation (you are in the airplane), but make it special so that the stick can also be rotated around its axis to achieve a yaw rotation. Store the set of orthonormal vectors describing the orientation of the plane <span class="math-container">$e_1,e_2,e_3$</span> and identify the stick's current direction with <span class="math-container">$e_2$</span>. Now let the airplane's computer record the airplane's basis <span class="math-container">$e_1, e_2, e_3$</span>, and the stick's direction <span class="math-container">$d$</span>, every <span class="math-container">$x$</span> seconds and keep its last two states: previous <span class="math-container">$p$</span> and current <span class="math-container">$c$</span>. Assume you have tilted the stick from <span class="math-container">$e_2$</span> in <span class="math-container">$p$</span> to <span class="math-container">$e'_2$</span> in <span class="math-container">$c$</span>. Intuitively one wants to align the plane so that <span class="math-container">$e'_2$</span> is the plane's &quot;up&quot; again. This can be done by rotating the previous basis <span class="math-container">$e_1, e_2, e_3$</span> along the shortest path as to align <span class="math-container">$e_2$</span> to <span class="math-container">$e'_2$</span>. This can be achieved using the following formula:
<span class="math-container">$$e'_i = e_i - \frac{e_i \cdot e'_2}{1 + (e_2 \cdot e'_2)}(e_2 + e'_2), \, i \in \{1,3\},$$</span>
and the vectors have to be further normalized. This yields a new basis <span class="math-container">$e'_1, e'_2, e'_3$</span> that you align your airplane to. This has a singularity if you allow your joystick a range of motion of 180 degrees, since if in <span class="math-container">$c$</span> you recorded <span class="math-container">$e'_2 = -e_2$</span> it is not clear along which rotation you reached it (all rotations are equal then: 180 degrees around any axis perpendicular to <span class="math-container">$e_2$</span>, and there are infinitely many such axes). A solution is to either disallow 180 degrees tilts (which holds for actual joysticks), poll your joystick state more often than every <span class="math-container">$x$</span> seconds so it would be physically impossible to flip it by 180 degrees between polling in <span class="math-container">$p$</span> and <span class="math-container">$c$</span>, or set a &quot;default&quot; flip rotation, e.g. <span class="math-container">$e'_1 = e_1, e'_2 = -e_2, e'_3 = -e_3$</span> which rotates around <span class="math-container">$e_1$</span> whenever <span class="math-container">$e'_2 = -e_2$</span> in <span class="math-container">$c$</span> (your airplane becomes reversed, but any other axis perpendicular to <span class="math-container">$e_2$</span> would work). Now what should be done about the yaw rotation induced by the rotation of the stick around its axis? One option is to rotate around <span class="math-container">$e'_2$</span>. Note that the above combination of operations do not lead to gimbal lock ever, since it's not a gimbal configuration of rotations in the first place. In all states you get the exact same &quot;intuitive&quot; behaviour.</p>
<p>Note that one could have chosen a different vector <span class="math-container">$d$</span> instead of <span class="math-container">$e_2$</span> to correspond to the joystick's direction and the idea remains the same. The point is that the two rotations - one induced from the tilting of <span class="math-container">$d$</span>, and one induced from the rotation of <span class="math-container">$d$</span> around its axis, are different in behaviour, but at least for flight sims/joystick that seems to be the intuitive expected behaviour. You can achieve the same thing by using a keyboard too, e.g. up/down corresponds to tilting the stick forward/backward, left/right = tilting left/right, some other two keys for the clockwise and counter-clockwise rotation around its axis.</p>
<p>Now forget the airplane and joystick setting, and assume you were given an actual physical 3-gimbal as a controller. In that scenario it is likely that you would not find the joystick behaviour intuitive but the 3-gimbal one, in which case it would make sense to use Euler angles. The point is that the gimbal lock by itself isn't the issue, it's the mismatch between expectations and how a system operates. That is, if I give you a joystick controller and it acts like a 3-gimbal virtually (i.e. I use Euler angles), or if I give you a 3-gimbal controller and it acts like a joystick (i.e. I use the shortest rotation described for the joystick), you will likely find both confusing. All in all, I would say this issue arises simply because people apply the wrong mathematical model to what they envision, i.e. it doesn't model their expectations but something else instead. Speaking of which, I haven't seen any 3-gimbal PC controllers. Using those, Euler angles ought to make perfect sense.</p>
<p>TLDR:</p>
<p>In order to achieve incremental rotations while avoiding gimbal lock don't do this:</p>
<pre><code>pitch += incr_pitch; yaw += incr_yaw; roll += incr_yaw;
R = Rz(roll) * Ry(yaw) * Rx(pitch);
</code></pre>
<p>Some alternatives are to store the orientation matrix <span class="math-container">$R$</span> and modify it by the desired incremental change:</p>
<pre><code>R = Rz(incr_roll) * Ry(incr_yaw) * Rx(incr_pitch) * R;
</code></pre>
<p>Another very convoluted and inefficient option, which nevertheless doesn't exhibit gimbal lock and thus illustrates that the issue is the incrementing of <code>pitch, yaw, roll</code> and not the storage of Euler angles, is the following:</p>
<pre><code>R = Rz(incr_roll) * Ry(incr_yaw) * Rx(incr_pitch) * Rz(roll) * Ry(yaw) * Rx(pitch);
(pitch,yaw,roll) = extract_Euler(R)
</code></pre>
<p>A different alternative is to use quaternions in the exact same way as the second snippet (<code>q</code> is assumed to be stored):</p>
<pre><code>q = quat(incr_roll/2,(0,0,1)) * quat(incr_yaw/2,(0,1,0)) * quat(incr_pitch/2,(1,0,0)) * q;
</code></pre>
<p>This also provides a counterexample to a common misconception that you cannot get gimbal lock by using quaterions. The below snippet will exhibit gimbal lock:</p>
<pre><code>pitch+=incr_pitch; yaw+=inct_yaw; roll+=incr_roll;
q = quat(incr_roll/2,(0,0,1)) * quat(incr_yaw/2,(0,1,0)) * quat(incr_pitch/2,(1,0,0));
</code></pre>
<p>The point I am trying to make is that the issue arises when incrementing Euler angles and then producing a rotation from those. The increment results in a behaviour consistent with turning a specific gimbal from a 3-axis gimbal, and not with the controls of an airplane for example. For the latter one has to produce the increment through matrix/quaternion composition with the orientation, or the trick that I suggested:</p>
<p><span class="math-container">$$e'_i = e_i - \frac{e_i \cdot e'_2}{1 + (e_2 \cdot e'_2)}(e_2 + e'_2), \, i \in \{1,3\},$$</span></p>

CC BY-SA 4.0
2021-10-27T17:41:14.930Z
The problem as i see it is that people expect to have the cake and eat it too. So the real problem is that if i have a real spherical object and roll it around on the floor, theres no way for me to know how many full revolutions its gone between then and now. But on a computer you just have for some reason be able to express the integral without having to integrate it so to speak. So the unwillingness to actually position stuff with an axis or so is the cause of this. So why do we use these? maybe Rotors? Anyway we should stop thinking in 2D when doing 3D
joojaa
CC BY-SA 4.0
2021-10-27T17:48:06.383Z
Also maybe we should make a plan for a 3D gimbal controller. Its just a bit on the hard side to get your hands on say 6-8 mm slip rings with encoders.
joojaa
CC BY-SA 4.0
2021-10-27T21:07:09.320Z
@joojaa Yes indeed, sometimes it's unwillingness to specify a rotation axis. On the other hand even without a specific axis `R = Rz(incr_roll) * Ry(incr_yaw) * Rz(incr_pitch) * R;` doesn't cause gimbal lock (at least not in the usual sense). Honestly I cannot tell why incrementing the pitch/yaw/roll was ever a thing for modeling relative rotations when it comes to anything but gimbals. As far as rotors go, one can show that those are equivalent to quaternions, axis-angle representations, and matrix rotation from axis angle (which can also be translated in the language of Euler angles).
lightxbulb
CC BY-SA 4.0
2021-10-27T21:20:32.577Z
offcourse they are equivalent. Once you eliminate the deficiency of having a space that is really unoptimal and come closer to something that behaves like a space rotation its going to be equivalent. But really we should also get the gui tools to align to the model. Quats are a bit hard to visualize, and for some reason nobody uses axis angles. So we should get rid of the angular represation tendency. Its probably not good for us.
joojaa
CC BY-SA 4.0
2021-10-27T21:37:52.430Z
@joojaa Rotation quaternions (i.e. versors) are conceptually the same as axis-angle rotation, the fact that they are 4D shouldn't be an issue with the visualization since ultimately they represent a rotation by $\alpha$ around an axis $\vec{u}$: $(\cos(\alpha/2), \sin(\alpha/2) \vec{u})$. From my experience relating to the 4D visualization doesn't lead to any notable insights. Similarly you can construct a matrix from an axis angle, and you can even interpret a matrix from Euler angles as an axis-angle rotation. Those are homomorphic, so you can do the same things with all (the price differs).
lightxbulb
CC BY-SA 4.0
2021-10-27T21:43:27.180Z
Yes thats what i said if they perfectly model x they are equivalent a d have same properties. But im more concerned with the fact that no software tries to visualize any of the other options. Always a angle ball. It would be better ef users were more tuned to how the system actually works than tow they think it does. Its really hard to imput a quat with that visualisation. Though maybe axis angles then. Obviously all space rotations can be expressed as matrices.
joojaa
CC BY-SA 4.0
2021-10-27T21:45:01.447Z
@joojaa Ah, this is what you meant. I have not much experience with rendering software. But at least physical joysticks coupled with a flight sim act like the other option.
lightxbulb
CC BY-SA 4.0
2021-10-27T21:47:45.883Z
Yes, sortof they work same as a euler rotation would too if you were to reset it after every update. Im afraid its still a bit bad intuition for humans
joojaa
CC BY-SA 4.0
2021-10-25T08:06:35.887Z
2021-10-27T22:29:05.257Z
2021-10-27T22:29:05.257Z
lightxbulb
<p>I am trying to understand exactly what is happening when Gimbal lock occurs. I have read many explanations now which provide the high-level idea, in that Gimbal lock occurs when two axes are aligned during the sequence of three rotations. But I am struggling to understand what this really means in terms of the calculations that are going on.</p>
<p>Here's my understanding of the setup. We have an initial 3D rotation of a body, and a target 3D rotation of that body, and we want to move the body from the initial to the target rotation. To do this, we calculate the Euler angles representing this rotation. (I don't know the maths behind this, but I will assume that this is just an algorithm that takes in an initial and target rotation, and returns a third rotation).</p>
<p>So, we now have a rotation expressed as Euler angles, which we want the body to move over. And now I will explain my confusion. From what I have been reading, there are two ideas:</p>
<ol>
<li>Gimbal lock occurs when two of the axes become aligned, during the sequence of three rotations, which means that there is one axis about which rotation cannot occur.</li>
<li>Due to Gimbal lock, the path which the rotation occurs over will not be &quot;straight&quot;, and there will be a curve.</li>
</ol>
<p>This to me is very confusing. 1) is saying that Gimbal lock means that we cannot rotate the body along a certain axis. 2) is saying that Gimbal lock means that we can rotate the body, but that the path will not be &quot;straight&quot;.</p>
<p>Please can somebody explain which one is correct, and help me to overcome this confusion? Thanks!</p>

CC BY-SA 4.0
2021-10-24T16:00:08.567Z
See: https://upload.wikimedia.org/wikipedia/commons/4/49/Gimbal_Lock_Plane.gif
lightxbulb
CC BY-SA 4.0
2021-10-25T06:11:18.333Z
Both are correct at the same time. Its just that its not clear from the question that your thinking of euler angles as vectors that you directly manipulate by numeric interpolation. Or put a other way your not manipulating objects by gimbals. If you do not then you will never gimal lock, nor will you understand why it locks. So if you dont think from within euler space it dont affect you.
joojaa
CC BY-SA 4.0
2021-10-25T16:46:10.037Z
Also, since you asked about the calculations: https://en.wikipedia.org/wiki/Gimbal_lock#Loss_of_a_degree_of_freedom_with_Euler_angles
lightxbulb
CC BY-SA 4.0
2021-11-02T10:08:22.107Z
check [this](https://www.youtube.com/watch?v=zc8b2Jo7mno) video where its very well explained
rustyBucketBay
<transformations>
Gimbal lock confusion
John Rowlay
# Gimbal lock confusion

(Asked by: username_0 on 2021-10-24)

I am trying to understand exactly what is happening when Gimbal lock occurs. I have read many explanations now which provide the high-level idea, in that Gimbal lock occurs when two axes are aligned during the sequence of three rotations. But I am struggling to understand what this really means in terms of the calculations that are going on.

Here's my understanding of the setup. We have an initial 3D rotation of a body, and a target 3D rotation of that body, and we want to move the body from the initial to the target rotation. To do this, we calculate the Euler angles representing this rotation. (I don't know the maths behind this, but I will assume that this is just an algorithm that takes in an initial and target rotation, and returns a third rotation).

So, we now have a rotation expressed as Euler angles, which we want the body to move over. And now I will explain my confusion. From what I have been reading, there are two ideas:

1. Gimbal lock occurs when two of the axes become aligned, during the sequence of three rotations, which means that there is one axis about which rotation cannot occur.
2. Due to Gimbal lock, the path which the rotation occurs over will not be "straight", and there will be a curve.

This to me is very confusing. 1) is saying that Gimbal lock means that we cannot rotate the body along a certain axis. 2) is saying that Gimbal lock means that we can rotate the body, but that the path will not be "straight".

Please can somebody explain which one is correct, and help me to overcome this confusion? Thanks!

**Tags:** transformations

> **Comments:**
> **username_1**: See: https://upload.wikimedia.org/wikipedia/commons/4/49/Gimbal_Lock_Plane.gif  
> **username_2**: Both are correct at the same time. Its just that its not clear from the question that your thinking of euler angles as vectors that you directly manipulate by numeric interpolation. Or put a other way your not manipulating objects by gimbals. If you do not then you will never gimal lock, nor will you understand why it locks. So if you dont think from within euler space it dont affect you.  
> **username_1**: Also, since you asked about the calculations: https://en.wikipedia.org/wiki/Gimbal_lock#Loss_of_a_degree_of_freedom_with_Euler_angles  
> **username_3**: check [this](https://www.youtube.com/watch?v=zc8b2Jo7mno) video where its very well explained  

---

## 2 answers

### Answer by username_4 on 2021-10-24. Score: 6

Gimbal lock is your item 1. It is the situation where we have rotated our 2nd axis (in the order of application of the three axes) by ±90 degrees, which aligns the 1st axis and the 3rd axis together, so that rotating either one of them does the same thing. From that position, there are some directions we cannot rotate in.

For a concrete example, let's say we apply rotations in the order of roll, pitch, yaw. If I have pitched up by 90 degrees, so that my aircraft (or whatever) is pointing straight up, then rolling will rotate about the global vertical axis (because I'm pitched straight up), and yawing will also rotate around the global vertical axis (as it always does). From this position I am able to roll and pitch, but what I *can't* do is tilt the aircraft to its local left or right. I would have to pitch away from that 90 degree position by some distance, and then "circle around" so to speak in order to get to the left- or right-tilted position. (This is the situation represented in the .gif that username_1 posted.)

Item 2 isn't the same thing as gimbal lock, but is affected by it. It is a property of interpolating in Euler angles in general. If you move from your initial to your target rotation by, say, linearly interpolating each of the three Euler angles individually from its initial value to its target value, then in general the path taken will not be the shortest path through the space of rotations to the target—and it may look odd to the eye, perhaps appearing to rotate in the "wrong" direction at first and then circle around to come at the desired target orientation from a different angle.

This happens to some extent for almost any choice of initial and target orientations, but it gets worse if the path taken approaches close to a gimbal lock configuration. This can happen if the initial or target orientation is a gimbal lock configuration, or if we happen to pass through a gimbal lock configuration (or close to it) in the middle of the interpolation. When that happens, we will get particularly strange-looking "wrong" rotation paths. If we don't happen to get near a gimbal lock configuration, then the "wrongness" won't be so clearly visible, or may go unnoticed entirely.

An analogy that may help is to think about the Earth's surface with latitude and longitude coordinates, and what happens if you generate a path between two points on Earth by interpolating the latitude and longitude individually. You can see that things may get weird if the path gets close to the poles, where the coordinate system has a singularity. That is very analogous to how gimbal lock configurations are singularities in the Euler angle coordinate system. These singularities can be resolved by using quaternions, which would be analogous to representing points on the Earth's surface using Cartesian xyz vectors instead of latitude/longitude.

> **Comments:**
> **username_2**: Yes this is a good answer you should just stress that it only affects you if you interpolate in euler angles. None of the tasks op says indicate that he is interpolating in euler angles.  
> **username_2**: Can i insert images from [this post](https://computergraphics.stackexchange.com/questions/4436/how-to-achieve-gimbal-lock-with-euler-angles/4438#4438) here? They seem appropriate  
> **username_4**: @username_2 Sure, go for it!  
> **username_5**: Sorry maybe you can clarify this - "and yawing will also rotate around the global vertical axis (as it always does)`" - what if I choose to always rotate in the body frame, I pitch 90 degrees, than rolling will rotate along global Z axis and yaw will rotate along global X axis (this is because I chose to always represent my rotations in local or body frame). Is my understanding correct that gimbal lock will never occur with this convention?  
> **username_4**: @username_5, sure, but then you are not really using Euler angles. You would need to represent the rotation in some other way (e.g. quaternion) and then accumulate rotations by multiplying onto the quaternion; multiplying in one order would make the rotations always in body frame, and the other order would make them always in global frame.  
> **username_5**: @username_4 thanks for the response. I'm still a bit confused. How come what I described is not Euler Angles? From what I read everywhere on the internet Euler Angles is about rotating three times along three axis around local or body frame, and you can choose different sequences (XYZ, ZYX, ZXZ, etc.) in which sequence you rotate, even Wikipedia says it here https://en.wikipedia.org/wiki/Euler_angles So if I choose XYZ convention - rotating along X, Y and Z axes of a body frame, by three angles, gimbal lock will never occur, because I always rotate in local frame.  
> **username_5**: So it seems to me gimbal lock is only relevant when you model your rotations similar to a real physical gimbal mechanism. But why would you do it this way? You can just model it as three angles in the body or global frame, convert it to three rotation matrices, then compose a single transformation matrix from them. And then you can use it instead of quternion and avoid gimbal lock. I asked this question separetely already, if you want to answer I will vote you up https://computergraphics.stackexchange.com/questions/14020/do-euler-angles-always-cause-gimbal-lock?noredirect=1#comment21906_14020  
> **username_4**: @username_5 With Euler angles you have three angles that you're always applying in a fixed order, like XYZ. You pick one order and stick with it. If you always rotate in local frame then you accumulate more axes onto the list, like XYXZYZX...etc depending on what rotations you did. You can't trivially collapse that back down into just XYZ again.  
> **username_4**: "Model your rotations similar to a real physical gimbal" is exactly what Euler angles is. As for "why would you do it this way", well, it's a good representation for some things and not a good representation for other things.  

---

### Answer by username_1 on 2021-10-25. Score: 1

Maybe it's also worth considering why people find gimbal lock "wrong" even when they do not know what gimbal lock is. This suggests some intuitive expectation that doesn't align with what Euler angles do (i.e. they actually do not want to work with gimbals). It begs the question how this natural expectation may be fulfilled instead.

Assume you are given a joystick to control an airplane's orientation (you are in the airplane), but make it special so that the stick can also be rotated around its axis to achieve a yaw rotation. Store the set of orthonormal vectors describing the orientation of the plane $e\_1,e\_2,e\_3$ and identify the stick's current direction with $e\_2$. Now let the airplane's computer record the airplane's basis $e\_1, e\_2, e\_3$, and the stick's direction $d$, every $x$ seconds and keep its last two states: previous $p$ and current $c$. Assume you have tilted the stick from $e\_2$ in $p$ to $e'\_2$ in $c$. Intuitively one wants to align the plane so that $e'\_2$ is the plane's "up" again. This can be done by rotating the previous basis $e\_1, e\_2, e\_3$ along the shortest path as to align $e\_2$ to $e'\_2$. This can be achieved using the following formula:
$$e'\_i = e\_i - \frac{e\_i \cdot e'\_2}{1 + (e\_2 \cdot e'\_2)}(e\_2 + e'\_2), \, i \in \{1,3\},$$
and the vectors have to be further normalized. This yields a new basis $e'\_1, e'\_2, e'\_3$ that you align your airplane to. This has a singularity if you allow your joystick a range of motion of 180 degrees, since if in $c$ you recorded $e'\_2 = -e\_2$ it is not clear along which rotation you reached it (all rotations are equal then: 180 degrees around any axis perpendicular to $e\_2$, and there are infinitely many such axes). A solution is to either disallow 180 degrees tilts (which holds for actual joysticks), poll your joystick state more often than every $x$ seconds so it would be physically impossible to flip it by 180 degrees between polling in $p$ and $c$, or set a "default" flip rotation, e.g. $e'\_1 = e\_1, e'\_2 = -e\_2, e'\_3 = -e\_3$ which rotates around $e\_1$ whenever $e'\_2 = -e\_2$ in $c$ (your airplane becomes reversed, but any other axis perpendicular to $e\_2$ would work). Now what should be done about the yaw rotation induced by the rotation of the stick around its axis? One option is to rotate around $e'\_2$. Note that the above combination of operations do not lead to gimbal lock ever, since it's not a gimbal configuration of rotations in the first place. In all states you get the exact same "intuitive" behaviour.

Note that one could have chosen a different vector $d$ instead of $e\_2$ to correspond to the joystick's direction and the idea remains the same. The point is that the two rotations - one induced from the tilting of $d$, and one induced from the rotation of $d$ around its axis, are different in behaviour, but at least for flight sims/joystick that seems to be the intuitive expected behaviour. You can achieve the same thing by using a keyboard too, e.g. up/down corresponds to tilting the stick forward/backward, left/right = tilting left/right, some other two keys for the clockwise and counter-clockwise rotation around its axis.

Now forget the airplane and joystick setting, and assume you were given an actual physical 3-gimbal as a controller. In that scenario it is likely that you would not find the joystick behaviour intuitive but the 3-gimbal one, in which case it would make sense to use Euler angles. The point is that the gimbal lock by itself isn't the issue, it's the mismatch between expectations and how a system operates. That is, if I give you a joystick controller and it acts like a 3-gimbal virtually (i.e. I use Euler angles), or if I give you a 3-gimbal controller and it acts like a joystick (i.e. I use the shortest rotation described for the joystick), you will likely find both confusing. All in all, I would say this issue arises simply because people apply the wrong mathematical model to what they envision, i.e. it doesn't model their expectations but something else instead. Speaking of which, I haven't seen any 3-gimbal PC controllers. Using those, Euler angles ought to make perfect sense.

TLDR:

In order to achieve incremental rotations while avoiding gimbal lock don't do this:

```
pitch += incr_pitch; yaw += incr_yaw; roll += incr_yaw;
R = Rz(roll) * Ry(yaw) * Rx(pitch);

```

Some alternatives are to store the orientation matrix $R$ and modify it by the desired incremental change:

```
R = Rz(incr_roll) * Ry(incr_yaw) * Rx(incr_pitch) * R;

```

Another very convoluted and inefficient option, which nevertheless doesn't exhibit gimbal lock and thus illustrates that the issue is the incrementing of `pitch, yaw, roll` and not the storage of Euler angles, is the following:

```
R = Rz(incr_roll) * Ry(incr_yaw) * Rx(incr_pitch) * Rz(roll) * Ry(yaw) * Rx(pitch);
(pitch,yaw,roll) = extract_Euler(R)

```

A different alternative is to use quaternions in the exact same way as the second snippet (`q` is assumed to be stored):

```
q = quat(incr_roll/2,(0,0,1)) * quat(incr_yaw/2,(0,1,0)) * quat(incr_pitch/2,(1,0,0)) * q;

```

This also provides a counterexample to a common misconception that you cannot get gimbal lock by using quaterions. The below snippet will exhibit gimbal lock:

```
pitch+=incr_pitch; yaw+=inct_yaw; roll+=incr_roll;
q = quat(incr_roll/2,(0,0,1)) * quat(incr_yaw/2,(0,1,0)) * quat(incr_pitch/2,(1,0,0));

```

The point I am trying to make is that the issue arises when incrementing Euler angles and then producing a rotation from those. The increment results in a behaviour consistent with turning a specific gimbal from a 3-axis gimbal, and not with the controls of an airplane for example. For the latter one has to produce the increment through matrix/quaternion composition with the orientation, or the trick that I suggested:

$$e'\_i = e\_i - \frac{e\_i \cdot e'\_2}{1 + (e\_2 \cdot e'\_2)}(e\_2 + e'\_2), \, i \in \{1,3\},$$

> **Comments:**
> **username_2**: The problem as i see it is that people expect to have the cake and eat it too. So the real problem is that if i have a real spherical object and roll it around on the floor, theres no way for me to know how many full revolutions its gone between then and now. But on a computer you just have for some reason be able to express the integral without having to integrate it so to speak. So the unwillingness to actually position stuff with an axis or so is the cause of this. So why do we use these? maybe Rotors? Anyway we should stop thinking in 2D when doing 3D  
> **username_2**: Also maybe we should make a plan for a 3D gimbal controller. Its just a bit on the hard side to get your hands on say 6-8 mm slip rings with encoders.  
> **username_1**: @username_2 Yes indeed, sometimes it's unwillingness to specify a rotation axis. On the other hand even without a specific axis `R = Rz(incr_roll) * Ry(incr_yaw) * Rz(incr_pitch) * R;` doesn't cause gimbal lock (at least not in the usual sense). Honestly I cannot tell why incrementing the pitch/yaw/roll was ever a thing for modeling relative rotations when it comes to anything but gimbals. As far as rotors go, one can show that those are equivalent to quaternions, axis-angle representations, and matrix rotation from axis angle (which can also be translated in the language of Euler angles).  
> **username_2**: offcourse they are equivalent. Once you eliminate the deficiency of having a space that is really unoptimal and come closer to something that behaves like a space rotation its going to be equivalent. But really we should also get the gui tools to align to the model. Quats are a bit hard to visualize, and for some reason nobody uses axis angles. So we should get rid of the angular represation tendency. Its probably not good for us.  
> **username_1**: @username_2 Rotation quaternions (i.e. versors) are conceptually the same as axis-angle rotation, the fact that they are 4D shouldn't be an issue with the visualization since ultimately they represent a rotation by $\alpha$ around an axis $\vec{u}$: $(\cos(\alpha/2), \sin(\alpha/2) \vec{u})$. From my experience relating to the 4D visualization doesn't lead to any notable insights. Similarly you can construct a matrix from an axis angle, and you can even interpret a matrix from Euler angles as an axis-angle rotation. Those are homomorphic, so you can do the same things with all (the price differs).  
> **username_2**: Yes thats what i said if they perfectly model x they are equivalent a d have same properties. But im more concerned with the fact that no software tries to visualize any of the other options. Always a angle ball. It would be better ef users were more tuned to how the system actually works than tow they think it does. Its really hard to imput a quat with that visualisation. Though maybe axis angles then. Obviously all space rotations can be expressed as matrices.  
> **username_1**: @username_2 Ah, this is what you meant. I have not much experience with rendering software. But at least physical joysticks coupled with a flight sim act like the other option.  
> **username_2**: Yes, sortof they work same as a euler rotation would too if you were to reset it after every update. Im afraid its still a bit bad intuition for humans  

---

