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

Provide Derivatives in FunctionHandleTrajectory #22076

Closed
cohnt opened this issue Oct 24, 2024 · 5 comments · Fixed by #22262
Closed

Provide Derivatives in FunctionHandleTrajectory #22076

cohnt opened this issue Oct 24, 2024 · 5 comments · Fixed by #22262
Assignees
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning type: feature request

Comments

@cohnt
Copy link
Contributor

cohnt commented Oct 24, 2024

#21093 introduced a way for the user to specify trajectories as the image of an arbitrary function, completing the feature request in #20699. However, it does not yet support computing derivatives of the trajectory, which is needed for trajectory processing algorithms like Toppra. I think this should be pretty straightforward to implement, so I'll self-assign (and ask for help if I get stuck).

@cohnt cohnt added type: feature request component: planning and control Optimization-based planning and control, and search- and sampling-based planning labels Oct 24, 2024
@cohnt cohnt self-assigned this Oct 24, 2024
@cohnt
Copy link
Contributor Author

cohnt commented Oct 24, 2024

Actually, maybe this is more complicated than I thought, since I don't think we can use AutoDiffXd to get higher order derivatives. Would love to hear if people have other ideas.

I know Russ suggested allowing a user to provide a function if the derivatives are known. Or we could provide a finite-difference approximation.

@cohnt
Copy link
Contributor Author

cohnt commented Dec 2, 2024

@RussTedrake do you have any thoughts on how we should handle the user providing a function to give derivatives? I'm guessing the signature should be func(double t, int order), but Trajectory::DoEvalDerivative needs to work with all scalars, not just double. I'm not sure I even know what behavior would be expected if you call that method with an autodiff instead of double.

@RussTedrake
Copy link
Contributor

the signature should be func(double t, int order)

That seems basically right to me. We should decide/recommend if it's ok for methods to throw if e.g. they don't support all positive orders.

Trajectory::DoEvalDerivative needs to work with all scalars, not just double.

That's true, and I think we're on the same page but just to make sure: you only need to support T=AutoDiffXd if people call set_derivative_callback (or whatever you call it) on a FunctionHandle<AutoDiffXd>. This is why the signature should actually be Matrix<T> func(const T& t, int order). And everything is well defined, even if T=AutoDiffXd (each scalar would have the derivatives of the derivative... that's fine). Symbolic Expression works, too.

@cohnt
Copy link
Contributor Author

cohnt commented Dec 3, 2024

The interaction between std::function and templates is getting pretty far away from my comfort zone in C++. Can we maybe find someone else to get this done?

@cohnt cohnt removed their assignment Dec 3, 2024
@rpoyner-tri
Copy link
Contributor

Assigning to @hongkai-dai for further triage and delegation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning type: feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants