Closed AndyZe closed 3 years ago
Are you expecting users to clip the target velocity and acceleration before inputting to Ruckig? That is easy enough, I guess.
These checks make the Ruckig smoothing almost worthless, I would say, other than jerk.
Yes, Ruckig expects target velocities and accelerations within the given limits, otherwise a Result::ErrorInvalidInput
is returned. #72 proposes a final acceleration phase, so that target values can be outside of the limits while maximizing the time of the trajectory staying within the limits. This might be of interest for you.
Isn't the the purpose of Ruckig to take a target waypoint (position,velocity,acceleration) that is not necessarily achievable? And Ruckig will calculate the best possible solution?
Ruckig calculates a time-optimal and exact trajectory to a target waypoint. In fact Ruckig guarantees (e.g. for numerical exactness) that the error of the final position and final velocity to be within 1e-8, and for the final acceleration to be within 1e-10. When a target waypoint is not achievable (e.g. if the waypoints are outside of the limits, but also if a jerk limit is too low to reach the target velocity within the acceleration limit), an error is returned. The method validate_input(input)
can be used to check the input before an update step.
We had some questions about these lines (and similar) in ruckig.hpp:
This does not make sense to us. Isn't the the purpose of Ruckig to take a target waypoint (position,velocity,acceleration) that is not necessarily achievable? And Ruckig will calculate the best possible solution?
@nbbrooks