Only released in EOL distros:   indigo kinetic

If you are using this package in your research work, please cite these papers:

• Multi-robot Map Exploration Based on Multiple Rapidly-Exploring Randomized Trees.

• Autonomous robotic exploration based on multiple rapidly-exploring randomized trees.

Introduction

"rrt_exploration" is a ROS package that implements a multi-robot map exploration algorithm for mobile robots. It is based on the Rapidly-Exploring Random Tree (RRT) algorithm. It uses occupancy grids as a map representation.The package has 5 different ROS nodes:

• Global RRT frontier point detector node.
• Local RRT frontier point detector node.
• OpenCV-based frontier detector node.
• Filter node.
• Assigner node.

This is a playlist showing the package running on real robots and on Gazebo simulation:

Package Requirements

The package has been tested on both ROS Kinetic and ROS Indigo, it should work on other distributions like Jade. The following requirements are needed before installing the package:

1- You should have installed a ROS distribution (indigo or later. Recommended is either indigo or kinetic).

2- Created a workspace.

3- Installed the "gmapping" ROS package, you can do that by typing the following command in the terminal:

sudo apt-get install ros-$ROS_DISTRO-gmapping

4- Install ROS navigation stack. You can do that with the following command:

sudo apt-get install ros-$ROS_DISTRO-navigation

5- You should have Python 2.7. (it was not tested on Python 3).

6-You should have/install the following python modules:

-OpenCV (cv2)

sudo apt-get install python-opencv

-Numpy

sudo apt-get install python-numpy

-Sklearn

sudo apt-get install python-scikits-learn

Hardware Requirements

A mobile robot that can be used with the navigation stack (publishes /odom and /tf. Receives velocity commands ..). The robot must also be equipped with a laser scanner or any sensor that publishes laser scan message (sensor_msgs/LaserScan).

Installation

Download the package and place it inside the /src folder in your workspace. And then compile using catkin_make.

Setting Up Your Robots

This package provides an exploration strategy for single or multiple robots. However, for it to work, you should have set your robots ready using the navigation stack. And each robot should run the "slam_gmapping" node from the gmapping package.

Additionally, the robots must be set and prepared as follows.

Note: If you want to quickly run and test the package, you can try out the rrt_exploration_tutorials package which provides Gazebo simulation for single and multiple robots, you can use it directly with this package.

Single Robot Setup

If you are using this package for exploration using a single robot, then you will first need the following:

Setting up the navigation stack on the robot

The move_base_node node, which brings up the navigation stack on the robot, must be running. This package (rrt_exploration) generates target exploration goals, each robot must be able to receive these points and move towards them. This is why the navigation stack is needed. Additionally, each robot must have a global and local cost maps. All of these are proivded from the move_base_node.

A mapping node

The robot should have a local map generated from the gmapping package.

Multiple Robots Setup

Robots Network

For the multi-robot configuration, the package doesn't require special network configuration, it simply works by having a single ROS master (can be one of the robots). So on the other robots, the ROS_MASTER_URI parameter should be pointing at the master's address. For more information on setting up ROS on multiple machines, follow this link.

Robot's frame names in tf

All robot's frames should be prefixed by its name. Naming of robots starts from "/robot_1", "/robot_2", "/robot_3", .. and so on. So for robot_1, the frames in the tf tree should look like this:

Robot's node and topic names

All the nodes and topics running on a robot must also be prefixed by its name. For robot 1, node names should look like: /robot_1/move_base_node, /robot_1/slam_gmapping.

And topic names should be like: /robot_1/odom, /robot_1/map, /robot_1/base_scan, ..etc.

Setting up the navigation stack on the robots

The move_base_node node, which brings up the navigation stack on the robot, must be running. This package (rrt_exploration) generates target exploration goals, each robot must be able to receive these points and move towards them. This is why the navigation stack is needed. Additionally, each robot must have a global and local cost maps. All of these are proivded from the move_base_node.

A mapping node

Each robot should have a local map generated from the gmapping package.

A map merging node

There should be a node that merges all the local maps into one global map. You can use the "multirobot_map_merge" package developed by Jiri Horner.

