` ~<name>/include_dynamic_obstacles ` ( ` bool ` , default: false)


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


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

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


,
proportional to robot speed6 or when the goal is updated7
.
However, it is sometimes desirable for robotic applications to
not dynamically replan (except when strictly required due to
a potential future collision) to produce predictable behavior8
.
Practical BTs typically include recovery behaviors to
resolve the vast majority of errors that may occur during
navigation due to dynamic scenes, uncertainty, or confined
environments. ROS 2 includes BTs that invoke contextspecific actions in case of particular component failures.
They also contain a global recovery branch for handling
system-level failures9
. More advanced BTs include mixedreplanning10 and goal patience11 to resolve an assortment
of commonplace behavioral issues, such as oscillation due
to frequent replanning and handling temporary blockages,
respectively.
The navigate-through-poses configurations provide a similar behavior but contain hard pose constraints for via-points
to navigate through on the way to a final goal. These
behavior trees make use of the ‘Compute Path Through
Poses’ planning node rather than ‘Compute Path To Pose’. In
addition, this class of BT removes waypoints passed so that
subsequent replanning iterations contains only future looking
constraints12. These configurations may also contain different
replanning mechanics, recoveries, and advanced features as
described prior.
The BT tasks are not required to be represented by a goal
or via-points - or even full autonomy. Instead, a BT may
be only interested in following a particular object13 with a
collision free path or exploring new areas. Other examples
include algorithm assisted remote tele-operation, odometry
calibration experiments14, and complete-coverage tasks.
As an illustrated example, Fig. 14 shows the mixedreplanning navigate-to-pose behavior tree with recoveries
described in footnote 10. The left branch from the root
node contains its navigation logic, while the right is used
for system-level recovery. If a new goal is received during
system-level recoveries, it will abort and reattempt navigation. There are also context-specific recoveries clearing the
global and local environmental models within the navigation
branch when path planning or local trajectory planning fail,
respectively. In the navigation branch, mixed replanning is


A 2D A* implementation Using either 4 or 8 connected neighborhoods with
smoother and multi-resolution query


Calls coverage planner server

Condition Plugin Name


#  User


* The discrete pose list (SE2) of the current local plan. Used primarily for visualization purposes.


Inflation The inflation layer uses the occupancy information from the other layers to add an inflated exponential
decay function around untraversable regions. It does this by
iteratively expanding from known obstacles to a configurable
distance, applying Eq. 6:
cost(x, y) = (costlethal − 1) e
−ωscale (do−r)
(6)
where ωscale is the cost scaling factor, do is the distance to
the obstacle, costlethal is the lethal obstacle cost, and r is the
inscribed radius of the footprint. For circular robots, the cost
map regions that are traversable after this is applied represent
the configuration space of the robot. For non-circular robots,
the cell cost for the largest distance between an edge of
the robot and the center can be used with Eq. 6 to recover
the cost at the center where full footprint collision checking
is required. When the center cost is below that value, it
is known that the robot cannot be in collision. Thus when
using non-circular robots, it is important to still use inflation
to optimize collision checking used in such algorithms as
found in the Smac Planner framework described in II-B. It is
recommended to set a smooth inflation decay across the cost
map, rather than maintaining only steep costs near obstacles,
as shown in Fig. 11.
Keepout The keepout layer (a.k.a. keepout filter) uses input masks to mark cells as obstacles. These masks are highly
configurable to contain a great deal of semantic information
and interpreted through CostmapFilterInfo into cost
values to apply to the grid. These need not be only binary
obstacle information, but also setting a range of costs to
weight certain regions over others.
Speed The speed limiting layer uses the same filters API
as the keepout zones, but embedding maximum speeds as
either percentages or absolute values in the filter masks. This
layer allows users to specify zones at which a robot should
slow down, such as when entering or exiting aisles.
Binary The binary layer uses the same filters API as previously introduced, but embeds binary behavioral triggers into
a spatial mask. When the cost value crosses the threshold, a
ROS message is sent to a client server to indicate a change in
binary state. An illustrative example would be to set spatial
bounds conveying locations where it is and is not appropriate
to stream camera feeds to a robot operations center. There


[19] D. Fox, W. Burgard, and S. Thrun, “The dynamic window approach to
collision avoidance,” Robotics & Automation Magazine, IEEE, vol. 4,
no. 1, pp. 23–33, 1997.
[20] K. Konolige, M. Agrawal, R. C. Bolles, C. Cowan, M. Fischler, and
B. Gerkey, Outdoor Mapping and Navigation Using Stereo Vision,
2008.
[21] S. Quinlan and O. Khatib, “Elastic bands: connecting path planning
and control,” in [1993] Proceedings IEEE International Conference
on Robotics and Automation, 1993, pp. 802–807 vol.2.
[22] C. Rosmann, F. Hoffmann, and T. Bertram, “Timed-elastic-bands for ¨
time-optimal point-to-point nonlinear model predictive control,” in
2015 European Control Conference (ECC), 2015, pp. 3352–3357.
[23] C. Rosmann, “teb ¨ local planner,” 9 2022. [Online]. Available:
https://github.com/rst-tu-dortmund/teb local planner
[24] R. Kummerle, G. Grisetti, H. Strasdat, K. Konolige, and W. Burgard, ¨
“G2o: A general framework for graph optimization,” in 2011 IEEE
International Conference on Robotics and Automation, 2011, pp.
3607–3613.
[25] G. Williams, P. Drews, B. Goldfain, J. M. Rehg, and E. A. Theodorou,
“Aggressive driving with model predictive path integral control,” in
2016 IEEE International Conference on Robotics and Automation
(ICRA), 2016, pp. 1433–1440.
[26] R. C. Coulter, “Implementation of the pure pursuit path tracking
algorithm,” 1992.
[27] L. Kong, “Adaptive pure pursuit model for autonomous vehicle path
tracking,” 2017.
[28] S. Macenski, S. Singh, F. Mart´ın, and J. Gines Clavero, “Regulated ´
pure pursuit for robot path tracking,” 2022.
[29] M. Ferguson, “graceful controller,” 9 2022. [Online]. Available:
https://github.com/mikeferguson/graceful controller
[30] J. J. Park and B. Kuipers, “A smooth control law for graceful motion of
differential wheeled mobile robots in 2d environment,” in 2011 IEEE
International Conference on Robotics and Automation. IEEE, 2011,
pp. 4896–4902.
[31] J. M. Snider, “”automatic steering methods for autonomous automobiles”,” Tech. Rep. CMU-RI-TR-09-08, Robotics Institute, vol. 6,
no. 61, p. 2783, 2009.
[32] M. Vargovcik, “Ceres smoother pull request 2753,” 3 2022. [Online].
Available: https://github.com/ros-planning/navigation2/pull/2753
[33] A. Savitzky and M. J. E. Golay, “Smoothing and differentiation of data
by simplified least squares procedures,” Analytical Chemistry, vol. 36,


