Skip to content
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

Checking target vel/accel do not exceed limits #74

Closed
AndyZe opened this issue Sep 28, 2021 · 2 comments
Closed

Checking target vel/accel do not exceed limits #74

AndyZe opened this issue Sep 28, 2021 · 2 comments

Comments

@AndyZe
Copy link

AndyZe commented Sep 28, 2021

We had some questions about these lines (and similar) in ruckig.hpp:

            if (input.min_acceleration) {
                if (input.target_acceleration[dof] > input.max_acceleration[dof] || input.target_acceleration[dof] < input.min_acceleration.value()[dof]) {
                    return false;
                }

            } else {
                if (std::abs(input.target_acceleration[dof]) > input.max_acceleration[dof]) {
                    return false;
                }
            }

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

@AndyZe
Copy link
Author

AndyZe commented Sep 28, 2021

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.

@pantor
Copy link
Owner

pantor commented Sep 29, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants