Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The RoboCup Rescue competitions provide benchmarks for evaluating robot platforms’ usability in disaster mitigation. Research groups should demonstrate their ability to deploy a team of robots that explore a devastated area and locate victims. RoboCup is moving towards longterm goals of sophisticated resource allocation in disaster situations, both at a large scale (the Agents competition) and at a small scale (the Virtual Robots competition). Each year the benchmarks are made more challenging to accommodate and encourage progress by all teams. The Infrastructure competition showcases innovations that have enabled extensions of these benchmarks.

The Infrastructure competition was started in 2004 with the aim of promoting the development of new tools to improve rescue simulation. The simulation of various disaster situations turns out to be complicated and difficult to validate. Therefore, the infrastructure competition was launched to promote the maintenance and development of simulation environments. For example, the fire simulator [24] was developed by the winner of the infrastructure competition in 2004. Another nice example of a component developed in the infrastructure competition is the flood simulator [27]. Recently, an extension towards flying robots has been proposed, both in the Virtual Robot [7] and Agent competitions [9].

The Amsterdam Oxford Joint Rescue Forces, and their predecessor the UvA Rescue Team, has participated several times in the Infrastructure competition. In 2010 the simulator of the Virtual Robot competition was extended with a realistic response of laser scanners to smoke; a circumstance which is quite common in disaster situations. The response of the laser scanners was validated in a number of experiments in a training center of the Dutch fire brigade [8]. In 2011 a model of a humanoid robot was introduced in USARSim, which made it possible to model one of the robots in the RoboCup@Home League [31]. In 2012 a validated flying robot was introduced to USARSim and it was demonstrated that such a robot allows for fast exploration of disaster areas, while creating a visual map of the area [7]. This resulted in the UvA Rescue team winning the Infrastructure award in 2012.

What was still missing inside the Rescue Simulation League is an environment which is a common ground for both the Agent and Virtual Robot competitions. Inside the Agent competition the focus is on the coordination of rescue teams [20, 33]. The competition consists of a simulation environment which resembles a city after an earthquake. Teams of fire brigade, police and ambulance team agents try to extinguish fires and rescue victims in the collapsed buildings. In contrast, inside the Virtual Robot competition the focus is on sensor-data fusion on maps automatically generated by teams of robots which explore inside buildings. The multi-robot exploration simulator MRESimFootnote 1, described in this paper, is proposed as a middle ground between the Agent and Virtual Robot competitions.

In the following section the background behind this new infrastructure is given, followed by a section which gives an overview of the research performed with this multi-robot exploration simulator.

2 Simulator

2.1 Simulation Cycle

MRESim is a discrete-time simulator. Unlike the existing Virtual Robot competition simulator USARSim, which uses a three-dimensional representation, MRESim works from a two-dimensional grid representation. In each time step, the simulator moves the robots to their new positions, updates their sensor information, simulates communication between the robots and outputs the current state of the simulation. The ordering of the events that happen in each time step are outlined in Algorithm 1. This is equivalent with the discrete-time step procedure in the simulator environment of the Agent competition. All of the robots process their next steps simultaneously. Since this tends to be the most computationally intensive part of each time step, planning robot movements in parallel allows the simulator to take advantage of modern multi-core CPUs. Other events in each time step are processed sequentially.

figure a
figure b

2.2 User Interface and Environments

The user interface (Fig. 1) contains a panel on the right for each robot with toggle buttons to visualize the information which is the basis of each robot’s decisions. Example of information that can be made visible is the following: location; path; free space; safe space; frontiers; communication range; skeleton and potential rendezvous points; exact rendezvous points; potential rendezvous points through obstacles; exact rendezvous points through obstacles. There are further toggle buttons for the environment walls and the team hierarchy at the bottom right, and a run may at any time be paused, continued, or stopped using the green buttons at the bottom. This means that it is very easy to examine specific aspects of any supported exploration approach. In addition, simulation logs produced by MRESim can be replayed in the simulator; this means that each simulation run can be analyzed in detail after the run has completed.

