Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ParallelPlan can return failure even if some planning attempts succeed (OMPL) #3146

Open
amalnanavati opened this issue Dec 3, 2024 · 1 comment

Comments

@amalnanavati
Copy link
Contributor

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:

  1. 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).
  2. However, the system incorrectly sets result.val to SUCCESS if and only if all the separate instances of parallel plan succeeded (L923).
  3. This seems problematic for two reasons:
    1. It differs from the documented behavior "Shortest solution will be reported," which makes it seem like at least one planning attempt needs to succeed.
    2. It differs from the behavior when 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.
      1. 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
@sea-bass
Copy link
Contributor

sea-bass commented Dec 4, 2024

@sjahr This may be of interest to you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants