-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix initializing quadratic trajectory in smoother #1482
base: production
Are you sure you want to change the base?
Conversation
…ializing a quadratic input trajectory
@cielavenir did you test for regressions? thanks |
this branch has been tested at latest_test pipeline, and we ran some cycles as morning test |
…itialize_quadratic_20241224
…itialize_quadratic_20241224
…itialize_quadratic_20241224
I ran some cycles at the real cell and I don't think there are issues cc @ntohge @Puttichai Is this still draft? |
I have been running simulations with these changes and have not noticed any issues so far. So I'm changing the status to ready now. Thanks for helping check it @cielavenir |
Background
When a parabolic trajectory segment is checked for constraint violation via
CheckPathAllConstraints
(in the functionSegmentFeasible2
in parabolicsmoother), the resulting trajectory segment returned from the check function may be slightly different due to modifications from the check function. Parabolicsmoother handles this slight modification byIf the ramp is still consistent with the new acceleration value, then the ramp is accepted as valid.
Even though acceleration values of all ramps are computed and validated by the smoother, they are not getting written to the output trajectory.
Issue
When a trajectory output from parabolicsmoother is fed back as an input to parabolicsmoother (as part of different computation process, for example), during initialization of ramps, the smoother only does step 1 above (computing the acceleration values most consistent with the boundary conditions) but without the step 2 (adjusting acceleration value in case of limit violation).
This discrepancy between when the ramps were first produced by the smoother and when the ramps are being initialized anew from an OpenRAVE trajectory instance may lead to an error later on.