|
6 | 6 | Planning Adapter Tutorials
|
7 | 7 | ==========================
|
8 | 8 |
|
9 |
| -Planning Request Adapters is a concept in MoveIt which can be used to modify the trajectory (pre-processing and/or post-processing) for a motion planner. Some examples of existing planning adapters in MoveIt include AddTimeParameterization, FixWorkspaceBounds, FixStartBounds, FixStartStateCollision, FixStartStatePathConstraints, CHOMPOptimizerAdapter, etc. ! Using the concepts of Planning Adapters, multiple motion planning algorithms can be used in a pipeline to produce robust motion plans. For example, a sample pipeline of motion plans might include an initial plan produced by OMPL which can then be optimized by CHOMP to produce a motion plan which would likely be better than a path produced by OMPL or CHOMP alone. Similarly, using the concept of Planning Adapters, other motion planners can be mixed and matched depending on the environment the robot is operating in. This section provides a step by step tutorial on using a mix and match of different motion planners and also provides insights on when to use which particular motion planners. |
| 9 | +Planning Request Adapters is a concept in MoveIt which can be used to modify the trajectory (pre-processing and/or post-processing) for a motion planner. Some examples of existing planning adapters in MoveIt include AddTimeParameterization, FixWorkspaceBounds, FixStartBounds, FixStartStateCollision, CHOMPOptimizerAdapter, etc. ! Using the concepts of Planning Adapters, multiple motion planning algorithms can be used in a pipeline to produce robust motion plans. For example, a sample pipeline of motion plans might include an initial plan produced by OMPL which can then be optimized by CHOMP to produce a motion plan which would likely be better than a path produced by OMPL or CHOMP alone. Similarly, using the concept of Planning Adapters, other motion planners can be mixed and matched depending on the environment the robot is operating in. This section provides a step by step tutorial on using a mix and match of different motion planners and also provides insights on when to use which particular motion planners. |
10 | 10 |
|
11 | 11 | Getting Started
|
12 | 12 | ---------------
|
@@ -50,7 +50,6 @@ To achieve this, follow the steps:
|
50 | 50 | default_planner_request_adapters/FixWorkspaceBounds
|
51 | 51 | default_planner_request_adapters/FixStartStateBounds
|
52 | 52 | default_planner_request_adapters/FixStartStateCollision
|
53 |
| - default_planner_request_adapters/FixStartStatePathConstraints |
54 | 53 | chomp/OptimizerAdapter" />
|
55 | 54 |
|
56 | 55 | #. The values of the ``planning_adapters`` is the order in which the mentioned adapters are called / invoked. Order here matters. Inside the CHOMP adapter, a :moveit_codedir:`call <moveit_planners/chomp/chomp_optimizer_adapter/src/chomp_optimizer_adapter.cpp#L169>` to OMPL is made before invoking the CHOMP optimization solver, so CHOMP takes the initial path computed by OMPL as the starting point to further optimize it.
|
@@ -85,7 +84,6 @@ To achieve this, follow the steps:
|
85 | 84 | default_planner_request_adapters/FixWorkspaceBounds
|
86 | 85 | default_planner_request_adapters/FixStartStateBounds
|
87 | 86 | default_planner_request_adapters/FixStartStateCollision
|
88 |
| - default_planner_request_adapters/FixStartStatePathConstraints |
89 | 87 | chomp/OptimizerAdapter" />
|
90 | 88 |
|
91 | 89 | #. The values of the ``planning_adapters`` is the order in which the mentioned adapters are called / invoked. Order here matters. Inside the CHOMP adapter, a call to STOMP is made before invoking the CHOMP optimization solver, so CHOMP takes the initial path computed by STOMP as the starting point to further optimize it.
|
@@ -122,7 +120,6 @@ To achieve this, follow the steps:
|
122 | 120 | default_planner_request_adapters/FixWorkspaceBounds
|
123 | 121 | default_planner_request_adapters/FixStartStateBounds
|
124 | 122 | default_planner_request_adapters/FixStartStateCollision
|
125 |
| - default_planner_request_adapters/FixStartStatePathConstraints |
126 | 123 | stomp_moveit/StompSmoothingAdapter" />
|
127 | 124 |
|
128 | 125 | #. The values of the ``planning_adapters`` is the order in which the mentioned adapters are called / invoked. Order here matters. Inside the STOMP adapter, a call to OMPL is made before invoking the STOMP smoothing solver, so STOMP takes the initial path computed by OMPL as the starting point to further optimize it.
|
|
0 commit comments