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
Stop replanning when near the goal if path is valid (#872)
* Stop replanning when near the goal if path is valid
Signed-off-by: Maurice <mauricepurnawan@gmail.com>
* Update
Signed-off-by: Maurice <mauricepurnawan@gmail.com>
---------
Signed-off-by: Maurice <mauricepurnawan@gmail.com>
@@ -203,6 +231,10 @@ The only differences in the BT subtree of ``ComputePathToPose`` and ``FollowPath
203
231
- The ``ComputePathToPose`` subtree centers around the ``ComputePathToPose`` action.
204
232
- The ``FollowPath`` subtree centers around the ``FollowPath`` action.
205
233
234
+
- The use of conditional flow control (``Fallback``):
235
+
- The ``ComputePathToPose`` subtree incorporates logic to handle the robot's behavior as it nears the goal. When using feasible planners, re-planning within a small radius (e.g., < 1.0m) can be detrimental due to state estimation drift or path-tracking errors, often resulting in unnecessary "looping" behaviors.
236
+
To prevent this, the subtree uses a ``ReactiveSequence`` with the ``IsGoalNearby`` node. If the robot is within a specified proximity threshold and the current path remains valid (i.e., no new obstacles), the subtree will skip the re-planning request. This allows the robot to smoothly transition into its final approach using its current path without unnecessary re-planning.
237
+
- The ``FollowPath`` subtree, by contrast, does not typically use this conditional gating. Once a path is available, the controller is invoked directly to produce velocity commands.
206
238
- The ``RateController`` that decorates the ``ComputePathToPose`` subtree
207
239
The ``RateController`` decorates the ``ComputePathToPose`` subtree to keep planning at the specified frequency. The default frequency for this BT is 1 hz.
208
240
This is done to prevent the BT from flooding the planning server with too many useless requests at the tree update rate (100Hz). Consider changing this frequency to something higher or lower depending on the application and the computational cost of
@@ -212,7 +244,7 @@ The only differences in the BT subtree of ``ComputePathToPose`` and ``FollowPath
212
244
- The ``ComputePathToPose`` subtree clears the global costmap. The global costmap is the relevant costmap in the context of the planner
213
245
- The ``FollowPath`` subtree clears the local costmap. The local costmap is the relevant costmap in the context of the controller
214
246
215
-
This subtree also utilizes the ``PlannerSelector``and ``ControllerSelector`` nodes. These nodes ffer flexibility for applications that need to adjust navigation behavior on the fly.
247
+
This subtree also utilizes the ``PlannerSelector``, ``ControllerSelector``, ``GoalCheckerSelector``, ``ProgressCheckerSelector``, and ``PathHandlerSelector`` nodes. These nodes offer flexibility for applications that need to adjust navigation behavior on the fly.
Copy file name to clipboardExpand all lines: behavior_trees/trees/nav_through_poses_recovery.rst
+19-9Lines changed: 19 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ By convention we name these by the style of algorithms that they are (e.g. not `
13
13
In this behavior tree, we attempt to retry the entire navigation task 6 times before returning to the caller that the task has failed.
14
14
This allows the navigation system ample opportunity to try to recovery from failure conditions or wait for transient issues to pass, such as crowding from people or a temporary sensor failure.
15
15
16
-
In nominal execution, this will replan the path at every 3 seconds and pass that path onto the controller, similar to the behavior tree in :ref:`behavior_trees`.
16
+
In nominal execution, this will replan the path at every 3 seconds if not close enough to goal and pass that path onto the controller, similar to the behavior tree in :ref:`behavior_trees`.
17
17
The planner though is now ``ComputePathThroughPoses`` taking a vector, ``goals``, rather than a single pose ``goal`` to plan to.
18
18
The ``RemovePassedGoals`` node is used to cull out ``goals`` that the robot has passed on its path.
19
19
In this case, it is set to remove a pose from the poses when the robot is within ``0.5`` of the goal and it is the next goal in the list.
@@ -38,29 +38,39 @@ While this behavior tree does not make use of it, the ``PlannerSelector``, ``Con
Copy file name to clipboardExpand all lines: behavior_trees/trees/nav_to_pose_recovery.rst
+13-3Lines changed: 13 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ By convention we name these by the style of algorithms that they are (e.g. not `
14
14
In this behavior tree, we attempt to retry the entire navigation task 6 times before returning to the caller that the task has failed.
15
15
This allows the navigation system ample opportunity to try to recovery from failure conditions or wait for transient issues to pass, such as crowding from people or a temporary sensor failure.
16
16
17
-
In nominal execution, this will replan the path at every second and pass that path onto the controller, similar to the behavior tree in :ref:`behavior_trees`.
17
+
In nominal execution, this will replan the path at every second if not close enough to goal and pass that path onto the controller, similar to the behavior tree in :ref:`behavior_trees`.
18
18
However, this time, if the planner fails, it will trigger contextually aware recovery behaviors in its subtree, clearing the global costmap.
19
19
Additional recovery behaviors can be added here for additional context-specific recoveries, such as trying another algorithm.
20
20
@@ -45,15 +45,25 @@ While this behavior tree does not make use of it, the ``PlannerSelector``, ``Con
0 commit comments