Environments in MRESim can be uploaded from text-based or PNG files, as can be found on dataset repositories like RadishFootnote 2. The environments are occupancy grid models, with each cell being either free or an obstacle.

Fig. 1.
figure 1

Screenshot of MRESim. Obstacles are shown in black (

figure c
)(), unexplored area is shown in grey (
figure d
)(), area known at base station is shown in green (
figure e
)(). The blue arrows (
figure f
)() represent exploring robots, and the communication range of robot D is shown as the blue polygon (
figure g
)() (Color figure online).

Full size image

2.3 Planning and Movement

In every time step, each robot has to decide where to move next. The next destination is decided by the robot by calling the takeStep method (line 3 of Algorithm 1). If the robot has a path to its destination, and has replanned the path recently, then it simply continues on the current path by retrieving the next path point. Otherwise, it calls the corresponding replan method of the exploration strategy assigned to the robot team to generate a new path (line 2 of Algorithm 2). The exploration strategy then selects the best destination for the robot, and generates a path to the destination. The exploration strategy can use all the information known to the robot when making that decision — including the information about last known locations of the robot’s teammates and agreements made in previous communication with other robots or the base station. Note that this information is not globally available, but communicated when in range. When no recent information is available, reasonable estimates are made.

Each robot \(r\) can move a maximum distance of \(d_{r}\) in each time step (line 5 of Algorithm 1). This is defined as the robot “speed”, and can be set up to be different for each robot, allowing for heterogeneous teams of robots to be created. By default, this parameter is set for each robot to \(DEFAULT\_SPEED = 3\), configured in the Constants class of the config package. In each time step, each robot moves a maximum distance of \(d_{r}\) along the path generated in the planning stage (see line 2 in Algorithm 2). If the robot reaches the planned destination before \(d_{r}\) is exhausted, it will not move any further in that timestep.

2.4 Sensing and Mapping

Once a robot has taken a step, the simulator provides it with sensor data at its new location (lines 6–7 of Algorithm 1). This sensor data is generated using raytracing from the robot’s location at 1-degree intervals in the 180-degree field of view of the robot (the same field of view as many real laser scanners, as for instance the SICK LMS200). A maximum sensor range can be configured for each robot, allowing for heterogeneity of sensors across the team. An array of 181 measurements is returned to the robot. The measurements are assumed to be noise-free (see Sect. 2.7 for more detail).

The robot subsequently turns this sensor data into a polygon of free space, detecting obstacles where two points are sufficiently close to one another and below the sensor’s range limit. This free space and obstacle detection is maintained in an occupancy grid. When robots are within communication range of one another, they can decide to exchange their local maps in the form of occupancy grids.

2.5 Path Planning

Several path planning algorithms have been implemented in the MRESim simulator. The most straightforward one is the A* algorithm [11], operating directly on the occupancy grid representation of the map. While A* generates optimal paths, it can be very slow with a sufficiently high resolution of the occupancy grid. In an attempt to overcome this problem, we have implemented several more efficient path planning algorithms. One of them is Jump Point Path search [10], which is a modification of the A* algorithm which significantly improves the performance in environments with large open areas. However, complex paths can still take several hundred milliseconds to compute.

We found that using A* search on a combination of a simple topological map that captures the connectivity between regions and the underlying occupancy grid map can significantly improve performance over the other implemented approaches. In each time step, if the map of the environment has been updated, we can generate a new topological map as follows. First, we perform thinning on the occupancy grid map in order to obtain a skeleton of the free space. Then, we uniformly select a set of nodes from the skeleton. Each point of the occupancy grid is then assigned to the nearest node. The set of nodes and edges connecting the nodes then represents a simple topological map of the environment. An illustration of the process is given in Fig. 2. We can then plan a path between any two points on the occupancy grid map by using the A* algorithm to find a path in the graph between the two corresponding nodes on the topological map, and using A* on the occupancy grid map to find paths from start and finish locations to their corresponding node locations. Generating paths then becomes very computationally efficient, which improves the speed of running the simulation and can increase the performance of exploration strategies by allowing them to calculate more accurate path lengths, instead of relying on crude approximations.

