Now that a laser scanner has been added to the robot base, we shall configure the move_base server, which will help the robot navigate autonomously with ROS packages. What is move_base? Let's consider that the robot moves autonomously in an environment through a known map. The map consists of information, such as obstructions, walls, or tables (called costs in robotics), that are known to us. This known information is treated as global information.

While the robot tries to move around with this global information, the robot might be introduced to sudden dynamic changes in the environment, such as changes in the position of a chair or dynamic movement such as a person walking. These changes are treated as local information. In simple terms, global information is with respect to the environment and local information is with respect to the robot. move_base is a complicated (in terms of code) yet simple (in terms of understanding) node that helps in linking together global and local information to accomplish a navigation task. move_base is an ROS action implementation. When given a goal, the robot base would try to reach that goal. A simple representation of move_base is shown in the following diagram:

From the preceding diagram, it is evident that if the robot base receives a goal command, the move_base server understands the goal and gives out a series of command velocities to direct the robot toward the goal. For this, the robot base would need to be defined with certain parameters that are defined in the following YAML files:

• costmap_common_params.yaml
• global_costmap_params.yaml
• local_costmap_params.yaml
• base_local_planner.yaml

Now, let's follow these steps to configure the navigation stack:

1. Let's create a navigation package and add these files to them:

$ cd ~/chapter_5_ws/src
$ catkin_create_pkg navigation
$ cd navigation
$ mkdir config
$ cd config
$ gedit costmap_common_params.yaml

2. Copy the following code into the costmap_common_params.yaml file:

footprint: [[0.70, 0.65], [0.70, -0.65], [-0.70, -0.65], [-0.75, 0.65]]
observation_sources: laser_scan_sensor
laser_scan_sensor:
 sensor_frame: laser_link
 data_type: LaserScan
 topic: scan
 marking: true
 clearing: true

Since our robot is of rectangular geometry, we have defined its footprint as coordinate limits. Since we are using a laser scanner, we provide the necessary information.

3. Now, save the file, close it, and create another file and name it global_costmap_params.yaml:

$ gedit global_costmap_params.yaml

Copy the following code into it:

global_costmap:
 global_frame: map
 robot_base_frame: base_link
 static_map: true

In general, our frame of reference for movement is with respect to the world. In the case of the robot, it is with respect to the environment that is defined as a map. It is the robot's base_link that geometrically moves with respect to the map.

4. Now, save the file, close it, and create another file and name it local_costmap_params.yaml:

$ gedit local_costmap_params.yaml

Copy the following code into it:

local_costmap:
 global_frame: odom
 robot_base_frame: base_link
 rolling_window: true

As we mentioned earlier, local information is with respect to the robot. Hence, our global_frame of reference is the robot's odom frame. The local cost in the environment is updated only within a certain footprint, which could be defined as a rolling_window parameter.

Now that we have the necessary information, let's go about mapping and localizing our robot in the given environment.