• The "multirobot_map_merge" has been updated, some users have reported problems getting correct map merging. However, the old version still works fine. You can get the forked old version here

Nodes

There are 3 types of nodes; nodes for detecting frontier points in an occupancy grid map, a node for filtering the detected points, and a node for assigning the points to the robots. The following figure shows the structure:

global_rrt_frontier_detector

Subscribed Topics

• Topic name is defined by the ~map_topic parameter. It is the topic name on which the node will receive the map.

• The global_rrt_frontier_detector node requires that the region to be explored is defined. This topic is where the node recieves five points that define the region. The first four points are four defining a square region to be explored, and the last point is the tree starting point. After publishing those five points on this topic, the RRT will start detecting frontier points. The five points are intended to be published from Rviz using button.

Published Topics

• The topic on which the node publishes detected frontier points.

• On this topic, the node publishes line shapes to visualize the RRT using Rviz.

Parameters

• This parameter defines the topic name on which the node will receive the map.

• This parameter controls the growth rate of the RRT that is used in the detection of frontier points, the unit is in meters. This parameter should be set according to the map size, a very large value will cause the tree to grow faster and hence detect frontier points faster, but a large growth rate also implies that the tree will be missing small corners in the map.

local_rrt_frontier_detector

Subscribed Topics

• Topic name is defined by the ~map_topic parameter. It is the topic name on which the node will receive the map.

• The lobal_rrt_frontier_detector also subscribes to this topic similar to the global_rrt_frontier_detector.

Published Topics

• The topic on which the node publishes detected frontier points.

• On this topic, the node publishes line shapes to visualize the RRT using Rviz.

Parameters

• The frame attached to the robot. Every time the tree resets, it will start from the current robot location obtained from this frame.

• This parameter defines the topic name on which the node will receive the map.

• This parameter controls the growth rate of the RRT that is used in the detection of frontier points, the unit is in meters. This parameter should be set according to the map size, a very large value will cause the tree to grow faster and hence detect frontier points faster, but a large growth rate also implies that the tree will be missing small corners in the map.

frontier_opencv_detector

Subscribed Topics

• Topic name is defined by the ~map_topic parameter. It is the topic name on which the node will receive the map.

Published Topics

• The topic on which the node publishes detected frontier points.

• On this topic, the node publishes detected points to be visualized using Rviz.

Parameters

• This parameter defines the topic name on which the node will receive the map.

filter

Subscribed Topics

• Topic name is defined by the ~map_topic parameter. It is the topic name on which the node will receive the map.

• where x (in robot_x) refers to robot's number.
  The filter node subscribes for all the costmap topics of all the robots, the costmap is required therefore. Normally, costmaps should be published by the navigation stack (after bringing up the navigation stack on the robots, each robot will have a costmap). For example, if n_robots=2, the node will subscribe to: robot_1/move_base_node/global_costmap/costmap and robot_2/move_base_node/global_costmap/costmap. The costmaps are used to delete invalid points.
  Note: Namespaces of all the nodes corresponding to a robot should start with robot_x. Again x is the robot number.

• Topic name is defined by the ~goals_topic parameter. It's the topic on which the filter node receives detected frontier points.

Published Topics

• The topic on which the filter node publishes the received frontier points for visualiztion on Rviz.

• The topic on which the filter node publishes only the filtered frontier points for visualiztion on Rviz.

• All the filtered points are sent as an array of points to the assigner node on this topic.

Parameters

• This parameter defines the topic name on which the node will recieve the map. The map is used to know which points are no longer frontier points (old points).

• Any frontier point that has an occupancy value greater than this threshold will be considered invalid. The occupancy value is obtained from the costmap.

• The information radius used in calculating the information gain of frontier points.

• defines the topic on which the node receives detcted frontier points.points.

• Number of robots.

@INPROCEEDINGS{8202319,
author={H. Umari and S. Mukhopadhyay},
booktitle={2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS)},
title={Autonomous robotic exploration based on multiple rapidly-exploring randomized trees},
year={2017},
volume={},
number={},
pages={1396-1402},
keywords={},
doi={10.1109/IROS.2017.8202319},
ISSN={},
month={Sept},}