2.6 Communication

MRESim supports a variety of communication models. In principle messages from both robots are exchanged (as indicated in lines 17 and 18 of Algorithm 1), but only when the robots are inRange (line 16 of Algorithm 1). Simple models include a straight-line model (any robot within radius \(x\) is considered in range, regardless of obstacles) and a line-of-sight model (any two robots that can be connected by a line that doesn’t hit an obstacle are in range). A more realistic communication model implemented in MRESim is a path loss model, originally proposed by Bahl and Padmanabhan [2]. This model is also used for simulating communication in the USARSim simulator used at RoboCup, and is considerably more realistic as it takes attenuation by walls into account. In this model, communication strength is calculated as follows:

$$ S = P_{d_0} - 10 \times N \times log_{10} \frac{d_m}{d_0} \times \min (nW,C) \times W\!AF $$

where \(P_{d_0}\) is the signal strength at reference distance \(d_0\), \(N\) is the rate of path loss, \(d_m\) is the distance, \(nW\) is the number of obstructing walls, \(W\!AF\) is the wall attenuation factor and \(C\) is the maximum number of walls where the attenuation factor needs to be considered.

Typical communication ranges using this model can be seen in Fig. 1.

Fig. 2.
figure 2

Illustration of the process used by MRESim to generate topological maps from occupancy grid maps. On top, we see an occupancy grid of a partially explored environment, shown in white. In the middle, we apply “thinning” to obtain a skeleton, and sample uniformly points, shown in red (

figure h
)(), from the skeleton to act as nodes in the topological graph. In the bottom picture, we map each point of the occupancy grid map to the nearest node (Color figure online).

Full size image

2.7 Realism of Simulator Results

Clearly MRESim does not take into account a number of factors that any robot system in the real world would have to consider. The most significant ones are:

  1. 1.

    There is no sensor noise. In reality, wheel encoders provide inexact data, and laser range finders often have spurious measurements at either close or maximum range. Localisation remains a significant challenge in robotics, even if a number of techniques such as particle filters and scan matching show great promise.

  2. 2.

    Environments are two-dimensional and flat. In the real world this is almost never the case.

  3. 3.

    The simulator is discrete-time. Real robots would each run their own (multi-thread) processes, take different amounts of time to do the required processing, and would not always move the same distance in each time segment.

  4. 4.

    Communication in reality is highly variable and very difficult to predict. Nevertheless, for purposes of quick, simple, controlled, and repeatable comparison of exploration algorithms, MRESim remains a useful tool.

In the next section we give an overview of published work that used MRESim to evaluate exploration strategies. In some of the work, results are compared with those obtained from high-fidelity simulators such as USARSim, as well as with results obtained on real robots. Those experiments suggest that results obtained in MRESim have much in common with the results obtained in real life experiments.

3 MRESim as Benchmark

A number of exploration strategies have already been implemented in MRESim and are available “out-of-the-box”. This makes it a potentially useful tool for benchmarking various exploration strategies against each other. According to [19], the performance of most algorithms is compared using the following three methods, from the best to the worst:

  1. 1.

    Using the same implementation that was used in other work.

  2. 2.

    Using a custom implementation, created from descriptions of the algorithm in published work.

  3. 3.

    Simply taking the results from those in other papers, without re-running the algorithm.

According to [1], most algorithm comparisons in robotics are currently conducted using the second approach. Publishing of the team’s source-code, as done inside the Rescue Simulation League, made it possible to reimplement existing algorithms and to make a fair comparison (see for instance [1, 28]). Using MRESim, the first approach can be used more often:

  1. 1.

    Results of using different exploration strategies can be directly compared with each other.

  2. 2.

    Existing implementations of exploration strategies can be used.

3.1 Studies Based on MRESim

MRESim was first mentioned in [13]. In this study the effect of robots with a relay role was studied, when exploration was needed outside the direct communication range from the base station. This study inspired several other researchers [3, 5, 6] to base the coordination decisions on multiple criteria.

