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

Use Pro-RRT directly under MoveToJointState and MoveToWaypoint #63

Merged
merged 1 commit into from
Dec 30, 2024

Conversation

marioprats
Copy link

Refactors the base MoveToJointState and MoveToWaypoint to:

  1. Use Pro-RRT directly instead of MTC.
  2. Make MoveToWaypoint use MoveToJointState internally.

This PR effectively makes Pro-RRT the default in all configs everywhere where MoveToJointState or MoveToWaypoint is called (e.g. move to waypoint shortcuts, etc.)
This should save planning time, improve determinism, reduce number of layers to maintain and give more flexibility to the user, since now we directly expose ports for:

  • Link padding
  • Orientation constraint
  • Velocity / acceleration scale factor.

It also lets us get rid of the 'RetryUntilSuccessful' decorators in planning Objectives, since the plans are now deterministic.

I manually tested all the configs this PR is touching to make sure they still work.

Here's an example of planning around a keep-out zone with a tool 'keep upright' constraint:

RRT.Constraints.webm

MTC stages doing joint-space planning still not updated to use Pro-RRT by default (https://github.com/PickNikRobotics/moveit_studio/issues/9810).

Requires https://github.com/PickNikRobotics/moveit_studio/pull/9924
Closes https://github.com/PickNikRobotics/moveit_studio/issues/9701

@marioprats marioprats requested a review from dyackzan December 19, 2024 14:39
Copy link

@dyackzan dyackzan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any risk that this switch could incur deterministic failure where the base rrt would be able to find a solution eventually if it re-tried planning enough?

@marioprats
Copy link
Author

Is there any risk that this switch could incur deterministic failure where the base rrt would be able to find a solution eventually if it re-tried planning enough?

There's the risk it can't find a solution for a given problem. If that happens, it will never find a solution given the same conditions, even if it retries, which is a good thing, otherwise there's no way users can write reliable applications. On the flip side, if it succeeds, it will always succeed.
The new way to 'make it work' would be to increase the number of iterations (or timeout) in the input port so that it spends more time searching for a solution.

@marioprats marioprats marked this pull request as ready for review December 20, 2024 10:57
@dyackzan dyackzan merged commit 17eb85f into main Dec 30, 2024
4 checks passed
dyackzan added a commit that referenced this pull request Jan 21, 2025
Use Pro-RRT directly under `MoveToJointState` and `MoveToWaypoint`
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

Successfully merging this pull request may close these issues.

2 participants