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

Operations on PiecewisePolynomials with different breaks #22100

Open
2 of 4 tasks
sadraddini opened this issue Oct 31, 2024 · 2 comments
Open
2 of 4 tasks

Operations on PiecewisePolynomials with different breaks #22100

sadraddini opened this issue Oct 31, 2024 · 2 comments
Assignees
Labels
component: planning and control Optimization-based planning and control, and search- and sampling-based planning type: feature request

Comments

@sadraddini
Copy link
Contributor

Currently operations such as addition on piecewise polynomials are supported only if the objects have the same breaks. There have been discussions about the need for other operations such as stacking multiple piecewise polynomials into a new one.

In order to support these operations, I am proposing some methods:

  • AddBreak: which adds "fake" breaks into a pp trajectory without modifying its values at anytime.
  • Trim: extracting a timed slice of a piecewise trajectory trimmed_pp = pp[t_1,t_2].

I have the features above in #22099

In future, I also plan to include:

  • Stack (this is different from StackedTrajectory as it allows the user the maintain the object as piecewise polynomial).
  • Add support for += when pp objects don't have the same breaks.

Let me know your thoughts @RussTedrake

@RussTedrake
Copy link
Contributor

AddBreak, Trim, and Stack sound very good to me. (thanks!)

The question I have is whether we should modify the existing += to support objects that don't have the same break seems vs making a new method. Presumably the proposal is to call AddBreak repeatedly until the existing polynomial includes all of the breaks from other. The functionality sounds very good, of course, I just don't know if it should be called out as a different method rather than the operator overload.

@sadraddini
Copy link
Contributor Author

I fully agree on the need for a different addition function for +=!

@xuchenhan-tri xuchenhan-tri added the component: planning and control Optimization-based planning and control, and search- and sampling-based planning label Nov 1, 2024
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

No branches or pull requests

3 participants