Gimbal lock is the reason robotics software stores orientations as quaternions instead of roll, pitch and yaw. It is often described as a mysterious loss of a degree of freedom. It is easier to understand with a concrete example and a few numbers, which is what this guide provides.
The short version
When pitch reaches exactly +90° or −90°, the roll axis and the yaw axis line up, so roll and yaw turn the robot about the same axis. Only their difference (or sum) matters. Infinitely many roll/yaw pairs then describe the same orientation, and near that point tiny changes in orientation produce huge swings in the angles.
Seeing it with numbers
ROS applies roll about X, then pitch about Y, then yaw about Z, all about fixed axes (see ROS conventions). Take two sets of angles:
They look different. Their rotation matrices are identical:
Pitching by 90° turns the robot's nose straight down onto the original Z axis. After that, a roll about the robot's X axis and a yaw about the world Z axis are rotations about the same line. At pitch +90°, only roll − yaw matters (30 − 0 and 0 − (−30) are both 30). At pitch −90°, only roll + yaw matters.
Why it bites: sensitivity near the singularity
Exactly 90° is rare in practice. The real damage happens near it. We took an orientation with a given pitch, applied a tiny extra rotation of 1° about the world X axis, and converted the result back to roll, pitch and yaw:
| Starting pitch | Roll afterwards | Yaw afterwards |
|---|---|---|
| 45° | 1.4° | 1.0° |
| 85° | 11.3° | 11.3° |
| 89° | 45.0° | 45.0° |
| 89.9° | 84.3° | 84.3° |
A 1° nudge to the orientation turned into an 84° jump in roll and yaw. A controller that steers on yaw, a filter that averages angles, or a plot of an IMU's angles goes haywire as the device nears vertical, even though nothing dramatic happened physically.
Where robots meet it
- Arm end effectors pointing straight down, the most common pose in pick-and-place, sit exactly at pitch 90° in the base frame.
- IMUs mounted vertically, on a robot's side or a leg, report pitch near ±90° all the time.
- Drones and legged robots during flips, falls or climbing.
- Camera frames: the standard optical frame is a 90° rotation from the body frame, so careless conversions between them can land on the singularity.
How libraries handle the exact case
When asked for angles at pitch ±90°, a library has to choose one of the infinitely many answers. A common choice, used by SciPy (which prints "Gimbal lock detected") and by the Quaternion ↔ Euler Converter, is to set yaw to zero and put the whole rotation into roll. So converting roll 10°, pitch 90°, yaw 40° to a quaternion and back gives roll −30°, pitch 90°, yaw 0°: different numbers, same orientation. Code that expects to get its original angles back will be surprised.
How to avoid gimbal lock
- Store and compute with quaternions or rotation matrices. They have no singularities. This is why ROS messages use quaternions.
- Convert to angles only for display or simple control, and only when you know the pitch stays well away from ±90°, as it does for a ground robot's heading.
- Compute errors as rotations. To find how far one orientation is from another, compute the relative quaternion and take its angle, rather than subtracting Euler angles.
- Interpolate with slerp, spherical linear interpolation of quaternions, not by interpolating angles.
- For a heading only, extract yaw directly with
atan2(2(wz + xy), 1 − 2(y² + z²)), which is well behaved for robots that stay roughly level.
Try it
Open the converter and click the "Gimbal lock" example: it sets roll 20°, pitch 90°, yaw 10°, warns about gimbal lock and shows the equivalent answer it picks. Drag the 3D view to see why: the roll and yaw axes coincide. Then read quaternions for ROS developers to get comfortable with the alternative.
