Feature Request: Cartesian Path Constraints

[mpowelson]

Cartesian path contraints would be useful. While eventually, different kinds of splines might be nice, for now I think the input may just be 2 isometries. The tcp must lie somewhere on the line between them.

This would ideally be added as a constraint to trajopt_ifopt

[JuliusSustarevas]

Hi, this might not be the right place for this comment.
I might be misunderstanding optimisation based control very well, but I was under the impression that the reference signal can be time-varying and thus cartesian path can be passed as a target trajectory, not necessarily a constraint. Where your normal " go to pose" type of problem would have (Y-R)'Q(Y-R) and R would be a repeated setpoint, a trajectory following could simply have target trajectory inside R? Is this too superficial understanding? Apologies, I'm just trying to figure out cartesian path following capabilities of traj_opt

[Levi-Armstrong]

The current trajopt implementation was developed for full trajectory optimization assuming constraints, costs functions and collision environment are fixed and only the trajectory joints states can be changed during the optimization. Where you motion plan upfront and then execute the trajectory assuming things have not changed.

In some case this may not be ideal where you would like to use this as the nominal trajectory and your system has some type of sensor feedback where you what to use optimization based control to adapt the trajectory while trying to track the nominal trajectory as close as possible. The trajopt_ifopt package was created to support doing just this and it is currently under active development to support this functionality. There is an example in tesseract_ros_examples called the online planner which demos early capabilities.