You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was doing a deep dive into the OMPL interface code to understand the details of where/when/how shortcutting and hybridization are automatically applied. And I believe I came across a bug (or, at least, a case where the documented behavior doesn't match the implementation). Specifically:
When request_.num_planning_attempts > max_planning_threads_, the system correctly runs request_.num_planning_attempts / max_planning_threads_ separate parallel plans (L897 and L903).
However, the system incorrectly sets result.val to SUCCESS if and only if all the separate instances of parallel plan succeeded (L923).
This seems problematic for two reasons:
It differs from the documented behavior "Shortest solution will be reported," which makes it seem like at least one planning attempt needs to succeed.
Notably, since max_planning_threads_ defaults to 4 (as specified here and here) and can't be changed via the ROS interface, this means that when request_.num_planning_attempts <= 4, the planner returns success if at least one thread found a solution, but when request_.num_planning_attempts > 4the planner returns success if all sets of 4 planner threads found at least one solution each.
Could others look at the linked code lines and let me know if my logic is sound, or whether I'm missing something?
I haven't yet created a specifc example that shows the impact of the bug, because my work interacts with MoveIt via the ROS service interface, which isn't amenable to testing a few lines in isolation. I'd be happy to go deeper into this once others have weighed in on whether this truly seems like a bug, or whether I overlooked something.
System Details:
ROS2 Humble
MoveIt2 Binary 2.5.5-1jammy.20241028.145304
Ubuntu 22.04.5 LTS
The text was updated successfully, but these errors were encountered:
I was doing a deep dive into the OMPL interface code to understand the details of where/when/how shortcutting and hybridization are automatically applied. And I believe I came across a bug (or, at least, a case where the documented behavior doesn't match the implementation). Specifically:
request_.num_planning_attempts > max_planning_threads_
, the system correctly runsrequest_.num_planning_attempts / max_planning_threads_
separate parallel plans (L897 and L903).result.val
to SUCCESS if and only if all the separate instances of parallel plan succeeded (L923).request_.num_planning_attempts <= max_planning_threads_
. Specifically, in that case, a single instance of ParallelPlan runs multiple threads and returns success as long as any of the threads find a solution.max_planning_threads_
defaults to 4 (as specified here and here) and can't be changed via the ROS interface, this means that whenrequest_.num_planning_attempts <= 4
, the planner returns success if at least one thread found a solution, but whenrequest_.num_planning_attempts > 4
the planner returns success if all sets of 4 planner threads found at least one solution each.Could others look at the linked code lines and let me know if my logic is sound, or whether I'm missing something?
I haven't yet created a specifc example that shows the impact of the bug, because my work interacts with MoveIt via the ROS service interface, which isn't amenable to testing a few lines in isolation. I'd be happy to go deeper into this once others have weighed in on whether this truly seems like a bug, or whether I overlooked something.
System Details:
The text was updated successfully, but these errors were encountered: