TrajectoryConstraints message needs better documentation

[kalakris]

The TrajectoryConstraints message, and the trajectory_constraints field in the MotionPlanRequest message need better documentation. I was unsure about how it is different from path_constraints, why it has an array of constraints within it, and what a motion planner should be doing with such constraints.

[davetcoleman]

@kalakris This enhancement request has been open for 3 years, are you ok if we close it?

[130s]

Actually, I recently found that some message types are missing description, which could make the developers fail to reuse them (unless they are not designed to be reused).

I was also thinking of offering to fill in these msg description as my task at the upcoming WMD, hoping this task is practically small enough to be finished in a few hours.

[davetcoleman]

Cool, sounds like a great idea!

[knorth55]

Are there any good documentation for TrajectoryConstraints in MotionPlanRequest?
I thought TrajectoryConstraints is similar as waypoints in CartesianPath, but MotionPlanResponse seems that these constraints are not like those.
I want to know how to use these constraints. Thank you.

[davetcoleman]

No, that's what this issue is for. It would be great if someone looked into the code where these messages are used and write up some documentation based on that

[knorth55]

I slightly read codes in moveit_core, but it seems that moveit do not pass TrajectoryConstraints to plannar. And also it seems ompl planner do not have that kind of constraints API. The message is only used in moveit_ros/benchmarks, but I have no idea how these msgs work.
I'm not sure about my understanding, but it looks that TrajectoryConstraints in MotionPlanRequest do nothing.

[davetcoleman]

I see what you mean - TrajectoryConstraints just stores multiple Constraints. Seems like its not very necessary, a std::vector could easily replace it inside its usage in BenchmarkExecutor

[v4hn]

Wow, that message has a short, but intense history.

@isucan introduced it 28. Sep. 2012 with a lot of ideas in mind (check out the commit).
One month later he decided that it does not make sense to have an interface for waypoint_constraints that can be violated by the trajectories in between the waypoints, partially undoing the previous commit.
Eventually, three month later, he reduced it to its current state without a proper commit message...
I guess it was overengineered for that time. In the end, such constraints can be simulated (to a degree) by planning multiple successive trajectories..

[davetcoleman]

Kill the message!