ROS Index
|
micros_mars_task_alloc package from micros_mars_task_alloc repomicros_mars_task_alloc |
|
|
Package Summary
| Tags | No category tags. |
| Version | 0.0.5 |
| License | BSD |
| Build type | CATKIN |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/liminglong/micros_mars_task_alloc.git |
| VCS Type | git |
| VCS Version | master |
| Last Updated | 2019-07-02 |
| Dev Status | DEVELOPED |
| CI status | Continuous Integration |
| Released | RELEASED |
| Tags | No category tags. |
| Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Minglong Li
Authors
- Minglong Li
- Xiaodong Yi
- Yanzhen Wang
- Zhongxuan Cai
micros_mars_task_alloc
A cooperative robot team is a multi-agent robot system in essence. In the team, each robot can be seen as an intelligent agent. This is a ROS package used for the mult-task allocation in a robot team. It is based on Multi-Agent theory and is an abstraction of ALLIANCE model. We have developed a prototype system by python hitherto. The nodelet-based C++ version is being developed and will be released in short time periods.
ALLIANCE model
ALLIANCE model is a natural extension of Brooks’ famous subsumption model, which is applicable to fault-tolerant cooperative multi-robot systems. As shown in the figure above, each single robots in the cooperative team should obey a same ALLIANCE model. The model is composed of several behavior sets and behavior layers. Both of them are implemented by following the subsumption model. The behavior sets correspond to some high-level task-achieving functions. The module named ‘motivational behavior’ can activate the behavior sets to select a task adaptively. The ‘F’ circles in the figure above connect the output of each motivational behavior with the output of its corresponding behavior set indicating that a motivational behavior either allows all or none of the outputs of its behavior set to pass through to the robot’s actuators. The lower several layers of the ALLIANCE architecture composed a subsumption model, we can also use the subsumption method to coordinate the behavior inside the behavior sets. Note that the motivational behavior needs to receive the sensor information. Besides, the output of some behavior set can also be used as the sensor information, which is called `virtual sensors’ in ALLIANCE model(imaginary lines in the figure above).
General Overview
At the bottom layer, we encapsulate the ROS communication and python multi-process libraries into ROS node classes. By inheriting the ROS node classes, one may implement Function Units and connect them (i.e. establish message passing channels among them) to construct Behavior Layers quite conveniently. To do that, one could focus only on application logic, leaving others to the framework. Besides, several ALLIANCE elements including Inhibitors, Suppressors and Forwarders (i.e. the ‘I’, ‘S’ and ‘F’ circles) are all available, which can be directly put between Behavior Layers to construct Behavior Sets. A Motivational Behavior template is also available for developers. Once again, one could focus only on the parameters of the Motivational Behavior, others including the following three aspects are already handled by the framework:
- The fault-tolerant adaptive multi-task selection algorithm that incorporates the use of mathematically-modeled motivations.
- The interconnected communication among all motivational behaviors in the team robots by using ROS broadcasting mechanism.
- By specifying the forwarder name as a parameter, the interaction with the behavior set can be built automatically.
Finally, Behavior Layers and Behavior Sets can aggregate the Robots.
UML Graph
The UML graph shows the overall software architecture of the package.
Main APIs
The main APIs are shown below. The parameter names present the parameter function clearly. As mentioned above, each motivational behavior is responsible for activating a forwarder to forward the messges sent from the attached behavior set. So the ‘MotivationalBehavior’ class should have a parameter named ‘forwarder_name’ indicating that which forwarder it activates. The paramters of the topics in ‘Forwarder’ indicate which behavior set they attach.
Inhibitor(inhibitor_name, topic_in, in_out_msg_type, topic_out, inhibiting_topic, inhibiting_msg_type)
suppressor(suppressor_name, topic_in, in_out_msg_type, topic_out, suppressing_topic, suppressing_msg_type)
Forwarder(forwarder_name, topic_1_in , msg_1_type, topic_1_out, topic_2_in, msg_2_type, topic_2_out)
MotivationalBehavior(motivational_behavior_name, robot_ID, behavior_set_ID, forwarder_name)
A Demo
We assume a scenario that there are three rooms in a house and each robot patrols a room according to several pre-selected goals. If another intruder robot moves into the house, one of the three patrol robots can detect it, follow it and alarm. But at the same time, the room the robot patrols before is empty. So the other two patrol robots will compensate for this fault and patrol different rooms alternately. Besides, during the whole system running, one of the robot may break down, the other two robots may also compensate the fault according to the way mentioned above. We have used the package to develop the system.
- The ALLIANCE model and UML graph of the application is shown in the figures below
- The exprimental result is shown in the figures below.
If you want to test the demo yourself, please follow the steps below.
- environmental configuration
Notice that, the multi-robot task need multi-robot collision avoidance. One ROS package can help you do this, so you should git clone and compile the collvoid package first.
git clone https://github.com/daenny/collvoid.git
The package needs a simulated environment supporting multi-robot navigation without confliction (the prefixes of the namespace and TF may conflict with each other). You should git clone the multi_robot_stage package in your own catkin_ws.
git clone https://github.com/liminglong/multi_robot_stage.git
And then git clone this package micros_mars_task_alloc in your workspace.
git clone https://github.com/liminglong/micros_mars_task_alloc.git
Finally, even all the codes are witten in python, you should compile the files in your workspace again. Such that the added message files can be imported by the python modules. Don’t forget to source your setup.bash.
- run the demo First, launch the simulated multi-robot environment.
roslaunch multi_robot_stage multi_robot.launch
Run the following commands in your terminal.
cd /catkin_ws/src/micros_mars_task_alloc/scripts/basic_support
Use the python interpreter to start the first robot.
python robot0.py
Open a new terminal in the same directory to start the second robot.
python robot1.py
Open another new ternimal in the same directory to run the third robot.
python robot2.py
Then the whole system will run as a whole. The three robots patrol the three rooms. Besides, you can also control a suspicious robot to invade the room.
roslaunch micros_mars_task_alloc robot3_control.launch
One of the robot can detect and follow it immediately. The remained room will not be empty, because the other two robots will patrol the three rooms alternatively and compensate for this fault.
Videos
The experimental videos can be downloaded and watched here.
Changelog for package micros_mars_task_alloc
0.0.5 (2016-06-17)
- commit on June 16th
- Contributors: minglongli
0.0.4 (2016-06-15)
- Update README.md
- commit on June 15th
- commit on June 15th
- Update README.md
- Update README.md
- Update README.md
- Update README.md
- first commit
- first commit Description of the package.
- Contributors: Minglong Li, liminglong, minglongli
0.0.3 (2016-06-14)
- first commit
- Contributors: liminglong
Wiki Tutorials
Package Dependencies
| Deps | Name |
|---|---|
| actionlib | |
| actionlib_msgs | |
| geometry_msgs | |
| message_generation | |
| roscpp | |
| rospy | |
| std_msgs | |
| kobuki_msgs | |
| tf | |
| sensor_msgs | |
| cv_bridge | |
| nav_msgs | |
| nodelet | |
| message_filters | |
| catkin |
System Dependencies
Dependant Packages
Launch files
- launch/start_follow_demo.launch
- launch/suppressor_test.launch
- launch/inhibitor_test.launch
- launch/multi_robot.launch
- launch/two_robot_patrol.launch
-
- map_file [default: $(find multi_robot_stage)/maps/three_rooms.yaml]
- world_file [default: $(find multi_robot_stage)/maps/stage/three_rooms.world]
- urdf_file [default: $(find xacro)/xacro.py '$(find turtlebot_description)/robots/$(arg base)_$(arg stacks)_$(arg 3d_sensor).urdf.xacro']
- odom_frame_id [default: odom]
- base_frame_id [default: base_link]
- global_frame_id [default: /map]
- odom_topic [default: odom]
- cmd_vel_topic [default: cmd_vel]
- scan_topic [default: base_scan]
- launch/suppressor_test_manager.launch
- launch/nodelet_sub.launch
- launch/robot0_control.launch
- launch/robot1_control.launch
- launch/turtlebot_in_stage.launch
- Turtlebot navigation simulation: - stage - map_server - move_base - static map - amcl - rviz view
-
- base [default: $(optenv TURTLEBOT_BASE kobuki)]
- stacks [default: $(optenv TURTLEBOT_STACKS hexagons)]
- 3d_sensor [default: $(optenv TURTLEBOT_3D_SENSOR kinect)]
- map_file [default: $(env TURTLEBOT_STAGE_MAP_FILE)]
- world_file [default: /home/liminglong/catkin_ws/src/multi_robot_patrol/maps/stage/maze.world]
- initial_pose_x [default: 2.0]
- initial_pose_y [default: 2.0]
- initial_pose_a [default: 0.0]
- launch/nodelet_pub.launch
- launch/robot3_control.launch
- launch/start_tf_demo_test.launch
- launch/robot_patrol_test.launch
- launch/robot_follow_test.launch
- launch/nodelet_manager.launch
- launch/auto_wander_test.launch
- launch/nodelet_test.launch
- launch/multi_robot_patrol.launch
- launch/robot2_control.launch
- launch/nodelet_mux_test.launch