Setting Up Navigation Plugins

In this part of the guide, we discuss how your robot can utilize different planner and controller algorithms to complete navigation tasks. We will discuss some of the available algorithm plugins you can use based on your robot type and environment.

Planner and Controller Servers

Navigation algorithms are implemented in Nav2 through the use of plugins running on ROS action servers - the planner, controller and behavior servers (among others). For this section, we discuss the planner and controller servers, which are the heart of the navigation stack. These servers may implement one or more algorithm plugins each with its own configuration tailored for a specific action or robot state. This guide will highlight the different algorithms based on the type of robot and environment the robot is deployed in. This guide will not cover behaviors, smoothers, etc as those are dependent on application and not hardware/environment to offer generalized advice.

The planner server is responsible for implementing algorithms that compute the robot’s path. For example, one plugin can be configured to compute a simple shortest path between two relatively near locations while another plugin computes for a path to locations that cover the entire robot environment.

The controller server generates the appropriate control efforts needed for a robot to complete a task in its local environment. These tasks include but are not limited to: following a path generated by the planner server, avoiding dynamic obstacles along this path, and even charging at a docking station.

As mentioned before, the planner and controller servers host a map of one or multiple plugins wherein a certain plugin will be used for a certain environment, scenario, or task. For instance, the controller server can have a plugin for following a path when in long corridors to stay in the middle of the aisle, and then another plugin for avoiding dynamic obstacles in a crowded place. Selecting which planning algorithm to execute based on the robot’s task can be done through the behavior tree of your navigation system or application server.

Selecting the Algorithm Plugins

In this section, we discuss some of the available algorithm plugins for the planner and controller servers. We also discuss the purpose of each algorithm, and for which type of robot they are recommended to be used. Lastly, we show some sample yaml configuration that specifies the plugin to be used for each server.

Note

The algorithm plugins you can use are not limited to the ones mentioned in this section. You may create custom plugins as well and new plugins are added to Nav2 regularly. For tutorials on how to write your own plugins, please see Writing a New Planner Plugin and Writing a New Controller Plugin. The list of all available Nav2 plugins and their descriptions can be found in Navigation Plugins Section.

Planner Server

The algorithm plugins for the planner server find the robot’s path using a representation of its environment captured by its different sensors. Some of these algorithms operate by searching through the environment’s grid space while others expand the robot’s possible states while accounting for path feasibility.

As mentioned, the planner server may utilize plugins that work on the grid space such as the NavFn Planner, Smac Planner 2D, and Theta Star Planner. The NavFn planner is a navigation function planner that uses either Dijkstra or A*. Next, the Smac 2D planner implements a 2D A* algorithm using 4 or 8 connected neighborhoods with a smoother and multi-resolution query. Lastly, the Theta Star planner is an implementation of Theta* using either line of sight to create non-discretely oriented path segments.

One issue you may encounter when using algorithms that work on the grid space is that there is no guarantee that a drivable path can be generated for any type of robot. For example, it is not guaranteed that the NavFn Planner can plan a feasible path for a non-circular robot in a tight space since it uses the circular footprint of a robot (by approximating the robot’s largest cross-sectional radius) and checks for collisions per costmap grid cell. In addition, these algorithms are also not suitable for ackermann and legged robots since they have turning constraints. That being said, these plugins are best used on robots that can drive in any direction or rotate safely in place, such as circular differential and circular omnidirectional robots.

Another planner plugin is the Smac Hybrid-A* planner that supports arbitrary shaped ackermann and legged robots. It is a highly optimized and fully reconfigurable Hybrid-A* implementation supporting Dubin and Reeds-Shepp motion models. This algorithm expands the robot’s candidate paths while considering the robot’s minimum turning radius constraint and the robot’s full footprint for collision avoidance. Thus, this plugin is suitable for arbitrary shaped robots that require full footprint collision checking. It may also be used for high-speed robots that must be navigated carefully to not flip over, skid, or dump load at high speeds.

There is also the Smac Lattice planner plugin which is based on a State Lattice planner. This plugin functions by expanding the robot state space while ensuring the path complies with the robot’s kinematic constraints. The algorithm provides minimum control sets which allows it to support differential, omnidirectional, and ackermann vehicles of any shape and size with minimal reconfiguration.

Summary

