Fix spline point velocity and acceleration precision - #559
Open
s4lmon wants to merge 4 commits into
Open
Conversation
s4lmon
commented
Aug 26, 2026
| const int32_t vel_acc_mult = primitive->type == MotionType::SPLINE ? MULT_VEL_ACC : MULT_JOINTSTATE; | ||
| write_block(first_block, MULT_JOINTSTATE); | ||
| write_block(second_block, vel_acc_mult); | ||
| write_block(third_block, vel_acc_mult); |
Author
There was a problem hiding this comment.
prefer this but happy to revert for readability
s4lmon
commented
Aug 26, 2026
| joint-vs-pose interpretation as the target at indices 0-5, see the motion type at | ||
| index 20). | ||
| - trajectory point velocities (multiplied by ``MULT_JOINTSTATE``) for spline joint types | ||
| - trajectory point velocities (multiplied by ``MULT_VEL_ACC``) for spline joint types |
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
1 participant
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.
The spline vel/acc are quantised at
1e-6byMULT_JOINTSTATE, so near-zero accelerations reconstruct as jagged profiles. On our UR15 we notice many current compensation errors, that make the arm unusable with the ROS 2 driver.We have this fix that is working, implementing the same strategy as #482.
We implement a finer dedicated multiplier (
MULT_VEL_ACC = 1e8) and an explicit range guard (~21.47 rad/s(²)), analagous to max goal time check. This is backwards compatible.Credit to Toni Divic for discovering this bug.
Note
Medium Risk
Changes the on-wire encoding for spline vel/acc and requires matching robot script deployment; incorrect pairing would mis-decode trajectories, but non-spline paths are unchanged.
Overview
Spline trajectory points now encode per-sample velocities and accelerations with a dedicated
MULT_VEL_ACC(1e8) instead ofMULT_JOINTSTATE(1e6). Positions and non-spline motion primitives still use the old multipliers, so the wire layout is unchanged but spline vel/acc get 1e-8 resolution and avoid near-zero values collapsing to zero and producing jagged acceleration profiles that can fault the controller (e.g. current compensation errors on UR15).The library rejects spline vel/acc whose magnitude exceeds ~21.47 rad/s (²) (
MAX_VEL_ACC_), mirroring the existing max goal-time guard.external_control.urscriptdecodes splineqd/qddwith the injectedMULT_velacc, andUrDriverpassesVEL_ACC_REPLACEwhen templating the script. Docs and tests cover the new constant, near-zero roundtrip behavior, and range validation.Reviewed by Cursor Bugbot for commit 09e5d81. Bugbot is set up for automated code reviews on this repo. Configure here.