# Confusion regarding Euler rotations and Gimbal Lock

I'm having difficult understanding the issue with gimbal lock, namely why so many diagrams show an aircraft in apparent gimbal lock unable to turn about an axis conventionally, using yaw/pitch/roll. For example, below are some diagrams depicting a common scene of gimbal lock.

In the first one, let us call it Frame A we start in a position where the Euler angles are all 0 and the aircraft is flying level:

Depicted are the gimbles aligned with their respective axis on the body frame denoted in yellow. Now, in the second image, we have pitched up 90 degrees, and we are in what, all resources I've found, is called gimbal lock:

If you notice the second graphic, called Frame B, the body frame has followed along and we can see the intermediate frame after the pitch. The y-gimble and the z-gimble are now aligned however, and adjusting yaw results in the same response as adjusting roll:

But this is where to me that doesn't make any sense. If we refer back to Frame B and look at our body frame, the yellow, it indicates that a roll does what we see in the two images above as the x-axis, or roll axis, is extending through the nose, but the z-axis, or the yaw axis, is perpendicular. Thus, the aircraft should be able to yaw appropriately (give rudder control surfaces and thrust).

So why is it depicted here as if the body frame after Frame A is like so:

With this axis that makes sense, but its not how I understand aircraft mechanics to work.

• Is this about engineering or physics?
– Fred
Aug 19, 2022 at 7:52
• Its not that you can not move. Its that you can not move uniformly and with a small step in the direction you want at this time. So differentiation in euler space is a bit hard. Its a bit like having shopping mall across the street but having no way to go over the street and needing to go via city center to reach it. Also see this and this for another view Aug 21, 2022 at 20:03

"Thus, the aircraft should be able to yaw appropriately (give rudder control surfaces and thrust)."

The above statement is correct for an aircraft freely flying in the air. In fact, for such an aircraft there is no gimbal lock since there is no gimbal mechanism.

For a toy aircraft which is fixed to three gimbals, yawing motion is not possible for the configuration shown in the second image, since two of the gimbal axes are aligned to toy aircraft roll axis and the third one aligned to toy aircraft pitch axis, and there is no gimbal axis / joint which is aligned to toy aircraft yaw (or even having a component along yaw).

Gimbal lock is usually referred to in two contexts :

1. An actual, physical, gimbal mechanism. e.g. a gyroscope instrument suspended in a three axis gimbal mechanism. or a toy aircraft mounted in a gimbal mechanism.
2. Software which tries to represent angular orientation of a body using three angles involving mathematical operations which are the same as the mathematical operations which describe a gimbal mechanism. e.g. The software whose screenshot you have posted in the question.

## edit

In response to this comment.

For #2, does that mean software that uses these angles to maneuver a model do not have their axes rotate with them? If you look here youll see a step diagram showing that after a yaw, the Y and X axes rotate; then a pitch and the Z and X axes rotate again. What confuses me about gimbal lock is it seems that when applied to software, this does not happen and instead, children of a rotation order are carried through each rotation. It's almost like rotations don't use intermediate frames for applying rotations as in the link I have.

Consider the software operation. At a given instant, let the aircraft be in the orientation as shown by the second frame (i.e. pitch angle 90 deg). Now, for the next time instant (imagine that the software is a video game), the user has applied rudder input and the software needs to rotate the aircraft slightly about the yaw axis. But, since none of the three gimbal axes (in this case the three variables $$(\theta,\ \psi,\ \phi)$$ stored in the video game memory) align with the yaw axis, the software won't be able to compute a small change in the variable $$(\theta,\ \psi,\ \phi)$$ to represent the small yawing motion required. Sure,as you said

when applied to software, this does not happen and instead, children of a rotation order are carried through each rotation. It's almost like rotations don't use intermediate frames for applying rotations

Problem is that, for a small incremental rotation (yaw in this example), the increments in $$(\theta,\ \psi,\ \phi)$$ will not be small. This often leads the video game to have non smooth motion of the body and the software writer needs to write extra software logic to make the animation smooth.

• For #2, does that mean software that uses these angles to maneuver a model do not have their axes rotate with them? If you look here youll see a step diagram showing that after a yaw, the Y and X axes rotate; then a pitch and the Z and X axes rotate again. What confuses me about gimbal lock is it seems that when applied to software, this does not happen and instead, children of a rotation order are carried through each rotation. It's almost like rotations don't use intermediate frames for applying rotations as in the link I have. Aug 21, 2022 at 2:07
• I think you have understood the concept. The intermediate rotations are not used. only the final combined rotation is used. The problem occurs when the software wants to update $\theta,\ \psi,\ \phi$ to show yawing motion when the situation is as in frame 2.
– AJN
Aug 21, 2022 at 11:15
• @pstatix its not necceserily a problem for software. Its just that the space is really nonuniform. There are other ways to do this too such as using axis angles, quaternionions or rotors. The problem is if your sensor, camera mount or vectoring thruster has a physical gimbal like setup then its a problem. Its not a problem if you want to leisurely move gimbals. But its a problem for the instantaneus differential direction change. Aug 21, 2022 at 20:26
• @AJN it seems like the software choses to use Euler rotations in a gimbal fashion, but if we look here we can see that each frame in between is used after a rotation along an axis. So to your updated edit, why would the game want to use gimbals to render the object and handle angular rotations that way instead of performing a single rotation per axis and updating state with the intermediate frames as shown in the GIF? Aug 21, 2022 at 23:40
• As mentioned in a comment above, using other means of representation such as quaternion, or using 3x3 rotation matrices (instead of just storing three numbers and re-constructing the matrix every computation cycle) or having additional logic to handle gimbal locks gets around the problem.
– AJN
Aug 22, 2022 at 11:56

I had a discussion on this in cg.se and ill summarize it as following:

You cant have a gimbal lock unless you have a physical gimbal or are modeling one.

The dynamics can be modelled with either eulers equation (not to be confused by euler angles), larangian dynamics or a hamiltonian one.

In practice the equations are cumbersome to derive in 3D. But particularily the larangian formulation does not care about the original coordinate systems so its not prone to any of the problems of the used cordinates.

Since the derivation is cumbersome one usually copies the derivation from literature. Now this derivation is most likely been made with only a few different ways. Usually in euler angle* form since that makes setting external forces easy, and a larangian formulation since it ignore coordinate problems.

The benefits of euler rotations is that its easy to interpret, and communicate (for navigation etc) especially if one is not near the lock condition. Which a well behaved plane should be. For dynamics it has the benefits of having the right amount of state variables so does not need big shenanigans to formulate for the solver.

Now all this said its a bit beyond what i do comfortably daily. I have done the derivation in euler angles as a practice exactly once. I have a vague recollection of having seen it done in a form that uses imaginary numbers for rotations and as a extension quaternion. But at that time I ignored it**.

* how does one store angular momentum in a nonangular definition like say matrix?

Though euler did not propose xyz formulation byt a zxz formulation go figure. Maybe they should be called tait-brimyant angles?

** So perhaps the simple answer is that its used because of historical precedent. Not particularily inspired result.