Repository Summary
Checkout URI | https://github.com/hasauino/rrt_exploration.git |
VCS Type | git |
VCS Version | indigo-devel |
Last Updated | 2023-11-25 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
rrt_exploration | 1.0.0 |
README
rrt_exploration
It 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 girds as a map representation.The packgae has 5 different ROS nodes:
-
Global RRT frontier point detector node.
-
Local RRT frontier point detector node.
-
Filter node.
-
Assigner node.
-
opencv-based frontier detector node.
This is a Youtube playlist showing the package running on single/multiple robots, using real setup (Kobuki robots) and simulation (Gazebo).
Note: This package was written during my master’s thesis at the American University of Sharjah. My thesis advisor is Dr. Shayok Mukhopadhyay. 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.
1. 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: on Ubuntu, and if you are running ROS Kinectic, you can do that by typing the following command in the terminal:
$ sudo apt-get install ros-kinetic-gmapping
4- Install ROS navigation stack. You can do that with the following command (assuming Ubuntu, ROS Kinetic):
$ sudo apt-get install ros-kinetic-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
2. Installation
Download the package and place it inside the
``` folder in your workspace. And then compile using
```catkin_make
```.
## 3. 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](http://wiki.ros.org/navigation). 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](https://github.com/hasauino/rrt_exploration_tutorials) package which provides Gazebo simulation for single and multiple robots, you can use it to directly with this package.
### 3.1. 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](http://wiki.ros.org/ROS/NetworkSetup) link.
### 3.2. 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. Even if you are using the package for single robot, robot’s frames should be prefixed by its name (i.e. /robot_1). So for robot_1, the frames in the
tf
tree should look like this:
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 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.
3.4. 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
.
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 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:
4.1. global_rrt_frontier_detector
The
global_rrt_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. In multi-robot configuration, it is intended to have only a single instance of this node running.
Running additional instances of the global frontier detector can enhance the speed of frontier points detection, if needed.
4.1.1. Parameters
-
~map_topic
(string, default: “/robot_1/map”): This parameter defines the topic name on which the node will recieve the map. -
~eta
(float, default: 0.5): 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.
4.1.2. Subscribed Topics
-
The map (Topic name is defined by the
~map_topic
parameter) (nav_msgs/OccupancyGrid) -
clicked_point
(geometry_msgs/PointStamped Message): Theglobal_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 usingbutton.
4.1.3. Published Topics
File truncated at 100 lines see the full file
CONTRIBUTING
Repository Summary
Checkout URI | https://github.com/hasauino/rrt_exploration.git |
VCS Type | git |
VCS Version | kinetic-devel |
Last Updated | 2023-11-25 |
Dev Status | MAINTAINED |
CI status | No Continuous Integration |
Released | UNRELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Packages
Name | Version |
---|---|
rrt_exploration | 1.0.0 |
README
rrt_exploration
It 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 girds as a map representation.The packgae has 5 different ROS nodes:
-
Global RRT frontier point detector node.
-
Local RRT frontier point detector node.
-
Filter node.
-
Assigner node.
-
opencv-based frontier detector node.
This is a Youtube playlist showing the package running on single/multiple robots, using real setup (Kobuki robots) and simulation (Gazebo).
Note: This package was written during my master’s thesis at the American University of Sharjah. My thesis advisor is Dr. Shayok Mukhopadhyay. 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.
1. 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: on Ubuntu, and if you are running ROS Kinectic, you can do that by typing the following command in the terminal:
$ sudo apt-get install ros-kinetic-gmapping
4- Install ROS navigation stack. You can do that with the following command (assuming Ubuntu, ROS Kinetic):
$ sudo apt-get install ros-kinetic-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
2. Installation
Download the package and place it inside the
``` folder in your workspace. And then compile using
```catkin_make
```.
## 3. 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](http://wiki.ros.org/navigation). 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](https://github.com/hasauino/rrt_exploration_tutorials) package which provides Gazebo simulation for single and multiple robots, you can use it to directly with this package.
### 3.1. 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](http://wiki.ros.org/ROS/NetworkSetup) link.
### 3.2. 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. Even if you are using the package for single robot, robot’s frames should be prefixed by its name (i.e. /robot_1). So for robot_1, the frames in the
tf
tree should look like this:
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 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.
3.4. 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
.
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 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:
4.1. global_rrt_frontier_detector
The
global_rrt_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. In multi-robot configuration, it is intended to have only a single instance of this node running.
Running additional instances of the global frontier detector can enhance the speed of frontier points detection, if needed.
4.1.1. Parameters
-
~map_topic
(string, default: “/robot_1/map”): This parameter defines the topic name on which the node will recieve the map. -
~eta
(float, default: 0.5): 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.
4.1.2. Subscribed Topics
-
The map (Topic name is defined by the
~map_topic
parameter) (nav_msgs/OccupancyGrid) -
clicked_point
(geometry_msgs/PointStamped Message): Theglobal_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 usingbutton.
4.1.3. Published Topics
File truncated at 100 lines see the full file