A guide to implement ROS Navigation Stack on any robot

Introduction

Navigation is one of the most crucial goals for mobile robots. It is also one of the complex tasks to accomplish. A tremendous amount of work has already been completed in this area. One such off-the-shelf tool is the navigation stack in Robotic Operating System (ROS) http://wiki.ros.org/navigation. However, every robot is different, thus making it a non trivial task to use the existing package as is. Several steps are involved in configuring the available package to work for the customized robot and the environment. This tutorial will explain step by step how to configure the ROS navigation stack for your robot.

At a very high level, there are four major steps involved in navigation. Those are; mapping, localization, path planning and obstacle avoidance. So, let’s dive into what they mean, how they differ from each other and mainly how to implement them on your robot.

It is a lengthy tutorial! The organization of the tutorial is as follows. The first section explains the basics and the pre-requisites required for implementing the tutorial. The second section/page is about Mapping and provides details about how to create a 2D map. The third section/page is about Localization and explains how to use the navigation stack for localizing a robot in a given map. The last and the most important section is about Path Planning.

Note 1: For this tutorial, I used ROS Melodic, Ubuntu 18.04 and Gazebo 9.0.

Note 2: This tutorial is focused on 2D maps. If you are interested in creating 3D maps. please see rtabmap package.

Before we jump into using the ROS navigation package, it is important to review and meet the prerequisites of making sure the robot is ready and the environment is properly set up.So, let’s move on to the first section of the tutorial.

Prerequisites required for using the ROS navigation stack

It is assumed that the reader is familiar with basics of ROS. Below are the inputs and outputs to the navigation stack that the robot must be capable of handling before the navigation stack can be implemented. See this link for further details.

Inputs to the navigation stack

• Transforms: The robot must be publishing transforms (the relationship between different links of the robot) on the /tf topic. This is typically published by robot_state_publisher.
• Odometry: The robot must be publishing the odometry data. This is typically published on the /odom topic.
• Sensor data: The robot must be publishing sensor data on the topic that publishes lidar/laser data.
• Map: The map of the environment in which to navigat must be published on a /map topic. NOTE: We assume that we don’t have a map of the environment for this tutorial. Therefore, this topic is not yet being published.

Outputs of the navigation stack

• cmd_vel (geometry_msgs/Twist message). We must have a topic that is capable of receiving geometry_msgs/Twist messages. This is typically received on the /cmd_vel topic.

ROS packages

Several ROS packages are needed and they will be installed step by step as needed. At this time, we just need to install the following ROS package. Be sure to install the right package for the ROS version on your machine.

$ sudo apt-get install ros-melodic-navigation

How to check if these prerequisites are met by your robot?

Firstly, we should know the configuration of our robot. This can be seen through a transform tree which shows how various links of the robot are connected to each other. Below is the tf tree for my robot. This can be obtained by running the command line utility tf view_frames

As can be seen, it shows that we have a odometry connected to base_link of the robot and there are several other links connected to the base_link. The fact that we got this tree indicates that data is being published on the /tf topic. So, this is a good sign so far.

Next, we will check each of the topics mentioned in the Inputs/Outputs section above and make sure they are sending (publishing) or receiving (subscribing) to the data we want. So, let’s check the following topics. Note that the topic names could be different for your robot bu the message type subscribed/published must match below.

• Check the topic providing transforms. Here, the topic name is /tf topic

• Check the topic providing odometry data. Here topic name is /odom topic

• Check the topic publishing lidar data. In my case ,the topic name is /hydra_one/laser/scan topic

• Check the topic that will be receiving geometry_msg/Twist commands. In my case, the topic name is /cmd_vel topic

Now that we have verified that we have met the prerequisites, we will go through the first step of navigation, which is to make the map of the environment. This step is called mapping. So, let’s get to the core.

See you on the next page!