Weirdly, gimbal lock, which totally sounds like the physical jamming of a mechanical device, was explained to me as being about the math behind the device – specifically, its coordinates.
For an example, let’s say I want to be able to control your head so you can look in any direction you want. I’ll use two angles in space:
* Elevation – how far your head is angled up or down; your neck will handle most of this and we can involve your spine if we have to
* Azimuth – how far you’re turned to the north/south/east/west; your neck could do this, but as it’s handling elevation we’ll have you do all the turning by moving your feet
Good so far? Alright, here’s the situation that’s going to gimbal-lock you: way out on the horizon, to the northeast, a plane is coming. It’s going to fly exactly overtop of you, and I need you to track it; never take your eyes off it.
The plane starts way off to the northeast, so you set yourself to elevation +3° and azimuth 045°. The plane gets closer; you raise your head a bit. Elevation +5°, azimuth 045°. Closer. Elevation 12°, azimuth 045°.
The plane’s almost overhead. Elevation +89°, azimuth 045°. The crisis is coming.
The plane goes a bit further and is now directly overhead, elevation +90° and azimuth 045°; the crisis has arrived: **what should you do when the plane moves a bit further?**.
There are two answers: most anatomically-normal humans would turn their body around real fast (azimuth 225°) and then start lowering their head elevation to keep up with the plane…but you could also keep your feet where they are, and just keep bending backwards into a limbo position – elevation 91°, 95°, 100° and so on, while your azimuth (the way your feet are pointing) stays at 045°.
You’re thinking that’s not so bad, you just have to pick one of those approaches when you’re writing the software…but these devices aren’t software-driven, they tend to be connected to analog control systems and those systems behave unpredictably when they have “two valid choices”. At every other position, when the plane moved a bit, there was a single unique rotation that would enable you to track it, but in the passing-overhead situation, there are two valid moves and that causes controllers to get lost.
(I wrote this from the standpoint of someone who’s trying to control the movement from the outside, but if we’re talking about an inertial guidance system, a similar issue occurs where if we’re *measuring* the movement, in some orientations are sensors are going to produce outputs that the IGS can’t interpret. Unfortunately that’s all the detail I’ve got because my knowledge of IGS is paper-thin.)
Here’s a pretty good animation about it, in the context of 3D animations where you’re trying to tell an object to turn the way you want to. https://www.youtube.com/watch?v=zc8b2Jo7mno
Latest Answers