Understanding the Navigation Stack - UTRA-ART/Caffeine GitHub Wiki

Written by: Erick Mejia Uzeda

The Navigation Stack serves to autonomously plan and navigate the robot to a specified navigation goal (move_base_simple/goal). As shown in the figure below, it requires the following inputs:

• tf tree
• odometry
• sensors (eg. Lidar, Camera)
• base controller (converts cmd_vel to motor commands)

Optionally, a static map can be provided. This will be computed by a SLAM package (RTAB).

In using the Navigation Stack as is, there are 4 ROS APIs that are of interest:

• move_base
• costmap_2d
• navfn
• base_local_planner

I recently found out about move_base_flex which is backward compatible with move_base and has more flexibility than it. We may switch to this if we need the additional flexibility, though our main goal is getting everything to work.

move_base

Serves as the high level interface to the navigation stack. It has parameters in which we can select which planner plugins to use. By looking through the documentation, the default global planner is navfn and the default local planner is base_local_planner.

Note: we can change which plugins we need if the default do not suit our needs (here are some options: (global) http://wiki.ros.org/global_planner, (local) http://wiki.ros.org/dwa_local_planner, (local) http://wiki.ros.org/teb_local_planner).

Likewise we can specify some recovery behaviours or use a plugin for that as well. Other than specifying plugins, the other parameters of interest concern setting controller and planner update rates, modifying oscillatory behaviour and specifying the number of retries for the planner. Lastly, move_base provides services for feedback, status and result of the current navigation session.

costmap_2d

Costmaps serve as the internal representation of the environment used for navigation planning. The navigation stack creates 2 of them, one for global planning and the other for local planning. From the documentation most parameters allow us to specify the appropriate costmap dimensions and update/publish rates.

Note: rolling_window should in general only be used for a local costmap.

Not shown on the main page, there is an observation_sources parameter which allows us to define which sensors add (mark) and clear obstacle added to costmaps.

Lastly, it is possible to define custom costmap layers and use them with the navigation stack. Currently I do not have the details but we can potentially use an extra costmap layer to add obstacles generated from CV or for elevation mapping if going over a ramp is impossible for the navigation stack as is.

Note: another option we used last year for CV obstacles was updating the occupancy grid generated by RTAB Map before feeding it to the Navigation Stack.

navfn

Performs global path planning using the global_costmap. The available parameters are few, mainly concerning allowing the traversal of unknown spaces (probably want this true), goal planning tolerance and window size for planning.

base_local_planner

Performs local path planning using both information about the global plan and the local_costmap. As the main sections highlight, there are parameters for Target Scoring - will enable some degree of trajectory optimization, Goal Tolerance and Robot Configuration - set velocity and acceleration constraints.

---

Here is another Navigation Stack tuning guide: http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide. It provides a more in-depth look into how one would go about tuning. It also links to this paper, from which the prior ROS wiki is based on.