Is your feature request related to a problem? Please describe.
As a non-motion planning expert, I want predictable performance on easy to moderately-hard motion planning problems, where performance is broadly defined to include: fast planning times, "intuitive" motions, high repeatability. The default planner in the default planning pipeline (RRTConnect from the OMPL pipeline) is typically fast, requires minimal to no parameter tuning, but can produce wacky solutions on seemingly easy problems.

Describe the solution you'd like
I am looking at how moveitcpp::PlanningComponent::plan plans a path. I see it looks up the planning pipeline by some parameter, calls generatePlan for the selected pipeline and returns the solution if it finds one. I would like to propose to augment the semantics of the parameters.planning_pipeline parameter: instead of selecting one pipeline, you can select multiple, e.g., by setting its value to “ompl|stomp|pilz”. The only change would then be in moveitcpp::PlanningComponent::plan: it spawns interruptible threads for each planning pipeline, picks the first found solution, terminates the other threads. All existing code will behave the same way. This seems simple enough to try and might result in faster, more deterministic behavior in many cases. With some extra code, we can keep some stats around inside moveitcpp::PlanningComponent that tracks how often each planner “wins” and how much time it needs. These stats could be printed/logged upon destruction. (You could also further augment the parameter syntax to allow pipelines to run sequentially until one succeeds, e.g., using > as a separator: “pilz>stomp>ompl”.)

Describe alternatives you've considered

• Alternative planners in the OMPL planner pipeline have more parameters that non-experts find hard to tune or are simply not as performant in general.
• There are several alternative planning pipelines that each have their own weaknesses:
  • The Pilz planner pipeline is a fast, deterministic planner, but is incomplete (i.e., it won't always find a solution if one exists.
  • STOMP and CHOMP are typically fast and usually produce nice-looking paths, but are also incomplete.
• Currently, the ompl_interface in MoveIt measures distance as the unweighted L1 norm over joint angles. Weighting the distance in each joint differently might help a little bit, but picking “good” weights automatically may be hard. Alternatively, using swept volume as a distance measure to get more intuitive motions sounds nice, but is computationally too expensive. Another distance measure that is trying to capture some aspect of swept volume is to measure the distance between two robot configurations is to measure the sum of distances between the Cartesian positions of each joint in the two configurations (i.e. use FK to compute 3D positions of each joint, measure the sum of distances between corresponding 3D joint positions). Even that might be somewhat expensive. None of the alternative distance measures would eliminate the occasional wacky path. It would only make it more likely that the shortest path corresponds to what the user actually wants.