herolab-uga / cqlite

CQLite: Coverage-biased Q-Learning Lite for Efficient Multi-Robot Exploration
MIT License
13 stars 2 forks source link
map-merging mobile-robots multi-robot-cooperation multi-robot-exploration multi-robot-systems navigation reinforcement-learning robot-exploration robotics ros

CQLite

It is a ROS package that implements a CQLite: Coverage-biased Q-Learning Lite for Efficient Multi-Robot Exploration algorithm for mobile robots. It uses occupancy grid as a map representation.

The following figure shows the oevrview of CQLite exploration:

alt text

About package repository

The packgae has 5 different ROS nodes:

1. Requirements

The package has been tested on both ROS Noetic and ROS Melodic for both simulated and hardware Turtlebot3 robot (burger). The following requirements are needed before installing the package:

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

2- Created a workspace.

3- Install the "gmapping" ROS package: on PC and each robot, as:

$ sudo apt-get install ros-noetic-gmapping

4- Install the ROS navigation stack. You can do that with the following command (assuming Ubuntu, ROS Kinetic):

$ sudo apt-get install ros-noetic-navigation

5- You should have Python 3.6+

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

2. Installation

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

3. Setting Up Your Robots

This package provides an exploration strategy for cooperative robot. However, for it to work, you should have set your robots ready using the navigation stack. Additionally, the robots must be set and prepared as follows.

3.1. Robots Network

For the cooperative robotic 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.

3.2. Robot's frame names in tf

All robot's frames should be prefixed by its name. Naming of robots starts from "/tb3_0", "/tb3_1", ... and so on.

3.3. Robot's node and topic names

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

And topic names should be like: /tb3_0/odom, /tb3_0/map, /tb3_0/scan, ..etc.

3.5. A mapping node

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

3.6. A map merging node

For the multi-robot case, there should be a node that merges all the local maps into one global map. You can use this package.

4. Nodes

There are 4 types of nodes; nodes for detecting frontier points in an occupancy grid map, a node for filtering the detected points, a node for assigning the points to the robots, and a node for planning path for robot. The following figure shows the system arcitecture of CQLite:

alt text

4.1. global_frontier_detector

The global_frontier_detector node takes an occupancy grid and finds frontier points (which are exploration targets) in it. It publishes the detected points so the filter node can process.

4.1.1. Parameters

4.1.2. Subscribed Topics

4.1.3. Published Topics

4.2. local_frontier_detector

This node is similar to the global_frontier_detector. However, it works differently, as a connected graph here keeps resetting every time a frontier point is detected. This node is intended to be run along side the global__frontier_detector node, it is responsible for fast detection of frontier points that lie in the close vicinity of the robot.

All detectors will be publishing detected frontier points on the same topic (/detected_points).

4.2.1. Parameters

4.2.2. Subscribed Topics

4.3. frontier_opencv_detector

This node is another frontier detector, but it is not based on CQLite. This node uses OpenCV tools to detect frontier points. It is intended to be run alone, and only one instance should be run.

Originally this node was implemented for comparison against the standard frontier detectors. Running this node along side the CQLite detectors (local and global) may enhance the speed of frontier points detection.

4.3.1. Parameters

4.3.2. Subscribed Topics

4.3.3. Published Topics

4.4. CQLite Filter

The filter nodes receives the detected frontier points from all the detectors, filters the points, and passes them to the assigner node to command the robots. Filteration includes the delection of old and invalid points, and it also dicards redundant points.

4.4.1. Parameters

4.4.2. Subscribed Topics

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).

4.4.3. Published Topics

4.5. CQLite Planner

This node recieve target exploration goals, which are the filtered frontier points published by the filter node, and commands the robots accordingly. The assigner node commands the robots through the move_base. This is why you have bring up the navigation stack on your robots.

4.5.1. Parameters

4.5.2. Subscribed Topics

4.5.3. Published Topics

The assigner node does not publish anything. It sends the assigned point to the move_base using Actionlib.

5. Launch

Run the CQLite package after installation on a robot and source bash and /devel/setup.bash file:

$ roslaunch cqlite cqlite_exploration.launch

Core contributors

Heterogeneous Robotics (HeRoLab)

Heterogeneous Robotics Lab (HeRoLab), School of Computing, University of Georgia.

For further information, contact Ehsan Latif ehsan.latif@uga.edu or Dr. Ramviyas Parasuraman ramviyas@uga.edu

http://hero.uga.edu/