Important for the coordination of the explorer and relay role is the selection of an appropriate rendezvous point [15]. When those points are selected near gateways, the locations inside indoor environments become important junctions for a navigation algorithm. This work was followed up by several researchers [21, 23, 25] (although the concept of rendezvous points has already been known for a long time [26]). In addition, in [29] the possibility of communicating through obstacles, such as thin walls, was introduced into the planning.

Dividing the work into explorer and relay roles is already valuable, but sometimes the explorer finds a dead-end. This is an example of a situation where it is beneficial to switch roles dynamically using the role swap rule, as described in [14]. Other researchers have validated this results with real robots, such as [18].

In the study [35], the exploration indoors is extended to open areas which can be encountered in outdoor scenarios. The robots still use rendezvous points, but no longer near gateways. Instead, the robots divide the work into sectors and meet at the sector boundaries. This work has motivated several other studies [4, 17, 34].

The algorithms implemented in MRESim have been validated with Pioneer robots [16], although it is difficult to scale indoors to extensive environments with large robot teams. The MRESim environment was discussed in several dissertations [12, 22, 34] and a workshop contribution [32].

The latest extension are robot teams which can adjust their exploration strategy based on the information need of the base station [30]. When it is important that the base station gets timely updates more resources are allocated towards the relay role; when fast exploration is needed more resources are allocated towards the explorer role.

4 Discussion and Future Work

MRESim is a simulation environment with a well chosen level of detail, as discussed in 2.7. When the algorithms developed inside MRESim are applied in the real world issues will arise, which can be studied in separation inside the simulation. Precisely those issues could be identified as directions for future research.

In addition, the simulator itself can be extended in a number of ways to increase its realism and allow for using it to study a wider range of research problems:

  1. 1.

    Variable Terrain. In real applications, the terrain of the environment being explored can vary significantly, affecting the speed of robots navigating over such terrain. For example, robots are likely to be able to travel much faster just outside a partially-collapsed building, than inside where there is likely to be a lot of rubble. It may then be possible to improve the exploration speed by reducing the amount of travel over rough terrain, particularly for the relays.

  2. 2.

    Additional Communication Channels. It may be possible to use low- frequency, low-bandwidth, high range radio communication channels in disaster scenarios to transfer some control information between robots, as suggested in [29]. (We are about to test this hypothesis experimentally).

  3. 3.

    Robustness Against Failing Robots. Robots may fail for a number of reasons (and often do). In greedy approaches this does not affect the failed robot’s teammates, which continue exploring as if nothing happened. In some other approaches, meetings between robots at pre-agreed times and locations can be planned for explicitly. In those cases, the failure of robots is a scenario that must be dealt with carefully. A useful extension to the simulator could therefore be the ability to specify scenarios that include robot failure, making it a useful tool to evaluate the robustness of exploration strategies to individual robot failure.

  4. 4.

    Dynamic Environments. In many robotics applications, the environment may change as the exploration effort progresses. A possible extension to the simulator would be to specify how the environment should change over time, or allow for random changes to the environment. This is precisely where the current Agent competition accelerates and it would be nice if for example part of the fire, earthquake or flood simulation could be incorporated in MRESim.

  5. 5.

    Prior Knowledge. In practice, some knowledge about the environment may be available to the team before the start of the mission, even though this information may not be accurate.

5 Conclusions

The original motivating questions for this research were: How can a team of robots be coordinated to explore a previously unknown and communication-limited environment as efficiently as possible; and how can new information obtained by this team be gathered at a single location as quickly and as reliably as possible?

These are precisely the research questions studied in both the Agent and the Virtual Robot competition of the RoboCup Rescue Simulation League. The studies performed with the simulation environment MRESim are well recognized, both inside the RoboCup community and outside. MRESim is applied to compare several coordination algorithms and could be easily extended with other coordination algorithms. In this paper some ideas for future research are given, but many other extensions are possible.