Navigation algorithms are implemented in Nav2 via plugins. Those plugins run on ROS2 action servers: the planner, controller, behavior servers and so on.
The planner server is responsible for computing the robot's path. It is possible to use multiple plugins together, for example, one plugin will be responsible for creating a short range path between two close points, while the other will create a long path between remote points.
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 we saw in nav2_params.yaml, both planner and controller servers can have a list of plugins, and choose the one for a particular task. For example, one plugin can be used in narrow spaces, another one to drive on the street and so on.
The choice (which plugin to use) can be made using the behavior tree of our navigation system or application 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.
| Plugin Name | Supported Robot Types |
| NavFn Planner
Smac Planner 2D Theta Star Planner |
Circular Differential,
Circular Omnidirectional |
| 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'
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.
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.
Another 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.
The last 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.
| 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 |
Example Configuration:
controller_server:
ros__parameters:
controller_plugins: ["FollowPath"]
FollowPath:
plugin: "dwb_core::DWBLocalPlanner"
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 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.
The planner and controller servers, along with the other servers of Nav2, are launched in ROS2 through lifecycle nodes. Lifecycle nodes allow for easier bringup and teardown of the servers.