tesseract-robotics / tesseract_planning

Contains packages related to motion and process planning for the Tesseract Motion Planning Environment
http://tesseract-docs.rtfd.io
Other
46 stars 37 forks source link

Add time parameterization interface and optional implementation builds #254

Open marip8 opened 2 years ago

marip8 commented 2 years ago

It seems like all 3 existing implementations of time parameterization are intended to perform the same function. We should create an abstract interface for time parameterization and add the ability to optionally disable builds of implementations that need additional 3rd party dependencies (e.g., Ruckig)

Levi-Armstrong commented 2 years ago

I agree. We can still make them optional to build now if that is something needed now.

marip8 commented 11 months ago

Optional builds added in #373

Levi-Armstrong commented 11 months ago

@marip8 Are you working on the interface?

marip8 commented 11 months ago

Currently each algorithm has a slightly different signature for what it can/does support:

Shared

Does the per-waypoint max velocity/acceleration scaling factor actually function correctly? My experience was that it doesn't for ISP. If that is accurate, maybe we just drop that interface.

As far as jerk scaling, I think we would need to add it to the interface and just ignore the values for ISP and TOTG

Levi-Armstrong commented 11 months ago

Can we make the interface simpler so these are not part of the interface but just part of the yaml config/profiles?

marip8 commented 11 months ago

Can we make the interface simpler so these are not part of the interface but just part of the yaml config/profiles?

Depends. We could do this suggestion by just moving the algorithms into their respective tasks in task composer (like in SNP with the constant TCP speed time paramterization classes). I guess the question is whether or not there is value in having a stand-alone time parameterization class that exists outside of task composer. If there is value there, then it would make sense to create a common interface and force all implementations to provide that interface.

I personally only have only used the time parameterization algorithms as a part of a task pipeline, so I might lean towards dissolving tesseract_time_parameterization into tesseract_task_composer and creating libraries for the algorithms themselves in case anyone wants to use want for a special use-case