MRTeAm contains several tools to support the generation and analysis of experiments, including a pipeline that converts experimental results into training sets for a machine learning library [94] (discussed in Chapter 8). A scenario generator creates scenarios in which task locations and other properties of tasks, such as their arrival times, precedence constraints and the number of robots required ([1, n], where n = |R| the number of robots in the team), can be randomised. Messages and events generated during the course of an experiment are recorded in a ROS bag, a special type of logging file.11
3.5
Physical Platform
The physical environment for MRTeAm experiments is an arena that has been built in the smARTLab UGV laboratory at the University of Liverpool. The arena is 8 metres long and 6 metres wide, with walls 0.5 metres high. The layout of the arena is meant to resemble a simplified floor plan of an office-like building with spatial features like rooms and corridors. The arena can be reconfigured in different layouts.
MRTeAm’s physical robot platform is the Turtlebot 2.12 Each robot is equipped with a differential-drive mobile base and a colour- and depth-sensing camera and is controlled by an on-board laptop computer that runs the ROS navigation stack. Each robot is capable of fully autonomous navigation, and only depends on the auctioneer to receive tasks. Robots in the physical arena are shown in Figures 3.8.
Figure 3.8: Turtlebots in the smARTLab environment.
3.6
Simulation Platform
The layout of the physical arena is reproduced inside of the Stage13 robot simulator [37]. The Turtlebots’ physical properties (e.g., size, shape, acceleration) and sensors are
11http://wiki.ros.org/rosbag 12
http://www.turtlebot.com/turtlebot2/ 13
Chapter 3. The MRTeAm Experimental Framework 33
Figure 3.9: Turtlebots in an office-like environment.
modelled in Stage. The fidelity of the simulation is important. Most of the experiments presented in this thesis are conducted in simulation, with the goal of validating sim- ulation results on physical robots [107]. Section 4.7 (pg. 47) discusses the differences between simulated and physical settings and how these differences can be measured and mitigated.
I put approximately five months of effort into building the software necessary to run simulations on the University of Liverpool’s Chadwick cluster.14 This effort involved porting ROS and its software dependencies to the cluster’s computing environment. The Chadwick cluster is a grid computing resource with 200 compute nodes, each with 2 8-core Intel Xeon CPUs. I am able to run simulation experiments on the Chadwick cluster in parallel on a large scale, which allows for a large number of experiments to be run in a reasonable amount of time.
(a) A simulation of the smARTLab arena. (b) The office environment in Figure 3.9.
Figure 3.10: Turtlebots in the Stage simulator.
Chapter 3. The MRTeAm Experimental Framework 34
3.7
HRTeam
HRTeam [115] is a multi-robot framework with agents that implement auction-based multirobot task allocation mechanisms for multi-robot routing missions, with implemen- tations similar to those of MRTeAm. HRTeam uses software from the Player Project [37] to handle robot navigation and a central server to communicate messages between auc- tioneer and robot controller agents (Figure 3.11).
The robot platform of HRTeam is the Surveyor SRV-1 Blackfin robot (Figure 3.12a), which was modelled in the Stage simulator [37] for the experiments reported in Chapter 5. Controller Robot Controller Robot Controller Central Server Camera Agent Camera Agent Camera Agent Human Interface FORR Engine Camera Agent Camera Agent Camera Agent physical robots in arena Stage Simulator Robot
Figure 3.11: HRTeam system architecture
(a) Surveyor SRV-1 Blackfin robot. (b) The physical arena for HRTeam missions.
Figure 3.12: HRTeam physical platform.
3.8
Summary
This chapter has introduced the MRTeAm software framework, which was used to con- duct the majority of experiments presented in this thesis. I have developed MRTeAm to
Chapter 3. The MRTeAm Experimental Framework 35 run on both physical and simulated robots with minimal difference in the behaviour of the two. The following chapter describes the design of experiments presented in Chapters 5–8, defining the terminology, notation, and the metrics used to measure performance.
Chapter 4
Experimental Design
This chapter describes common elements of experiments presented in this thesis and a rationale for their design. Section 4.1 describes a hypothetical setting in which experi- ments take place. Section 4.2 describes the task environments investigated in Chapters 5–8. Section 4.3 defines the terms and notation used to discuss experiments. Section 4.4 defines the task allocation mechanisms employed in experiments, including their ex- pected computation and communication costs. Section 4.5 discusses the phases of an experiment time line. Section 4.6 defines the metrics that are used to measure perfor- mance. Section 4.7 discusses the differences between simulated and physical settings and how simulations can be used to develop and test algorithms that will ultimately work on physical robots despite a “reality gap” that exists between the two settings. Finally, Section 4.8 describes the practical factors that affect the design of experiments conducted in Chapters (5–8).
A portion of the results and discussion presented in Section 4.7 were published in Schneider et al. (2015) [107].
4.1
Mission Setting
A primary inspiration for the experiments presented in the following chapters is that of a search and rescue mission performed by a team of autonomous mobile robots. The mission is set on a floor of an office-like building with features like rooms and corridors that link them (Figure 4.1). Multi-stage missions, in which an advance team of surveying robots first explores and maps an area and discovers points of interest in it, have been employed in ground-based [66] and undersea [124] archaeological inspection and recovery settings. Here we assume that the area has been explored and mapped beforehand and that the map is available to the robots. The mission involves sending the robot team into the building from safe entry points at the edges of the map to travel to pre-identified points of interest and perform some action, for example, recording video or offering aid to a person in distress.
Chapter 4. Experimental Design 38
Figure 4.1: An office-like floorplan of the type used in experiments in Chapters 5–8.
4.2
Task Environments
The experiments presented in Chapters 5–8 investigate the performance of task allo- cation mechanisms employed in a number of task environments classified by the taxonomy given in Section 2.4. The “landscape” of task environments investigated is defined by three axes:
• Single-robot (SR) vs. multi-robot (MR) tasks • Independent (IT) vs. constrained (CT) tasks • Static allocation (SA) vs. dynamic allocation (DA)
A single task environment in this landscape is identified by a triple, for example, SR- IT-SA, which indicates an environment in which all tasks are single-robot tasks, have no constraints between them, and are all allocated at the beginning of an experiment.