If a parallel planning run returns a path you would not have picked, inspect its solution-selection function. Completing first, travelling the shortest joint-space distance and keeping the largest obstacle clearance are different objectives. MoveIt’s PlanningComponent parallel overload defaults to a shortest-solution selector; the lower-level parallel function can instead return all responses when no selector is supplied.
An early-stopping callback answers a separate question: when should still-active pipelines be asked to stop? It changes which attempts can continue. It does not define the metric used to pick a returned response. Record both choices before attributing a result to the planner’s name.
The implementation examined here is MoveIt 2 tag 2.15.2, commit 093360fef2ea8269c607821b551ffb2d4bc5c9a8, checked on October 6, 2026. It is an explicit source pin, not a claim about your installed ROS distribution or the newest release. The finite-box comparison below is authored geometry; it does not run MoveIt, ROS or a planning plugin.
Check which parallel interface you called
In the pinned parallel-pipeline implementation, each worker appends a response to the shared container. After joining the planning threads, planWithParallelPipelines() calls the supplied selection function and returns its response in a one-item vector. With no selection function, it returns the stored response vector instead. Failed responses are included.
That vector is not a ranking or a reconstruction of the request list. Workers append as they reach the container, and the implementation does not promise request order. Keep an explicit association between each request’s pipeline configuration and its response. Do not identify a pipeline by array position or interpret element zero as a quality winner.
The PlanningComponent overload has a different default: its omitted selector argument is getShortestSolution. Its implementation takes the first response from the lower-level result vector. Omitting this default argument is therefore different from deliberately passing a null selector. Check the overload and arguments in the code you actually call.
| Choice to record | What it determines | What it does not establish |
|---|---|---|
| Pipeline and planner configuration | Which planning attempts are launched | Which response should win |
| Stopping callback | Whether active pipelines receive termination requests | The best metric among returned candidates |
| Solution selector | Which response is selected from the stored results | Physical validity beyond its checks |
| Response status and trajectory | Whether there is usable output to examine | Clearance, timing or execution success by itself |
This boundary comes after the world representation has been chosen. The PlanningScene access guide explains live locks and detached copies. Here, the question is how to choose among returned responses for a declared planning problem.
“Shortest” refers to a particular distance
The pinned shortest-solution implementation prefers a successful response to a failed one. When both are successful, it compares robot_trajectory::pathLength(). The pinned path-length helper sums the distances between successive RobotState waypoints. It does not measure the Cartesian tool-centre polyline or the nearest obstacle surface.
As a result, a shorter value under that metric does not imply more clearance, shorter execution time, lower torque or smoother motion. A task can reasonably prioritize one of those properties, but it must define and validate the corresponding selector and required constraints. A clearance preference is not a universal replacement for the default.
The same source has no explicit empty-vector guard before dereferencing the result of std::min_element. Do not treat an empty candidate list as a zero-length plan. If all responses failed, choosing one of those responses does not turn it into a usable trajectory. A custom selector must also handle missing trajectory data and nonfinite metrics before ranking candidates. These are source-reading limits; we did not run a failing MoveIt process to reproduce them.
Equal metric values deserve a declared tie policy as well. The source does not supply a separate deterministic tie-break independent of response arrival. Retain candidate identity and the metric actually compared so that a selected response can be explained afterward.
A shorter box route can have a smaller gap
In a Blender 5.2.2 LTS experiment on October 6, 2026, we built these finite boxes, all seven full swept prisms and the three path meshes. We read back the complete evaluated geometry, then independently checked the finite surfaces, continuous segment minima and both ranking results. The diagram uses recovered design-frame coordinates: the scene was rigidly rotated by 17° about Z and translated by (0.13, −0.07, 0.08) m before readback. This normalization changes the displayed axes, not the relative distances.
The authored comparison fixes a 0.16 × 0.12 × 0.08 m tool box at zero yaw and a 0.50 × 0.50 × 0.08 m obstacle centred at (0, 0, 0.04) m. Every path starts at (−0.75, 0, 0.04) m and finishes at (0.75, 0, 0.04) m. One route goes through (−0.32, 0.34, 0.04) and (0.32, 0.34, 0.04) m. Another goes through (−0.45, −0.55, 0.04) and (0.45, −0.55, 0.04) m. A direct segment is the deliberately invalid control.
Both ranking rules use the same complete valid candidate set. The first minimizes Cartesian centreline length; the second maximizes the minimum finite-tool surface clearance over every declared segment. These are our authored criteria, not MoveIt’s joint-state shortest metric or paths produced by named planners.
For this fixed-orientation box and linear translation, each segment’s continuous swept solid is the convex hull of its start and end rectangles, extruded through the tool’s full height. The complete swept solid must be checked. Endpoint outlines and selected poses alone cannot prove the intervening segment clear.
| Authored candidate | Cartesian centreline length | Minimum finite-box clearance | Eligible for both selectors |
|---|---|---|---|
| Short route | 1.7364 m | 17.33 mm | Yes |
| Long route | 2.1530 m | 220.27 mm | Yes |
| Direct control | 1.5000 m | 0; positive intersection at the midpoint | No |
The minimum-length rule selects the short route. The maximum-minimum-clearance rule selects the long route from the same two eligible candidates. The direct route has a positive finite intersection at its actual midpoint, so it is excluded before either ranking. Neither rule gets to keep a colliding candidate merely because its length is smaller.
The reported distances are rounded digital geometry results. The independent distance comparison allowed 0.008 mm for numerical differences; this is not a manufacturing tolerance, measured sensor accuracy or an operating safety margin.
The minimum must include the diagonal approaches around the obstacle’s corners. Measuring only the horizontal plateau would answer a different question. Likewise, zero unsigned distance needs a separate intersection or touching classification; it is not a measured penetration depth or contact force.
The continuous interpretation applies only to this declared fixed-yaw, translating box. It does not cover an articulated arm’s other links, changing orientation, cables, dynamics, interpolation used by a real controller, tracking error or operational safety. The motion-planning and trajectory-optimization guide explains why geometric paths need further validation before execution.
Stopping early does not pick the best clearance
In the examined low-level implementation, a worker evaluates the stopping callback after appending its response. This happens for failed responses too. A true result attempts to terminate known pipelines that are still active; the caller still joins the planning threads before applying the selector. It is not an instantaneous return or a promise that every unfinished worker disappears without a response.
The parallel-planning tutorial illustrates separate stopping and selection functions. Its example code belongs to a separately versioned tutorials repository and includes older member names. Use it for workflow context and check signatures against the examined implementation before compiling; we did not compile or execute its example.
A stopping policy that reacts to one named planner can leave a different candidate set from a policy that lets all attempts finish. A selector can only compare the candidates it receives. To compare selection criteria fairly, first hold the usable candidate set fixed, as the finite-box example does. To compare stopping policies, separately record which attempts were stopped, which responses arrived, and how much time each stage took.
Do not convert a source comment about full time budgets into a measured timing guarantee. With no stopping callback, the examined orchestration code omits callback-driven termination; timing behavior also depends on the configured planning pipelines. Neither this source review nor the box experiment measures scheduling, planner latency or termination responsiveness.
Keep enough evidence to explain the chosen response
For a run that selects an unexpected path, inspect the actual selector and stopping arguments first. Then retain the common start and goal, constraints, scene identity, each pipeline and planner configuration, response status, available trajectory and evaluated metric. Log failures alongside successful responses instead of discarding them from the diagnostic record.
Filter unusable candidates before assigning quality scores, and distinguish failure from a legitimate zero value. Apply the required full-robot and scene validity checks to the output representation you intend to execute. Compare remaining candidates using the declared objective, and record the chosen identity and tie rule. If smoothing, timing or another post-processing stage changes the trajectory, validate that changed result again.
A returned response is understandable only in relation to those inputs and decisions. Adding more pipelines does not by itself define what “best” means. State the metric, preserve the candidate set it evaluated, and keep stopping, selection and execution validation as separate decisions.