Auctions mechanisms for multi-robot task allocation are implemented in multi-robot systems that are strongly coordinated (i.e. an auction mechanism is a coordinating protocol); centralised, decentralised, or a hybrid; and that use explicit communication to submit bids and awards. The following chapters investigate the performance of different auction mechanisms empirically, with a multi-robot system implemented on physical robots and in high-fidelity simulations. A primary interest is in seeing how theoretical guarantees of solution quality made during task allocation, such as ssi’s upper bound of two times the optimal team distance for the minisum objective (Section 2.3.1), accurately predict or diverge from observed performance during task execution. Of equal interest is understanding how performance varies as mechanisms are employed in a range of task environments that can be complicated in ways which might not have been considered by mechanism designs. The following chapter describes the architecture of the multi-robot system used to conduct these experiments.
Chapter 3
The MRTeAm Experimental
Framework
This thesis investigates the comparative performance of different market-based task al- location mechanisms when employed for the same multi-robot routing missions. I am especially interested in measuring the empirical performance of a mission by a team of real (or realistically simulated) robots in physical environments, with the noise, un- certainty, and inter-robot interference that can arise in a physical system. To conduct this experimental work, I have developed a software framework named MRTeAm, a combination of “Multi-Robot Task Allocation” and “Teamwork”. MRTeAm is an im- plementation of a multi-robot system that runs on both physical and simulated robots and is designed to investigate research problems in multi-robot task allocation [107–110], multi-robot communication quality [141], and other domains.
MRTeAm is an evolution of the HRTeam (“Human-Robot Teamwork”) software framework [115], which itself has been used as a research platform for similar problem domains [26–28]. HRTeam is a multi-robot system based on the Player Project [37], which is no longer actively maintained. In an effort to adopt a more mature infrastruc- ture, MRTeAm is based on the Robot Operating System (ROS) [96], a pervasive software infrastructure underlying many single- and multi-robot systems in both research and applied industrial settings. ROS provides many services needed by the kind of mobile multi-robot systems that MRTeAm was designed to work with: drivers for sensing, sen- sor fusion and motor control; map representation;1 localisation;2 path planning3 and execution, including plan repair and recovery;4 and, importantly, a standard messaging system5 for inter-process communication, which allows these services to be distributed across multiple hosts in a flexible way.
MRTeAm builds upon ROS by adding several key components. Robot Controllers are agents responsible for the bidding and task execution behaviour of robot team members.
1 http://wiki.ros.org/map server 2http://wiki.ros.org/amcl 3 http://wiki.ros.org/global planner 4 http://wiki.ros.org/move base 5 http://wiki.ros.org/Messages 23
Chapter 3. The MRTeAm Experimental Framework 24 An Auctioneer is a coordinating agent responsible for conducting auctions among the robot controllers and guiding the overall course of an experiment. The Robot Controller and Auctioneer agents implement task allocation and execution for missions which are set in the SR/MR-IT/CT-SA/DA task environments described in Chapter 2. The ROS Master Bridge is an extension to ROS’s messaging system that connects multiple ROS communication hubs (“masters”), enabling multi-robot communication
Section 3.1 explains some of the basic concepts behind ROS and its implementation of navigation services for mobile robots, which are relevant to understanding the results of experiments in later chapters. This review of existing software is followed by sections that describe my own work on MRTeAm. Section 3.2 discusses the auctioneer and robot controller agents that implement task allocation and execution behaviours to accomplish multi-robot routing missions. Section 3.3 discusses the ROS Master Bridge and multi- robot communication. Section 3.5 describes the physical platform on which MRTeAm has been deployed and section 3.6 describes its counterpart in simulations. Section 3.7 discusses the HRTeam framework used to carry out the experiments discussed in Chapter 5.
3.1
The Robot Operating System (ROS)
ROS consists of a set of computation units (“nodes”), which run as separate processes, and a structured communications layer based on message-passing [96], which enables communication between them. A ROS node is a process that performs some computation and communicates with other nodes via messages. ROS messages are sent between nodes on topics using a publish-subscribe model [34]. A ROS master is a special process that provides naming and directory services that keep track of nodes and publishers and subscribers to topics. A ROS message is an instance of a typed data structure that nodes use to communicate. The set of all ROS nodes that are connected to a single master comprises a ROS Computation Graph (Figure B.1, pg. 138).
3.1.1 The ROS Navigation Stack
The ROS navigation stack6 is a collection of nodes which provide services that enable mobile robots to plan and navigate through physical spaces. Physical space is repre- sented by a two-dimensional, grid-based cost map, where the value of each grid cell represents the likelihood of occupancy by an obstacle in that location. Obstacles may be inserted or cleared from the cost map based on readings from a robot’s range sensors (e.g., a laser or infrared-based camera). A localisation node attempts to find the most likely position of the robot on the map from spatial features detected by the robot’s range sensors using a particle filter approach [31]. A global planner finds the shortest path between two locations through the cost map using an A* search algorithm [45]. A
Chapter 3. The MRTeAm Experimental Framework 25
Figure 3.1: Components of the ROS navigation stack and their interactions.
path plan produced by the global planner is made up of a series of positions, or way- points, from the robot’s current position to the goal. A local planner follows a global plan by computing motion trajectories and issuing velocity commands that follow them to a robot’s drive motors. Several of these services are coordinated by the move base7 node (Figure 3.1). Some components of the navigation stack can be visualised for monitoring and debugging (Figure 3.2).