<p>You can use rotations where only the deltas are based on Euler angles. Say you have a rotation matrix <span class="math-container">$R$</span>, e.g. which can be the identity initially. Then you can update the rotation as <span class="math-container">$R'= R_z(\Delta roll) R_y(\Delta yaw) R_x(\Delta pitch)R$</span>. Note that the <span class="math-container">$\Delta$</span> are only small angular changes. This will in general not cause gimbal lock and allow you to use Euler or Tait-Bryan angles (you have to change the above expression based on the convention you use) at least for the frame to frame rotational changes.</p>

CC BY-SA 4.0
2023-08-30T11:44:17.000Z
2023-09-03T15:29:57.723Z
2023-09-03T15:29:57.723Z
lightxbulb
<p>I am programming a camera viewer in Python to move around an object on a sphere given YPR Euler angles (intrinsic) from the user.</p>
<p>Everything seemed nice until I pitched the camera 90 degrees up/down. The calculations then stopped working and I could not move as expected. I understand this has to do with the gimbal lock as it causes two rotation axes to align.</p>
<p>So far I have only found solutions such as changing the order of Euler angles or using quaternions, but this is not compatible with the desired solution as:</p>
<ol>
<li>changing the order of Euler angles changes the intuitive behavior of YPR angles for the user</li>
<li>using quaternions is far from intuitive in itself</li>
</ol>
<p>Is there some other way out of this mess? The key point is to maintain intuitive user control while avoiding gimbal locks.</p>
<p>Thanks a lot beforehand!</p>

CC BY-SA 4.0
2023-08-30T09:20:19.513Z
Welcome to Computer Graphics Stack Exchange! Quaternions are not as complicated as they look at first sight... They have the advantage that they have not gimbal lock at all. Please describe how you want the camera to move (preferably with an image that also visualizes the coordinate frame). With such a description of the desired behavior, we can better analyze the problem and find a good way to work around the gimbal lock. Also describe the restrictions (e.g. no rotation more than 90°).
Thomas
<transformations>
Avoiding gimbal lock in spherical movement around an object - Python
garma
# Avoiding gimbal lock in spherical movement around an object - Python

(Asked by: username_0 on 2023-08-30)

I am programming a camera viewer in Python to move around an object on a sphere given YPR Euler angles (intrinsic) from the user.

Everything seemed nice until I pitched the camera 90 degrees up/down. The calculations then stopped working and I could not move as expected. I understand this has to do with the gimbal lock as it causes two rotation axes to align.

So far I have only found solutions such as changing the order of Euler angles or using quaternions, but this is not compatible with the desired solution as:

1. changing the order of Euler angles changes the intuitive behavior of YPR angles for the user
2. using quaternions is far from intuitive in itself

Is there some other way out of this mess? The key point is to maintain intuitive user control while avoiding gimbal locks.

Thanks a lot beforehand!

**Tags:** transformations

> **Comments:**
> **username_1**: Welcome to Computer Graphics Stack Exchange! Quaternions are not as complicated as they look at first sight... They have the advantage that they have not gimbal lock at all. Please describe how you want the camera to move (preferably with an image that also visualizes the coordinate frame). With such a description of the desired behavior, we can better analyze the problem and find a good way to work around the gimbal lock. Also describe the restrictions (e.g. no rotation more than 90°).  

---

## 1 answers

### Answer by username_2 on 2023-08-30. Score: 1

You can use rotations where only the deltas are based on Euler angles. Say you have a rotation matrix $R$, e.g. which can be the identity initially. Then you can update the rotation as $R'= R\_z(\Delta roll) R\_y(\Delta yaw) R\_x(\Delta pitch)R$. Note that the $\Delta$ are only small angular changes. This will in general not cause gimbal lock and allow you to use Euler or Tait-Bryan angles (you have to change the above expression based on the convention you use) at least for the frame to frame rotational changes.


---

