v18.2.0: Manual reset swaps roll/pitch on chest and thigh trackers

[AlfaKeNTAvR]

Description

After upgrading from v18.1.0 to v18.2.0, performing a manual reset causes roll and pitch to be swapped on chest and thigh trackers. This did not occur on v18.1.0.

Automatic mounting calibration resolves the issue, but manual reset alone produces incorrect orientation.

Steps to reproduce

1. Install SlimeVR v18.2.0 (Flatpak, Linux)
2. Connect Sony Mocopi trackers via MoSlime (BLE to SlimeVR bridge)
3. Tracker setup: chest, hip, thighs, and ankles
4. Perform a manual reset while standing with arms down
5. Sit down on a chair and lean forward
6. Observe that roll and pitch are swapped on chest and thigh trackers

Screenshot

After full reset standing up with arms down, then sitting on a chair and leaning forward:

Expected behavior

Manual reset should preserve correct roll/pitch orientation, as it did in v18.1.0.

Workaround

• Use automatic mounting calibration instead of manual reset
• Downgrade to v18.1.0

Environment

• SlimeVR v18.2.0 (Flatpak, Linux)
• Confirmed working on v18.1.0 (.deb, same machine)
• Sony Mocopi trackers connected via MoSlime (BLE to SlimeVR bridge)
• Tracker setup: chest, hip, thighs, ankles

[AlfaKeNTAvR]

Root cause analysis

Traced the regression to PR #1748 (commit 28deb357, merged 2026-02-20, shipped in v18.2.0). Despite the title "Revert TrackerResetsHandler & add comments", it did not restore the v18.1.0 behavior. The mounting orientation math in adjustToReference() was rewritten.

The change

v18.1.0 (correct):

rot = mountingOrientation.inv() * rot * mountingOrientation

This is a conjugation (similarity transform) that properly remaps pitch/roll axes to match the physical mounting direction.

v18.2.0+ (broken):

rot *= mountingOrientation

Simple right-multiply that only adds a yaw-like rotation. Does NOT remap pitch/roll axes.

Why manual mounting selection has no visible effect

In v18.2.0+, mountingOrientation is baked into the gyroFix and attachmentFix computation:

fixGyroscope(mountingAdjustedRotation * tposeDownFix)

where mountingAdjustedRotation = rawRot * mountingOrientation.

During adjustToReference, the mounting is applied via simple-multiply and then effectively canceled by the correction quaternions that were themselves computed with mounting baked in. The net effect of changing mounting direction is near-zero.

In v18.1.0, gyroFix was computed from the raw rotation WITHOUT mounting, and mounting was applied independently via conjugation in adjustToReference. The two operations were decoupled, so changing mounting actually affected the final axis mapping.

Why arms work but chest/hip don't

For FRONT mounting (identity quaternion or 180-degree yaw), conjugation and simple-multiply produce similar results because pitch/roll axes are already aligned with the body. For non-identity mountings (LEFT, RIGHT, BACK), conjugation correctly rotates the pitch/roll axes to match the physical tracker orientation. Simple-multiply does not, which is why pitch and roll appear swapped.

Additional changes in the same PR

• fixGyroscope euler order changed from YXZ to YZX for extracting yaw.
• fixYaw was rewritten to no longer apply conjugation with mountingOrientation.
• getYawQuaternion lost its configurable euler order parameter.

Confirmed reproduction

Reproduced independently with both MoSlime (Python/bluepy) and a custom Rust BLE-to-SlimeVR bridge. Same trackers, same machine, same behavior. The bug persists through v19.0.0 and v20.0.0-rc.1 (no changes to TrackerResetsHandler.kt since v18.2.0).

Suggested fix

Restore the conjugation form in adjustToReference():

rot = mountingOrientation.inv() * rot * mountingOrientation

And decouple mounting from gyroFix/attachmentFix computation, matching the v18.1.0 approach. Happy to submit a PR if the maintainers agree with this direction.