Skip to content

Research #3

Description

@A31A18B25C9D012

7/4/2026


Firmware first...
The firmware fusion is VQF.
In published benchmarks (Laidig & Seel 2023, comparing against Madgwick, Mahony, and EKF variants across datasets) VQF is at or near state of the art for single-IMU orientation...
Replacing or heavily reworking it would be effort spent where there is almost nothing left to win.
Same for the smoothing filter: the adaptive slerp EMA with velocity easing is heuristic, but the theoretical gain from a "proper" quaternion Kalman smoother there is small and costs latency. So the fusion core and the filter are not where the math should improve.

First, Kinematic hinge constraints to make yaw observable (big one)
The fundamental problem is that yaw is unobservable from a single IMU without a magnetometer(Or any other hardware like a lighthouse + IMU tracker setup). But it is not unobservable for a kinematic chain. Knees and elbows are approximately hinge joints, and the hinge axis constrains the relative orientation of the two segments: whenever the knee bends, the relative heading between thigh and shank becomes mathematically observable, and you can correct their relative yaw drift continuously with no magnetometer and no reset.
This is established literature; Seel, Raisch & Schauer (2014) on IMU joint angles, and Laidig, Müller & Seel on magnetometer free heading correction using joint constraints.
Stay Aligned already has the architectural slot for it... NeighborErrorVisitor pulls neighboring trackers toward consistency heuristically. Upgrading that from a heuristic pull to a hinge constraint error term (weighted by how much the joint is actually flexing, since a straight knee gives no information) would be the single largest principled drift improvement available in pure software. Every step you take would recalibrate your leg yaw a little.

Second, continuous mounting refinement via joint-axis estimation.
A large chunk of what users perceive as drift is actually mounting error, and mounting is calibrated once and assumed fixed while straps shift over a session. The same hinge math gives you the fix: the knee axis direction in each sensors frame can be estimated from gyro data during ordinary walking (axis-of-rotation correlation between adjacent segments). That lets the server refine sensor-to-segment alignment continuously in the background instead of trusting one mounting reset. Laidig et al. called this automatic anatomical calibration; fewer mounting resets, and drift correction stops fighting a miscalibrated frame.

Third, replace the temperature bins with a fitted curve.
The drift model is currently twenty independent 2-degree bins, each an EMA, no sharing between bins.
Gyro bias vs temperature is physically smooth and near linear over the relevant range. Fitting a low order polynomial or spline with recursive least squares instead would generalize from far fewer samples (one measurement informs the whole curve, not one bin), interpolate for free, and give an honest variance estimate.
This is also exactly a "cold start fix from the tester conversation" I made does.
This change makes it more so done properly rather than as a patch.

Fourth, soften the yaw extraction degeneracy instead of hard gating it.
Yaw comes from the Y term of a YZX Euler decomposition, and the code hard gates it when a limb is within 30 degrees of vertical (MIN_ON_SIDE_ANGLE). A swing twist experiment oscillated and was reverted, which is a known failure mode. A better more supported approach is a continuous confidence weight proportional to the horizontal projection magnitude, propagated into how strongly Stay Aligned and resets trust that yaw, rather than a binary gate.
Smooth degradation instead of a cliff at 30 degrees, and it composes with the sitting/lying leg problems I've hit
(Those are all this same degeneracy)

Fifth, foot locks as heading measurements, not just position corrections.
LegTweaks already detects when a foot is planted and locks its position. A planted foot is also a rotational constraint, the foot isnt twisting against the floor. So feeding the lock event into the shank/foot yaw estimate as a pseudo-measurement (a ZUPT-style update for heading) turns something the code already detects into a drift correction it currently throws away.

Sixth, the long term big gun.... whole body sliding window optimization.
Currently every tracker is processed independently and the skeleton assembles the results. The literature alternative (Kok, Hol & Schön 2014) is a sliding window MAP optimization over the whole kinematic chain at once... Bone lengths, joint constraints, and all sensor data in one estimator, which is provably drift-free in relative pose without magnetometers. This is a large rewrite and real CPU cost, so it can be though as an eventual destination rather than a next step, but items 1, 2, and 5 are incremental pieces of exactly this estimator, so the work builds toward it rather than away from it.

(Minor item)
Constant-acceleration (rather than constant-velocity) prediction with variance-gated blending; per-unit gyro noise characterization from rest data (Allan-variance style) to weight the drift learning; and a numerical audit of the >180-degree wrap that currently forces the 15-minute cap on drift measurement intervals.
Tracking accumulated rotation continuously instead of endpoint-differencing would lift that cap.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions