Computation Error: from euler angles to quaternion

[Fanxing-LI]

Describe the bug
I' ve read your Notes page.
The function "from_euler_angles" produces wrong result when euler angle is [-np.pi/2, 0.0, 0.0].

To Reproduce
import quaternion
from scipy.spatial.transform import Rotation as R
import numpy as np

euler1 = np.array([0.0, 0.0, -np.pi/2])
euler2 = np.array([-np.pi/2, 0.0, 0.0])

print("Euler 1: ", euler1, "quaternion Quaternion 1", quaternion.from_euler_angles(euler1), "Scipy Quaternion 1: ", R.from_euler("xyz", euler1).as_quat())
print("Euler 2: ", euler2, "quaternion Quaternion 2", quaternion.from_euler_angles(euler2), "Scipy Quaternion 2: ", R.from_euler("xyz", euler2).as_quat())

output:
Euler 1: [ 0. 0. -1.57079633] quaternion Quaternion 1 quaternion(0.707106781186548, -0, 0, -0.707106781186547) Scipy Quaternion 1: [ 0. 0. -0.70710678 0.70710678]
Euler 2: [-1.57079633 0. 0. ] quaternion Quaternion 2 quaternion(0.707106781186548, 0, 0, -0.707106781186547) Scipy Quaternion 2: [-0.70710678 0. 0. 0.70710678]

Expected behavior
For quaternion obtained by euler2 (rotated along x axis), i value should be non-zero while others (j, k) should be.
Further, even without considering the cooerdinate definition issues, at least, transformation outputs of two different euler angles (single rotation) should be different.

Environment (please complete the following information):

• ubuntu 20.04
• anaconda
• python 3.8.18
• Numpy version (use np.version.version) '1.24.3'
• Quaternion version '2022.4.2'

[moble]

I' ve read your Notes page.

Then you should have noticed the most important part:

Q = (alpha*quaternion.z/2).exp() * (beta*quaternion.y/2).exp() * (gamma*quaternion.z/2).exp()

What part of this suggests that it would correspond to "xyz" in scipy's notation? I would have guessed "zyz". And indeed, when you use that in the arguments to scipy (and account for the fact that scipy puts the scalar part last), you get the same answer that this package gives you.

Further, even without considering the cooerdinate definition issues, at least, transformation outputs of two different euler angles (single rotation) should be different.

No, this is the whole problem with Euler angles: no matter which convention you use, you run into "gimbal lock" somewhere. You've chosen a pair of different coordinate values that really represent the same rotation.

Your question is basically identical to #71 and #83.