MultiPlanner

[rhaschke]

This introduces MultiPlanner, a new meta planner implementing the PlannerInterface, that runs multiple alternative planners in sequence and returns the first found solution.
This is useful to sequence different planning strategies of increasing complexity, e.g. Cartesian or joint-space interpolation first, then OMPL, ...
This is (slightly) different from the Fallbacks container, as the MultiPlanner directly applies its planners to each individual planning job. In contrast, the Fallbacks container first runs the active child to exhaustion before switching to the next child, which possibly applies a different planning strategy.

As the children planners should be able to use different timeouts (than the stage employing MultiPlanner), I also introduced a timeout property for all planners.

Doing so, I noticed and fixed a bug in the timeout handling of JointInterpolation.

[codecov]

Codecov Report

Base: 58.85% // Head: 58.63% // Decreases project coverage by -0.21% ⚠️

Coverage data is based on head (db6d90a) compared to base (eae0bdc).
Patch coverage: 17.50% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #429      +/-   ##
==========================================
- Coverage   58.85%   58.63%   -0.21%     
==========================================
  Files          89       90       +1     
  Lines        8386     8419      +33     
==========================================
+ Hits         4935     4936       +1     
- Misses       3451     3483      +32     

Impacted Files	Coverage Δ
...oveit/task_constructor/solvers/planner_interface.h	100.00% <ø> (ø)
core/src/solvers/cartesian_path.cpp	82.93% <0.00%> (ø)
core/src/solvers/multi_planner.cpp	0.00% <0.00%> (ø)
core/src/solvers/joint_interpolation.cpp	87.76% <100.00%> (ø)
core/src/solvers/pipeline_planner.cpp	67.75% <100.00%> (ø)
core/src/solvers/planner_interface.cpp	100.00% <100.00%> (ø)
demo/src/pick_place_task.cpp	96.78% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[v4hn]

Sorry for leaving this specifically hanging. There's clearly no harm in supporting the new mechanism in MTC now that it's upstream, but I still think this whole project should actually be handled as a variation of the Fallback container within the MTC framework instead of having its own opaque implementation as a single planner.
However, to get the same behavior rather big changes are required in MTC (including parallel stage computations).

The other fixes/cleanups make sense too.

[rhaschke]

As discussed in the initial comment, I don't see how this feature could be implemented as a Fallback container.

[v4hn]

Not without support for running multiple children at the same time, that's what I said. I definitely do not consider it out of scope though, but clearly out of current functionality.

[rhaschke]

Even if you can run multiple children in parallel, the semantics is different: Fallback containers run their children to exhaustion before switching to the next child/method, while the MultiPlanner switches to the next method on failure of the previous one(s) for each and every job immediately.

[v4hn]

Sorry, I meant to write a variation of *ParallelContainer*, not Fallback. I am well aware of the differences.