Summary

Now that the issues of localization, mapping, representations and limited communica- tion were introduced, a MRSLAM strategy that implicitly incorporates these subjects was implemented and is described in more detail in the next chapter. As for representation, the metric approach used is occupancy grids maps, the coordination architecture is distributed, robots communicate when they are close by and when the probability of delivering mes- sages exchanged between them is high, by monitoring the quality of the communication link between them. Further details on how the maps are acquired, when the robots exchange maps, how alignment and merging of maps is conducted and how the robots mutually detect teammates will be discussed in the next chapter.

Chapter 3

Implementation of a Multi-Robot SLAM

System

This chapter provides a detailed description of each module of the MRSLAM System in order to generate a coherent global map of an environment using a team of cooperative robots.

The algorithm consists of diverse modules that are regarded as the groundwork of this MRSLAM's approach presented on Table 3.1. Firstly, some aspects about the framework used and how to support MRS are presented in section 3.1. Each robot runs a single robot SLAM approach based on RBPF-SLAM, which is described in section 3.2. In order to maintain an update list of teammates that are currently performing the cooperative task, we leverage the information made available by the communication protocol Optimized Link State Routing Protocol (OLSR). This will enable the discovery and detecting departures of teammates described in section 3.3. Furthermore, we monitor the link quality between each pair of robots so as to conduct a rendezvous and exchange maps between them (cf., section 3.4). When a robot receives a partial map from one of its teammates, map alignment and merging is necessary to the fuse both contributions.

exchange_robot_1/  map  

exchange_robot_2/  map  

22

MRSLAM Module Brief Description

MRS in ROS Organizing ROS structures for Multi-Robot Systems

SLAM approach Using RBPF-SLAM as the individual mapping proce-

dure of each robot

Discovery and Departure Continuously updating the list of teammates in the mis-

sion

Rendezvous and Map exchange Monitoring the link quality

Alignment Finding the transformation to align partial maps

Mutual Detection Avoiding mapping other robots as obstacles

Map Merging Creating the global map by fusing partial contributions

Table 3.1: Modules list and brief description.

This is described in sections 3.5 and 3.7. Additionally, a method for mutual detection of teammates is described in section 3.6. The diagram in Figure 3.1 shows the basic operation of the algorithm running on each robot with the respective modules.

3.1 Multi-Robot Systems in ROS

In this work, Robot Operating System (ROS) is used as the development framework.

ROS is a framework for robot software development and is maintained by Willow Garage1_.

It uses a publish/subscribe semantics architecture and a central master instance known as the roscore. The roscore provides lookup information about messages and processes for each system. Each node (i.e., application or process) reports its register information back to the roscore. A node that subscribes to a topic requests a connection information through the roscore and connects directly (via peer-to-peer) to a publisher node, thus receiving messages from it (Figure 3.2). The interpretation and the execution of algorithms are controlled by such ROS nodes, which can be programmed in C++, Python, Java or Lisp. Therefore, custom nodes can be developed intuitively and on a high abstraction level. Moreover, ROS provides a series of tools and existing algorithms that can be easily tested in robots [Quigley et al., 2009].

In general, the multi-robot case over wireless communication in ROS presents a challenge and most of the focus for solutions is to support multiple ROS masters, i.e., distributed

roscores. To that end, a ROS package called wi_comm2 _{is used to publish and subscribe}

topics to/from foreign masters. This is done by opening a connection between the ma- chines with known Internet Protocol (IP) which share a common topic and relaying specic information from a local topic over the given connection.

Another challenge to overcome when dealing with multiple robots are the fact that each robot should have a dierent namespace to avoid misinterpretation of data transferred be- tween robots. To deal with this, when passing messages between robots with similar link

1_{Willow Garage's site: http://www.willowgarage.com/} 2_{wi_comm package: http://www.ros.org/wiki/wifi_comm}

23 Node B1 Node A1 Node B2 Stack B Sensor Message Node C1 Float Message Range Message Package 1 Stack A Package 2 Node Bn Package n Int Message PointCloud Message Stack C Package Package Type of messages

exchanged in topics Topics

Subscriber Node

Publisher Node

Figure 3.2: ROS architecture example diagram [Araújo, 2012].

names a frame_id remapping needs to be applied, both to transform data as well as to use

a common naming convention. The use of the tf_prex parameter is the recommended

SHARED TOPICS • INTERNAL TOPICS: robot_1/odom robot_1/scan robot_1/cmd_vel … robot 1 robot 2 • INTERNAL TOPICS: robot_2/odom robot_2/scan robot_2/cmd_vel … • namespace: robot_1 • namespace: robot_2 /exchange_map /exchange_pose

Figure 3.3: Denition of an unique namespace for each robots for all its information's. standard way of using multiple robots, when sharing reference frame transforms. Addition- ally, the user may also need to remap topics of each individual robot, for example in the case where the dierent robots use the same node internally: the output of a Laser Range Finder (LRF) sensor from robot 1 should not be published in the same topic as the output of an LRF sensor of robot 2. Each robot should publish the scan message in a dierent and appropriate topic. Dening a prex will allow each robot to use a unique namespace for all its data and transforms, this prex will turn things like the odometry reference of the robot (typically named /odom) into r1/odom and r2/odom automatically, depending on which robot it is. This is shown in Figure 3.3.

24

Figure 3.4: Hierarchical multi-robot control system (rxgraph).

ROS supports replication of functionality by allowing nodes and entire roslaunch cluster- description les to be pushed into a child namespace, thus ensuring that there can be no name collisions. Essentially, this prepends a string (the namespace) to all nodes, topics, and service names, without requiring any modication to the code of the node or cluster. The graph from Figure 3.4 is obtained running the rxgraph tool in ROS. Figure 3.4 shows hierarchical multi-robot nodes, where in each robot uses a SLAM package with its own namespace.