Size: 19301
Comment:
|
Size: 18379
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 69: | Line 69: |
=== 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 ==== |
=== 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 [[http://wiki.ros.org/ROS/NetworkSetup/|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. 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: {{https://github.com/hasauino/storage/blob/master/pictures/framesTf.png?raw=true}} === 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 === |
Line 75: | Line 85: |
==== A mapping node ==== The robot should have a local map generated from the [[http://wiki.ros.org/gmapping/|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 [[http://wiki.ros.org/ROS/NetworkSetup/|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: {{https://github.com/hasauino/storage/blob/master/pictures/framesTf.png?raw=true}} ==== 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 ==== |
=== A mapping node === |
Line 98: | Line 88: |
==== A map merging node ==== There should be a node that merges all the local maps into one global map. You can use the [[http://wiki.ros.org/multirobot_map_merge/|"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 [[https://github.com/hasauino/m-explore|here]] |
=== 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 [[http://wiki.ros.org/multirobot_map_merge/|this]] package. |
Line 363: | Line 352: |
Only released in EOL distros:
Package Summary
A ROS package that implements a multi-robot RRT-based map exploration algorithm. It also has the image-based frontier detection that uses image processing to extract frontier points
- Maintainer status: maintained
- Maintainer: Hassan Umari <oh91 AT windowslive DOT com>
- Author: Hassan Umari
- License: MIT
- Source: git https://github.com/hasauino/rrt_exploration.git (branch: indigo-devel)
Package Summary
A ROS package that implements a multi-robot RRT-based map exploration algorithm. It also has the image-based frontier detection that uses image processing to extract frontier points
- Maintainer status: maintained
- Maintainer: Hassan Umari <oh91 AT windowslive DOT com>
- Author: Hassan Umari
- License: MIT
- Source: git https://github.com/hasauino/rrt_exploration.git (branch: kinetic-devel)
Contents
If you are using this package in your research work, please cite this paper.
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 girds 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.
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. 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:
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
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.
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:
Tutorials
Tutorials on how to use the package are listed here.
Feedback
To report a bug, or suggest an enhancement, please create a Github issue here.
If you have a question, please post it on ROS answers, make sure your question is tagged by rrt_exploration so I get notified.
Acknowledgements & Citation
This package was written during my master's thesis at the American University of Sharjah. My thesis advisor is Dr. Shayok Mukhopadhyay.
This work has been published on IROS. If you are using this package, please cite our paper.
@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},}
Thesis title: "Multi-Robot Map Exploration Based on Multiple Rapidly-Exploring Randomized Trees"