** Dependencies  (19) **


        * [ 1- Launch Navigation2 ](../../tutorials/docs/navigation2_with_slam.html#launch-navigation2)
        * [ 2- Launch SLAM ](../../tutorials/docs/navigation2_with_slam.html#launch-slam)
        * [ 3- Working with SLAM ](../../tutorials/docs/navigation2_with_slam.html#working-with-slam)
        * [ 4- Getting Started Simplification ](../../tutorials/docs/navigation2_with_slam.html#getting-started-simplification)
    * [ (STVL) Using an External Costmap Plugin ](../../tutorials/docs/navigation2_with_stvl.html)
      * [ Overview ](../../tutorials/docs/navigation2_with_stvl.html#overview)
      * [ Costmap2D and STVL ](../../tutorials/docs/navigation2_with_stvl.html#costmap2d-and-stvl)
      * [ Tutorial Steps ](../../tutorials/docs/navigation2_with_stvl.html#tutorial-steps)
        * [ 0- Setup ](../../tutorials/docs/navigation2_with_stvl.html#setup)
        * [ 1- Install STVL ](../../tutorials/docs/navigation2_with_stvl.html#install-stvl)
        * [ 1- Modify Navigation2 Parameter ](../../tutorials/docs/navigation2_with_stvl.html#modify-navigation2-parameter)
        * [ 2- Launch Navigation2 ](../../tutorials/docs/navigation2_with_stvl.html#launch-navigation2)
        * [ 3- RVIZ ](../../tutorials/docs/navigation2_with_stvl.html#rviz)
    * [ Navigating Using GPS Localization ](../../tutorials/docs/navigation2_with_gps.html)
      * [ Overview ](../../tutorials/docs/navigation2_with_gps.html#overview)
      * [ Requirements ](../../tutorials/docs/navigation2_with_gps.html#requirements)
      * [ GPS Localization Overview ](../../tutorials/docs/navigation2_with_gps.html#gps-localization-overview)
      * [ Tutorial Steps ](../../tutorials/docs/navigation2_with_gps.html#tutorial-steps)
        * [ 0- Setup Gazebo World ](../../tutorials/docs/navigation2_with_gps.html#setup-gazebo-world)
        * [ 1- Setup GPS Localization system ](../../tutorials/docs/navigation2_with_gps.html#setup-gps-localization-system)
        * [ 2- Setup Navigation system ](../../tutorials/docs/navigation2_with_gps.html#setup-navigation-system)
        * [ 3- Interactive GPS Waypoint Follower ](../../tutorials/docs/navigation2_with_gps.html#interactive-gps-waypoint-follower)
        * [ 4- Logged GPS Waypoint Follower & Waypoint Logging ](../../tutorials/docs/navigation2_with_gps.html#logged-gps-waypoint-follower-waypoint-logging)
      * [ Conclusion ](../../tutorials/docs/navigation2_with_gps.html#conclusion)
    * [ Groot - Interacting with Behavior Trees ](../../tutorials/docs/using_groot.html)
      * [ Overview ](../../tutorials/docs/using_groot.html#overview)
      * [ Visualize Behavior Trees ](../../tutorials/docs/using_groot.html#visualize-behavior-trees)
      * [ Edit Behavior Trees ](../../tutorials/docs/using_groot.html#edit-behavior-trees)
      * [ Adding A Custom Node ](../../tutorials/docs/using_groot.html#adding-a-custom-node)
    * [ Using VIO to Augment Robot Odometry ](../../tutorials/docs/integrating_vio.html)
      * [ Overview ](../../tutorials/docs/integrating_vio.html#overview)
      * [ Setting Up the ZED X Camera ](../../tutorials/docs/integrating_vio.html#setting-up-the-zed-x-camera)
      * [ Setting Up ZED ROS ](../../tutorials/docs/integrating_vio.html#setting-up-zed-ros)
      * [ Fusing VIO Into Local State Estimate ](../../tutorials/docs/integrating_vio.html#fusing-vio-into-local-state-estimate)
        * [ Fusing VSLAM Into Global State Estimate ](../../tutorials/docs/integrating_vio.html#fusing-vslam-into-global-state-estimate)
      * [ Testing it Out! ](../../tutorials/docs/integrating_vio.html#testing-it-out)
    * [ Dynamic Object Following ](../../tutorials/docs/navigation2_dynamic_point_following.html)
      * [ Overview ](../../tutorials/docs/navigation2_dynamic_point_following.html#overview)
      * [ Tutorial Steps ](../../tutorials/docs/navigation2_dynamic_point_following.html#tutorial-steps)
        * [ 0- Create the Behavior Tree ](../../tutorials/docs/navigation2_dynamic_point_following.html#create-the-behavior-tree)


False

Description


      * [ BackUp BT-node Interface Changes ](../../migration/Foxy.html#backup-bt-node-interface-changes)
      * [ BackUp Recovery Interface Changes ](../../migration/Foxy.html#backup-recovery-interface-changes)
      * [ Nav2 Controllers and Goal Checker Plugin Interface Changes ](../../migration/Foxy.html#nav2-controllers-and-goal-checker-plugin-interface-changes)
      * [ FollowPath goal_checker_id attribute ](../../migration/Foxy.html#followpath-goal-checker-id-attribute)
      * [ Groot Support ](../../migration/Foxy.html#groot-support)
      * [ New Plugins ](../../migration/Foxy.html#new-plugins)
      * [ Costmap Filters ](../../migration/Foxy.html#costmap-filters)
      * [ SmacPlanner ](../../migration/Foxy.html#smacplanner)
      * [ ThetaStarPlanner ](../../migration/Foxy.html#thetastarplanner)
      * [ RegulatedPurePursuitController ](../../migration/Foxy.html#regulatedpurepursuitcontroller)
      * [ Costmap2D ` current_  ` Usage ](../../migration/Foxy.html#costmap2d-current-usage)
      * [ Standard time units in parameters ](../../migration/Foxy.html#standard-time-units-in-parameters)
      * [ Ray Tracing Parameters ](../../migration/Foxy.html#ray-tracing-parameters)
      * [ Obstacle Marking Parameters ](../../migration/Foxy.html#obstacle-marking-parameters)
      * [ Recovery Action Changes ](../../migration/Foxy.html#recovery-action-changes)
      * [ Default Behavior Tree Changes ](../../migration/Foxy.html#default-behavior-tree-changes)
      * [ NavFn Planner Parameters ](../../migration/Foxy.html#navfn-planner-parameters)
      * [ New ClearCostmapExceptRegion and ClearCostmapAroundRobot BT-nodes ](../../migration/Foxy.html#new-clearcostmapexceptregion-and-clearcostmaparoundrobot-bt-nodes)
      * [ New Behavior Tree Nodes ](../../migration/Foxy.html#new-behavior-tree-nodes)
      * [ sensor_msgs/PointCloud to sensor_msgs/PointCloud2 Change ](../../migration/Foxy.html#sensor-msgs-pointcloud-to-sensor-msgs-pointcloud2-change)
      * [ ControllerServer New Parameter failure_tolerance ](../../migration/Foxy.html#controllerserver-new-parameter-failure-tolerance)
      * [ Removed BT XML Launch Configurations ](../../migration/Foxy.html#removed-bt-xml-launch-configurations)
      * [ Nav2 RViz Panel Action Feedback Information ](../../migration/Foxy.html#nav2-rviz-panel-action-feedback-information)
    * [ Galactic to Humble ](../../migration/Galactic.html)
      * [ Major improvements to Smac Planners ](../../migration/Galactic.html#major-improvements-to-smac-planners)
      * [ Simple (Python) Commander ](../../migration/Galactic.html#simple-python-commander)
      * [ Reduce Nodes and Executors ](../../migration/Galactic.html#reduce-nodes-and-executors)
      * [ API Change for nav2_core ](../../migration/Galactic.html#api-change-for-nav2-core)
      * [ Extending the BtServiceNode to process Service-Results ](../../migration/Galactic.html#extending-the-btservicenode-to-process-service-results)
      * [ Including new Rotation Shim Controller Plugin ](../../migration/Galactic.html#including-new-rotation-shim-controller-plugin)
      * [ Spawning the robot in Gazebo ](../../migration/Galactic.html#spawning-the-robot-in-gazebo)
      * [ Recovery Behavior Timeout ](../../migration/Galactic.html#recovery-behavior-timeout)
      * [ New parameter ` use_final_approach_orientation  ` for the 3 2D planners ](../../migration/Galactic.html#new-parameter-use-final-approach-orientation-for-the-3-2d-planners)
      * [ SmacPlanner2D and Theta*: fix goal orientation being ignored ](../../migration/Galactic.html#smacplanner2d-and-theta-fix-goal-orientation-being-ignored)
      * [ SmacPlanner2D, NavFn and Theta*: fix small path corner cases ](../../migration/Galactic.html#smacplanner2d-navfn-and-theta-fix-small-path-corner-cases)
      * [ Change and fix behavior of dynamic parameter change detection ](../../migration/Galactic.html#change-and-fix-behavior-of-dynamic-parameter-change-detection)
      * [ Dynamic Parameters ](../../migration/Galactic.html#dynamic-parameters)
      * [ BT Action Nodes Exception Changes ](../../migration/Galactic.html#bt-action-nodes-exception-changes)
      * [ BT Navigator Groot Multiple Navigators ](../../migration/Galactic.html#bt-navigator-groot-multiple-navigators)
      * [ Removed Kinematic Limiting in RPP ](../../migration/Galactic.html#removed-kinematic-limiting-in-rpp)


from the goal cell to the start using a Von Neumann neighborhood. The potential field is calculated using a quadratic
kernel function rather than distances to the goal (NF1) to
create a smoother potential field, and thus smoother output
paths [11]. The kernel at a cell is found based on the cell’s
cost and the value of its neighboring cells’ potentials. The
planning costs at each cell are linearly remapping from the
cost grid to produce a minimum cost to travel, or neutral cost.
Therefore, each cell’s cost ranges from the neutral to maximum cost when populating the potential field. This generates
increasing costs each wavefront until the start cell is found.
Finally, to traceback the path, gradient descent is applied
from the start cell in the potential field in half resolution
sized increments to produce a uniformly distributed path.
This planner is the oldest algorithm in Nav2 - derived
from the ROS (1) Navigation Stack and created in the first
public commit to the project. Regardless of age, it is highly
optimized with managed priority buffers and remains as one
TABLE I
PATH PLANNERS COMPARISON, BOLDED WITHIN 3% OF BEST
Path Planner Plan Time (ms) Path Length (m) Feasible Circular Non-Circ. Diff. Omni. Ackermann Legged
NavFn 61.02 52.25 - ✓ - ✓ ✓ - -
Lazy Theta*-P1 94.42 50.28 - ✓ - ✓ ✓ - -
Smac 2D-A*1 88.82 49.65 - ✓ - ✓ ✓ - -
Smac Hybrid-A*1 38.77 50.78 ✓ ✓ ✓ ✓ - ✓ ✓
Smac State Lattice1 39.40 50.51 ✓ ✓ ✓ ✓ ✓ ✓ ✓
1 Exclusive to ROS 2. An inter-modal algorithm selection summary can be found in Appendix I.
of the most effective holonomic planners available, typically
taking between 15 - 175 ms. It has been proven by dozens,
if not hundreds, of robotics companies and researchers over
the past ten years in a variety of industry, consumer, and
service applications. Due to its speed and long-term stability,
the Navigation Function planner is a good general-purpose
option and remains the default planning algorithm in Nav2.
Although it is the fastest holonomic planner, it produces
paths 5% longer by design, Table I. The neutral cost balances
cell costs with path lengths when generating the potential
field. It was carefully selected empirically to produce highquality paths in a variety of environments, including routing
down centers of hallways, maintaining safe margins from
obstacles when space is allotted, and lacking in excessive
movements. The planner is made to prefer slightly longer
routes to minimize cost, which provides additional margins


Description

---|---|---

[ NavigateToPoseNavigator ](https://github.com/ros-
planning/navigation2/tree/main/nav2_bt_navigator/src/navigators)


        * [ 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)


` <name> ` .use_astar


  1. Overview
  2. Video
  3. Node API
    1. Topics
      1. Published Topics
      2. Subscribed Topics
    2. Parameters
      1. Robot Configuration Parameters
      2. Goal Tolerance Parameters
      3. Trajectory Configuration Parameters
      4. Obstacle Parameters
      5. Optimization Parameters
      6. Parallel Planning in distinctive Topologies
      7. Miscellaneous Parameters
  4. Roadmap


      * [ 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
      * Parameters
      * Example
    * [ Smac Planner ](configuring-smac-planner.html)
      * [ Provided Plugins ](configuring-smac-planner.html#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 ](configuring-smac-planner.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)


A MPC-like controller suitable for ackermann, differential, and holonomic
robots.


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


poses can be converted into velocities before being passed
to the filter. This feature is useful when attempting to fuse
world-referenced pose data from sources that do not agree
with one another.
r l uses an omnidirectional three-dimensional kinematic
state transition function to estimate the 15-dimensional state
vector given in Eq. 8.
x = [x, y, z, ϕ, θ, ψ, x,˙ y,˙ z,˙ ϕ,˙ ˙θ, ψ,˙ x, ¨ y, ¨ z¨] (8)
While the package does not support any other kinematic
models, common models like the unicycle model can be obtained by clamping all three-dimensional state variables (as
well as y˙ and y¨) to 0. Furthermore, kinematic models such as
Ackermann steering can be used if the measurement source
provides absolute pose data and the appropriate process noise
covariance matrix entries are increased to force the filter to
trust measurements more than the filter. In practice, this is
sufficient for most mobile robotics applications and the most
common method of sensor fusion for state estimation in ROS
over the last half-decade.
The large number of parameters available to the user in
r l can be used to tune the filter’s performance and tailor it
to the user’s application. In general, the following practices
are recommended:
• If operating in a planar environment, set two d mode
to true. While the filter will still continue to perform
full 3D state estimation, dimensions outside SE2 will
be set to 0.
• For differential drive platforms, the only body-frame velocities that are typically relevant are x˙ and ˙θ. However,
the 0 value for y˙ that is produced by the wheel encoder
odometry should be fused in the filter. This prevents the
filter from artificially generating non-zero y˙ in the state
as the robot goes around turns.
• Every linear and rotational dimension must have a
reference (i.e., it must be measured by one of the user’s
sensor inputs). This measurement can be provided via
absolute pose data or velocity data. Prefer pose sources
when fusing only a single input in that dimension.
Prefer one pose and many velocity sources when fusing
multiple sources for a dimension.
• While the filter accepts linear acceleration measurements, they are generally insufficient for state estimation, as the double-integration of linear acceleration
without any velocity or pose reference will lead to


* Topic name of the odometry message, provided by the robot driver or simulator.


Modifies a path making it shorter

[ Truncate Path Local ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/truncate_path_local_action.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: melodic-devel)


` ~<name>/no_outer_iterations ` ( ` int ` , default: 4)


Pradheep Padmanabhan


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


Sensor Models: Models of variables with associated constraints generated from received sensor data. The variables
and constraints are then passed to the optimizer. For example, the Imu2D sensor model produces the relevant twodimensional orientation and angular velocity data variables
to add to the graph, as well as constraints on those variables
as given by the measurement itself.
Motion Models: Models of kinematic constraints between
timestamped variables. These are generated on request and
passed to the optimizer. For example, the Unicycle2D
kinematic model generates a constraint between two pose
variables in the graph. If those poses are not feasible given a
unicycle kinematic model, the constraint will generate nonzero cost.
Optimizers: Build and optimize the graph. The core nodes
in fuse are effectively wrappers around optimizer plugins.
For example, the primary state estimation node in fuse is
known as the fixed-lag smoother. It wraps an optimizer of
the same name.
Publishers: Extract relevant quantities from the optimizer
and publish the ROS 2 messages containing results. For example, the Pose2DPublisher publishes the most recent
optimized pose and covariance from the graph as both a
geometry msgs/PoseStamped ROS 2 message as well
as a transform to be consumed by other nodes via tf.
Each iteration, sensor model plugins will receive sensor
data and create constraints based on them. The optimizer
will receive these constraints and request the motion model
plugin to generate constraints to connect the sensor model
constraints to the existing graph. These new variables and
constraints are optimized over via the optimizer to compute
optimal values. Finally, the publisher will return the results
over ROS 2 topics to interested nodes.
fuse has a number of advantages over r l, both due to
software design and affordances provided by factor graphs:
• fuse is more flexible and extensible. In addition to
r l’s support of an arbitrary number of sensors, fuse’s
plugin-based architecture allows configuration of the
state vector, motion, and sensor models.
• Relative pose measurements are better supported in fuse.
• Linearization errors are reduced in fuse at every iteration
in the optimization.
• fuse can be used for applications outside sensor fusion,
mapping, and calibration; one such application is robot
control.


* If positive, via-points are extrected from the global plan (path-following mode). The value determines the resolution of the reference path (min. separation between each two consecutive via-points along the global plan, if negative: disabled). Refer to parameter ` weight_viapoint ` for adjusting the intensity. **New in version 0.4**


Joshua Wallace


` ~<name>/map_frame ` ( ` string ` , default: "odom")


####  Goal Tolerance Parameters


        * [ 1- Launch Navigation2 ](../tutorials/docs/navigation2_with_slam.html#launch-navigation2)
        * [ 2- Launch SLAM ](../tutorials/docs/navigation2_with_slam.html#launch-slam)
        * [ 3- Working with SLAM ](../tutorials/docs/navigation2_with_slam.html#working-with-slam)
        * [ 4- Getting Started Simplification ](../tutorials/docs/navigation2_with_slam.html#getting-started-simplification)
    * [ (STVL) Using an External Costmap Plugin ](../tutorials/docs/navigation2_with_stvl.html)
      * [ Overview ](../tutorials/docs/navigation2_with_stvl.html#overview)
      * [ Costmap2D and STVL ](../tutorials/docs/navigation2_with_stvl.html#costmap2d-and-stvl)
      * [ Tutorial Steps ](../tutorials/docs/navigation2_with_stvl.html#tutorial-steps)
        * [ 0- Setup ](../tutorials/docs/navigation2_with_stvl.html#setup)
        * [ 1- Install STVL ](../tutorials/docs/navigation2_with_stvl.html#install-stvl)
        * [ 1- Modify Navigation2 Parameter ](../tutorials/docs/navigation2_with_stvl.html#modify-navigation2-parameter)
        * [ 2- Launch Navigation2 ](../tutorials/docs/navigation2_with_stvl.html#launch-navigation2)
        * [ 3- RVIZ ](../tutorials/docs/navigation2_with_stvl.html#rviz)
    * [ Navigating Using GPS Localization ](../tutorials/docs/navigation2_with_gps.html)
      * [ Overview ](../tutorials/docs/navigation2_with_gps.html#overview)
      * [ Requirements ](../tutorials/docs/navigation2_with_gps.html#requirements)
      * [ GPS Localization Overview ](../tutorials/docs/navigation2_with_gps.html#gps-localization-overview)
      * [ Tutorial Steps ](../tutorials/docs/navigation2_with_gps.html#tutorial-steps)
        * [ 0- Setup Gazebo World ](../tutorials/docs/navigation2_with_gps.html#setup-gazebo-world)
        * [ 1- Setup GPS Localization system ](../tutorials/docs/navigation2_with_gps.html#setup-gps-localization-system)
        * [ 2- Setup Navigation system ](../tutorials/docs/navigation2_with_gps.html#setup-navigation-system)
        * [ 3- Interactive GPS Waypoint Follower ](../tutorials/docs/navigation2_with_gps.html#interactive-gps-waypoint-follower)
        * [ 4- Logged GPS Waypoint Follower & Waypoint Logging ](../tutorials/docs/navigation2_with_gps.html#logged-gps-waypoint-follower-waypoint-logging)
      * [ Conclusion ](../tutorials/docs/navigation2_with_gps.html#conclusion)
    * [ Groot - Interacting with Behavior Trees ](../tutorials/docs/using_groot.html)
      * [ Overview ](../tutorials/docs/using_groot.html#overview)
      * [ Visualize Behavior Trees ](../tutorials/docs/using_groot.html#visualize-behavior-trees)
      * [ Edit Behavior Trees ](../tutorials/docs/using_groot.html#edit-behavior-trees)
      * [ Adding A Custom Node ](../tutorials/docs/using_groot.html#adding-a-custom-node)
    * [ Using VIO to Augment Robot Odometry ](../tutorials/docs/integrating_vio.html)
      * [ Overview ](../tutorials/docs/integrating_vio.html#overview)
      * [ Setting Up the ZED X Camera ](../tutorials/docs/integrating_vio.html#setting-up-the-zed-x-camera)
      * [ Setting Up ZED ROS ](../tutorials/docs/integrating_vio.html#setting-up-zed-ros)
      * [ Fusing VIO Into Local State Estimate ](../tutorials/docs/integrating_vio.html#fusing-vio-into-local-state-estimate)
        * [ Fusing VSLAM Into Global State Estimate ](../tutorials/docs/integrating_vio.html#fusing-vslam-into-global-state-estimate)
      * [ Testing it Out! ](../tutorials/docs/integrating_vio.html#testing-it-out)
    * [ Dynamic Object Following ](../tutorials/docs/navigation2_dynamic_point_following.html)
      * [ Overview ](../tutorials/docs/navigation2_dynamic_point_following.html#overview)
      * [ Tutorial Steps ](../tutorials/docs/navigation2_dynamic_point_following.html#tutorial-steps)
        * [ 0- Create the Behavior Tree ](../tutorials/docs/navigation2_dynamic_point_following.html#create-the-behavior-tree)


**_Update:_ Two tutorials on planning with dynamic obstacles added ( [ click
here ](/teb_local_planner/Tutorials) ) **


validating the autonomous navigation system or its outputs.
Lifecycle Manager governs the state transitions of the
nodes. It is used to orchestrate the bringup and shutdown
of the system safely and deterministically to guarantee all
constituent components of ROS 2 are active and ready
before the first command is processed. It also maintains a
connection to each server throughout execution to deactivate
the system should any component fail. It may also re-activate
the system after an error is handled.
Collision Monitor checks for breaches in zones around
the robot from sensors such as pointclouds, laser scans, or
sonars to prevent imminent collisions, bypassing navigation’s
planners in case of sudden and urgent changes. These zones
may ask a robot to slow to a reduced speed or immediately
stop when a sufficient number of returns are detected. These
zones may also be scheduled based on velocity. The monitor
also has an Approach mode to project a robot’s footprint
forward in time and reduce the speed to assure the system is
always a certain duration away from potential collisions. An
example can be seen in Fig. 19, showing the three primitive
types of collision monitoring supported: stop, slowdown, and
approach polygons. Note that any convex or concave polygon
may be specified in the primary robot body-fixed frame.
Fig. 19. Collision Monitor zones on a sample robot.
Velocity Smoother smooths the output velocities from the
navigation system by applying dynamic constraints based
on the current robot state. This improves smoothness of
the commands sent to a base controller, which can increase
the longevity of the hardware. When set to a higher rate
than incoming velocity commands, it will also interpolate
the commands by dynamic limits providing even smoother
output to the hardware at a regular interval.
Simple Commander is a Python3 API to command Nav2
at all levels from the BT Navigator down to its constituent
servers allowing a user to have a ‘pythonic’ user experience.
It may be used to create autonomy systems leveraging
Nav2 (or bypassing BT Navigator to define custom handengineered logic) in Python3. It contains a cost map API for
handling incoming occupancy grid messages and querying it
for information.
Waypoint Follower is a server used to request navigation


We support circular differential-drive and omni-directional drive robots using
the ` SmacPlanner2D  ` planner which implements a cost-aware A* planner. We
support car-like (ackermann) and legged vehicles using the ` SmacPlannerHybrid
` plugin which implements a Hybrid-A* planner. We support non-circular,
arbitrary shaped, any model vehicles using the ` SmacPlannerLattice  ` plugin
which implements a State Lattice planner (e.g. omni, diff, ackermann, legged,
custom). It contains control sets and generators for ackermann, legged,
differential drive and omnidirectional vehicles, but you may provide your own
for another robot type or to have different planning behaviors.


* This parameter is only relevant for type "two_circles". It contains the radius of front circle.


Documented


Description

---|---|---

[ Keepout Filter ](https://github.com/ros-
planning/navigation2/tree/main/nav2_costmap_2d/plugins/costmap_filters/keepout_filter.cpp)


* Specify the value of the scalar product between obstacle heading and goal heading in order to take them (obstacles) into account for exploration.


` ~<name>/global_plan_viapoint_sep ` ( ` double ` , default: -0.1 (disabled))


      * [ 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>/is_footprint_dynamic ` ( ` bool ` , default: false)


Plugin Name


` ~<name>/max_number_classes ` ( ` int ` , default: 4)


` ~<name>/costmap_converter_plugin ` ( ` string ` , default: "")


Alexey Merzlyakov


* This parameter is only relevant for type "two_circles". It contains the radius of rear circle.


set to compute a new path if any of the following conditions
are met: the path has expired after its duration of use, a
new goal has been requested, or the path is found to be
invalid due to sufficiently increased costs or collision. Thus,
this BT will immediately replan if the path or goal requires
4navigate to pose w replanning time.xml
5navigate w replanning distance.xml
6navigate w replanning speed.xml
7navigate w replanning only if goal is updated.xml
8navigate w replanning only if path becomes invalid.xml
9navigate to pose w replanning and recovery.xml
10nav to pose with consistent replanning and if path becomes invalid.xml
11navigate to pose w replanning goal patience and recovery.xml
12navigate through poses w replanning and recovery.xml
13follow point.xml
14odometry calibration.xml
Fig. 14. Mixed-replanning navigate-to-pose behavior tree 10.
it, but also refine periodically (typically 5-30s). This enables
responsiveness to urgent needs while providing refinement as
new information is processed. Dynamic replanning is under
a rate controller to limit the replanning rate slower than the
tree’s tick rate (100 Hz).
While not included in Fig. 14, it is advisable to leverage
algorithm selector nodes as a recovery action to recompute
a key function (path planning, trajectory planning) with
another implementation. When backup implementations and
contextual recovery actions are well selected for an application, they can resolve most issues. Further, the algorithm
selectors allow a system to utilize many algorithms in their
most useful contexts, rather than only a single method.
When designing behavior trees, it is prudent to create
many independent nodes which are assembled in the tree’s
configuration for easy reusability and/or later customization.
It is also wise to place as much logic in the tree as possible, in
contrast to client servers, to provide the maximum flexibility.
These principles were followed in the BTs outlined in this
section, which has allowed them all to be composed from
the same set of BT nodes from Table IV.
VII. OVERVIEW OF STATE ESTIMATION
For a mobile robot to successfully navigate through its
environment, it needs to maintain an estimate of its state


Checks if goal is preempted in the global BT context

[ Initial Pose received Condition ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/condition/initial_pose_received_condition.cpp)


  * Add and improve safety functions in case of unavoidable obstacles (e.g. for obstacles that are located really close to the goal).
  * Implementation of suitable escape behaviors.
  * Improvements/Solutions for cases in which the planner oscillates between multiple locally optimal solutions (not on a topologic basis, but due to occuring noise etc.).


* Optimization weight for satisfying the maximum allowed angular acceleration


Steve Macenski


A “shim” controller to rotate to path heading before passing to main
controller for tracking.


Francisco Martín


The following video presents the features of the package and shows examples
from simulation and real robot situations.  Some spoken explanations are
included in the audio track of the video.


collision-free space, known as “bubbles,” are overlaid on the
path and overlap in such a way as to guarantee collisionfree movement between them. The path is then deformed
by subjecting the bubbles to repulsive forces that represent
distances from obstacles and contracting forces that eliminate
excess slack in the path.
TEB is an extension of Elastic Bands that also accounts
for temporal constraints on motion, such as acceleration
and velocity limits [22]. The constraints are weighted and
optimized using a numerical optimization framework.
The poses of the robot and time deltas between poses are
optimized in TEB. Numerous constraints are considered in
the problem formulation:
• Waypoints are attractive forces that encourage the robot
to remain close to intermediate points along the original
global path.
• Obstacles (both static and dynamic) represent repulsive
forces that keep the path from colliding with objects in
its environment.
Fig. 4. Example of an optimized Timed Elastic Band. The robot’s global
plan is shown as a red path. Way points are shown as blue squares. The
robot’s cost map is transformed into a vector representation (red blocks)
that is suitable for distance calculations in the optimizer. The optimized
trajectory, shown in green, comprises poses that are depicted as red arrows.
• Kinematic constraints can be used to ensure that the
optimized trajectory is kinematically feasible.
• Velocity and acceleration constraints ensure the final
trajectory is dynamically feasible
• Fastest path constraints ensure that the optimized trajectory is temporally efficient.
In ROS 2, the TEB Local Planner package contains
the TEB implementation [23]. It uses the g2o framework
to carry out numerical optimization [24]. At each control
iteration, the poses from some portion of the global path
and estimated time deltas between them are added to the
graph, along with the constraints described above. The graph
is then optimized and the control command is extracted
from the optimized TEB. To help constrain the problem, the
planner uses the previous cycle’s optimized trajectory as the
estimated starting values for the optimization in the current
cycle. Figure 4 shows an example of an optimized TEB. The
final trajectory accounts for the kinematic constraints of the


* Specify the robot footprint model type used for optimization. Different types are "point", "circular", "line", "two_circles" and "polygon." The type of the model significantly influences the required computation time.


  * **[ Code API ](http://docs.ros.org/en/melodic/api/teb_local_planner/html) **
  * **[ Msg API ](http://docs.ros.org/en/melodic/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/melodic/changelogs/teb_local_planner/changelog.html)
  * [ Change List ](/teb_local_planner/ChangeList)
  * [ Reviews ](/teb_local_planner/Reviews)


Documented


##  Provided Plugins  ¶


* If true, underlying trajectories might be initialized with backwards motions in case the goal is behind the start within the local costmap (this is only recommended if the robot is equipped with rear sensors).


      * [ Subtrees Obtain Shared Resources ](../../migration/Iron.html#subtrees-obtain-shared-resources)
      * [ Collision Monitor: added watchdog mechanism based on ` source_timeout  ` parameter with default blocking behavior ](../../migration/Iron.html#collision-monitor-added-watchdog-mechanism-based-on-source-timeout-parameter-with-default-blocking-behavior)
      * [ BtActionServer: use native library haltTree() ](../../migration/Iron.html#btactionserver-use-native-library-halttree)
      * [ Global Frame Removed from 2 BT Nodes ](../../migration/Iron.html#global-frame-removed-from-2-bt-nodes)
      * [ Introduction of ` CostmapUpdate.msg  ` ](../../migration/Iron.html#introduction-of-costmapupdate-msg)
      * [ Full Stack Uses Node Clocks ](../../migration/Iron.html#full-stack-uses-node-clocks)
      * [ New Graceful Motion Controller ](../../migration/Iron.html#new-graceful-motion-controller)
      * [ Plugin Libraries in BT Navigator Only Includes Custom Nodes ](../../migration/Iron.html#plugin-libraries-in-bt-navigator-only-includes-custom-nodes)
      * [ New RViz Plugin for selecting Planners, Controllers, Goal Checkers, Progress Checkers and Smoothers ](../../migration/Iron.html#new-rviz-plugin-for-selecting-planners-controllers-goal-checkers-progress-checkers-and-smoothers)
      * [ RPP new optional ` interpolate_curvature_after_goal  ` behavior and fix conflict between ` use_rotate_to_heading  ` and ` allow_reversing  ` ](../../migration/Iron.html#rpp-new-optional-interpolate-curvature-after-goal-behavior-and-fix-conflict-between-use-rotate-to-heading-and-allow-reversing)
      * [ Cancel Checker Interface For GlobalPlanner ](../../migration/Iron.html#cancel-checker-interface-for-globalplanner)
      * [ New BtActionServer/BtNavigator parameter ](../../migration/Iron.html#new-btactionserver-btnavigator-parameter)
      * [ New collision monitor parameter ](../../migration/Iron.html#new-collision-monitor-parameter)
      * [ New graceful cancellation API for Controllers ](../../migration/Iron.html#new-graceful-cancellation-api-for-controllers)
      * [ Standardization of Plugin Naming with Double Colons (::) ](../../migration/Iron.html#standardization-of-plugin-naming-with-double-colons)
      * [ Collision monitor: dynamic radius for circle type polygons ](../../migration/Iron.html#collision-monitor-dynamic-radius-for-circle-type-polygons)
  * [ Simple Commander API ](../../commander_api/index.html)
    * [ Overview ](../../commander_api/index.html#overview)
    * [ Commander API ](../../commander_api/index.html#id1)
    * [ Costmap API ](../../commander_api/index.html#costmap-api)
    * [ Footprint Collision Checker API ](../../commander_api/index.html#footprint-collision-checker-api)
    * [ Examples and Demos ](../../commander_api/index.html#examples-and-demos)
  * [ Roadmaps ](../../roadmap/roadmap.html)
    * [ Jazzy Roadmap ](../../roadmap/roadmap.html#jazzy-roadmap)
    * [ Iron Roadmap ](../../roadmap/roadmap.html#iron-roadmap)
    * [ Humble Roadmap ](../../roadmap/roadmap.html#humble-roadmap)
  * [ About and Contact ](../../about/index.html)
    * [ Related Projects ](../../about/related_projects.html)
    * [ About ](../../about/index.html#id1)
    * [ Contact ](../../about/index.html#contact)


Carl Delsey


Joshua Wallace


` ~<name>/acc_lim_y ` ( ` double ` , default: 0.5)


` ~<name>/max_vel_x ` ( ` double ` , default: 0.4)


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


BT Node for other BehaviorTree.CPP BTs to call Navigation2 as a subtree action

[ Reinitalize Global Localization Service ](https://github.com/ros-
planning/navigation2/tree/main/nav2_behavior_tree/plugins/action/reinitialize_global_localization_service.cpp)


** Dependencies  (23) **


Differential, Omnidirectional, Legged

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


![Paths generated by the Smac Planners](../../_images/3planners.png)


Maintains temporal 3D sparse volumetric voxel grid with decay through sensor
models

[ Non-Persistent Voxel Layer
](https://github.com/SteveMacenski/nonpersistent_voxel_layer)


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


  * Maintainer status: maintained
  * 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: noetic-devel)


to improve practical drivability while retaining kinematic
feasibility. It also balances improving the smoothness of the
path with shifting the plan into lower-cost regions. Since
it has no constraint on the original path coordinates, this
smoother may make larger, global level changes to the path
beyond localized artifacts. Thus, the benchmark shows that
the Constrained Smoother generated paths typically longer
then the Simple Smoother, but with significantly reduced
costs, while also improving on smoothness and curvature
from the original path. Fig. 8 demonstrates this visually
with a path of similar length, but maximizing distance from
obstacles and reducing path curvature.
When reversing path segments exist, ωcc (cusp-cost) is
used instead of ωc within close proximity to cusp points.
This value is strictly larger than ωc and incentivizes the
optimization problem to push direction-changing maneuvers
further away from obstacles for additional safety margins.
Figure 9 shows an example of the impact of an elevated ωcc
in close proximity to cusp points.
Fig. 9. Impact of increased cusp costs near direction-changing points. The
cyan path is the unsmoothed original path, purple is using the same ωc,
and green uses ωcc near the direction change. The cost-field is shown as
the background colored gradient near a rectangular obstacle [32].
While the Constrained Smoother is targeting feasible
planners, it may also be used by the holonomic planners.
The curvature term is removed when ωκ = 0 and may
operate on paths using only the cost and smoothness terms to
perform global-level optimization rather than only removing
localized imperfections and discontinuities. However, this
smoother is much more computationally expensive than the
Simple Smoother, taking up to several seconds depending
on the length of the global path and the environment. Thus,
it is primarily recommended where maintaining feasibility
is a strict requirement. The smoother terminates when the
parameter, function, or gradient tolerance is achieved, the
maximum number of iterations has been reached, or the
maximum time has been used.
Savitzky-Golay Smoother is a path smoother derived
from the famed digital filter of its namesake [33]. This filter
analytically smooths regularly-spaced data using a sliding


the grid is still unknown (grey). Due to the high accuracy
of the sensors, these observations are treated as absolute,
without the probabilistic calculations of occupancy seen in
the 1980s. The simplification of logic also assists in quicker
computation. As a robot moves through the scene and/or
more measurements are taken, it will dynamically generate
an occupancy map of the environment around it based on
depth sensing.
The two dimensional nature of this layer makes it ideal for
planar laser scanners, but may be overly constrained when
using three-dimensional data. It may be necessary when
working with low-accuracy or noisy sensors to pre-filter the
data stream before processing in the obstacle layer to reduce
noisy results in the cost map.
Voxel The voxel layer is similar to the obstacle layer, but
Fig. 12. Visual demonstration of ray-tracing based marking and clearing
in a grid map. Overlaid on a sandbox map, a low-resolution laser scan is
raytracing freespace (white) from measurements (blue).
tracks the environment and ray-traces measurements in three
dimensions. It is most useful for RGB-D, 3D laser scanners, or other non-trivially two-dimensional sensor streams.
Internally, it uses a voxel grid model the size of the cost
map to represent the environment in a non-probabilistic way.
This model scales linearly with cost map size, similar to the
two-dimensional grid, by maintaining the height dimension
through manipulating the bits of an unsigned 32 bit integer.
Thus, its maximum height is limited. It is recommended to
only track heights to the limit of what is useful (e.g., a home
vacuum robot need not maintain a voxel grid > 1m off the
ground). The vertical resolution of the voxels is independent
from their horizontal resolution, and is typically larger. The
three-dimensional data is projected down to two dimensions
for writing into the main cost map. As it conducts threedimensional raytracing, this layer is more computationally
expensive than the obstacle layer.
Non-Persistent Voxel The non-persistent voxel layer computes values in the same manner as the voxel layer, but does
not persist the data from one update to the next. Thus, each
iteration a new voxel grid is created to populate the cost map,
then cleared.
Spatio-temporal Voxel The Spatio-temporal voxel layer
(STVL) use a more refined data structure than the voxel
layer, Fig. 13. It tracks obstacles in three-dimensions using OpenVDB, a sparse voxel grid library developed by


* 2D A* computed the path in 243ms


        * [ 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 ](../index.html)
    * [ Behavior-Tree Navigator ](configuring-bt-navigator.html)
      * [ Parameters ](configuring-bt-navigator.html#parameters)
      * [ Example ](configuring-bt-navigator.html#example)
    * [ Behavior Tree XML Nodes ](configuring-bt-xml.html)
      * [ Action Plugins ](configuring-bt-xml.html#action-plugins)
        * [ Wait ](bt-plugins/actions/Wait.html)
        * [ Spin ](bt-plugins/actions/Spin.html)
        * [ BackUp ](bt-plugins/actions/BackUp.html)
        * [ DriveOnHeading ](bt-plugins/actions/DriveOnHeading.html)
        * [ AssistedTeleop ](bt-plugins/actions/AssistedTeleop.html)
        * [ ComputePathToPose ](bt-plugins/actions/ComputePathToPose.html)
        * [ FollowPath ](bt-plugins/actions/FollowPath.html)
        * [ NavigateToPose ](bt-plugins/actions/NavigateToPose.html)
        * [ ClearEntireCostmap ](bt-plugins/actions/ClearEntireCostmap.html)
        * [ ClearCostmapExceptRegion ](bt-plugins/actions/ClearCostmapExceptRegion.html)
        * [ ClearCostmapAroundRobot ](bt-plugins/actions/ClearCostmapAroundRobot.html)
        * [ ReinitializeGlobalLocalization ](bt-plugins/actions/ReinitializeGlobalLocalization.html)
        * [ TruncatePath ](bt-plugins/actions/TruncatePath.html)
        * [ TruncatePathLocal ](bt-plugins/actions/TruncatePathLocal.html)
        * [ PlannerSelector ](bt-plugins/actions/PlannerSelector.html)
        * [ ControllerSelector ](bt-plugins/actions/ControllerSelector.html)
        * [ SmootherSelector ](bt-plugins/actions/SmootherSelector.html)
        * [ GoalCheckerSelector ](bt-plugins/actions/GoalCheckerSelector.html)
        * [ ProgressCheckerSelector ](bt-plugins/actions/ProgressCheckerSelector.html)
        * [ NavigateThroughPoses ](bt-plugins/actions/NavigateThroughPoses.html)
        * [ ComputePathThroughPoses ](bt-plugins/actions/ComputePathThroughPoses.html)
        * [ ComputeCoveragePath ](bt-plugins/actions/ComputeCoveragePath.html)


Eitan Marder-Eppstein & Kurt Konolige


Steve Macenski


* If true, time cost (sum of squared time differences) is replaced by the total transition time (sum of time differences).


#  Navigation Plugins  ¶


Christoph Rösmann


A plugin to take and save photos to specified directory on waypoint arrivals.

[ InputAtWaypoint ](https://github.com/ros-
planning/navigation2/tree/main/nav2_waypoint_follower/plugins/input_at_waypoint.cpp)


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


##  Node API


* **indigo:** _Documentation generated on June 09, 2019 at 04:06 AM_ ( [ doc job ](http://build.ros.org/view/Idoc/job/Idoc__teb_local_planner__ubuntu_trusty_amd64) ).


* Global plan that the local planner is currently attempting to follow. Used primarily for visualization purposes.


**Note** , reduce ` ~<name>/weight_kinematics_nh ` significantly in order to
adjust the tradeoff between compliant longitudinal motion and non-compliant
lateral motion (strafing).


Uses a probabalistic model to put data from sensors that publish range msgs on
the costmap

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


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


` <name> ` .allow_unknown


Eitan Marder-Eppstein


extensible, systematic way to update the cost map with many,
configurable, and arbitrary perception algorithm results. The
Layered Costmap comprises an ordered list of dynamically
run-time loaded layers which each represent a different data
source, algorithm, or result. Each update cycle, the main cost
map is updated by polling each of these layers in turn to
populate the grid with new information.
Any developer may write a costmap layer and include it
on their robot system for their specific applications. Common
types of layers include: cost map inflation, sensor processing, semantic information, results from machine learning
detection or segmentation algorithms, and multi-robot coordination. However, a set of common layers are provided by
ROS 2 applicable for a broad range of common applications.
B. Costmap Layers
Static A map provides information about where obstacles
are known to be a priori, often from an offline mapping
Fig. 11. Cost Map example in a practical home environment. Black are
lethal obstacles, light blue are inscribed lethal costs due to robot dimensions,
the gradient from red to blue are a cost potential field caused by the Inflation
Layer, and grey are unknown cost cells. Free space with no potential cost
are white, not shown.
algorithm or other data source like blueprints. The static layer
subscribes to an OccupancyGrid topic containing this
information. It is common for the static layer to be the first
costmap layer, providing the base information about the environment for later algorithms to modify. While the name implies non-changing, the static layer can have the map change
over time as the result of map sharding over large spaces or
updates to the environment due to continual mapping. There
is a separate subscription to a OccupancyGridUpdate
topic for efficient non-dimension changing updates to localized map information.
Obstacle The obstacle layer stores information from high
accuracy sensors such as lasers and RGB-D cameras in
a two dimensional grid. Each point in the sensor data is
treated as a ray, originating from the sensor pose. That
ray is ray-traced through the grid in two dimensions using
Bresenham’s algorithm, where the endpoint is marked as
occupied and its path is marked as free space due to direct
visibility. Fig. 12 demonstrates this process visually. The 2D
laser scanner produces measurements from obstacles which
are marked in the grid in blue. Breshenham’s ray-casting
algorithm is used to clear out the visible free-space from
the sensor to the obstacle in white, while the remainder of


        * [ SimpleGoalChecker ](nav2_controller-plugins/simple_goal_checker.html)
        * [ StoppedGoalChecker ](nav2_controller-plugins/stopped_goal_checker.html)
      * [ Default Plugins ](configuring-controller-server.html#default-plugins)
      * [ Example ](configuring-controller-server.html#example)
    * [ DWB Controller ](configuring-dwb-controller.html)
      * [ Controller ](configuring-dwb-controller.html#controller)
        * [ DWB Controller ](dwb-params/controller.html)
        * [ XYTheta Iterator ](dwb-params/iterator.html)
        * [ Kinematic Parameters ](dwb-params/kinematic.html)
        * [ Publisher ](dwb-params/visualization.html)
      * [ Plugins ](configuring-dwb-controller.html#plugins)
        * [ LimitedAccelGenerator ](dwb-plugins/limited_accel_generator.html)
        * [ StandardTrajectoryGenerator ](dwb-plugins/standard_traj_generator.html)
      * [ Trajectory Critics ](configuring-dwb-controller.html#trajectory-critics)
        * [ BaseObstacleCritic ](trajectory_critics/base_obstacle.html)
        * [ GoalAlignCritic ](trajectory_critics/goal_align.html)
        * [ GoalDistCritic ](trajectory_critics/goal_dist.html)
        * [ ObstacleFootprintCritic ](trajectory_critics/obstacle_footprint.html)
        * [ OscillationCritic ](trajectory_critics/oscillation.html)
        * [ PathAlignCritic ](trajectory_critics/path_align.html)
        * [ PathDistCritic ](trajectory_critics/path_dist.html)
        * [ PreferForwardCritic ](trajectory_critics/prefer_forward.html)
        * [ RotateToGoalCritic ](trajectory_critics/rotate_to_goal.html)
        * [ TwirlingCritic ](trajectory_critics/twirling.html)
      * [ Example ](configuring-dwb-controller.html#example)
    * [ Regulated Pure Pursuit ](configuring-regulated-pp.html)
      * [ Regulated Pure Pursuit Parameters ](configuring-regulated-pp.html#regulated-pure-pursuit-parameters)
      * [ Example ](configuring-regulated-pp.html#example)
    * [ Model Predictive Path Integral Controller ](configuring-mppic.html)
      * [ MPPI Parameters ](configuring-mppic.html#mppi-parameters)
        * [ Trajectory Visualization ](configuring-mppic.html#trajectory-visualization)
        * [ Path Handler ](configuring-mppic.html#path-handler)
        * [ Ackermann Motion Model ](configuring-mppic.html#ackermann-motion-model)
        * [ Constraint Critic ](configuring-mppic.html#constraint-critic)
        * [ Goal Angle Critic ](configuring-mppic.html#goal-angle-critic)
        * [ Goal Critic ](configuring-mppic.html#goal-critic)
        * [ Obstacles Critic ](configuring-mppic.html#obstacles-critic)
        * [ Cost Critic ](configuring-mppic.html#cost-critic)
        * [ Path Align Critic ](configuring-mppic.html#path-align-critic)
        * [ Path Angle Critic ](configuring-mppic.html#path-angle-critic)


**Package Links**


##  Behavior-Tree Navigators  ¶


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


latest


` ~<name>/legacy_obstacle_association ` ( ` bool ` , default: false)


Differential, Omni, **Ackermann**

[ Rotation Shim Controller ](https://github.com/ros-
planning/navigation2/tree/main/nav2_rotation_shim_controller)


A simple path smoother for infeasible (e.g. 2D) planners

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


  * **[ Code API ](http://docs.ros.org/kinetic/api/teb_local_planner/html) **
  * **[ Msg API ](http://docs.ros.org/en/kinetic/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/kinetic/changelogs/teb_local_planner/changelog.html)
  * [ Change List ](/teb_local_planner/ChangeList)
  * [ Reviews ](/teb_local_planner/Reviews)


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


* Maximum translational velocity of the robot in meters/sec


` ~<name>/weight_kinematics_nh ` ( ` double ` , default: 1000.0)


Guillaume Doisy


* Overwrite orientation of local subgoals provided by the global planner (since they often provide only a 2D path)


Updates the goal received via topic subscription.

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


If true, the last pose of the path generated by the planner will have its
orientation set to the approach orientation, i.e. the orientation of the
vector connecting the last two points of the path


Cancels assisted teleop behavior action

[ Cancel Complete Coverage Action ](https://github.com/open-
navigation/opennav_coverage/blob/main/opennav_coverage_bt/src/cancel_complete_coverage_path.cpp)


      * [ 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>/footprint_model/line_end ` ( ` double[2] ` , default: [0.3, 0.0])


` ~<name>/obstacles ` ( [ costmap_converter/ObstacleArrayMsg
](http://docs.ros.org/en/api/costmap_converter/html/msg/ObstacleArrayMsg.html)
)


environments navigating over 2 marathons in length on an
active college campus. The authors recommend reviewing
this document for a practical and reproducible example of
the composed capabilities described in this paper.
This survey comes from the desks of core ROS developers
and maintainers to be the authoritative discussion on the
state-of-the-art in ROS 2 robotics navigation. This survey
includes overviews, analysis, and unique expert insight into
the algorithms and capabilities, new and old. We discuss and
compare current research products with historically robust
methods. Brief benchmarking within provides metrics for the
first time for the new key methods. Finally, this survey ends
arXiv:2307.15236v2 [cs.RO] 31 Jul 2023
with a glimpse into the future of ROS 2 mobile robotics
capabilities.
II. OVERVIEW OF GLOBAL PATH PLANNERS
Global path planning seeks to address the foundational
problem of finding optimal sequences of valid configurations
to determine a route through an environment. A path may
have different levels of fidelity. It may comprise sequences of
neighboring cells in a grid map, feasible and continuous sequences, or even vehicle dynamics. For global path planning
in Nav2, only up to kinematic constraints are considered. The
hybrid planning schema utilized establishes that the global
planner’s objective is to find a route through the environment,
while a local trajectory planner follows this route considering
system dynamics and other criteria [5].
The definition of optimal in global path planning can
vary with application, and at its core, the algorithms are all
extensions of Dijkstra’s algorithm in trying to find the path
with minimal cost [6]. In Nav2, the cost is largely determined
by the cost map which is discussed at length in Sec. V. In
practice, the result is usually the shortest path that does not
navigate too closely to any obstacle, as seen in Figure 1.
Path planners are typically either search- or samplingbased. Sampling-based planners, like RRT and its variants,
are prevalent for higher dimensional planning problems and
can provide near-optimal paths - although they commonly require post-processing before use [7]. However, search-based
planners in lower dimensional state spaces, like those found
in mobile robotics, are typically faster and produce truly
optimal paths when heuristics are admissible and consistent.
Search-based planners also provide more predictable execution times important to dynamic replanning over complex


Steve Macenski


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


` <name> ` is the corresponding planner plugin ID selected for this type.


planning and local navigation implemented on a mobile robot in indoor
environment,” in Proceedings of the IEEE Internatinal Symposium on
Intelligent Control, 2002.
[6] E. Dijkstra, “A note on two problems in connexion with graphs.
numeriske mathematik, 1, 269–271,” 1959.
[7] S. M. LaValle, “Rapidly-exploring random trees : a new tool for path
planning,” The annual research report, 1998.
[8] O. Brock and O. Khatib, “High-speed navigation using the global
dynamic window approach,” in Proceedings 1999 IEEE International
Conference on Robotics and Automation (Cat. No.99CH36288C),
vol. 1, 1999.
[9] A. Nash, K. Daniel, S. Koenig, and A. Felner, “Theta*: Any-angle
path planning on grids,” in AAAI, vol. 7, 2007, pp. 1177–1183.
[10] P. E. Hart, N. J. Nilsson, and B. Raphael, “A formal basis for the
heuristic determination of minimum cost paths,” IEEE transactions on
Systems Science and Cybernetics, vol. 4, no. 2, pp. 100–107, 1968.
[11] R. Philippsen, “A light formulation of the e interpolated path replanner,” ETH Zurich, Tech. Rep., 2006.
[12] J. E. Bresenham, “Algorithm for computer control of a digital plotter,”
IBM Systems journal, vol. 4, no. 1, pp. 25–30, 1965.
[13] A. Nash, S. Koenig, and C. Tovey, “Lazy theta*: Any-angle path
planning and path length analysis in 3d,” in Proceedings of the AAAI
Conference on Artificial Intelligence, vol. 24, no. 1, 2010, pp. 147–
154.
[14] D. Dolgov, S. Thrun, M. Montemerlo, and J. Diebel, “Practical
search techniques in path planning for autonomous driving,” International Symposium on Search Techniques in Artificial Intelligence
and Robotics, 2008.
[15] M. Likhachev and D. Ferguson, “Planning long dynamically feasible
maneuvers for autonomous vehicles,” The International Journal of
Robotics Research, vol. 28, no. 8, pp. 933–945, 2009.
[16] M. Pivtoraiko, R. A. Knepper, and A. Kelly, “Optimal, smooth,
nonholonomic mobile robot motion planning in state lattices,” Robotics
Institute, Carnegie Mellon University, Pittsburgh, PA, Tech. Rep.
CMU-RI-TR-07-15, 2007.
[17] M. Pivtoraiko, T. Howard, I. Nesnas, and A. Kelly, “Field experiments in rover navigation via model-based trajectory generation and
nonholonomic motion planning in state lattices,” in Proceedings of
9th International Symposium on Artificial Intelligence, Robotics, and
Automation in Space (iSAIRAS ’08), February 2008.
[18] N. Limpert, S. Schiffer, and A. Ferrein, “A local planner for
ackermann-driven vehicles in ros sbpl,” in 2015 Pattern Recognition
Association of South Africa and Robotics and Mechatronics International Conference (PRASA-RobMech), 2015, pp. 172–177.


Maintains persistent 2D costmap from 2D laser scans with raycasting to clear
free space

[ Spatio-Temporal Voxel Layer
](https://github.com/SteveMacenski/spatio_temporal_voxel_layer/)


Creator


Eitan Marder-Eppstein


      * [ 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)


exploration rovers, legged robots; or differential-drive inplace rotations and omnidirectional lateral motions [17].
Thus, it is a generalized class of planner for any robot drivetrain type when matched with a complimentary minimum
control set - making it a powerful addition to Nav22
.
The State Lattice planner in Nav2 provides a number of
noteworthy optimizations to improve performance beyond
historical libraries such as SBPL, to 20-300 ms [18]. Classical State Lattice planners struggle to efficiently determine
the best route through complex scenes using only distancebased heuristics. They also labor to find paths to precise goal
poses with solely search. The cost-aware obstacle heuristic
and analytic expansions are also shared with this planner
to resolve these issues, respectively. In providing the Smac
Hybrid-A* capabilities, this planner improves performance
by an order of magnitude and provides remarkably similar results to Hybrid-A* both in compute time and path
length/quality, show in Table I. The path lengths and planning
times are within 0.5% and 1.6% of each other, respectively.
This is a powerful result: Nav2 contains two planners with
analogous behavior each covering important niches to establish support for the breadth of possible robot platform types.
Therefore, effectively any robot base can be used with Nav2
to create kinematically feasible plans, which are also akin
to any other robot type’s plans - forming consistency across
heterogeneous fleets. Fig. 2 illustrates two paths produced
by Hybrid-A* and State Lattice planners.
Note that both of these planners and the 2D-A* discussed
previously derive from the Smac Planner framework. A number of shared optimizations, pre-computations, and caching
have been made within the framework to be competitive with
established planning algorithm implementations in planning
time, behavior and path length. The Smac Hybrid-A* and
State Lattice planners are notably faster than their 2D-A*
counterpart in large part due to an initially reduced costaware obstacle heuristic resolution used to steer the feasible
search, which is later upsampled as nodes are visited.
III. OVERVIEW OF LOCAL TRAJECTORY PLANNERS
Once a global path planner or similar has found an
acceptable route through the environment, another technology needs to convert the intended route to navigate into
a stream of velocity commands for the mobile platform
to track. These commands generally attempt to follow the
path, but may also consider objectives such as reducing
likelihood of collision, improving smoothness, minimizing
important objectives (curvature, acceleration, jerk), or may
implement other primitive behaviors. This is the work of
the (Local) Trajectory Planner, which generates collisionfree trajectories and issues current velocity commands to the


  * [ ](../../index.html)
  * [ Configuration Guide ](../index.html)
  * Smac Planner
  *


* Each outerloop iteration automatically resizes the trajectory according to the desired temporal resolution ` dt_ref ` and invokes the internal optimizer (that performs ` no_inner_iterations ` ). The total number of solver iterations in each planning cycle is therefore the product of both values.


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

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


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.


        * [ Path Follow Critic ](../configuration/packages/configuring-mppic.html#path-follow-critic)
        * [ Prefer Forward Critic ](../configuration/packages/configuring-mppic.html#prefer-forward-critic)
        * [ Twirling Critic ](../configuration/packages/configuring-mppic.html#twirling-critic)
        * [ Velocity Deadband Critic ](../configuration/packages/configuring-mppic.html#velocity-deadband-critic)
      * [ Example ](../configuration/packages/configuring-mppic.html#example)
      * [ Notes to Users ](../configuration/packages/configuring-mppic.html#notes-to-users)
        * [ General Words of Wisdom ](../configuration/packages/configuring-mppic.html#general-words-of-wisdom)
        * [ Prediction Horizon, Costmap Sizing, and Offsets ](../configuration/packages/configuring-mppic.html#prediction-horizon-costmap-sizing-and-offsets)
        * [ Obstacle, Inflation Layer, and Path Following ](../configuration/packages/configuring-mppic.html#obstacle-inflation-layer-and-path-following)
    * [ Rotation Shim Controller ](../configuration/packages/configuring-rotation-shim-controller.html)
      * [ Rotation Shim Controller Parameters ](../configuration/packages/configuring-rotation-shim-controller.html#rotation-shim-controller-parameters)
      * [ Example ](../configuration/packages/configuring-rotation-shim-controller.html#example)
    * [ Graceful Controller ](../configuration/packages/configuring-graceful-motion-controller.html)
      * [ Graceful Controller Parameters ](../configuration/packages/configuring-graceful-motion-controller.html#graceful-controller-parameters)
      * [ Example ](../configuration/packages/configuring-graceful-motion-controller.html#example)
    * [ Map Server / Saver ](../configuration/packages/configuring-map-server.html)
      * [ Map Saver Parameters ](../configuration/packages/configuring-map-server.html#map-saver-parameters)
      * [ Map Server Parameters ](../configuration/packages/configuring-map-server.html#map-server-parameters)
      * [ Costmap Filter Info Server Parameters ](../configuration/packages/configuring-map-server.html#costmap-filter-info-server-parameters)
      * [ Example ](../configuration/packages/configuring-map-server.html#example)
    * [ AMCL ](../configuration/packages/configuring-amcl.html)
      * [ Parameters ](../configuration/packages/configuring-amcl.html#parameters)
      * [ Example ](../configuration/packages/configuring-amcl.html#example)
    * [ Behavior Server ](../configuration/packages/configuring-behavior-server.html)
      * [ Behavior Server Parameters ](../configuration/packages/configuring-behavior-server.html#behavior-server-parameters)
      * [ Default Plugins ](../configuration/packages/configuring-behavior-server.html#default-plugins)
      * [ Spin Behavior Parameters ](../configuration/packages/configuring-behavior-server.html#spin-behavior-parameters)
      * [ BackUp Behavior Parameters ](../configuration/packages/configuring-behavior-server.html#backup-behavior-parameters)
      * [ DriveOnHeading Behavior Parameters ](../configuration/packages/configuring-behavior-server.html#driveonheading-behavior-parameters)
      * [ AssistedTeleop Behavior Parameters ](../configuration/packages/configuring-behavior-server.html#assistedteleop-behavior-parameters)
      * [ Example ](../configuration/packages/configuring-behavior-server.html#example)
    * [ Smoother Server ](../configuration/packages/configuring-smoother-server.html)
      * [ Smoother Server Parameters ](../configuration/packages/configuring-smoother-server.html#smoother-server-parameters)
      * [ Example ](../configuration/packages/configuring-smoother-server.html#example)
    * [ Simple Smoother ](../configuration/packages/configuring-simple-smoother.html)
      * [ Simple Smoother Parameters ](../configuration/packages/configuring-simple-smoother.html#simple-smoother-parameters)
      * [ Example ](../configuration/packages/configuring-simple-smoother.html#example)
    * [ Savitzky-Golay Smoother ](../configuration/packages/configuring-savitzky-golay-smoother.html)
      * [ Savitzky-Golay Smoother Parameters ](../configuration/packages/configuring-savitzky-golay-smoother.html#savitzky-golay-smoother-parameters)
      * [ Example ](../configuration/packages/configuring-savitzky-golay-smoother.html#example)


* Rate that defines how often the costmap_converter plugin processes the current costmap (the value should not be much higher than the costmap update rate) [in Hz].


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


planning to ensure obstacle avoidance which is reactive
to changes in the local environment, which may be more
fine grained, up-to-date, or information rich than that used
in global planning. This knowledge may include sensory
information in addition to map or occupancy information,
though not definitionally. In Nav2, all planners use live
sensor information fused with a map via its local cost map
(discussed in Sec. V).
Although reactive trajectory planners often consider the
environment around it, they lack full context in temporal
TABLE II
TRAJECTORY PLANNERS COMPARISON
Local Trajectory Planner Max. Frequency (Hz) Type Circular Non-Circ. Diff. Omni. Ackermann Legged
Model Pred. Path Integral1 125 Predictive ✓ ✓ ✓ ✓ ✓ ✓
Timed Elastic Band 130 Predictive ✓ ✓ ✓ ✓ ✓ ✓
DWB 250 Reactive ✓ ✓ ✓ ✓ - -
Graceful 1, 800 Control-law ✓ ✓ ✓ ✓3
- -
Reg. Pure Pursuit1 > 4, 000 Geometric ✓ ✓ ✓ ✓ ✓ ✓
Rotation Shim1 2 >> 10, 000 Kinematic ✓ ✓ ✓ ✓ - -
1 Exclusive to ROS 2 2 To be paired with other algorithms 3 While not taking full advantage of the omni-directional base, this control law works
well on powered caster bases which are not fully holonomic An inter-modal algorithm selection summary can be found in Appendix I.
Fig. 3. Visualization of the dynamic window of feasible velocity commands from the robot’s current state, with 9 angular velocities (vθ) and 5
translational samples (vx).
dimensions. These methods typically rely on potential fields
or hand-engineered heuristics which score trajectories based
on the robot’s current state and the localized surroundings in
the current time-step only. While this can be effective in a
number of environments and boasts low computational complexity, it is often susceptible to local minima. Nonetheless,
robust reactive control methods continue to find a great deal
of application in modern robotic systems.
In particular, the Dynamic Window Approach endures
as a method of interest to system designers and researchers
alike. DWA is enabled by the DWB Local Planner in Nav2 3
.
The method sub-samples a set of feasible velocity commands from the dynamic window of achievable velocities,
shown in Fig. 3. These are a set of candidate commands from
the robot’s current velocity state (vx, vθ) within its dynamic
limits [19]. This set contains constant velocities which create
circular arcs when projected forward - a simple trajectory.


#  Wiki