Page tree
Skip to end of metadata
Go to start of metadata

The navigation move_base node

move_base is a node from the navigation package that implements the necessary parts to drive a mobile platform from a starting position to a goal position.

The basic structure is shown in the picture below:

move_base relies on input data from the environment like a map and the current position of the mobile platform within the map as well as sensor readings from the current situation around the platform.

To control the mobile platform, move_base sends commands to the /cmd_vel topic with type geometry_msgs/Twist.

Within move_base there are different logical areas with different responsibilities:

  • Global Planner
  • Global Costmap
  • Local Planner
  • Local Costmap
  • Recovery Behaviors

These logical areas are implemented as plugins and can be individually selected by modifying the "neo_mp[...]/configs/navigation/move_base/move_base.launch" file.

By default we are using the NavfnROS global planner and the NeoLocalPlanner local planner (see neo_local_planner).

The full documentation can be found here:

Recovery Behavior

If the mobile platform gets stuck, move_base needs to know what should be done.

This procedure is named Recovery Behavior.

There is a number of steps on how the mobile platform tries to get unstuck, before aborting the goal completely.

  • First, obstacles outside of a user-specified region will be cleared from the robot's map.
  • Next, if possible, the robot will perform an in-place rotation to clear out space.
  • If this too fails, the robot will more aggressively clear its map, removing all obstacles outside of the rectangular region in which it can rotate in place.
  • This will be followed by another in-place rotation.
  • If all this fails, the robot will consider its goal infeasible and notify the user that it has aborted.

A graphical overview is shown in the image below:

The actions taking place in the different steps can be changed by writing your own Recovery Behavior using the pluginlib.

Starting move_base + localization

First we need to start move_base and the AMCL localization on the platform:

roslaunch neo_mp_400 navigation_basic_amcl.launch
roslaunch neo_mp_500 navigation_basic_amcl.launch
roslaunch neo_mpo_500 navigation_basic_amcl.launch
roslaunch neo_mpo_700 navigation_basic_amcl.launch

Since April 2020 we also offer our own neo_localization package which provides an alternate to AMCL:

roslaunch neo_mp_400 navigation_basic_neo.launch
roslaunch neo_mp_500 navigation_basic_neo.launch
roslaunch neo_mpo_500 navigation_basic_neo.launch
roslaunch neo_mpo_700 navigation_basic_neo.launch

Please choose the correct package name depending on your platform.

This can be done automatically upon startup by adding the command to the ~/ script.

Make sure a map has been created and selected first, see Creating a Map.

Visualization with RViz

To visualize the whole move_base process we supply predefined RViz configurations, which can be loaded as follows:

roslaunch neo_mp_400 rviz_navigation.launch
roslaunch neo_mp_500 rviz_navigation.launch
roslaunch neo_mpo_500 rviz_navigation.launch
roslaunch neo_mpo_700 rviz_navigation.launch

Please choose the correct package name depending on your platform.

Visualization is best done on a Client PC, see Getting Started for how to setup the connection.

Initializing the Localization

Before we can send goals to move_base we first have to initialize the localization, so the platform can find it's starting position on the map.

There are multiple ways to do this, like for example publishing a pose on the /initialpose topic.

However the easiest way for testing is to use the RViz 2D Pose Estimate feature as shown below:

First we click the "2D Pose Estimate" button to define the pose by clicking and holding the left mouse button (to set the position) and then dragging it to define the orientation.

Make sure the "Fixed Frame" is set to "map", otherwise it will not work.

After doing this we can check how good our estimate is by comparing the laser points with the map. This process can be repeated any number of times.

Note: The initial pose does not have to be perfect, it is sufficient to be within ~50 cm of the true position and within ~20 degrees of the true orientation.

Once the platform moves it will correct the initial localization estimate. It will not do so while standing still however.

More information regarding the localization can be found here:

Global Localization

Another way to initialize the localization is to attempt a global localization step. This can be initiated by calling the /global_localization service as follows:

rosservice call /global_localization

Define Goal Position(s)

Goal Positions are the locations inside the known environment, that move_base should navigate towards.

These goals can be sent to move base in different formats and by different methods.

Using ROS-Topic

The topic move_base_simple/goal is one of the options to send a goal to move_base.

The format of the message used is geometry_msgs/PoseStamped.

Using RViz

The easiest way to define a goal for move_base is to use the 2D Nav Goal option in RViz and just click and drag on the goal position and define the orientation.

This method is recommended for testing and monitoring.

Make sure the "Fixed Frame" is set to "map", otherwise it will not work.

Using the move_base Action Client

Step by step tutorial can be found here:

Using the neo_goal_sequence_driver

The neo_goal_sequence_driver implements the functionality to navigate a sequence of goals using the move_base action client.

The tutorial can be found here.

  • No labels