Plugin Name	Supported Robot Types
NavFn Planner	Circular Differential, Circular Omnidirectional
Smac Planner 2D
Theta Star Planner
Smac Hybrid-A* Planner	Non-circular or Circular Ackermann, Non-circular or Circular Legged
Smac Lattice Planner	Non-circular Differential, Non-circular Omnidirectional

Example Configuration

planner_server:
  ros__parameters:
    planner_plugins: ['GridBased']
    GridBased:
      plugin: 'nav2_navfn_planner::NavfnPlanner' # In Iron and older versions, "/" was used instead of "::"

An example configuration of the planner server is shown above. The planner_plugins parameter accepts a list of mapped planner plugin names. For each plugin namespace defined in planner_plugins (GridBased in our example), we specify the type of plugin to be loaded in the plugin parameter. Additional configurations must then be specified in this namespace based on the algorithm to be used. Please see the Configuration Guide for more details.

Controller Server

The default controller plugin is the DWB controller. It implements a modified Dynamic Window Approach (DWA) algorithm with configurable plugins to compute the control commands for the robot. This controller makes use of a Trajectory Generator plugin that generates the set of possible trajectories. These are then evaluated by one or more Critic plugins, each of which may give a different score based on how they are configured. The sum of the scores from these Critic plugins determine the overall score of a trajectory. The best scoring trajectory then determines the output command velocity.

The DWB controller can be used on circular or non-circular differential, and circular or non-circular omnidirectional robots. It may also be configured for ackerman and legged robots if it is given a Trajectory Generation plugin that produces a set of possible trajectories that considers the robot’s minimum curvature constraint.

Next example of a controller server plugin is the TEB controller which is an MPC time optimal controller. It implements the Timed Elastic Band (TEB) approach which optimizes the robot’s trajectory based on its execution time, distance from obstacles, and feasibility with respect to the robot’s kinematic constraints. This controller can be used on differential, omnidirectional, ackermann, and legged robots.

Another example for this section is the Regulated Pure Pursuit controller (RPP) . This controller implements a variant of the pure pursuit algorithm with added regulation heuristic functions to manage collision and velocity constraints. This variation is implemented to target the needs of service or industrial robots and is suitable for use with differential, ackermann, and legged robots.

The last example is the Vector Pursuit Controller . It implements the Vector Pursuit algorithm and calculates the command velocity using screw theory. This controller is suitable for high speed path tracking and sharp turns or when computation resources are limited. It can be used for differential, ackermann, and legged robots.

Summary

Plugin Name	Supported Robot Types	Task
DWB controller	Differential, Omnidirectional	Dynamic obstacle avoidance
TEB Controller	Differential, Omnidirectional, Ackermann, Legged	Dynamic obstacle avoidance
RPP controller	Differential, Ackermann, Legged	Exact path following
MPPI controller	Differential, Ackermann, Legged, Omnidirectional	Modern MPC controller
VP controller	Differential, Ackermann, Legged	High speed path tracking

All of these algorithms work for both circular and non-circular robots.

Example Configuration

controller_server:
  ros__parameters:
    controller_plugins: ["FollowPath"]
    FollowPath:
       plugin: "dwb_core::DWBLocalPlanner"

Shown above is a sample basic configuration of the controller server. The list of mapped names for controller plugins are defined in the controller_plugins parameter. Similar to the planner server, each namespace defined in the controller_plugins (FollowPath in our example) must define the type of plugin it will use in the plugin parameter. Additional configurations must also be made for the selected algorithm in the namespace. Please see the Configuration Guide for more details.

Note

The planner and controller servers, along with the other servers of Nav2, are launched in ROS 2 through lifecycle nodes. Lifecycle nodes allow for easier bringup and teardown of the servers. Lifecycle node management will be discussed in the next tutorial.

Conclusion

In this tutorial, we have discussed the roles and configuration of Nav2’s planner and controller servers. To summarize, these servers host a map of one or more algorithm plugins which are selected depending on your robot’s structure and surroundings. We also described a few of the available plugins for the planner and controller servers to help you identify which plugins are suitable for your robot. Lastly, we also provided some simple configuration examples to show how these plugins are instantiated on the servers. You can refer to the configuration guide of the algorithm plugin you will select for more details on its configuration parameters.