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
@@ -183,7 +193,7 @@ The below is the ``ComputePathToPose`` subtree:
183
193
|
184
194
185
195
The parent ``RecoveryNode`` controls the flow between the action, and the contextual recovery subtree.
186
-
The contextual recoveries for both ``ComputePathToPose`` and ``FollowPath`` involve checking if the goal has been updated, and involves clearing the relevant costmap.
196
+
The contextual recoveries for both ``ComputePathToPose`` and ``FollowPath`` involve checking if the recovery could help clear the error code and clearing the relevant costmap.
187
197
188
198
Consider changing the ``number_of_retries`` parameter in the parent ``RecoveryNode`` control node if your application can tolerate more attempts at contextual recoveries before moving on to system-level recoveries.
189
199
@@ -202,6 +212,8 @@ The only differences in the BT subtree of ``ComputePathToPose`` and ``FollowPath
202
212
- The ``ComputePathToPose`` subtree clears the global costmap. The global costmap is the relevant costmap in the context of the planner
203
213
- The ``FollowPath`` subtree clears the local costmap. The local costmap is the relevant costmap in the context of the controller
204
214
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.
At the top level, a ``Sequence`` ensures the following steps are executed in order:
254
+
255
+
- A ``Fallback`` node first checks whether planner or controller recoveries might help resolve the issue. If either returns ``SUCCESS``, the fallback succeeds and the sequence proceeds to the next step.
234
256
235
-
The top most parent, ``ReactiveFallback`` controls the flow between the rest of the system wide recoveries, and asynchronously checks if a new goal has been received.
257
+
- A ``ReactiveFallback`` that controls the flow between the rest of the system wide recoveries, and asynchronously checks if a new goal has been received.
236
258
If at any point the goal gets updated, this subtree will halt all children and return ``SUCCESS``. This allows for quick reactions to new goals and preempt currently executing recoveries.
237
259
This should look familiar to the contextual recovery portions of the ``Navigation`` subtree. This is a common BT pattern to handle the situation "Unless 'this condition' happens, Do action A".
238
260
@@ -263,7 +285,7 @@ For example, let's say the robot is stuck and the ``Navigation`` subtree returns
263
285
264
286
4. Let's say the next action, ``Wait`` returns ``SUCCESS``. The robot will then move on to the ``Navigation`` subtree
265
287
266
-
5. Assume the ``Navigation`` subtree returns ``FAILURE`` (clearing the costmaps, attempting a spin, and waiting were *still* not sufficient to recover the system. The robot will move onto the ``Recovery`` subtree and attempt the ``BackUp`` action. Let's say that the robot attempts the ``BackUp`` action and was able to successfully complete the action. The ``BackUp`` action node returns ``SUCCESS`` and so now we move on to the Navigation subtree again.
288
+
5. Assume the ``Navigation`` subtree returns ``FAILURE`` (clearing the costmaps, attempting a spin, and waiting were *still* not sufficient to recover the system). The robot will move onto the ``Recovery`` subtree and attempt the ``BackUp`` action. Let's say that the robot attempts the ``BackUp`` action and was able to successfully complete the action. The ``BackUp`` action node returns ``SUCCESS`` and so now we move on to the Navigation subtree again.
267
289
268
290
6. In this hypothetical scenario, let's assume that the ``BackUp`` action allowed the robot to successfully navigate in the ``Navigation`` subtree, and the robot reaches the goal. In this case, the overall BT will still return ``SUCCESS``.
0 commit comments