fix: foot-IK idle leg buzz (wrong leg orientation targets)#86
Merged
Conversation
The two-bone IK solver built each leg segment's orientation target from scratch via _basis_looking_along (Basis(s, -d, f)), assuming a local-axis convention that sat ~130deg off the real Mixamo bone bases. The velocity spring then perpetually tried to twist the legs to those joint-unreachable orientations, causing a sustained idle leg vibration. Measured on the ybot asset at rest, before -> after this change: UpperLeg target error 130deg -> 0.6deg, ang vel 1.1 -> 0.17 rad/s LowerLeg target error 33deg -> 1.0deg, ang vel 1.8 -> 0.52 rad/s Foot target error 11deg -> 2.4deg, ang vel 1.7 -> 1.17 rad/s The solver now expresses each segment's orientation as a SWING of that segment's animation basis onto the new IK bone direction — the same delta-from-animation approach the foot already used for slope correction. When the IK direction equals the animation direction (no adjustment needed) the swing is identity, so the target equals the animation pose and there is no spurious rotation error for the spring to chase. This is convention-agnostic: it no longer assumes a Mixamo local axis, so non-Mixamo rigs benefit too. Foot planting, pelvis drop, and leg lengths are unchanged — only segment ORIENTATIONS are corrected; positions (knee, foot target, pelvis) are untouched. Removes _basis_looking_along; adds a degeneracy-hardened _swing. The remaining ~1 rad/s residual on the foot is the spring's steady-state floor, addressed separately by the spring-hardening change. GUT 113/113. Headless import clean. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes the idle leg vibration in foot IK — a latent 0.3.0 quality bug surfaced while validating the (now-parked) 0.4.0 stumble work. Substrate hardening; lands on
mainbefore 0.4.0 resumes.Root cause (data-backed)
The two-bone IK solver built each leg segment's orientation target from scratch with an assumed local-axis convention (
_basis_looking_along→Basis(s, -d, f)). That convention sits ~130° off the real Mixamo bone bases. The velocity spring then perpetually tried to twist the legs to those joint-unreachable orientations → sustained idle buzz.Measured headlessly on the real ybot asset at rest (target error = angle between the IK target basis and the actual bone; ang vel = idle angular velocity):
(The investigation also confirmed the velocity-spring core is sound — it tracks consistent targets calmly and is the same formula Jolt's own
DriveToPoseUsingKinematicsuses. It was faithfully chasing garbage targets, not malfunctioning.)The fix
Express each leg segment's orientation as a swing of its animation basis onto the new IK bone direction — the same delta-from-animation approach the foot already used for slope correction (and why the foot's error was smallest). When the IK direction equals the animation direction (no adjustment needed), the swing is identity, so the target equals the animation pose → zero error.
_basis_looking_along; adds a degeneracy-hardened_swinghelper.Validation
Note
The remaining ~1 rad/s residual on the foot is the spring's steady-state floor — addressed by the separate spring-hardening PR (settle deadband + solver-cooperative velocity), the second half of the substrate hardening.
🤖 Generated with Claude Code