Add time parameterization interface and optional implementation builds

[marip8]

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]

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

[marip8]

Optional builds added in #373

[Levi-Armstrong]

@marip8 Are you working on the interface?

[marip8]

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

Shared

• max_velocity_scaling_factor (single value)
• acceleration_scaling_factor (single_value)
• max_velocity (single value and per joint)
• max_acceleration (single value and per joint)

Different

• max_velocity_scaling_factor (per waypoint - ISP, Ruckig)
• max_acceleration_scaling_factor (per waypoint - ISP, Ruckig)
• max_jerk (single value and per joint - Ruckig)
• max_jerk_scaling_factor (single value, per waypoint - Ruckig)

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]

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

[marip8]

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