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
make time_optimal_trajectory_generation harder to misuse #2624
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2624 +/- ##
==========================================
- Coverage 51.00% 50.68% -0.32%
==========================================
Files 387 386 -1
Lines 32308 32151 -157
==========================================
- Hits 16476 16293 -183
- Misses 15832 15858 +26 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This change hardens the
Path
andTrajectory
APIs in thetrajectory_processing
package, by checking for a couple of conditions that are not well handled by the algorithm:Path
, and the path won't be constructed if it makes a 180 deg. turn.max_deviation
of 0.0 (default) create trajectories that are not valid, even ifisValid()
returns true. This is because such paths don't have blending at the corners, and therefore their parameterizations are not differentiable. The algorithm completes andisValid()
returns true, but the resulting trajectory has inconsistent velocities and accelerations.These conditions are now checked and handled appropriately. A
path_tolerance
of 0.0 is no longer an option. The defaultpath_tolerance
is now consistent betweenPath
andTimeOptimalTrajectoryGeneration
.To make this possible I had to change the API to use builder methods (to return error), and make the constructors private.
A side-effect is that
Trajectory::isValid()
is no longer needed.Trajectory::Create()
will returnstd::nullopt
if the trajectory can't be created.I also changed
Path
construction to take the waypoints as astd::vector
instead ofstd::list
, becausestd::vector
is a more common representation for a path, and should avoid requiring the user to make the conversion (and a copy) in most cases. This is a bit unrelated to the original issue but I made the change since I was changing the API anyway.Finally, adds test for the failing cases.
Closes #2600