From a54e0ecd59528705f03658db17da9901f96de20e Mon Sep 17 00:00:00 2001 From: Steve Macenski Date: Fri, 26 Mar 2021 18:12:04 -0700 Subject: [PATCH 1/2] adding documentation for nav through poses PR --- .../actions/ComputePathThroughPoses.rst | 88 +++++++++++++++++++ .../bt-plugins/actions/ComputePathToPose.rst | 30 +++---- .../bt-plugins/actions/ControllerSelector.rst | 4 +- .../actions/NavigateThroughPoses.rst | 51 +++++++++++ .../bt-plugins/actions/PlannerSelector.rst | 4 +- .../bt-plugins/actions/RemovePassedGoals.rst | 76 ++++++++++++++++ configuration/packages/configuring-bt-xml.rst | 3 + migration/Foxy.rst | 13 +++ plugins/index.rst | 16 ++++ 9 files changed, 266 insertions(+), 19 deletions(-) create mode 100644 configuration/packages/bt-plugins/actions/ComputePathThroughPoses.rst create mode 100644 configuration/packages/bt-plugins/actions/NavigateThroughPoses.rst create mode 100644 configuration/packages/bt-plugins/actions/RemovePassedGoals.rst diff --git a/configuration/packages/bt-plugins/actions/ComputePathThroughPoses.rst b/configuration/packages/bt-plugins/actions/ComputePathThroughPoses.rst new file mode 100644 index 0000000000..cdee3e4ae2 --- /dev/null +++ b/configuration/packages/bt-plugins/actions/ComputePathThroughPoses.rst @@ -0,0 +1,88 @@ +.. _bt_compute_path_through_poses_action: + +ComputePathThroughPoses +======================= + +Invokes the ComputePathThroughPoses ROS 2 action server, which is implemented by the nav2_planner_ module. +The server address can be remapped using the ``server_name`` input port. + +.. _nav2_planner: https://github.com/ros-planning/navigation2/tree/main/nav2_planner + +Input Ports +----------- +:start: + + ===================================== ======= + Type Default + ------------------------------------- ------- + geometry_msgs::msg::PoseStamped N/A + ===================================== ======= + + Description + Start pose. Optional. Only used if not left empty. Takes in a blackboard variable, e.g. "{start}". + +:goals: + + ============================================= ======= + Type Default + --------------------------------------------- ------- + vector N/A + ============================================= ======= + + Description + Goal poses. Takes in a blackboard variable, e.g. "{goals}". + +:planner_id: + + ============== ======= + Type Default + -------------- ------- + string N/A + ============== ======= + + Description + Mapped name to the planner plugin type to use, e.g. GridBased. + +:server_name: + + ============== ======= + Type Default + -------------- ------- + string N/A + ============== ======= + + Description + Action server name. + + +:server_timeout: + + ============== ======= + Type Default + -------------- ------- + double 10 + ============== ======= + + Description + Action server timeout (ms). + +Output Ports +------------ + +:path: + + ========================== ======= + Type Default + -------------------------- ------- + nav_msgs::msg::Path N/A + ========================== ======= + + Description + Path created by action server. Takes in a blackboard variable, e.g. "{path}". + +Example +------- + +.. code-block:: xml + + diff --git a/configuration/packages/bt-plugins/actions/ComputePathToPose.rst b/configuration/packages/bt-plugins/actions/ComputePathToPose.rst index bba0363ccb..39935c9b62 100644 --- a/configuration/packages/bt-plugins/actions/ComputePathToPose.rst +++ b/configuration/packages/bt-plugins/actions/ComputePathToPose.rst @@ -12,22 +12,22 @@ Input Ports ----------- :start: - ============== ======= - Type Default - -------------- ------- - string N/A - ============== ======= + ===================================== ======= + Type Default + ------------------------------------- ------- + geometry_msgs::msg::PoseStamped N/A + ===================================== ======= Description Start pose. Optional. Only used if not left empty. Takes in a blackboard variable, e.g. "{start}". :goal: - ============== ======= - Type Default - -------------- ------- - string N/A - ============== ======= + ===================================== ======= + Type Default + ------------------------------------- ------- + geometry_msgs::msg::PoseStamped N/A + ===================================== ======= Description Goal pose. Takes in a blackboard variable, e.g. "{goal}". @@ -71,11 +71,11 @@ Output Ports :path: - ============== ======= - Type Default - -------------- ------- - string N/A - ============== ======= + ========================== ======= + Type Default + -------------------------- ------- + nav_msgs::msg::Path N/A + ========================== ======= Description Path created by action server. Takes in a blackboard variable, e.g. "{path}". diff --git a/configuration/packages/bt-plugins/actions/ControllerSelector.rst b/configuration/packages/bt-plugins/actions/ControllerSelector.rst index 0ecee00f7a..fb84cb4dc2 100644 --- a/configuration/packages/bt-plugins/actions/ControllerSelector.rst +++ b/configuration/packages/bt-plugins/actions/ControllerSelector.rst @@ -1,7 +1,7 @@ .. _bt_controller_selector_node: ControllerSelector -============== +================== It is used to select the Controller that will be used by the Controller server. It subscribes to the ``controller_selector`` topic to receive command messages with the name of the Controller to be used. It is commonly used before of the FollowPathAction. The ``selected_controller`` output port is passed to ``controller_id`` input port of the FollowPathAction. If none is provided on the topic, the ``default_controller`` is used. @@ -34,7 +34,7 @@ Input Ports Output Ports ------------ +------------ :selected_controller: diff --git a/configuration/packages/bt-plugins/actions/NavigateThroughPoses.rst b/configuration/packages/bt-plugins/actions/NavigateThroughPoses.rst new file mode 100644 index 0000000000..4d318f999a --- /dev/null +++ b/configuration/packages/bt-plugins/actions/NavigateThroughPoses.rst @@ -0,0 +1,51 @@ +.. _bt_navigate_through_poses_action: + +NavigateThroughPoses +==================== + +Invokes the NavigateThroughPoses ROS 2 action server, which is implemented by the bt_navigator_ module. + +.. _bt_navigator: https://github.com/ros-planning/navigation2/tree/main/nav2_bt_navigator + +Input Ports +----------- + +:goals: + + ============================================= ======= + Type Default + --------------------------------------------- ------- + vector N/A + ============================================= ======= + + Description + Goal poses. Takes in a blackboard variable, e.g. "{goals}". + +:server_name: + + ====== ======= + Type Default + ------ ------- + string N/A + ====== ======= + + Description + Action server name. + +:server_timeout: + + ====== ======= + Type Default + ------ ------- + double 10 + ====== ======= + + Description + Action server timeout (ms). + +Example +------- + +.. code-block:: xml + + diff --git a/configuration/packages/bt-plugins/actions/PlannerSelector.rst b/configuration/packages/bt-plugins/actions/PlannerSelector.rst index 206545ed44..11e4b7bc9c 100644 --- a/configuration/packages/bt-plugins/actions/PlannerSelector.rst +++ b/configuration/packages/bt-plugins/actions/PlannerSelector.rst @@ -1,7 +1,7 @@ .. _bt_planner_selector_node: PlannerSelector -============== +=============== It is used to select the planner that will be used by the planner server. It subscribes to the ``planner_selector`` topic to receive command messages with the name of the planner to be used. It is commonly used before of the ComputePathToPoseAction. The ``selected_planner`` output port is passed to ``planner_id`` input port of the ComputePathToPoseAction. If none is provided on the topic, the ``default_planner`` is used. @@ -34,7 +34,7 @@ Input Ports Output Ports ------------ +------------ :selected_planner: diff --git a/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst b/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst new file mode 100644 index 0000000000..0cdc8150f7 --- /dev/null +++ b/configuration/packages/bt-plugins/actions/RemovePassedGoals.rst @@ -0,0 +1,76 @@ +.. _bt_remove_passed_goals_action: + +RemovePassedGoals +================= + +Looks over the input port ``goals`` and removes any point that the robot is in close proximity to or has recently passed. +This is used to cull goal points that have been passed from ``ComputePathToPoses`` to enable replanning to only the current task goals. + +Input Ports +----------- + +:radius: + + ====== ======= + Type Default + ------ ------- + double 0.5 + ====== ======= + + Description + The radius (m) in proximity to the viapoint for the BT node to remove from the list as having passed. + +:global_frame: + + ====== ======= + Type Default + ------ ------- + string "map" + ====== ======= + + Description + Reference frame. + +:robot_base_frame: + + ====== =========== + Type Default + ------ ----------- + string "base_link" + ====== =========== + + Description + Robot base frame. + +:input_goals: + + ===================================== ======= + Type Default + ------------------------------------- ------- + geometry_msgs::msg::PoseStamped N/A + ===================================== ======= + + Description + A vector of goals to check if it passed any in the current iteration. + +Output Ports +------------ + +:output_goals: + + ===================================== ======= + Type Default + ------------------------------------- ------- + geometry_msgs::msg::PoseStamped N/A + ===================================== ======= + + Description + A vector of goals with goals removed in proximity to the robot + +Example +------- + +.. code-block:: xml + + + diff --git a/configuration/packages/configuring-bt-xml.rst b/configuration/packages/configuring-bt-xml.rst index 255400e164..ccccb5e8a0 100644 --- a/configuration/packages/configuring-bt-xml.rst +++ b/configuration/packages/configuring-bt-xml.rst @@ -32,6 +32,9 @@ Action Plugins bt-plugins/actions/TruncatePath.rst bt-plugins/actions/PlannerSelector.rst bt-plugins/actions/ControllerSelector.rst + bt-plugins/actions/NavigateThroughPoses.rst + bt-plugins/actions/ComputePathThroughPoses.rst + bt-plugins/actions/RemovePassedGoals.rst Condition Plugins ***************** diff --git a/migration/Foxy.rst b/migration/Foxy.rst index bf38691641..5b20b7d1b3 100644 --- a/migration/Foxy.rst +++ b/migration/Foxy.rst @@ -20,6 +20,16 @@ The NavigateToPose input port has been changed to PoseStamped instead of Point a See :ref:`bt_navigate_to_pose_action` for more information. + +NavigateThroughPoses and ComputePathThroughPoses Actions Added +************************************************************** + +The ``NavigateThroughPoses`` action has been added analog to the ``NavigateToPose``. Rather than going to a single position, this Action will allow a user to specify a number of hard intermediary pose constraints between the start and final pose to plan through. The new ``ComputePathThroughPoses`` action has been added to the ``planner_server`` to process these requests through ``N goal_poses``. + +The ``ComputePathThroughPoses`` action server will take in a set of ``N`` goals to achieve, plan through each pose and concatenate the output path for use in navigation. The controller and navigator know nothing about the semantics of the generated path, so the robot will not stop or slow on approach to these goals. It will rather continue through each pose as it were any other point on the path continuously. When paired with the ``SmacPlanner``, this feature can be used to generate **completely kinematically feasible trajectories through pose constraints**. + +If you wish to stop at each goal pose, consider using the waypoint follower instead, which will stop and allow a user to optionally execute a task plugin at each pose. + ComputePathToPose BT-node Interface Changes ******************************************* @@ -201,3 +211,6 @@ Original GitHub tickets: - `SingleTrigger `_ - `PlannerSelector `_ - `ControllerSelector `_ +- `NavigateThroughPoses `_ +- `RemovePassedGoals `_ +- `ComputePathThroughPoses `_ diff --git a/plugins/index.rst b/plugins/index.rst index 682a026ce8..68dfc127ce 100644 --- a/plugins/index.rst +++ b/plugins/index.rst @@ -252,6 +252,19 @@ Behavior Tree Nodes | | | topic input, otherwises uses a default | | | | controller id | +--------------------------------------------+---------------------+------------------------------------------+ +| `Navigate Through Poses`_ | Steve Macenski | BT Node for other BehaviorTree.CPP BTs | +| | | to call Nav2's NavThroughPoses action | +| | | | ++--------------------------------------------+---------------------+------------------------------------------+ +| `Remove Passed Goals`_ | Steve Macenski | Removes goal poses passed or within a | +| | | tolerance for culling old viapoints from | +| | | path re-planning | ++--------------------------------------------+---------------------+------------------------------------------+ +| `Compute Path Through Poses`_ | Steve Macenski | Computes a path through a set of poses | +| | | rather than a single end goal pose | +| | | using the planner plugin specified | ++--------------------------------------------+---------------------+------------------------------------------+ + .. _Back Up Action: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/back_up_action.cpp .. _Clear Entire Costmap Service: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/clear_costmap_service.cpp .. _Clear Costmap Except Region Service: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/clear_costmap_service.cpp @@ -265,6 +278,9 @@ Behavior Tree Nodes .. _Truncate Path: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/truncate_path_action.cpp .. _Planner Selector: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/planner_selector.cpp .. _Controller Selector: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/controller_selector.cpp +.. _Navigate Through Poses: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/navigate_through_poses_action.cpp +.. _Remove Passed Goals: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/remove_passed_goals_action.cpp +.. _Compute Path Through Poses: https://github.com/ros-planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/compute_path_through_poses_action.cpp From bc67bca81d9a1834069ed54c08e64024e908f9cf Mon Sep 17 00:00:00 2001 From: Steve Macenski Date: Wed, 31 Mar 2021 15:34:13 -0700 Subject: [PATCH 2/2] adding new params for nav through poses --- behavior_trees/index.rst | 47 +++++++++++ behavior_trees/trees/follow_point.rst | 39 ++++++++++ .../trees/nav_through_poses_recovery.rst | 78 +++++++++++++++++++ behavior_trees/trees/nav_to_pose_recovery.rst | 72 +++++++++++++++++ .../packages/configuring-bt-navigator.rst | 48 +++++++++++- index.rst | 1 + migration/Foxy.rst | 10 +++ 7 files changed, 291 insertions(+), 4 deletions(-) create mode 100644 behavior_trees/index.rst create mode 100644 behavior_trees/trees/follow_point.rst create mode 100644 behavior_trees/trees/nav_through_poses_recovery.rst create mode 100644 behavior_trees/trees/nav_to_pose_recovery.rst diff --git a/behavior_trees/index.rst b/behavior_trees/index.rst new file mode 100644 index 0000000000..a1d9aa53c9 --- /dev/null +++ b/behavior_trees/index.rst @@ -0,0 +1,47 @@ +.. _behavior_trees: + +Behavior Tree XMLs +################## + +.. toctree:: + :maxdepth: 1 + + trees/nav_to_pose_recovery.rst + trees/nav_through_poses_recovery.rst + trees/follow_point.rst + +Nav2 is an incredibly reconfigurable project. It allows users to set many different plugin types, across behavior trees, core algorithms, status checkers, and more. +This section highlights some of the example behavior tree xml files provided by default in the project to do interesting tasks. +It should be noted that these can be modified for your specific application, or used as a guide to building your own application-specific behavior tree. +These are some exemplary examples of how you can reconfigure your navigation behavior significantly by using behavior trees. +Other behavior trees are provided by Nav2 in the ``nav2_bt_navigator`` package, but this section highlights the important ones. + +A **very** basic, but functional, navigator can be seen below. + +.. code-block:: xml + + + + + + + + + + + + +This behavior tree will simply plan a new path to ``goal`` every 1 meter (set by ``DistanceController``) using ``ComputePathToPose``. +If a new path is computed on the ``path`` blackboard variable, ``FollowPath`` will take this ``path`` and follow it using the server's default algorithm. + +This tree contains: + +- No recovery methods +- No retries on failure +- No selected planner or controller algorithms +- No nodes to contextually change settings for optimal performance +- No integration with automatic door, elevator, or other APIs +- No user provided custom BT nodes +- No subtrees for other behaviors like docking, following, etc. + +All of this, and more, can be set and configured for your customized navigation logic in Nav2. diff --git a/behavior_trees/trees/follow_point.rst b/behavior_trees/trees/follow_point.rst new file mode 100644 index 0000000000..493b3f529b --- /dev/null +++ b/behavior_trees/trees/follow_point.rst @@ -0,0 +1,39 @@ +.. _behavior_tree_follow_point: + +Follow Dynamic Point +#################### + + +This behavior tree implements a navigation behavior from a starting point, attempting to follow a dynamic point over time. +This "dynamic point" could be a person, another robot, a virtual carrot, anything. +The only requirement is that the pose you'd like to follow is published to the topic outlined in the ``GoalUpdater`` BT node. + +In this tree, we replan at 1 hz just as we did in :ref:`behavior_tree_nav_to_pose` using the ``ComputePathToPose`` node. +However, this time when we replan, we update the ``goal`` based on the newest information in on the updated goal topic. +After we plan a path to this dynamic point, we use the ``TruncatePath`` node to remove path points from the end of the path near the dynamic point. +This behavior tree node is useful so that the robot always remains at least ``distance`` away from the obstacle, even if it stops. +It also smooths out any off path behavior involved with trying to path plan towards a probably occupied space in the costmap. + +After the new path to the dynamic point is computed and truncated, it is again passed to the controller via the ``FollowPath`` node. +However, note that it is under a ``KeepRunningUntilFailure`` decorator node ensuring the controller continues to execute until a failure mode. +This behavior tree will execute infinitely in time until the navigation request is preempted or cancelled. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + diff --git a/behavior_trees/trees/nav_through_poses_recovery.rst b/behavior_trees/trees/nav_through_poses_recovery.rst new file mode 100644 index 0000000000..631436a782 --- /dev/null +++ b/behavior_trees/trees/nav_through_poses_recovery.rst @@ -0,0 +1,78 @@ +.. _behavior_tree_nav_through_poses: + +Navigate Through Poses +###################### + +This behavior tree implements a navigation behavior from a starting point, through many intermediary hard pose constraints, to a final goal in freespace. +It contains both use of custom recoveries in specific sub-contexts as well as a global recovery subtree for system-level failures. +It also provides the opportunity for users to retry tasks multiple times before returning a failed state. + +The ``ComputePathThroughPoses`` and ``FollowPath`` BT nodes both also specify their algorithms to utilize. +By convention we name these by the style of algorithms that they are (e.g. not ``DWB`` but rather ``FollowPath``) such that a behavior tree or application developer need not worry about the technical specifics. They just want to use a path following controller. + +In this behavior tree, we attempt to retry the entire navigation task 6 times before returning to the caller that the task has failed. +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. + +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`. +The planner though is now ``ComputePathThroughPoses`` taking a vector, ``goals``, rather than a single pose ``goal`` to plan to. +The ``RemovePassedGoals`` node is used to cull out ``goals`` that the robot has passed on its path. +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. +This is implemented such that replanning can be computed after the robot has passed by some of the intermediary poses and not continue to try to replan through them in the future. +This time, if the planner fails, it will trigger contextually aware recoveries in its subtree, clearing the global costmap. +Additional recoveries can be added here for additional context-specific recoveries, such as trying another algorithm. + +Similarly, the controller has similar logic. If it fails, it also attempts a costmap clearing of the local costmap impacting the controller. +It is worth noting the ``GoalUpdated`` node in the reactive fallback. +This allows us to exit recovery conditions when a new goal has been passed to the navigation system through a preemption. +This ensures that the navigation system will be very responsive immediately when a new goal is issued, even when the last goal was in an attempted recovery. + +If these contextual recoveries fail, this behavior tree enters the recovery subtree. +This subtree is reserved for system-level failures to help resolve issues like the robot being stuck or in a bad spot. +This subtree also has the ``GoalUpdated`` BT node it ticks every iteration to ensure responsiveness of new goals. +Next, the recovery subtree will the recoveries: costmap clearing operations, spinning, waiting, and backing up. +After each of the recoveries in the subtree, the main navigation subtree will be reattempted. +If it continues to fail, the next recovery in the recovery subtree is ticked. + +While this behavior tree does not make use of it, the ``PlannerSelector``, ``ControllerSelector``, and ``GoalCheckerSelector`` behavior tree nodes can also be helpful. Rather than hardcoding the algorithm to use (``GridBased`` and ``FollowPath``), these behavior tree nodes will allow a user to dynamically change the algorithm used in the navigation system via a ROS topic. It may be instead advisable to create different subtree contexts using condition nodes with specified algorithms in their most useful and unique situations. However, the selector nodes can be a useful way to change algorithms from an external application rather than via internal behavior tree control flow logic. It is better to implement changes through behavior tree methods, but we understand that many professional users have external applications to dynamically change settings of their navigators. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/behavior_trees/trees/nav_to_pose_recovery.rst b/behavior_trees/trees/nav_to_pose_recovery.rst new file mode 100644 index 0000000000..1585095b6c --- /dev/null +++ b/behavior_trees/trees/nav_to_pose_recovery.rst @@ -0,0 +1,72 @@ +.. _behavior_tree_nav_to_pose: + +Navigate To Pose +################ + +This behavior tree implements a significantly more mature version of the behavior tree on :ref:`behavior_trees`. +It navigates from a starting point to a single point goal in freespace. +It contains both use of custom recoveries in specific sub-contexts as well as a global recovery subtree for system-level failures. +It also provides the opportunity for users to retry tasks multiple times before returning a failed state. + +The ``ComputePathToPose`` and ``FollowPath`` BT nodes both also specify their algorithms to utilize. +By convention we name these by the style of algorithms that they are (e.g. not ``DWB`` but rather ``FollowPath``) such that a behavior tree or application developer need not worry about the technical specifics. They just want to use a path following controller. + +In this behavior tree, we attempt to retry the entire navigation task 6 times before returning to the caller that the task has failed. +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. + +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`. +However, this time, if the planner fails, it will trigger contextually aware recoveries in its subtree, clearing the global costmap. +Additional recoveries can be added here for additional context-specific recoveries, such as trying another algorithm. + +Similarly, the controller has similar logic. If it fails, it also attempts a costmap clearing of the local costmap impacting the controller. +It is worth noting the ``GoalUpdated`` node in the reactive fallback. +This allows us to exit recovery conditions when a new goal has been passed to the navigation system through a preemption. +This ensures that the navigation system will be very responsive immediately when a new goal is issued, even when the last goal was in an attempted recovery. + +If these contextual recoveries fail, this behavior tree enters the recovery subtree. +This subtree is reserved for system-level failures to help resolve issues like the robot being stuck or in a bad spot. +This subtree also has the ``GoalUpdated`` BT node it ticks every iteration to ensure responsiveness of new goals. +Next, the recovery subtree will the recoveries: costmap clearing operations, spinning, waiting, and backing up. +After each of the recoveries in the subtree, the main navigation subtree will be reattempted. +If it continues to fail, the next recovery in the recovery subtree is ticked. + +While this behavior tree does not make use of it, the ``PlannerSelector``, ``ControllerSelector``, and ``GoalCheckerSelector`` behavior tree nodes can also be helpful. Rather than hardcoding the algorithm to use (``GridBased`` and ``FollowPath``), these behavior tree nodes will allow a user to dynamically change the algorithm used in the navigation system via a ROS topic. It may be instead advisable to create different subtree contexts using condition nodes with specified algorithms in their most useful and unique situations. However, the selector nodes can be a useful way to change algorithms from an external application rather than via internal behavior tree control flow logic. It is better to implement changes through behavior tree methods, but we understand that many professional users have external applications to dynamically change settings of their navigators. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/configuration/packages/configuring-bt-navigator.rst b/configuration/packages/configuring-bt-navigator.rst index 45ee4e5169..03f07d3475 100644 --- a/configuration/packages/configuring-bt-navigator.rst +++ b/configuration/packages/configuring-bt-navigator.rst @@ -14,7 +14,7 @@ in the navigation task and provide a way to easily specify complex robot behavio Parameters ********** -:default_bt_xml_filename: +:default_nav_to_pose_bt_xml: ====== ======= Type Default @@ -23,7 +23,21 @@ Parameters ====== ======= Description - Path to the default behavior tree XML description, see :ref:`configuring_behavior_tree_xml` for details on this file. + Path to the default behavior tree XML description for ``NavigateToPose``, see :ref:`configuring_behavior_tree_xml` for details on this file. + Used to be ``default_bt_xml_filename`` pre-Galactic. + + +:default_nav_through_poses_bt_xml: + + ====== ======= + Type Default + ------ ------- + string N/A + ====== ======= + + Description + Path to the default behavior tree XML description for ``NavigateThroughPoses``, see :ref:`configuring_behavior_tree_xml` for details on this file. New to Galactic after ``NavigateThroughPoses`` was added. + :plugin_lib_names: @@ -145,7 +159,29 @@ Parameters ====== ======= Description - Blackboard variable to use to supply the goal to the behavior tree. Should match ports of BT XML file. + Blackboard variable to use to supply the goal to the behavior tree for ``NavigateToPose``. Should match ports of BT XML file. + +:path_blackboard_id: + + ====== ======= + Type Default + ------ ------- + string "path" + ====== ======= + + Description + Blackboard variable to get the path from the behavior tree for ``NavigateThroughPoses`` feedback. Should match port names of BT XML file. + +:goals_blackboard_id: + + ====== ======= + Type Default + ------ ------- + string "goals" + ====== ======= + + Description + Blackboard variable to use to supply the goals to the behavior tree for ``NavigateThroughPoses``. Should match ports of BT XML file. :use_sim_time: @@ -171,7 +207,11 @@ Example enable_groot_monitoring: True groot_zmq_publisher_port: 1666 groot_zmq_server_port: 1667 - bt_xml_filename: replace/with/path/to/bt.xml + default_nav_to_pose_bt_xml: replace/with/path/to/bt.xml + default_nav_through_poses_bt_xml: replace/with/path/to/bt.xml + goal_blackboard_id: goal + goals_blackboard_id: goals + path_blackboard_id: path plugin_lib_names: - nav2_compute_path_to_pose_action_bt_node - nav2_follow_path_action_bt_node diff --git a/index.rst b/index.rst index a2fd6cee1c..eb3d16a9a3 100644 --- a/index.rst +++ b/index.rst @@ -124,6 +124,7 @@ Below is an example of the TB3 navigating in a small lounge. tutorials/index.rst plugin_tutorials/index.rst configuration/index.rst + behavior_trees/index.rst plugins/index.rst migration/index.rst contribute/index.rst diff --git a/migration/Foxy.rst b/migration/Foxy.rst index 5b20b7d1b3..c02ef7f32d 100644 --- a/migration/Foxy.rst +++ b/migration/Foxy.rst @@ -214,3 +214,13 @@ Original GitHub tickets: - `NavigateThroughPoses `_ - `RemovePassedGoals `_ - `ComputePathThroughPoses `_ + +sensor_msgs/PointCloud to sensor_msgs/PointCloud2 Change +******************************************************** +Due to deprecation of `sensor_msgs/PointCloud `_ the topics which were publishing sensor_msgs/PointCloud are converted to sensor_msgs/PointCloud2. The details on these topics and their respective information are listed below. + +- ``clearing_endpoints`` topic in ``voxel_layer`` plugin of ``nav2_costmap_2d`` package +- ``voxel_marked_cloud`` and ``voxel_unknown_cloud`` topic in ``costmap_2d_cloud`` node of ``nav2_costmap_2d`` package +- ``cost_cloud`` topic of ``publisher.cpp`` of ``dwb_core`` package. + +These changes were introduced inthis `pull request `_.