You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Change the default behavior of the euler_xyz_from_quat function to return Euler angles in the range (-π, π] instead of [0, 2π). Introduce an optional argument allowing users to explicitly request the [0, 2π) range when necessary.
Motivation
Euler angles represented in the (-π, π] range are more intuitive and widely adopted within the robotics community. Users currently must manually adjust outputs, which leads to redundant and scattered implementations across multiple projects. Examples of user-implemented adjustments can be found in:
This proposal aims to centralize and standardize angle normalization.
Alternatives
An alternative is to continue using the current implementation, which would require individual users to manually perform angle wrapping each time they invoke the function.
Additional context
Euler angle normalization issues frequently cause confusion and subtle bugs in robotics simulations and control algorithms.
Checklist
I have checked that there is no similar issue in the repo (required)
Acceptance Criteria
Default output from euler_xyz_from_quat is changed to the range (-π, π].
An argument enables the legacy [0, 2π) range.
Documentation clearly reflects the new default behavior and the optional argument.
Unit tests are provided to verify behavior.
The text was updated successfully, but these errors were encountered:
Hi @RandomOakForest, thanks for your comment!
Actually, I've opened a PR #2365 to address this improvement.
If the code meets the team's standards, I am glad to contribute that PR to the project : )
Proposal
Change the default behavior of the
euler_xyz_from_quat
function to return Euler angles in the range (-π, π] instead of [0, 2π). Introduce an optional argument allowing users to explicitly request the [0, 2π) range when necessary.Motivation
Euler angles represented in the (-π, π] range are more intuitive and widely adopted within the robotics community. Users currently must manually adjust outputs, which leads to redundant and scattered implementations across multiple projects. Examples of user-implemented adjustments can be found in:
This proposal aims to centralize and standardize angle normalization.
Alternatives
An alternative is to continue using the current implementation, which would require individual users to manually perform angle wrapping each time they invoke the function.
Additional context
Euler angle normalization issues frequently cause confusion and subtle bugs in robotics simulations and control algorithms.
Checklist
Acceptance Criteria
euler_xyz_from_quat
is changed to the range (-π, π].The text was updated successfully, but these errors were encountered: