# Gimbal lock confusion

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!

• Oct 24 '21 at 16:00
• 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. Oct 25 '21 at 6:11
• Also, since you asked about the calculations: en.wikipedia.org/wiki/… Oct 25 '21 at 16:46
• check this video where its very well explained Nov 2 '21 at 10:08

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

• 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. Oct 25 '21 at 6:08
• Can i insert images from this post here? They seem appropriate Oct 25 '21 at 6:17
• @joojaa Sure, go for it! Oct 25 '21 at 16:32

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\},$$

• 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 Oct 27 '21 at 17:41
• 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. Oct 27 '21 at 17:48
• @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). Oct 27 '21 at 21:07
• 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. Oct 27 '21 at 21:20
• @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). Oct 27 '21 at 21:37