Node must contain 2 children and returns success if first succeeds. If first
fails, the second will be ticked. If successful, it will retry the first and
then return its value

[ Round Robin ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/control/round_robin_node.cpp)


Tolerance in meters between requested goal pose and end of path.


###  Parameters


The Navfn Planner plugin implements a wavefront Dijkstra or A* expanded
holonomic planner.


Steve Macenski


The following parameters are relevant only if [ costmap_converter
](/costmap_converter) plugins are desired (see tutorial):


Checks if goal is reached within tol.

[ Goal Updated Condition ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/condition/goal_updated_condition.cpp)


Default

---|---

double


Pradheep Padmanabhan


        * [ CancelCoverage ](../configuration/packages/bt-plugins/actions/CancelCoverage.html)
        * [ RemovePassedGoals ](../configuration/packages/bt-plugins/actions/RemovePassedGoals.html)
        * [ CancelControl ](../configuration/packages/bt-plugins/actions/CancelControl.html)
        * [ CancelBackUp ](../configuration/packages/bt-plugins/actions/CancelBackUp.html)
        * [ CancelSpin ](../configuration/packages/bt-plugins/actions/CancelSpin.html)
        * [ CancelWait ](../configuration/packages/bt-plugins/actions/CancelWait.html)
        * [ CancelDriveOnHeading ](../configuration/packages/bt-plugins/actions/CancelDriveOnHeading.html)
        * [ CancelAssistedTeleop ](../configuration/packages/bt-plugins/actions/CancelAssistedTeleop.html)
        * [ SmoothPath ](../configuration/packages/bt-plugins/actions/Smooth.html)
      * [ Condition Plugins ](../configuration/packages/configuring-bt-xml.html#condition-plugins)
        * [ GoalReached ](../configuration/packages/bt-plugins/conditions/GoalReached.html)
        * [ TransformAvailable ](../configuration/packages/bt-plugins/conditions/TransformAvailable.html)
        * [ DistanceTraveled ](../configuration/packages/bt-plugins/conditions/DistanceTraveled.html)
        * [ GoalUpdated ](../configuration/packages/bt-plugins/conditions/GoalUpdated.html)
        * [ GloballyUpdatedGoal ](../configuration/packages/bt-plugins/conditions/GloballyUpdatedGoal.html)
        * [ InitialPoseReceived ](../configuration/packages/bt-plugins/conditions/InitialPoseReceived.html)
        * [ IsStuck ](../configuration/packages/bt-plugins/conditions/IsStuck.html)
        * [ TimeExpired ](../configuration/packages/bt-plugins/conditions/TimeExpired.html)
        * [ IsBatteryLow ](../configuration/packages/bt-plugins/conditions/IsBatteryLow.html)
        * [ IsPathValid ](../configuration/packages/bt-plugins/conditions/IsPathValid.html)
        * [ PathExpiringTimer ](../configuration/packages/bt-plugins/conditions/PathExpiringTimer.html)
        * [ AreErrorCodesPresent ](../configuration/packages/bt-plugins/conditions/AreErrorCodesPresent.html)
        * [ WouldAControllerRecoveryHelp ](../configuration/packages/bt-plugins/conditions/WouldAControllerRecoveryHelp.html)
        * [ WouldAPlannerRecoveryHelp ](../configuration/packages/bt-plugins/conditions/WouldAPlannerRecoveryHelp.html)
        * [ WouldASmootherRecoveryHelp ](../configuration/packages/bt-plugins/conditions/WouldASmootherRecoveryHelp.html)
        * [ IsBatteryCharging ](../configuration/packages/bt-plugins/conditions/IsBatteryCharging.html)
      * [ Control Plugins ](../configuration/packages/configuring-bt-xml.html#control-plugins)
        * [ PipelineSequence ](../configuration/packages/bt-plugins/controls/PipelineSequence.html)
        * [ RoundRobin ](../configuration/packages/bt-plugins/controls/RoundRobin.html)
        * [ RecoveryNode ](../configuration/packages/bt-plugins/controls/RecoveryNode.html)
      * [ Decorator Plugins ](../configuration/packages/configuring-bt-xml.html#decorator-plugins)
        * [ RateController ](../configuration/packages/bt-plugins/decorators/RateController.html)
        * [ DistanceController ](../configuration/packages/bt-plugins/decorators/DistanceController.html)
        * [ SpeedController ](../configuration/packages/bt-plugins/decorators/SpeedController.html)
        * [ GoalUpdater ](../configuration/packages/bt-plugins/decorators/GoalUpdater.html)
        * [ PathLongerOnApproach ](../configuration/packages/bt-plugins/decorators/PathLongerOnApproach.html)
        * [ SingleTrigger ](../configuration/packages/bt-plugins/decorators/SingleTrigger.html)
      * [ Example ](../configuration/packages/configuring-bt-xml.html#example)
    * [ Costmap 2D ](../configuration/packages/configuring-costmaps.html)
      * [ Costmap2D ROS Parameters ](../configuration/packages/configuring-costmaps.html#costmap2d-ros-parameters)


differential-drive platform being used, while also adhering to
the original global plan.
The package is highly configurable. As with other methods
described, tuning these weighting parameters to produce
optimal behavior for a given application can be time consuming. Furthermore, as with all numerical soft-constraint
optimization techniques, no guarantees can be given on the
optimized solution, e.g., kinematic constraints may not be
perfectly respected, or an insufficient weight on the obstacle
distance constraint may result in the TEB skirting close to
obstacles. This is in contrast to sampling-based approaches
like the Dynamic Window Approach, where kinematic constraints can be explicitly modeled during trajectory generation.
Model Predictive Path Integral is an MPC variant which
uses perturbed trajectory samples to estimate the optimal tra-
jectory [25]. Rather than numerically optimizing trajectories
each time-step, a large number of noised samples are generated derived from the previous time-step’s optimal trajectory,
each is scored, and the optimal trajectory is identified. Since
this method does not involve the non-linear optimization
stage found in most MPC techniques, the cost functions
are uniquely not required to be differentiable or convex -
yielding greater latitude in designing system behavior. The
iterative update law optimizes the trajectory between timesteps, refining it as the robot moves towards its objective. It
has been proven effective in a number of domains including
aggressive outdoor driving and commercial robotics.
In Nav2, the MPPI controller utilizes tensor representations to batch process trajectories. The trajectory planner
generates many randomly noised controls from Gaussian distributions for each control axis (x, θ, and optionally y). The
noised controls are added to the previous optimal trajectory’s
velocities to create a set of randomly perturbed trajectories.
Constraints are applied on these trajectories’ velocity limits
and turning radii to make them physically achievable for
omnidirectional, Ackermann, and differential-drive robots.
Using time samples in the trajectory, the velocities are then
projected to fully construct the trajectory poses.
Each trajectory is scored by a configurable set of critic
functions - or objective functions which optimize for particular elements of robot behavior. Like DWB, all of the
critic functions are dynamically loaded plugins and may be
added, removed, or customized for a particular application.
The following critics are provided and produce good highspeed path tracking and active collision avoidance behavior:
goal angle, goal distance, obstacle map, path align, path
angle, path follow, prefer forward, anti-twirling, and dynamic
constraints. After scoring, the batch’s costs are normalized


` ~<name>/weight_inflation ` ( ` double ` , default: 0.1)


      * [ Smoothers ](../../concepts/index.html#smoothers)
      * [ Robot Footprints ](../../concepts/index.html#robot-footprints)
      * [ Waypoint Following ](../../concepts/index.html#waypoint-following)
    * [ State Estimation ](../../concepts/index.html#state-estimation)
      * [ Standards ](../../concepts/index.html#standards)
      * [ Global Positioning: Localization and SLAM ](../../concepts/index.html#global-positioning-localization-and-slam)
      * [ Odometry ](../../concepts/index.html#odometry)
    * [ Environmental Representation ](../../concepts/index.html#environmental-representation)
      * [ Costmaps and Layers ](../../concepts/index.html#costmaps-and-layers)
      * [ Costmap Filters ](../../concepts/index.html#costmap-filters)
      * [ Other Forms ](../../concepts/index.html#other-forms)
    * [ Nav2 Academic Overview ](../../concepts/index.html#nav2-academic-overview)
  * [ First-Time Robot Setup Guide ](../../setup_guides/index.html)
    * [ Setting Up Transformations ](../../setup_guides/transformation/setup_transforms.html)
      * [ Transforms Introduction ](../../setup_guides/transformation/setup_transforms.html#transforms-introduction)
      * [ Static Transform Publisher Demo ](../../setup_guides/transformation/setup_transforms.html#static-transform-publisher-demo)
      * [ Transforms in Navigation2 ](../../setup_guides/transformation/setup_transforms.html#transforms-in-navigation2)
      * [ Conclusion ](../../setup_guides/transformation/setup_transforms.html#conclusion)
    * [ Setting Up The URDF ](../../setup_guides/urdf/setup_urdf.html)
      * [ URDF and the Robot State Publisher ](../../setup_guides/urdf/setup_urdf.html#urdf-and-the-robot-state-publisher)
      * [ Setting Up the Environment ](../../setup_guides/urdf/setup_urdf.html#setting-up-the-environment)
      * [ Writing the URDF ](../../setup_guides/urdf/setup_urdf.html#writing-the-urdf)
      * [ Build and Launch ](../../setup_guides/urdf/setup_urdf.html#build-and-launch)
      * [ Visualization using RVIZ ](../../setup_guides/urdf/setup_urdf.html#visualization-using-rviz)
      * [ Adding Physical Properties ](../../setup_guides/urdf/setup_urdf.html#adding-physical-properties)
      * [ Conclusion ](../../setup_guides/urdf/setup_urdf.html#conclusion)
    * [ Setting Up Odometry ](../../setup_guides/odom/setup_odom.html)
      * [ Odometry Introduction ](../../setup_guides/odom/setup_odom.html#odometry-introduction)
      * [ Setting Up Odometry on your Robot ](../../setup_guides/odom/setup_odom.html#setting-up-odometry-on-your-robot)
      * [ Simulating an Odometry System using Gazebo ](../../setup_guides/odom/setup_odom.html#simulating-an-odometry-system-using-gazebo)
        * [ Setup and Prerequisites ](../../setup_guides/odom/setup_odom.html#setup-and-prerequisites)
        * [ Adding Gazebo Plugins to a URDF ](../../setup_guides/odom/setup_odom.html#adding-gazebo-plugins-to-a-urdf)
        * [ Launch and Build Files ](../../setup_guides/odom/setup_odom.html#launch-and-build-files)
        * [ Build, Run and Verification ](../../setup_guides/odom/setup_odom.html#build-run-and-verification)
      * [ Robot Localization Demo ](../../setup_guides/odom/setup_odom.html#robot-localization-demo)
        * [ Configuring Robot Localization ](../../setup_guides/odom/setup_odom.html#configuring-robot-localization)
        * [ Launch and Build Files ](../../setup_guides/odom/setup_odom.html#id3)
        * [ Build, Run and Verification ](../../setup_guides/odom/setup_odom.html#id4)
      * [ Conclusion ](../../setup_guides/odom/setup_odom.html#conclusion)
    * [ Setting Up Sensors ](../../setup_guides/sensors/setup_sensors.html)


` ~<name>/teb_feedback ` ( [ teb_local_planner/FeedbackMsg
](http://docs.ros.org/en/api/teb_local_planner/html/msg/FeedbackMsg.html) )


* Optimization weight for satisfying the maximum allowed translational velocity


David Lu


Released


The following parameters are relevant for the footprint model used for
optimization (see [ Tutorial Obstacle Avoidance and Robot Footprint Model
](/teb_local_planner/Tutorials/Obstacle%20Avoidance%20and%20Robot%20Footprint%20Model)
). **New in version 0.3**


may be regions of homes (such as bathrooms) and other
facilities where remote monitoring of camera data would
breach legal or ethical bounds. This layer allows the native
embedding of spatial constraints to trigger binary actions.
VI. OVERVIEW OF BEHAVIOR TREES
In this section, we describe the architecture of how robotic
components previously described are assembled to create
autonomous navigation. Configurable behavior trees (BTs)
are used to orchestrate internal robot navigation tasks such
as planning, control, high-level behaviors, recoveries, and
more in Nav2 [2], [42]. This contrasts historical uses of
state machines and hard-coded logic for designing navigation
systems: typically passing a path to a path tracker with hand
programmed behaviors [3]. While it is possible to model
most BT configurations with hierarchical state machines (and
vise versa), behavior trees have been the subject of much
interest and are increasingly preferred from the results of user
studies. The BT Navigator is the highest level component of
Nav2, taking requests and processing them via the behavior
outlined in the tree. Each behavior tree is modeled as an
XML file comprising many BT nodes which are dynamically
loaded at run-time. The behavior tree can be specified perrun so a system may take on different behaviors or tasks.
Most BT nodes will invoke a remote server over a ROS 2
interface (action, topic, service) to compute a value for
component-level modularity, although this is not required.
A growing number of primitive BT nodes are provided by
Nav2, shown in Table IV, that may be used to develop useful
robot behaviors. Note that users may easily create and use
their own BT nodes and trees.
TABLE IV
INCLUDED BEHAVIOR TREE NODES
Behavior Tree Node Description
Action
Navigate To Pose Navigate from A to B
Navigate Through Poses Navigate from A-Z through B...Y
Compute Path To Pose⋄ Plan from A to B
Compute Path Through Poses⋄ Plan from A-Z through B...Y
Follow Path∗ ⋄ Follow Path
Clear Costmap Clear environmental model
Back Up∗ Reverse


      * [ Composition ](../../tutorials/docs/adding_a_nav2_task_server.html#composition)
      * [ Error codes ](../../tutorials/docs/adding_a_nav2_task_server.html#error-codes)
      * [ Conclusion ](../../tutorials/docs/adding_a_nav2_task_server.html#conclusion)
    * [ Filtering of Noise-Induced Obstacles ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html)
      * [ Overview ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html#overview)
      * [ Requirements ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html#requirements)
      * [ Tutorial Steps ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html#tutorial-steps)
        * [ 1\. Enable Denoise Layer ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html#enable-denoise-layer)
        * [ 2\. Run Nav2 stack ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html#run-nav2-stack)
      * [ How it works ](../../tutorials/docs/filtering_of_noise-induced_obstacles.html#how-it-works)
    * [ Camera Calibration ](../../tutorials/docs/camera_calibration.html)
      * [ Overview ](../../tutorials/docs/camera_calibration.html#overview)
      * [ Requirements ](../../tutorials/docs/camera_calibration.html#requirements)
      * [ Tutorial Steps ](../../tutorials/docs/camera_calibration.html#tutorial-steps)
    * [ Get Backtrace in ROS 2 / Nav2 ](../../tutorials/docs/get_backtrace.html)
      * [ Overview ](../../tutorials/docs/get_backtrace.html#overview)
      * [ Preliminaries ](../../tutorials/docs/get_backtrace.html#preliminaries)
      * [ From a Node ](../../tutorials/docs/get_backtrace.html#from-a-node)
      * [ From a Launch File ](../../tutorials/docs/get_backtrace.html#from-a-launch-file)
      * [ From Large Project ](../../tutorials/docs/get_backtrace.html#from-large-project)
      * [ From Nav2 Bringup ](../../tutorials/docs/get_backtrace.html#from-nav2-bringup)
      * [ Automatic backtrace on crash ](../../tutorials/docs/get_backtrace.html#automatic-backtrace-on-crash)
    * [ Profiling in ROS 2 / Nav2 ](../../tutorials/docs/get_profile.html)
      * [ Overview ](../../tutorials/docs/get_profile.html#overview)
      * [ Preliminaries ](../../tutorials/docs/get_profile.html#preliminaries)
      * [ Profile from a Node ](../../tutorials/docs/get_profile.html#profile-from-a-node)
      * [ Profile from a Launch File ](../../tutorials/docs/get_profile.html#profile-from-a-launch-file)
      * [ From Nav2 Bringup ](../../tutorials/docs/get_profile.html#from-nav2-bringup)
      * [ Interpreting Results ](../../tutorials/docs/get_profile.html#interpreting-results)
    * [ Docker for Development: Zero to Hero ](../../tutorials/docs/docker_dev.html)
      * [ Overview ](../../tutorials/docs/docker_dev.html#overview)
      * [ Preliminaries ](../../tutorials/docs/docker_dev.html#preliminaries)
      * [ Important Docker Commands ](../../tutorials/docs/docker_dev.html#important-docker-commands)
      * [ Exploring Your First Container ](../../tutorials/docs/docker_dev.html#exploring-your-first-container)
      * [ Understanding ROS Docker Images ](../../tutorials/docs/docker_dev.html#understanding-ros-docker-images)
      * [ For Docker-Based Development ](../../tutorials/docs/docker_dev.html#for-docker-based-development)
        * [ Building a Development Image ](../../tutorials/docs/docker_dev.html#building-a-development-image)
        * [ Visualizations from Docker ](../../tutorials/docs/docker_dev.html#visualizations-from-docker)
      * [ For Docker-Based Deployment ](../../tutorials/docs/docker_dev.html#for-docker-based-deployment)
      * [ Conclusion ](../../tutorials/docs/docker_dev.html#conclusion)


* This parameter is only relevant for type "line". It contains the start coordinates of the line segment.


Michael Jeronimo


**Ackermann** , Differential, Omnidirectional, Legged

[ SmacPlanner2D ](https://github.com/ros-
planning/navigation2/tree/main/nav2_smac_planner)


Dreamworks Animation for movies such as How to Train
Your Dragon and Puss in Boots [39]. Rather than ray-tracing
to clear obstacles in the voxel grid, STVL uses a method
called decay acceleration to maintain a representation of the
environment based on the sensor’s measurement frustum and
current measurements. As measurements are processed, the
timestamp of the data is added to the voxel belonging to
the reading. If an active (e.g. occupied) voxel is within the
sensor frustum and seen by new data, the time is updated. If a
voxel is not viewed by new data, a decay acceleration factor
is applied to its time, quickening its removal due to lack
of current visibility. The frustum models are configurable
and currently support 3D lidar ’donut’ models and RGB-D,
depth, and similar sensors using a 6-plane bounding volume
defined by the minimum and maximum range and horizontal
and vertical field of views.
For all voxels outside of the sensor’s frustum, a global
linear time decay is applied, usually 10-30 seconds. After
voxels are expired due to either method, they are removed
from the data structure. Thus, its storage size is only dependent on the number of currently active and occupied
cells. The sparse voxel data structure is projected to two
dimensions for inclusion in the main cost map. This layer
is most appropriate for robots operating in highly dynamic
environments with a high degree of sensor coverage. It was
created to resolve issues with discrete cell ray-tracing which
occasionally left uncleared obstacle cells in highly dynamic
environments with many moving agents.
Fig. 13. STVL’s internal sparse 3D voxel grid representing shelves in a
retail environment [40].
Range The range layer processes data from Infrared,
Sonar, and Ultrasonic sensors. Due to the noise inherent
to these types of sensors, the range layer tracks occupancy
using a probabilistic model in which only cells with high
confidence predictions are written into the main cost map.
It has support for both fixed reading (e.g. binary detection
of obstacles) or variable reading sensors. The probability of
an obstacle in a cell is calculated using the static properties
of the sensor (range of view, maximum reliable range and
sensor variance), the sensor reading itself, and the angle and
distance of the cell relative to the sensor origin [41].


  * [ base_local_planner ](/base_local_planner?distro=noetic)
  * [ catkin ](/catkin?distro=noetic)
  * [ cmake_modules ](/cmake_modules?distro=noetic)
  * [ costmap_2d ](/costmap_2d?distro=noetic)
  * [ costmap_converter ](/costmap_converter?distro=noetic)
  * [ dynamic_reconfigure ](/dynamic_reconfigure?distro=noetic)
  * [ geometry_msgs ](/geometry_msgs?distro=noetic)
  * [ interactive_markers ](/interactive_markers?distro=noetic)
  * [ libg2o ](/libg2o?distro=noetic)
  * [ mbf_costmap_core ](/mbf_costmap_core?distro=noetic)
  * [ mbf_msgs ](/mbf_msgs?distro=noetic)
  * [ message_generation ](/message_generation?distro=noetic)
  * [ message_runtime ](/message_runtime?distro=noetic)
  * [ nav_core ](/nav_core?distro=noetic)
  * [ nav_msgs ](/nav_msgs?distro=noetic)
  * [ pluginlib ](/pluginlib?distro=noetic)
  * [ roscpp ](/roscpp?distro=noetic)
  * [ std_msgs ](/std_msgs?distro=noetic)
  * [ tf2 ](/tf2?distro=noetic)
  * [ tf2_eigen ](/tf2_eigen?distro=noetic)
  * [ tf2_geometry_msgs ](/tf2_geometry_msgs?distro=noetic)
  * [ tf2_ros ](/tf2_ros?distro=noetic)
  * [ visualization_msgs ](/visualization_msgs?distro=noetic)


__ [ Nav2 ](../../index.html)


each other (Table I), where 2D-A* is the shortest largely
attributable to the lack of non-holonomic constraints.
The 2D-A* planner is most useful when being deployed in
heterogeneous fleets of robots, whereas the non-holonomic
or large robots are using other planners within the Smac
Planner framework. This enables all robots in a fleet to have
consistent planning behavior based on analogous penalty
functions trading off grid map cost and path length using
the same weights.
B. Kinematically Feasible Planners
In contrast to the holonomic planners, Nav2 also provides a set of kinematically feasible planners - or planners
that consider kinematic constraints. These planners enable
integration with modern robots such as Ackermann and
legged robots, as well as providing accurate modeling of
non-circular differential-drive and holonomic bases. There
are many cases where classical robots are large relative to
their environment and require explicit modeling to create
feasible global paths. Since orientations are being considered,
collision checking and planning may use the robot shape to
generate paths that are high fidelity even through narrow
spaces. The feasible planners in Nav2 are Hybrid-A* and
State Lattice, both members of the Smac Planner framework.
Fig. 2. Example plans for kinematically feasible planners with reversing.
Hybrid-A* in brown, State Lattice in magenta.
1Downsampled grids of half resolution results in planning times competitive with the other Smac Planner implementations.
Hybrid-A* was proposed by Stanford during the DARPA
Urban Challenge as an extension of traditional grid-A* [14].
It uses motion primitives to search a grid map in a treefashion using continuous coordinates associated at discrete
cells (x, y, θ). This ensures continuous and feasible paths.
The primitives are composed of straight segments and circular arcs (left and right) of the minimal turning radius for
a car-like base. Periodic analytic expansions are applied to
find exact and optimal solutions from a currently expanded
pose to the goal pose. If this expansion is valid and collision
free, it is included in the route to complete the planning
process. The search primitives and analytic expansions can
be computed utilizing using Dubin or Reeds-Shepp models,
depending if reversing is a permissible action.
Thus, this method is specifically designed for car-like or
Ackermann vehicles; however, it has utility for legged and
large robots beyond naked feasibility of non-circular platforms. Limiting path curvature can be of practical importance


* This parameter is only relevant for type "two_circles". It describes how much the center of the front circle is shifted along the robot's x-axis. The robot's axis of rotation is assumed to be located at [0,0].


Joshua Wallace


The last two plugins are both **kinematically feasible** and support
**reversing** . They have performance similar to its 2D counter parts like
2D-A* and NavFn via highly optimized heuristic functions and efficient
programming. An example of the 3 planners can be seen below, planning a
roughly 75 m path.


      * [ Appendix ](../../tutorials/docs/docker_dev.html#appendix)
        * [ Nav2 Development Image ](../../tutorials/docs/docker_dev.html#nav2-development-image)
        * [ Nav2 Deployment Image ](../../tutorials/docs/docker_dev.html#nav2-deployment-image)
  * [ Plugin Tutorials ](../../plugin_tutorials/index.html)
    * [ Writing a New Costmap2D Plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#tutorial-steps)
        * [ 1- Write a new Costmap2D plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#write-a-new-costmap2d-plugin)
        * [ 2- Export and make GradientLayer plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#export-and-make-gradientlayer-plugin)
        * [ 3- Enable the plugin in Costmap2D ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#enable-the-plugin-in-costmap2d)
        * [ 4- Run GradientLayer plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#run-gradientlayer-plugin)
    * [ Writing a New Planner Plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#tutorial-steps)
        * [ 1- Creating a new Planner Plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#creating-a-new-planner-plugin)
        * [ 2- Exporting the planner plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#exporting-the-planner-plugin)
        * [ 3- Pass the plugin name through params file ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#pass-the-plugin-name-through-params-file)
        * [ 4- Run StraightLine plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#run-straightline-plugin)
    * [ Writing a New Controller Plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#tutorial-steps)
        * [ 1- Create a new Controller Plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#create-a-new-controller-plugin)
        * [ 2- Exporting the controller plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#exporting-the-controller-plugin)
        * [ 3- Pass the plugin name through the params file ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#pass-the-plugin-name-through-the-params-file)
        * [ 4- Run Pure Pursuit Controller plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#run-pure-pursuit-controller-plugin)
    * [ Writing a New Behavior Tree Plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#tutorial-steps)
        * [ 1- Creating a new BT Plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#creating-a-new-bt-plugin)
        * [ 2- Exporting the planner plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#exporting-the-planner-plugin)
        * [ 3- Add plugin library name to config ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#add-plugin-library-name-to-config)
        * [ 4- Run Your Custom plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#run-your-custom-plugin)
    * [ Writing a New Behavior Plugin ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html#tutorial-steps)


Pablo Iñigo Blasco


      * [ Default Plugins ](configuring-costmaps.html#default-plugins)
      * [ Plugin Parameters ](configuring-costmaps.html#plugin-parameters)
        * [ Static Layer Parameters ](costmap-plugins/static.html)
        * [ Inflation Layer Parameters ](costmap-plugins/inflation.html)
        * [ Obstacle Layer Parameters ](costmap-plugins/obstacle.html)
        * [ Voxel Layer Parameters ](costmap-plugins/voxel.html)
        * [ Range Sensor Parameters ](costmap-plugins/range.html)
        * [ Denoise Layer Parameters ](costmap-plugins/denoise.html)
      * [ Costmap Filters Parameters ](configuring-costmaps.html#costmap-filters-parameters)
        * [ Keepout Filter Parameters ](costmap-plugins/keepout_filter.html)
        * [ Speed Filter Parameters ](costmap-plugins/speed_filter.html)
        * [ Binary Filter Parameters ](costmap-plugins/binary_filter.html)
      * [ Example ](configuring-costmaps.html#example)
    * [ Lifecycle Manager ](configuring-lifecycle.html)
      * [ Parameters ](configuring-lifecycle.html#parameters)
      * [ Example ](configuring-lifecycle.html#example)
    * [ Planner Server ](configuring-planner-server.html)
      * [ Parameters ](configuring-planner-server.html#parameters)
      * [ Default Plugins ](configuring-planner-server.html#default-plugins)
      * [ Example ](configuring-planner-server.html#example)
    * [ Coverage Server ](configuring-coverage-server.html)
      * [ Parameters ](configuring-coverage-server.html#parameters)
      * [ Example ](configuring-coverage-server.html#example)
    * [ NavFn Planner ](configuring-navfn.html)
      * [ Parameters ](configuring-navfn.html#parameters)
      * [ Example ](configuring-navfn.html#example)
    * Smac Planner
      * Provided Plugins
        * [ Smac 2D Planner ](smac/configuring-smac-2d.html)
        * [ Smac Hybrid-A* Planner ](smac/configuring-smac-hybrid.html)
        * [ Smac State Lattice Planner ](smac/configuring-smac-lattice.html)
      * Description
    * [ Theta Star Planner ](configuring-thetastar.html)
      * [ Parameters ](configuring-thetastar.html#parameters)
      * [ Example ](configuring-thetastar.html#example)
    * [ Controller Server ](configuring-controller-server.html)
      * [ Parameters ](configuring-controller-server.html#parameters)
      * [ Provided Plugins ](configuring-controller-server.html#provided-plugins)
        * [ SimpleProgressChecker ](nav2_controller-plugins/simple_progress_checker.html)
        * [ PoseProgressChecker ](nav2_controller-plugins/pose_progress_checker.html)


` ~<name>/selection_obst_cost_scale ` ( ` double ` , default: 100.0)


  * [ source ubuntu bionic ](https://build.ros.org/view/Msrc_uB/job/Msrc_uB__teb_local_planner__ubuntu_bionic__source)
  * [ binary ubuntu bionic amd64 ](https://build.ros.org/view/Mbin_uB64/job/Mbin_uB64__teb_local_planner__ubuntu_bionic_amd64__binary)
  * [ binary ubuntu bionic armhf ](https://build.ros.org/view/Mbin_ubhf_uBhf/job/Mbin_ubhf_uBhf__teb_local_planner__ubuntu_bionic_armhf__binary)
  * [ binary ubuntu bionic arm64 ](https://build.ros.org/view/Mbin_ubv8_uBv8/job/Mbin_ubv8_uBv8__teb_local_planner__ubuntu_bionic_arm64__binary)
  * [ devel ubuntu bionic amd64 ](https://build.ros.org/view/Mdev/job/Mdev__teb_local_planner__ubuntu_bionic_amd64)
  * [ doc ](https://build.ros.org/view/Mdoc/job/Mdoc__teb_local_planner__ubuntu_bionic_amd64)


* [ teb_local_planner_tu... ](/teb_local_planner_tutorials?distro=lunar)


Inflates lethal obstacles in costmap with exponential decay

[ Obstacle Layer ](https://github.com/ros-
planning/navigation2/tree/main/nav2_costmap_2d/plugins/obstacle_layer.cpp)


` ~<name>/footprint_model/radius ` ( ` double ` , default: 0.2)


        * [ 1- Setup Rviz clicked point ](../../tutorials/docs/navigation2_dynamic_point_following.html#setup-rviz-clicked-point)
        * [ 2- Run Dynamic Object Following in Nav2 Simulation ](../../tutorials/docs/navigation2_dynamic_point_following.html#run-dynamic-object-following-in-nav2-simulation)
    * [ Navigating with Keepout Zones ](../../tutorials/docs/navigation2_with_keepout_filter.html)
      * [ Overview ](../../tutorials/docs/navigation2_with_keepout_filter.html#overview)
      * [ Requirements ](../../tutorials/docs/navigation2_with_keepout_filter.html#requirements)
      * [ Tutorial Steps ](../../tutorials/docs/navigation2_with_keepout_filter.html#tutorial-steps)
        * [ 1\. Prepare filter mask ](../../tutorials/docs/navigation2_with_keepout_filter.html#prepare-filter-mask)
        * [ 2\. Configure Costmap Filter Info Publisher Server ](../../tutorials/docs/navigation2_with_keepout_filter.html#configure-costmap-filter-info-publisher-server)
        * [ 3\. Enable Keepout Filter ](../../tutorials/docs/navigation2_with_keepout_filter.html#enable-keepout-filter)
        * [ 4\. Run Nav2 stack ](../../tutorials/docs/navigation2_with_keepout_filter.html#run-nav2-stack)
    * [ Navigating with Speed Limits ](../../tutorials/docs/navigation2_with_speed_filter.html)
      * [ Overview ](../../tutorials/docs/navigation2_with_speed_filter.html#overview)
      * [ Requirements ](../../tutorials/docs/navigation2_with_speed_filter.html#requirements)
      * [ Tutorial Steps ](../../tutorials/docs/navigation2_with_speed_filter.html#tutorial-steps)
        * [ 1\. Prepare filter mask ](../../tutorials/docs/navigation2_with_speed_filter.html#prepare-filter-mask)
        * [ 2\. Configure Costmap Filter Info Publisher Server ](../../tutorials/docs/navigation2_with_speed_filter.html#configure-costmap-filter-info-publisher-server)
        * [ 3\. Enable Speed Filter ](../../tutorials/docs/navigation2_with_speed_filter.html#enable-speed-filter)
        * [ 4\. Run Nav2 stack ](../../tutorials/docs/navigation2_with_speed_filter.html#run-nav2-stack)
    * [ Using Rotation Shim Controller ](../../tutorials/docs/using_shim_controller.html)
      * [ Overview ](../../tutorials/docs/using_shim_controller.html#overview)
      * [ What is the Rotation Shim Controller? ](../../tutorials/docs/using_shim_controller.html#what-is-the-rotation-shim-controller)
      * [ Configuring Rotation Shim Controller ](../../tutorials/docs/using_shim_controller.html#configuring-rotation-shim-controller)
      * [ Configuring Primary Controller ](../../tutorials/docs/using_shim_controller.html#configuring-primary-controller)
      * [ Demo Execution ](../../tutorials/docs/using_shim_controller.html#demo-execution)
    * [ Adding a Smoother to a BT ](../../tutorials/docs/adding_smoother.html)
      * [ Overview ](../../tutorials/docs/adding_smoother.html#overview)
      * [ Requirements ](../../tutorials/docs/adding_smoother.html#requirements)
      * [ Tutorial Steps ](../../tutorials/docs/adding_smoother.html#tutorial-steps)
        * [ 0- Familiarization with the Smoother BT Node ](../../tutorials/docs/adding_smoother.html#familiarization-with-the-smoother-bt-node)
        * [ 1- Specifying a Smoother Plugin ](../../tutorials/docs/adding_smoother.html#specifying-a-smoother-plugin)
        * [ 2- Modifying your BT XML ](../../tutorials/docs/adding_smoother.html#modifying-your-bt-xml)
    * [ Using Collision Monitor ](../../tutorials/docs/using_collision_monitor.html)
      * [ Overview ](../../tutorials/docs/using_collision_monitor.html#overview)
      * [ Requirements ](../../tutorials/docs/using_collision_monitor.html#requirements)
      * [ Configuring Collision Monitor ](../../tutorials/docs/using_collision_monitor.html#configuring-collision-monitor)
      * [ Configuring Collision Monitor with VelocityPolygon ](../../tutorials/docs/using_collision_monitor.html#configuring-collision-monitor-with-velocitypolygon)
      * [ Preparing Nav2 stack ](../../tutorials/docs/using_collision_monitor.html#preparing-nav2-stack)
      * [ Demo Execution ](../../tutorials/docs/using_collision_monitor.html#demo-execution)
    * [ Adding a New Nav2 Task Server ](../../tutorials/docs/adding_a_nav2_task_server.html)
      * [ Lifecycle Nodes ](../../tutorials/docs/adding_a_nav2_task_server.html#lifecycle-nodes)


* Activate multiple threading in order to plan each trajectory in a different thread


The following parameters are relevant only for carlike robots:


Calls clear entire costmap service

[ Clear Costmap Except Region Service ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/clear_costmap_service.cpp)


` ~<name>/inflation_dist ` ( ` double ` , default: pre kinetic: 0.0, kinetic+:
0.6)


      * [ DWB Forward vs Reverse Pruning ](../migration/Humble.html#dwb-forward-vs-reverse-pruning)
      * [ More stable regulation on curves for long lookahead distances ](../migration/Humble.html#more-stable-regulation-on-curves-for-long-lookahead-distances)
      * [ Publish Collision Monitor State ](../migration/Humble.html#publish-collision-monitor-state)
      * [ Renamed ROS-parameter in Collision Monitor ](../migration/Humble.html#renamed-ros-parameter-in-collision-monitor)
      * [ New safety behavior model “limit” in Collision Monitor ](../migration/Humble.html#new-safety-behavior-model-limit-in-collision-monitor)
      * [ Velocity smoother applies deceleration when timeout ](../migration/Humble.html#velocity-smoother-applies-deceleration-when-timeout)
      * [ PoseProgressChecker plugin ](../migration/Humble.html#poseprogresschecker-plugin)
      * [ Allow multiple goal checkers and change parameter progress_checker_plugin(s) name and type ](../migration/Humble.html#allow-multiple-goal-checkers-and-change-parameter-progress-checker-plugin-s-name-and-type)
      * [ IsBatteryChargingCondition BT Node ](../migration/Humble.html#isbatterychargingcondition-bt-node)
      * [ Behavior Server Error Codes ](../migration/Humble.html#behavior-server-error-codes)
      * [ New Denoise Costmap Layer Plugin ](../migration/Humble.html#new-denoise-costmap-layer-plugin)
      * [ SmacPlannerHybrid viz_expansions parameter ](../migration/Humble.html#smacplannerhybrid-viz-expansions-parameter)
    * [ Iron to Jazzy ](../migration/Iron.html)
      * [ Added TwistStamped Option for Commands ](../migration/Iron.html#added-twiststamped-option-for-commands)
      * [ Add VelocityPolygon in Collision Monitor ](../migration/Iron.html#add-velocitypolygon-in-collision-monitor)
      * [ Change polygon points parameter format in Collision Monitor ](../migration/Iron.html#change-polygon-points-parameter-format-in-collision-monitor)
      * [ Introduction of Soft-Real Time Action Servers ](../migration/Iron.html#introduction-of-soft-real-time-action-servers)
      * [ ` opennav_coverage  ` Project ](../migration/Iron.html#opennav-coverage-project)
      * [ Introduce a new Multi-Robot Bringup Launch ](../migration/Iron.html#introduce-a-new-multi-robot-bringup-launch)
      * [ New option for the Voxel and Obstacle Layers ](../migration/Iron.html#new-option-for-the-voxel-and-obstacle-layers)
      * [ use_interpolation RPP Parameter Depreciated ](../migration/Iron.html#use-interpolation-rpp-parameter-depreciated)
      * [ Changes to MPPI Goal Critic ](../migration/Iron.html#changes-to-mppi-goal-critic)
      * [ Changes to MPPI Path Angle Critic ](../migration/Iron.html#changes-to-mppi-path-angle-critic)
      * [ Changes to MPPI Path Handling For Directionality ](../migration/Iron.html#changes-to-mppi-path-handling-for-directionality)
      * [ Addition of new MPPI Cost Critic ](../migration/Iron.html#addition-of-new-mppi-cost-critic)
      * [ MPPI Acceleration ](../migration/Iron.html#mppi-acceleration)
      * [ Move Error Code Enumerations ](../migration/Iron.html#move-error-code-enumerations)
      * [ Substitution in parameter file ](../migration/Iron.html#substitution-in-parameter-file)
      * [ Allow Behavior Server Plugins to Access The Action Result ](../migration/Iron.html#allow-behavior-server-plugins-to-access-the-action-result)
      * [ Smac Planner Debug Param Name Change ](../migration/Iron.html#smac-planner-debug-param-name-change)
      * [ Smac Planner On Approach to Goal Shortcutting Solutions ](../migration/Iron.html#smac-planner-on-approach-to-goal-shortcutting-solutions)
      * [ Added GPS Waypoint Follower Server ](../migration/Iron.html#added-gps-waypoint-follower-server)
      * [ Smac Planner Hybrid-A* New Features ](../migration/Iron.html#smac-planner-hybrid-a-new-features)
      * [ New node in nav2_collision_monitor: Collision Detector ](../migration/Iron.html#new-node-in-nav2-collision-monitor-collision-detector)
      * [ Dynamic enabling/disabling of sources/polygons in Collision Monitor/Detector ](../migration/Iron.html#dynamic-enabling-disabling-of-sources-polygons-in-collision-monitor-detector)
      * [ Expose action server’s result timeout ](../migration/Iron.html#expose-action-server-s-result-timeout)
      * [ RewrittenYaml could add new parameters to YAMLs ](../migration/Iron.html#rewrittenyaml-could-add-new-parameters-to-yamls)
      * [ Simple Commander API Allows Multi-Robot Namespacing ](../migration/Iron.html#simple-commander-api-allows-multi-robot-namespacing)
      * [ Change duration type in wait_action node ](../migration/Iron.html#change-duration-type-in-wait-action-node)
      * [ The costmap activation fails when required transforms are not available ](../migration/Iron.html#the-costmap-activation-fails-when-required-transforms-are-not-available)


Computes a path through a set of poses rather than a single end goal pose
using the planner plugin specified

[ Cancel Control Action ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/controller_cancel_node.cpp)


` ~<name>/min_turning_radius ` ( ` double ` , default: 0.0)


and a softmax function is applied to return the optimal trajectory. The first control in the optimal trajectory is then sent to
the robot base controller to track. This process is conducted
iteratively to refine the optimal trajectory each time. For
the next time-step the trajectory is shifted, removing the
first velocity which was sent to the robot base controller.
This improves performance by starting at the next predicted
location with the remainder of the as-of-yet not executed
portion of the trajectory. Thus, it is important that this
controller runs at a sufficiently high rate with a sufficiently
large number of samples. Empirically, 1000 samples at 50 Hz
or 2000 samples at 30 Hz yield good results and are easily
achievable in this CPU-only implementation (Table II).
MPPI behaviorally is a major improvement over reactive techniques. It is exceptionally effective at reacting to
dynamic obstacles intelligently even when not explicitly
modeled as dynamic in the cost map. Further, MPPI rarely requires active recovery behaviors to assist getting out of local
minima due to becoming stuck or unable to make progress.
Its predictive back-out maneuvers when in close proximity
to static or dynamic obstacles is a considerable asset in hightrafficked or confined environments to prevent the robot from
becoming stuck. Fig. 5 shows a similar behavior in isolation;
whereas MPPI smoothly backs up and switches directions
Fig. 5. Example MPPI controller in action; red is the original global
path, green is the actual path traveled by the robot (circle). The candidate
trajectories points are shown, with the optimal selected trajectory highlighted
on top.
in a partial 3-point turn when a holonomic path begins in
the opposite direction of the robot’s initial heading. While
there are performance and behavioral differences between
TEB and MPPI, the major relative strengths of MPPI is
in its software architecture and test coverage for long-term
maintenance, simpler and more intuitive configurations, and
active maintainer presence.
C. Geometric and Control-Law Controllers
As opposed to reactive and predictive controllers, geometric and control-law derived controllers are quite simple. Their
aim is to follow a given reference path or objective without
deviation. Many of these techniques were early undertakings
in trajectory planning, but have had an immense amount
of staying power. While dynamic behaviors give a robotic
system some of its most directly visible intelligence, that is
not necessarily optimal in some practical applications. For
example, exact route following behaviors have utility when


####  Subscribed Topics


A variant of a sequence node that will re-tick previous children even if
another child is running

[ Recovery ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/control/recovery_node.cpp)


Filters noise-induced standalone obstacles or small obstacles groups

##  Costmap Filters  ¶


* If true, the planner uses the exact arc length in velocity, acceleration and turning rate computations (-> increased cpu time), otherwise the Euclidean approximation is used.


From the Desks of ROS Maintainers: A Survey of Modern & Capable
Mobile Robotics Algorithms in the Robot Operating System 2
Steve Macenski
ROS 2 Project Lead
Samsung Research
s.macenski@samsung.com
Tom Moore
Robot Localization Maintainer
Locus Robotics
tmoore@locusrobotics.com
David V. Lu
ROS 1 Co-Maintainer
Metro Robots
davidvlu@gmail.com
Alexey Merzlyakov
ROS 2 Developer
Samsung Research
alexey.merzlyakov@samsung.com
Michael Ferguson
ROS 1 Co-Maintainer
Cobalt Robotics
fergs@cobaltrobotics.com
Abstract— The Robot Operating System 2 (ROS 2) is rapidly
impacting the intelligent machines sector - on space missions,
large agriculture equipment, multi-robot fleets, and more. Its
success derives from its focused design and improved capabilities targeting product-grade and modern robotic systems.
Following ROS 2’s example, the mobile robotics ecosystem has
been fully redesigned based on the transformed needs of modern
robots and is experiencing active development not seen since
its inception.
This paper comes from the desks of the key ROS Navigation
maintainers to review and analyze the state of the art of
robotics navigation in ROS 2. This includes new systems without
parallel in ROS 1 or other similar mobile robotics frameworks.
We discuss current research products and historically robust
methods that provide differing behaviors and support for
most every robot type. This survey consists of overviews,
comparisons, and expert insights organized by the fundamental
problems in the field. Some of these implementations have yet to
be described in literature and many have not been benchmarked


** Used by  (3) **


` <name> ` .tolerance


The teb_local_planner package implements a plugin to the base_local_planner of
the 2D navigation stack. The underlying method called Timed Elastic Band
locally optimizes the robot's trajectory with respect to trajectory execution
time, separation from obstacles and compliance with kinodynamic constraints at
runtime.


Selects the goal checker based on a topic input, otherwises uses a default
goal checker id

[ Smoother Selector ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/smoother_selector_node.cpp)


Enables binary (boolean) mask behavior to trigger actions.

##  Controllers  ¶


` ~<name>/costmap_converter_rate ` ( ` double ` , default: 5.0)


` ~<name>/max_global_plan_lookahead_dist ` ( ` double ` , default: 3.0)


for high-speed robot systems to prevent centripetal force
from flipping over legged platforms or dumping unsecured
loads off of differential or holonomic robots (e.g., material
handling, delivery).
The Hybrid-A* planner provided by Nav2 within the Smac
Planner framework provides a few additional unique variations. Rather than using solely binary collision information,
all values in the cost grid are utilized to steer the feasible
search via an admissible cost-aware obstacle heuristic function. This leads optimal paths into lower-costed regions away
from obstacles, respects user generated cost grid constraints
(such as keepout zones or penalizing narrow spaces), and
improves path quality. This is sufficiently effective that
expensive post-processing of the paths proposed in [14] is not
strictly necessary to improve paths’ smoothness and safety
margins from obstacles. Moreover, because expanded search
nodes are generally farther from obstacles, optimizations in
collision checking are made which further improve run-time
performance.
Additionally, limits are placed on the maximum length
of analytic expansions to prevent excessive bypassing of
heuristic search. Limiting the expansion distance prevents
suboptimal behaviors that would have been penalized in the
search and/or cost grid, such as reversing for long distances
or entering sensitive high-cost zones. The role of analytic
expansions are to find a path to the exact goal, thus, it is most
applicable in close proximity to the goal pose. Reducing the
expansion length impacts performance negligibly. A typical
run-time for this planner is between 10-250 ms in practical
large deployed environments.
State Lattice was utilized by Carnegie Mellon University
in the DARPA Urban Challenge [15], [16]. Like HybridA*, it uses continuous coordinates associated at discrete cells
to create feasible paths from motion primitives. However, it
leverages offline computed motion primitives that establish
a state lattice graph rather than expanding using trees.
It expands A* as a structured lattice graph and connects
primitives at precise bin quantizations rather than at arbitrary
locations. The minimum control set, or motion primitives for
State Lattice, may be computed based on an arbitrary motion
model, not only for Ackermann vehicles or restrictions based
on minimum curvature. This can handle novel or atypical
drive-train constraints, such as those found on planetary


####  Miscellaneous Parameters


* [ Login ](/action/login/teb_local_planner?action=login)


to many waypoints and performing some action at each. The
waypoint follower uses task executor plugins to complete
the action at each waypoint (ex. wait for user input, take a
photo, pick up an object, etc) which are dynamically loaded
at run-time and fully configurable. The server also supports
looping a series of waypoints for repetitive actions.
Command and Control Panel is an Rviz user interface
for interacting with Nav2 for testing, evaluation, or getting
started. It provides tools to command the robot with navigate
to pose, navigate through poses, and waypoint following
tasks. It also visualizes the action feedback, can cancel
ongoing tasks, and control the system’s lifecycle states.
Robot simulation eases the process of development, testing, and reproduction. Nav2 provides out-of-the-box support
for the Gazebo simulator, a sister project of ROS, for
testing and evaluation before deploying new capabilities onto
hardware robots [63]. Gazebo has been developed and used
for over a decade by ROS Community and contains numerous features helpful for building practical robot systems,
including:
• Wide variety of supported sensors
• Plugin-based physics with rigid body dynamics
• A client-server architecture allowing distributed computation
• Fully integrated with ROS
• Cross-platform support with cloud integration
• XML described simulation environments using Simulation Description Files (SDF)
Nav2 provides a set of simulations containing a robot
platform in various environments including a sandbox and
a warehouse environment for easy testing and evaluation of
the framework. As an alternative, additional environments
can be easily created for a robot platform, as depicted on
Fig. 20.
The Gazebo brand has two distinct products within it:
Gazebo (aka Gazebo Classic) and Ignition-Gazebo (aka
Ignition). Ignition-Gazebo is a re-write of the legacy software
to provide a modular, plugin-based simulation framework.
Although not yet as fully featured, Nav2 will soon provide
support for Ignition as well [65].
X. THE FUTURE OF ROS 2 MOBILE ROBOTICS
The previous sections discussed the algorithms, behaviors,
and features currently available in Nav2, and ROS 2 in
general. These have been the product of several years of


* The local plan or trajectory that the teb_local_planner optimizes and follows. Used primarily for visualization purposes.


Continuous Integration:  3 / 3


Default

---|---

bool


` ~<name>/h_signature_threshold ` ( ` double ` , default: 0.1)


        * [ 1- Creating a new Behavior Plugin ](../plugin_tutorials/docs/writing_new_behavior_plugin.html#creating-a-new-behavior-plugin)
        * [ 2- Exporting the Behavior Plugin ](../plugin_tutorials/docs/writing_new_behavior_plugin.html#exporting-the-behavior-plugin)
        * [ 3- Pass the plugin name through params file ](../plugin_tutorials/docs/writing_new_behavior_plugin.html#pass-the-plugin-name-through-params-file)
        * [ 4- Run Behavior Plugin ](../plugin_tutorials/docs/writing_new_behavior_plugin.html#run-behavior-plugin)
    * [ Writing a New Navigator Plugin ](../plugin_tutorials/docs/writing_new_navigator_plugin.html)
      * [ Overview ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#overview)
      * [ Requirements ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#requirements)
      * [ Tutorial Steps ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#tutorial-steps)
        * [ 1- Create a new Navigator Plugin ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#create-a-new-navigator-plugin)
        * [ 2- Exporting the navigator plugin ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#exporting-the-navigator-plugin)
        * [ 3- Pass the plugin name through the params file ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#pass-the-plugin-name-through-the-params-file)
        * [ 4- Run plugin ](../plugin_tutorials/docs/writing_new_navigator_plugin.html#run-plugin)
  * [ Configuration Guide ](../configuration/index.html)
    * [ Behavior-Tree Navigator ](../configuration/packages/configuring-bt-navigator.html)
      * [ Parameters ](../configuration/packages/configuring-bt-navigator.html#parameters)
      * [ Example ](../configuration/packages/configuring-bt-navigator.html#example)
    * [ Behavior Tree XML Nodes ](../configuration/packages/configuring-bt-xml.html)
      * [ Action Plugins ](../configuration/packages/configuring-bt-xml.html#action-plugins)
        * [ Wait ](../configuration/packages/bt-plugins/actions/Wait.html)
        * [ Spin ](../configuration/packages/bt-plugins/actions/Spin.html)
        * [ BackUp ](../configuration/packages/bt-plugins/actions/BackUp.html)
        * [ DriveOnHeading ](../configuration/packages/bt-plugins/actions/DriveOnHeading.html)
        * [ AssistedTeleop ](../configuration/packages/bt-plugins/actions/AssistedTeleop.html)
        * [ ComputePathToPose ](../configuration/packages/bt-plugins/actions/ComputePathToPose.html)
        * [ FollowPath ](../configuration/packages/bt-plugins/actions/FollowPath.html)
        * [ NavigateToPose ](../configuration/packages/bt-plugins/actions/NavigateToPose.html)
        * [ ClearEntireCostmap ](../configuration/packages/bt-plugins/actions/ClearEntireCostmap.html)
        * [ ClearCostmapExceptRegion ](../configuration/packages/bt-plugins/actions/ClearCostmapExceptRegion.html)
        * [ ClearCostmapAroundRobot ](../configuration/packages/bt-plugins/actions/ClearCostmapAroundRobot.html)
        * [ ReinitializeGlobalLocalization ](../configuration/packages/bt-plugins/actions/ReinitializeGlobalLocalization.html)
        * [ TruncatePath ](../configuration/packages/bt-plugins/actions/TruncatePath.html)
        * [ TruncatePathLocal ](../configuration/packages/bt-plugins/actions/TruncatePathLocal.html)
        * [ PlannerSelector ](../configuration/packages/bt-plugins/actions/PlannerSelector.html)
        * [ ControllerSelector ](../configuration/packages/bt-plugins/actions/ControllerSelector.html)
        * [ SmootherSelector ](../configuration/packages/bt-plugins/actions/SmootherSelector.html)
        * [ GoalCheckerSelector ](../configuration/packages/bt-plugins/actions/GoalCheckerSelector.html)
        * [ ProgressCheckerSelector ](../configuration/packages/bt-plugins/actions/ProgressCheckerSelector.html)
        * [ NavigateThroughPoses ](../configuration/packages/bt-plugins/actions/NavigateThroughPoses.html)
        * [ ComputePathThroughPoses ](../configuration/packages/bt-plugins/actions/ComputePathThroughPoses.html)
        * [ ComputeCoveragePath ](../configuration/packages/bt-plugins/actions/ComputeCoveragePath.html)


  * C. Rösmann, W. Feiten, T. Wösch, F. Hoffmann and T. Bertram: Trajectory modification considering dynamic constraints of autonomous robots. Proc. 7th German Conference on Robotics, Germany, Munich, 2012, pp 74–79.
  * C. Rösmann, W. Feiten, T. Wösch, F. Hoffmann and T. Bertram: Efficient trajectory optimization using a sparse model. Proc. IEEE European Conference on Mobile Robots, Spain, Barcelona, 2013, pp. 138–143.


The Smac Planner plugin implements three A* based planning algorithms: 2D A*,
Hybrid-A*, and State Lattice path planners. It is important to know that in
June 2021 and December 2021, the package received a several **major** updates
both improving path quality and run-times by 2-3x.


* Optimization weight for forcing the robot to choose only forward directions (positive transl. velocities). A small weight (e.g. 1.0) still allows driving backwards. A value around 1000 almost prevents backward driving (but cannot be guaranteed).


` ~<name>/via_points ` ( [ nav_msgs/Path
](http://docs.ros.org/en/api/nav_msgs/html/msg/Path.html) )


* Allowed final orientation error in radians


` ~<name>/weight_kinematics_turning_radius ` ( ` double ` , default: 1.0)


* Maximum strafing velocity of the robot (should be zero for non-holonomic robots!)


Calls assisted teleop behavior action

[ Clear Entire Costmap Service ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/clear_costmap_service.cpp)


` ~<name>/dt_ref ` ( ` double ` , default: 0.3)


A plugin to wait for user input before moving onto the next waypoint.

##  Goal Checkers  ¶


customized.
However, the method suffers from numerous, highly interrelated parameters that must be tuned to achieve such performance (e.g. choice of critic functions and their relative
weightings). This process can be complex and poorly tuned
DWB configurations can create extremely suboptimal behaviors. This tuning complexity has long been a source
of critique for the ROS mobile robotics community. Many
deploy un-tuned parameters and remark at poor robot behavior due to the trajectory planner, although the perception
systems and global planning systems are quite mature. It is
the maintainers’ aim in the medium-term future to replace
DWB as the default algorithm with MPPI - a well-tuned,
modern predictive controller algorithm, discussed in Sec. IIIB, once it reaches an appropriate level of maturity.
B. Predictive Controllers
Predictive trajectory planners are a specialization of reactive planners which consider temporal information in the process of constructing objective-maximizing trajectories. They
refine the previous time-step’s trajectory when evaluating a
current request and typically model trajectories as non-trivial
sequences of velocity commands at future time intervals.
This prediction gives the classification its distinction and
makes it more robust against local minima causing a system
to become in an unrecoverable or ’stuck’ state. Further,
oscillation, sudden changes in velocity (and its derivatives),
and other adverse behaviors are greatly reduced when using
well-established methods - making a robot system exhibit
more intelligent behavior. Predictive controllers come at a
cost however: they are far more computationally demanding
than other approaches and are an area of evolving research.
Many predictive controllers are modelled and solved using
optimization-based techniques under the umbrella of model
predictive control (MPC). MPC methods have been shown to
be effective on a broad range of problems within and outside
of robotics, including autonomous driving and industrial
applications. The two predictive controllers in Nav2 both
belong to the family of MPC approaches, namely the Timed
Elastic Band (TEB) and Model Predictive Path Integral
(MPPI) controllers - of which both are unique to the ROS
mobile robotics ecosystem.
Timed Elastic Band (TEB) is one of the most popular
trajectory planners in ROS (1). Some global path planners
generate plans that have frequent or abrupt changes in
direction. Elastic bands transform such paths into smooth,
deformable plans that are more appropriate for trajectory
following [21]. In the original formulation, small subsets of


Steve Macenski


AssistedTeleop behavior that scales teleop commands to prevent collisions.

##  Waypoint Task Executors  ¶


` ~<name>/weight_adapt_factor ` ( ` double ` , default: 2.0)


Calls Nav2 planner server

[ Smooth Path Action ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/smooth_path_action.cpp)


A navigation function using A* or Dijkstras expansion, assumes 2D holonomic
particle


Joshua Wallace


####  Published Topics


Guillaume Doisy


Pradheep Padmanabhan


latest


costs, but there are also special values for unknown and
occupied cells (255 and 254, respectively) to provide hard
constraints on robot behavior. These special values allow
planning and collision checking algorithms to guarantee
viable navigation in only free and known regions. The cost
map acts as the planning algorithms’ configuration space
[36]. Figure 11 shows an example of the key values in a
cost map.
The cost map provides a reasonably balanced approach
to the fidelity/efficiency trade-off on both low and high
power compute platforms. The grid data structure provides a
simple correspondence with the real world and also provides
constant time lookup. One drawback is that the memory
consumption required to maintain the cost map scales linearly with the number of cells. The use of Quad-trees to
represent occupancy grids has been proposed to alleviate this
scaling via multi-resolution data storage [37]. However, these
methods fail to recover substantial memory benefits when
cost map convolution or inflation are applied, or when the
density of obstacles in the environment leaves little open
space to represent with coarser-resolution quantizations -
while also introducing non-constant look-up times. While
these are useful developments for some applications, it is
most common for users in ROS 2 to apply a form of cost
map inflation and operate in restricted spaces. In practice, the
size of the cells in the cost map is 0.05 meters by 0.05 meters,
which typically is small enough to render the environment
with sufficient fidelity, but also large enough to not require
enormous amounts of computation.
While a two-dimensional cost grid discards a great deal of
potentially useful information, it has been applied repeatedly
to solve a great number of practical robotics challenges.
Further, it is common for perception algorithms populating
the cost map to maintain higher fidelity representations
internally for modeling the environment, which are binned
or reduced to two dimensions for consolidation with other
algorithms. Maintaining a two-dimensional cost map enables
the application of a broad number of highly-efficient planning, control, and collision checking techniques for arbitrary
types of robot systems.
The process by which the cost map is updated and
maintained in ROS 2 is the Layered Costmap [38]: an


` ~<name>/shrink_horizon_min_duration ` ( ` double ` , default: 10.0)


* Optimization weight for contracting the trajectory w.r.t transition/execution time


Since local planners such as the Timed-Elastic-Band get often stuck in a
locally optimal trajectory as they are unable to transit across obstacles, an
extension is implemented.  A subset of admissible trajectories of distinctive
topologies is optimized in parallel. The local planner is able to switch to
the current globally optimal trajectory among the candidate set. Distinctive
topologies are obtained by utilizing the concept of homology / homotopy
classes.  The following papers are describing the approach


  * [ base_local_planner ](/base_local_planner?distro=kinetic)
  * [ catkin ](/catkin?distro=kinetic)
  * [ cmake_modules ](/cmake_modules?distro=kinetic)
  * [ costmap_2d ](/costmap_2d?distro=kinetic)
  * [ costmap_converter ](/costmap_converter?distro=kinetic)
  * [ dynamic_reconfigure ](/dynamic_reconfigure?distro=kinetic)
  * [ geometry_msgs ](/geometry_msgs?distro=kinetic)
  * [ interactive_markers ](/interactive_markers?distro=kinetic)
  * [ libg2o ](/libg2o?distro=kinetic)
  * [ message_generation ](/message_generation?distro=kinetic)
  * [ message_runtime ](/message_runtime?distro=kinetic)
  * [ nav_core ](/nav_core?distro=kinetic)
  * [ nav_msgs ](/nav_msgs?distro=kinetic)
  * [ pluginlib ](/pluginlib?distro=kinetic)
  * [ roscpp ](/roscpp?distro=kinetic)
  * [ std_msgs ](/std_msgs?distro=kinetic)
  * [ tf ](/tf?distro=kinetic)
  * [ tf_conversions ](/tf_conversions?distro=kinetic)
  * [ visualization_msgs ](/visualization_msgs?distro=kinetic)


` ~<name>/weight_acc_lim_theta ` ( ` double ` , default: 1.0)


* **melodic:** _Documentation generated on June 01, 2022 at 10:22 AM_ ( [ doc job ](https://build.ros.org/view/Mdoc/job/Mdoc__teb_local_planner__ubuntu_bionic_amd64) ).


unbounded growth in that dimension.
• Start with the minimum set required to provide a
reference for every linear and angular dimension, and
then add inputs one-at-a-time.
• Take time to understand the coordinate frames of sensor
data. Make sure that transforms are available for all data
that is not provided in the principal coordinate frames.
Fuse The nonlinear state estimation problem can also be
solved through iterative numerical optimization. It can be
factored into the following least-squares form:
ˆxt = arg min
x
X
i

yi − g(x)
Σ
1
2
2
(9)
where ˆxt is the optimal state estimate. We obtain it
by finding the state that minimizes the sum squared error
between each observation yi
and the transformed state g(x),
weighted by the inverse square root of the covariance Σ.
Factor graphs represent this formulation graphically, as
shown in Fig. 15. Two types of nodes are present in the
graph: variable nodes represent specific quantities that we
want to estimate (e.g., the robot’s pose at time t) and
factor nodes represent constraints on those variables (e.g.,
kinematic constraints via a motion model). In Fig. 15, the
variable nodes are the states x1 through x4, with the square
factor nodes representing constraints between the connected
states. This example shows a common use case for sensor
fusion, in which asynchronous measurements arrive from different sensors. Each sensor measurement creates a constraint
between two states, leading to two separate sets of vertices.
In order to unify the graph, we create kinematic constraints
between x1 and x2, x2 and x3, and x3 and x4. The graph is
then optimized to find the most likely values for the states.


` ~<name>/enable_multithreading ` ( ` bool ` , default: true)


Throttles child node to a rate based on current robot speed.

[ Goal Updater ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/decorator/goal_updater_node.cpp)


` ~<name>/switching_blocking_period ` ( ` double ` , default: 0.0)


The ` nav2_smac_planner  ` package contains an optimized templated A* search
algorithm used to create multiple A*-based planners for multiple types of
robot platforms. It uses template node types to develop different search-based
planners.


  * [ Smac 2D Planner ](smac/configuring-smac-2d.html)
  * [ Smac Hybrid-A* Planner ](smac/configuring-smac-hybrid.html)
  * [ Smac State Lattice Planner ](smac/configuring-smac-lattice.html)


Default

---|---

bool


Get started by completing the tutorials in the [ Tutorials
](/teb_local_planner/Tutorials) section.


Joshua Wallace


Alexey Merzlyakov


      * [ Added Smoother Task Server ](../migration/Galactic.html#added-smoother-task-server)
      * [ Removed Use Approach Velocity Scaling Param in RPP ](../migration/Galactic.html#removed-use-approach-velocity-scaling-param-in-rpp)
      * [ Refactored AMCL motion models as plugins ](../migration/Galactic.html#refactored-amcl-motion-models-as-plugins)
      * [ Dropping Support for Live Groot Monitoring of Nav2 ](../migration/Galactic.html#dropping-support-for-live-groot-monitoring-of-nav2)
      * [ Replanning Only if Path is Invalid ](../migration/Galactic.html#replanning-only-if-path-is-invalid)
      * [ Fix CostmapLayer clearArea invert param logic ](../migration/Galactic.html#fix-costmaplayer-cleararea-invert-param-logic)
      * [ Dynamic Composition ](../migration/Galactic.html#dynamic-composition)
      * [ BT Cancel Node ](../migration/Galactic.html#bt-cancel-node)
      * [ BT PathLongerOnApproach Node ](../migration/Galactic.html#bt-pathlongeronapproach-node)
      * [ BT TruncatePathLocal Node ](../migration/Galactic.html#bt-truncatepathlocal-node)
      * [ Constrained Smoother ](../migration/Galactic.html#constrained-smoother)
      * [ Replanning at a Constant Rate and if the Path is Invalid ](../migration/Galactic.html#replanning-at-a-constant-rate-and-if-the-path-is-invalid)
      * [ Euclidean Distance 2D ](../migration/Galactic.html#euclidean-distance-2d)
      * [ Recovery To Behavior ](../migration/Galactic.html#recovery-to-behavior)
      * [ Respawn Support in Launch and Lifecycle Manager ](../migration/Galactic.html#respawn-support-in-launch-and-lifecycle-manager)
      * [ New Nav2 Velocity Smoother ](../migration/Galactic.html#new-nav2-velocity-smoother)
      * [ Goal Checker API Changed ](../migration/Galactic.html#goal-checker-api-changed)
      * [ Added Assisted Teleop ](../migration/Galactic.html#added-assisted-teleop)
    * [ Humble to Iron ](../migration/Humble.html)
      * [ New Behavior-Tree Navigator Plugins ](../migration/Humble.html#new-behavior-tree-navigator-plugins)
      * [ Added Collision Monitor ](../migration/Humble.html#added-collision-monitor)
      * [ Removed use_sim_time from yaml ](../migration/Humble.html#removed-use-sim-time-from-yaml)
      * [ Run-time Speed up of Smac Planner ](../migration/Humble.html#run-time-speed-up-of-smac-planner)
      * [ Recursive Refinement of Smac and Simple Smoothers ](../migration/Humble.html#recursive-refinement-of-smac-and-simple-smoothers)
      * [ Simple Commander Python API ](../migration/Humble.html#simple-commander-python-api)
      * [ Smac Planner Start Pose Included in Path ](../migration/Humble.html#smac-planner-start-pose-included-in-path)
      * [ Parameterizable Collision Checking in RPP ](../migration/Humble.html#parameterizable-collision-checking-in-rpp)
      * [ Expanded Planner Benchmark Tests ](../migration/Humble.html#expanded-planner-benchmark-tests)
      * [ Smac Planner Path Tolerances ](../migration/Humble.html#smac-planner-path-tolerances)
      * [ costmap_2d_node default constructor ](../migration/Humble.html#costmap-2d-node-default-constructor)
      * [ Feedback for Navigation Failures ](../migration/Humble.html#feedback-for-navigation-failures)
      * [ Costmap Filters ](../migration/Humble.html#costmap-filters)
      * [ Savitzky-Golay Smoother ](../migration/Humble.html#savitzky-golay-smoother)
      * [ Changes to Map yaml file path for map_server node in Launch ](../migration/Humble.html#changes-to-map-yaml-file-path-for-map-server-node-in-launch)
      * [ SmootherSelector BT Node ](../migration/Humble.html#smootherselector-bt-node)
      * [ Publish Costmap Layers ](../migration/Humble.html#publish-costmap-layers)
      * [ Give Behavior Server Access to Both Costmaps ](../migration/Humble.html#give-behavior-server-access-to-both-costmaps)
      * [ New Model Predictive Path Integral Controller ](../migration/Humble.html#new-model-predictive-path-integral-controller)
      * [ Behavior Tree Uses Error Codes ](../migration/Humble.html#behavior-tree-uses-error-codes)
      * [ Load, Save and Loop Waypoints from the Nav2 Panel in RViz ](../migration/Humble.html#load-save-and-loop-waypoints-from-the-nav2-panel-in-rviz)


Description

---|---|---

[ Simple Smoother ](https://github.com/ros-
planning/navigation2/tree/main/nav2_smoother)


` ~<name>/costmap_converter_spin_thread ` ( ` bool ` , default: true)


Calls wait behavior action

[ Truncate Path ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/truncate_path_action.cpp)


** Used by  (1) **


A service / industrial robot variation on the pure pursuit algorithm with
adaptive features.


` ~<name>/obstacle_poses_affected ` ( ` int ` , default: 30)


The extension to car-like robots is described in


* For reference: NavFn compute the path in 146ms, including some nasty path discontinuity artifacts


  * Maintainer status: developed
  * Maintainer: Christoph Rösmann <christoph.roesmann AT tu-dortmund DOT de>
  * Author: Christoph Rösmann <christoph.roesmann AT tu-dortmund DOT de>
  * License: BSD
  * Source: git [ https://github.com/rst-tu-dortmund/teb_local_planner.git ](https://github.com/rst-tu-dortmund/teb_local_planner) (branch: lunar-devel)


Description


  * [ noid_robot_interface... ](/noid_robot_interface?distro=kinetic)
  * [ rb1_base_navigation ](/rb1_base_navigation?distro=kinetic)
  * [ seed_r7_navigation ](/seed_r7_navigation?distro=kinetic)
  * [ summit_xl_navigation... ](/summit_xl_navigation?distro=kinetic)
  * [ teb_local_planner_tu... ](/teb_local_planner_tutorials?distro=kinetic)


Creator


Plugin Name


angle, it is particularly useful for maps at non-axially aligned
angles where planners restricted to 4- or 8-connected neighborhoods would produce jagged paths. While it is common to
rotate maps such that they are axially aligned with important
features, that is not always practical nor possible. It is also
useful in spaces with many long, straight corridors commonly found in office buildings, warehouses, retail stores,
and similar. Theta*’s straight line characteristics are powerful
for predictability of robot behavior to bystanders, as well
as providing more fine-tuned and localized alignment to the
environment, Fig. 1.
In experiments, this algorithm had the shortest path
lengths, yet the longest run-time due to the expensive LoS
checks. Yet it still displays appropriate run-time performance
under 100 ms making it applicable in many practical applications, Table I.
2D-A* planner is the simplest of the holonomic approaches, as a cost grid-A* planner [10]. It is implemented
within the Smac Planner Framework complimentary to the
feasible planners discussed in Sec. II-B. See Appendix II
for more information about the Smac Planner Framework.
The 2D-A* planner uses Moore neighborhoods with an L2
distance heuristic. The travel cost between cells is derivative
of the cost-aware obstacle heuristic discussed later in detail,
and takes the form:
costtravel = d (1.0 + ωcost
cost(x, y)
costmax
) (1)
where d is the distance between cells, ωcost is the configurable weight placed on penalizing cost, cost(x, y) is the
cost at a cell (x, y), and costmax is the maximum possible
cost to normalize the term relative to the penalty weight.
When the cost is 0, it is simply the distance between cells
(1.0 or √
2), thereby the heuristic is admissible.
To smooth out the path generated from backtracing cells,
the simple smoothing algorithm from Eq. 4 is employed
to remove jagged edges, smooth turns, and eliminate other
localized defects. This planner uniquely enables users to
downsample cost grids into different resolutions for holonomic planning to increase speed O(N2
) in large spaces1
.
Unsurprisingly, since the Smac Planners share much of the
search and penalty structures, their paths are within 3% of


` ~<name>/shrink_horizon_backup ` ( ` bool ` , default: true)


This file can be found and editted under ` sphinx_docs/plugins/index.rst  ` .
For tutorials on creating your own plugins, please see [ Writing a New
Costmap2D Plugin
](../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#writing-new-
costmap2d-plugin) , [ Writing a New Behavior Tree Plugin
](../plugin_tutorials/docs/writing_new_bt_plugin.html#writing-new-nbt-plugin)
, [ Writing a New Controller Plugin
](../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#writing-new-
nav2controller-plugin) , [ Writing a New Planner Plugin
](../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#writing-new-
nav2planner-plugin) , [ Writing a New Behavior Plugin
](../plugin_tutorials/docs/writing_new_behavior_plugin.html#writing-new-
behavior-plugin) , or [ Writing a New Navigator Plugin
](../plugin_tutorials/docs/writing_new_navigator_plugin.html#writing-new-
nav2navigator-plugin) .


the robot is slowed when close to obstacles or the curvature
of the turn exceeds configurable limits. This slows the robot
before sharp blind turns into partially observable settings
(e.g. into or out of hallways and aisles) and reduces speed
when close to other objects where the risk of collision is
particularly high.
This has been shown in experiments to decrease stopping distances for emergency stops, reduce overshoot and
undershoot in high-curvature turns, all without substantially
increasing time-to-goal metrics. The minimum velocity of
the two heuristics is used, Eq. 3:
vcurv =
vt
rmin κ
vprox =
(
vt
α dO
dprox
dO ≤ dprox
vt dO > dprox
(3)
where rmin is the minimum turning radius to apply the
heuristic curvature heuristic, dO is the distance to the nearest
obstacle, dprox is the proximity to obstacles to apply the
curvature heuristic and α is a tunable weight. Additionally,
direction changes (e.g. forward to reverse) computed by
feasible planners are used in RPP to switch directions as
necessary at pre-planned poses.
Graceful Controller aims to provide smooth path following and automatic speed regulation for differential drive
bases [29]. This trajectory planner is best used with a
kinematically feasible global planner.
This controller is based on a geometric control law derived for differential drive robot bases which generates only
feasible commands [30]. The control implements a fast and
slow subsystem. The slow subsystem is implemented as an
Archimedean spiral that will take the robot from the current
pose to a target lookahead pose, based on a single parameter,
k1. The fast control subsystem then determines the linear and
angular velocity required to follow the spiral based on the
k2 parameter. The default values for k1 and k2 suggested by
original paper appear to work well on a variety of platforms.


A plugin to check whether the robot was able to move a minimum distance or
angle in a given time to make progress towards a goal

##  Behavior Tree Nodes  ¶


* Minimum desired separation from obstacles in meters


A path smoother using a Savitzky-Golay filter to smooth the path via digital
signal processing to remove noise from the path.

##  Behaviors  ¶


Steve Macenski


Will tick ` i  ` th child until a result and move on to ` i+1  `

* * *


Joshua Wallace


Calls clear costmap except region service

[ Clear Costmap Around Robot Service ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/clear_costmap_service.cpp)


  * Maintainer status: developed
  * Maintainer: Christoph Rösmann <christoph.roesmann AT tu-dortmund DOT de>
  * Author: Christoph Rösmann <christoph.roesmann AT tu-dortmund DOT de>
  * License: BSD
  * Source: git [ https://github.com/rst-tu-dortmund/teb_local_planner.git ](https://github.com/rst-tu-dortmund/teb_local_planner) (branch: jade-devel)


[ Edit ](https://github.com/ros-planning/navigation.ros.org)


An implementaion of Theta* using either 4 or 8 connected neighborhoods,
assumes the robot as a 2D holonomic particle


** Jenkins jobs  (6) **


* Limit the occupied local costmap obstacles taken into account for planning behind the robot (specify distance in meters).


Differential, Omnidirectional, Legged

[ SmacPlannerLattice ](https://github.com/ros-
planning/navigation2/tree/main/nav2_smac_planner)


**Ackermann** , Legged, Differential

[ MPPI Controller ](https://github.com/ros-
planning/navigation2/tree/main/nav2_mppi_controller)


  * [ clober_navigation ](/clober_navigation?distro=noetic)
  * [ mir_navigation ](/mir_navigation?distro=noetic)
  * [ mpc_local_planner ](/mpc_local_planner?distro=noetic)


* If true, all trajectories of different topologies are attached to the set of via-points, otherwise only the trajectory sharing the same topology as the initial/global plan is connected with them (no effect on _test_optim_node_ ). **New in version 0.4**


Matej Vargovcik


**Package Links**


` ~<name>/obstacle_association_cutoff_factor ` ( ` double ` , default: 5)


** Dependencies  (23) **


Creator


` ~<name>/min_samples ` ( ` int ` , default: 3)


Alberto Tudela


Plugin Name


An implementation of State Lattice Planner using pre-generated minimum control
sets for kinematically feasible planning with any type of vehicle imaginable.
Includes generator script for Ackermann, diff, omni, and legged robots.


Description

---|---|---

[ Pipeline Sequence ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/control/pipeline_sequence.cpp)


* **jade:** _Documentation generated on October 24, 2016 at 12:10 PM_ ( [ doc job ](http://build.ros.org/view/Jdoc/job/Jdoc__teb_local_planner__ubuntu_trusty_amd64) ).


[ Nav2 ![Logo](../_static/nav2_logo_powered.png) ](../index.html)


  * [ summit_xl_navigation... ](/summit_xl_navigation?distro=indigo)
  * [ teb_local_planner_tu... ](/teb_local_planner_tutorials?distro=indigo)


  * C. Rösmann, F. Hoffmann and T. Bertram: Integrated online trajectory planning and optimization in distinctive topologies, Robotics and Autonomous Systems, Vol. 88, 2017, pp. 142–153.
  * C. Rösmann, F. Hoffmann and T. Bertram: Planning of Multiple Robot Trajectories in Distinctive Topologies, Proc. IEEE European Conference on Mobile Robots, UK, Lincoln, Sept. 2015


      * [ Appendix ](../../tutorials/docs/docker_dev.html#appendix)
        * [ Nav2 Development Image ](../../tutorials/docs/docker_dev.html#nav2-development-image)
        * [ Nav2 Deployment Image ](../../tutorials/docs/docker_dev.html#nav2-deployment-image)
  * [ Plugin Tutorials ](../../plugin_tutorials/index.html)
    * [ Writing a New Costmap2D Plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#tutorial-steps)
        * [ 1- Write a new Costmap2D plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#write-a-new-costmap2d-plugin)
        * [ 2- Export and make GradientLayer plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#export-and-make-gradientlayer-plugin)
        * [ 3- Enable the plugin in Costmap2D ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#enable-the-plugin-in-costmap2d)
        * [ 4- Run GradientLayer plugin ](../../plugin_tutorials/docs/writing_new_costmap2d_plugin.html#run-gradientlayer-plugin)
    * [ Writing a New Planner Plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#tutorial-steps)
        * [ 1- Creating a new Planner Plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#creating-a-new-planner-plugin)
        * [ 2- Exporting the planner plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#exporting-the-planner-plugin)
        * [ 3- Pass the plugin name through params file ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#pass-the-plugin-name-through-params-file)
        * [ 4- Run StraightLine plugin ](../../plugin_tutorials/docs/writing_new_nav2planner_plugin.html#run-straightline-plugin)
    * [ Writing a New Controller Plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#tutorial-steps)
        * [ 1- Create a new Controller Plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#create-a-new-controller-plugin)
        * [ 2- Exporting the controller plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#exporting-the-controller-plugin)
        * [ 3- Pass the plugin name through the params file ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#pass-the-plugin-name-through-the-params-file)
        * [ 4- Run Pure Pursuit Controller plugin ](../../plugin_tutorials/docs/writing_new_nav2controller_plugin.html#run-pure-pursuit-controller-plugin)
    * [ Writing a New Behavior Tree Plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#tutorial-steps)
        * [ 1- Creating a new BT Plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#creating-a-new-bt-plugin)
        * [ 2- Exporting the planner plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#exporting-the-planner-plugin)
        * [ 3- Add plugin library name to config ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#add-plugin-library-name-to-config)
        * [ 4- Run Your Custom plugin ](../../plugin_tutorials/docs/writing_new_bt_plugin.html#run-your-custom-plugin)
    * [ Writing a New Behavior Plugin ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html)
      * [ Overview ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html#overview)
      * [ Requirements ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html#requirements)
      * [ Tutorial Steps ](../../plugin_tutorials/docs/writing_new_behavior_plugin.html#tutorial-steps)


      * [ Added Smoother Task Server ](../../migration/Galactic.html#added-smoother-task-server)
      * [ Removed Use Approach Velocity Scaling Param in RPP ](../../migration/Galactic.html#removed-use-approach-velocity-scaling-param-in-rpp)
      * [ Refactored AMCL motion models as plugins ](../../migration/Galactic.html#refactored-amcl-motion-models-as-plugins)
      * [ Dropping Support for Live Groot Monitoring of Nav2 ](../../migration/Galactic.html#dropping-support-for-live-groot-monitoring-of-nav2)
      * [ Replanning Only if Path is Invalid ](../../migration/Galactic.html#replanning-only-if-path-is-invalid)
      * [ Fix CostmapLayer clearArea invert param logic ](../../migration/Galactic.html#fix-costmaplayer-cleararea-invert-param-logic)
      * [ Dynamic Composition ](../../migration/Galactic.html#dynamic-composition)
      * [ BT Cancel Node ](../../migration/Galactic.html#bt-cancel-node)
      * [ BT PathLongerOnApproach Node ](../../migration/Galactic.html#bt-pathlongeronapproach-node)
      * [ BT TruncatePathLocal Node ](../../migration/Galactic.html#bt-truncatepathlocal-node)
      * [ Constrained Smoother ](../../migration/Galactic.html#constrained-smoother)
      * [ Replanning at a Constant Rate and if the Path is Invalid ](../../migration/Galactic.html#replanning-at-a-constant-rate-and-if-the-path-is-invalid)
      * [ Euclidean Distance 2D ](../../migration/Galactic.html#euclidean-distance-2d)
      * [ Recovery To Behavior ](../../migration/Galactic.html#recovery-to-behavior)
      * [ Respawn Support in Launch and Lifecycle Manager ](../../migration/Galactic.html#respawn-support-in-launch-and-lifecycle-manager)
      * [ New Nav2 Velocity Smoother ](../../migration/Galactic.html#new-nav2-velocity-smoother)
      * [ Goal Checker API Changed ](../../migration/Galactic.html#goal-checker-api-changed)
      * [ Added Assisted Teleop ](../../migration/Galactic.html#added-assisted-teleop)
    * [ Humble to Iron ](../../migration/Humble.html)
      * [ New Behavior-Tree Navigator Plugins ](../../migration/Humble.html#new-behavior-tree-navigator-plugins)
      * [ Added Collision Monitor ](../../migration/Humble.html#added-collision-monitor)
      * [ Removed use_sim_time from yaml ](../../migration/Humble.html#removed-use-sim-time-from-yaml)
      * [ Run-time Speed up of Smac Planner ](../../migration/Humble.html#run-time-speed-up-of-smac-planner)
      * [ Recursive Refinement of Smac and Simple Smoothers ](../../migration/Humble.html#recursive-refinement-of-smac-and-simple-smoothers)
      * [ Simple Commander Python API ](../../migration/Humble.html#simple-commander-python-api)
      * [ Smac Planner Start Pose Included in Path ](../../migration/Humble.html#smac-planner-start-pose-included-in-path)
      * [ Parameterizable Collision Checking in RPP ](../../migration/Humble.html#parameterizable-collision-checking-in-rpp)
      * [ Expanded Planner Benchmark Tests ](../../migration/Humble.html#expanded-planner-benchmark-tests)
      * [ Smac Planner Path Tolerances ](../../migration/Humble.html#smac-planner-path-tolerances)
      * [ costmap_2d_node default constructor ](../../migration/Humble.html#costmap-2d-node-default-constructor)
      * [ Feedback for Navigation Failures ](../../migration/Humble.html#feedback-for-navigation-failures)
      * [ Costmap Filters ](../../migration/Humble.html#costmap-filters)
      * [ Savitzky-Golay Smoother ](../../migration/Humble.html#savitzky-golay-smoother)
      * [ Changes to Map yaml file path for map_server node in Launch ](../../migration/Humble.html#changes-to-map-yaml-file-path-for-map-server-node-in-launch)
      * [ SmootherSelector BT Node ](../../migration/Humble.html#smootherselector-bt-node)
      * [ Publish Costmap Layers ](../../migration/Humble.html#publish-costmap-layers)
      * [ Give Behavior Server Access to Both Costmaps ](../../migration/Humble.html#give-behavior-server-access-to-both-costmaps)
      * [ New Model Predictive Path Integral Controller ](../../migration/Humble.html#new-model-predictive-path-integral-controller)
      * [ Behavior Tree Uses Error Codes ](../../migration/Humble.html#behavior-tree-uses-error-codes)
      * [ Load, Save and Loop Waypoints from the Nav2 Panel in RViz ](../../migration/Humble.html#load-save-and-loop-waypoints-from-the-nav2-panel-in-rviz)


Description

---|---|---

[ SimpleProgressChecker ](https://github.com/ros-
planning/navigation2/blob/main/nav2_controller/plugins/simple_progress_checker.cpp)


Steve Macenski


` ~<name>/roadmap_graph_area_width ` ( ` double ` , default: 6)


from the path would be beneficial - for instance to optimize
for smoothness or increased distance from static obstacles
than the global infeasible plan provided.
Typically, path smoothers for circular differential drive
robots are not necessary for good performance. However,
infeasible global plans may be improved with the use of the
Savitzky-Golay smoother to remove localized path defects
as the result of gradient descent or cell binning, but these
changes are largely superficial and do not manifestly impact
system behavior when paired with a Nav2-provided trajectory planner.
B. Non-Circular Differential-Drive
Recommendation: Smac State Lattice + MPPI + Simple Smoother.
Non-circular differential drive robots generally require the
use of feasible planners to guarantee drivability in confined spaces whereas they may not rotate in place without
collision. The use of the Smac State Lattice planner is
recommended as a high performance option with adjustable
motion primitives (including rotating in place). However,
Smac Hybrid-A* could also be appropriate if a minimum
control set is difficult to model. If non-circular robots are in
settings where they may generally rotate in place anywhere
they might travel (e.g. not confined or large), infeasible
planners like the NavFn global planner may be deployed
instead.
All trajectory planners are built to work with non-circular
robots as well, using the robot’s footprint to collision check.
The same advice applies as described above for circular
robots, but with an added computational cost for these
heavier collision checking requirements. However, from experience with non-circular robots, it is recommended to
leverage the Rotation Shim controller to rotate the platform
to the relative path heading before path tracking when using
an infeasible planner with either DWB or Graceful. While not
required, it is a step-up in an observer’s predictability as these
may struggle to make massive angular changes effectively.
Providing large, non-circular robots with a smoother
global path can impact small oscillatory behaviors notable
on non-circular robot platforms due to their shape. Due to
this, the simple smoother is recommended as a fast and
reasonably effective solution to loosen turns and straighten
out oscillations. The constrained smoother may also be
applied, but it is computationally intensive and considers


** Used by  (1) **


Carl Delsey


** Used by  (2) **


David Lu!!


Checks if a controller recovery could help clear the controller server error
code.

[ Would A Planner Recovery Help ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/condition/would_a_planner_recovery_help.cpp)


**Package Links**


Checks if a path is valid by making sure there are no LETHAL obstacles along
the path.

[ Path Expiring Timer ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/condition/path_expiring_timer_condition.cpp)


Triggers nodes/subtrees below only a single time per BT run.

[ PathLongerOnApproach ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/decorator/path_longer_on_approach.cpp)


#  Smac Planner  ¶


Plugin Name


  * **[ Code API ](http://docs.ros.org/lunar/api/teb_local_planner/html) **
  * **[ Msg API ](http://docs.ros.org/en/lunar/api/teb_local_planner/html/index-msg.html) **
  * [ Tutorials ](/teb_local_planner/Tutorials)
  * [ FAQ ](http://answers.ros.org/questions/scope:all/sort:activity-desc/tags:teb_local_planner/page:1/)
  * [ Changelog ](http://docs.ros.org/en/lunar/changelogs/teb_local_planner/changelog.html)
  * [ Change List ](/teb_local_planner/ChangeList)
  * [ Reviews ](/teb_local_planner/Reviews)


world,” Journal of Open Source Software, vol. 6, no. 61, p. 2783,
2021.
[63] N. Koenig and A. Howard, “Design and use paradigms for gazebo, an
open-source multi-robot simulator,” in 2004 IEEE/RSJ International
Conference on Intelligent Robots and Systems (IROS) (IEEE Cat.
No.04CH37566), vol. 3, 2004, pp. 2149–2154 vol.3.
[64] AWS Bookstore Gazebo world. [Online]. Available: https://github.
com/aws-robotics/aws-robomaker-bookstore-world
[65] Gazebo Classic vs. Ignition feature comparison, 9 2022. [Online].
Available: https://gazebosim.org/docs/garden/comparison
[66] R. Valencia, J. Saarinen, H. Andreasson, J. Vallve, J. Andrade-Cetto, ´
and A. J. Lilienthal, “Localization in highly dynamic environments
using dual-timescale ndt-mcl,” in 2014 IEEE International Conference
on Robotics and Automation (ICRA), 2014, pp. 3956–3962.
APPENDIX I
ALGORITHM SELECTION BY ROBOT MODEL
Sections II - IV compare global path planners, trajectory
planners, and smoothers between each other with brief descriptions of their most useful robot model types in Tables
Tables I - III. However, it is useful to provide an expanded
discussion on these summaries and provide algorithm optimal use cases, which is further summarized in the table VI.
A. Circular Differential-Drive
Recommendation: NavFn + MPPI
Circular differential-drive robots typically leverage infeasible global path planners. NavFn is the recommended
algorithm for such cases, as a high performance and highly
deployed implementation used for over a decade. If deploying a circular differential-drive robot in injunction with
other non-circular platforms, the Smac 2D-A* may be a
good option to have behavioral consistency with other robots
using the feasible Smac Planners - in exchange for increased
compute time. When using a robot in non-axially aligned
maps, Theta* can be most useful to generate straight-line
paths at arbitrary angles.
All of Nav2’s trajectory planners are also built with
optimizations for circular robots and will work well for
this class of robot, but with different behavioral attributes.
The use of MPPI or TEB may be beneficial if in highly
dynamic settings or where needing to get out of tight spots.
These predictive controllers, however, come at an elevated
computational cost. Reg. Pure Pursuit is useful for exactpath tracking behavior in static scenes or where deviation
from paths is not permissible while having an exceptionally
small computational footprint. DWB is a middle-ground allaround option when not in dynamic scenes but deviations


Checks if initial pose has been set

[ Is Stuck Condition ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/condition/is_stuck_condition.cpp)


__ [ Nav2 ](../../index.html)


* Allows the planner to shrink the horizon temporary (50%) in case of automatically detected issues (e.g. infeasibility). Also see parameter ` shrink_horizon_min_duration ` .


Reinitialize AMCL to a new pose

[ Spin Action ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/spin_action.cpp)


* Specify how much trajectory cost must a new candidate have w.r.t. a previously selected trajectory in order to be selected (selection if new_cost < old_cost*factor).


The ROS Wiki is for ROS 1. Are you using ROS 2 ( [ Humble
](http://docs.ros.org/en/humble/) , [ Iron ](http://docs.ros.org/en/iron/) ,
or [ Rolling ](http://docs.ros.org/en/rolling/) )?
[ Check out the ROS 2 Project Documentation ](http://docs.ros.org)
Package specific documentation can be found on [ index.ros.org
](https://index.ros.org)


` <name> ` .use_final_approach_orientation