Keywords

1 Introduction

After occurring disasters such as earthquake, a team of rescue agents consist of police forces, ambulance teams and firefighters will deploy in the city and start search and rescue operations. The search strategy, communication method, estimation of the needed forces in different parts of the city, assignment of the available agents to various tasks and also individual decisions of rescue agents will affect the speed and quality of the aid provided by the agents. Thus computer assistance can be very helpful to maximize the efficiency of agents, this is where RoboCup Rescue Simulation System (RCRSS) [1, 2] comes to work.

The Rescue Simulation is a system for simulating a city after an earthquake happens and is considered an important league in RoboCup. This system, simulates the earthquake and the events that usually occurs after the earthquake, for example shattered buildings, buried civilians in the buildings, blocked roads due to the debris of buildings, fire, explosion of gas stations and even the communication problems that can occur after an earthquake. Utilizing such an elaborate system in real world scenarios demands preparations on different levels.

The intention of the RoboCup Rescue project is to promote research and development in this socially significant domain at various levels involving multi-agent teamwork, coordination, physical robotic agents for search and rescue, information infrastructures, personal digital assistants and decision support systems, evaluation benchmarks for rescue strategies and robotic systems that can all be integrated into comprehensive systems in future.

There are three main competitions in the league, and one technical challenge competition. Main competitions are the agent competition, infrastructure competition and virtual robot competition.

The agent competition involves primarily evaluating the performance of agent teams on different maps of the RoboCup Rescue Agent Simulation (RCRSS) platform. Specifically, it involves evaluating the effectiveness of Ambulances, Police Forces, and Fire Brigades agents on rescuing civilians, clearing blocked roads and extinguishing fires in cities where an earthquake has just happened.

The Infrastructure competition involves the presentation of an already existing tool or simulator related to disaster management issues in general. The aim is to evaluate possible enhancements and expansions of the RoboCup Rescue Simulation League environment (both the agent-simulator and the virtual robot platform) based on the new ideas and concepts proposed in these tools and simulators.

The MRL team is one of the most experienced and active teams in Rescue Simulation League since 2004. We took part in the agent competition every year since 2004 and we won the championship twice (in 2006 and 2007)Footnote 1. With the league becoming more popular and competitive the technical committee has released a new version of the Rescue Simulation Platform in 2010 with following featuresFootnote 2 [3]:

  • New kernel

  • New traffic simulator and GIS

  • New communication model

  • New perception model

  • Modified collapse and blockade simulator

  • New ignition simulator

  • Adjustment of the map scale to match real-word data

  • Introduction of special challenges in addition to normal simulation runs

  • Introduction of variable simulation parameters.

These fundamental modifications to the platform demanded a huge change in our agent code as well. We decided on rewriting the whole agent code from the scratch in order to be compatible with the new version of the platform. This was the biggest change in the Rescue Simulation history and all the other teams had to do the same thing as we did.

MRL’s activities divided into two stages since 2010. The first stage, from 2010 to the end of 2012’s competitions, which was spent on developing base code, utilities and infrastructure suitable for our high-level algorithms and the second stage, after RoboCup 2012 until 2016’s competitions, which we spent on developing the actual high-level logic and strategies which differentiate us from the other competitors. Through the first stage we have gained a lot of experience by interacting with the simulation kernel, that later inspired us for developing the kernel itself and taking part in Rescue Simulation Infrastructure competitions.

By relying on our experience and after years of hard working we achieved the first place for the third time in our team’s history in RoboCup 2016Footnote 3. We also won two other first prizes for infrastructure competition and technical challenge in RoboCup 2016 and first prize in IranOpen 2016.

In Sect. 2 we will explain our team organization and preparation then in Sects. 3 to 9 we will introduce some of our most important utilities that are developed and used by our team and finally in Sect. 10 we will discuss about our conclusion and future work.

2 Team Organization and Preparation

After the release of the kernel’s new version in 2010, we had to redesign and rewrite almost everything from the scratch to make our code compatible with the new release. All base-code, utilities and algorithms were re-written for the upcoming event.

In order to ensure our success in the future we have decided to change the structure of the team and recruited some energetic and young researchers. Then we divided our workforce to four different activities, which are developing infrastructural algorithms and utilities (e.g. path-planning and messaging), searching for applicable tactics and strategies (e.g. agent strategies, assignment algorithms and optimizations), designing and implementing the results of our research and finally testing and comparing the results of our implementations and picking the most effective solutions. Each task has an assignee who is responsible to make sure that the related task is resolving in time, but the rest of the members are contributing in each part that is needed based on their skills and team decision.

As you can see in Fig. 1, MRL managed to gain better results every year, comparing to past years until finally we achieved the first place.

Fig. 1.
figure 1

MRL ranks in agent competition from 2010 to 2016

Full size image

3 Visual Debugger

Considering the nature of the rescue simulation, monitoring agents’ performance and behavior is much easier by visualizing them rather than text-based outputs or logs, therefore it is vital to have a utility that provides a visual representation of output data and is easily extensible for everyone without deep knowledge of the kernel and viewer. MRL has realized this and added many features to the base viewer that made debugging an easy task comparing to debug by logging or by the basic viewer.

The Visual Debugger (Fig. 2) utility has a very similar appearance to the standard rescue simulation viewer and has every feature that is provided by the standard version. The advantage of visual debugger is in extending the viewer and adding new layers of graphic over the standard view in order to provide visual and real time representation of additional data (e.g. output of newly implemented algorithms, specific properties, custom drawings and etc.).

Fig. 2.
figure 2

A simple view of Visual Debugger project

Full size image

We generalized this debugger and presented it as MRL project for infrastructure competition in 2016 and we won the competition [4].

4 Partitioning

As the world is partially observable to the agents, we needed an approach to let the agents spread over the city in order to fullfill two requierments; first is to find buildings on fire and damaged civilians as fast as possible and second is to prevent congestion in some areas. While the former is a general requirement for all types of agents, the latter is mostly usable for ambulance and police force agents.

To handle this, we decided to use partitioning. We used Voronoi based algorithm [5] for partitioning in 2011. The method was so that, some important points were specified on map as input for Voronoi based algorithm to do the partitioning. But we decided to use K-means [6] clustering for the next year. The problem with previous method was that partitions were not created based on number of buildings in each partition but they were based on geometric clustering, and this could lead to unfair partitioning and inefficient assignment of healthy agents to partitions. So we decided to create variable number of partitions based on count of healthy agents (agents who can walk and are not trapped in buildings) then center of each partition will be determined using K-means algorithm.

The similarity measure for K-means is a function of number of buildings in a partition and distance between each building and center of the partition. This guarantees that there is at least one healthy agent available for each partition. In Fig. 3 the output of the new model is shown. Green circles with cross mark show the center of each partition and smaller circles in one color show center of entities of a specific partition.

Fig. 3.
figure 3

Partitioning by K-means algorithm (Color figure online)

Full size image

We have been using this stable and efficient algorithm since 2013 for partitioning.

figure a

5 Partition Assignment

We didn’t have any specific task assignment between the agents at the beginning of the simulation in our previous versions. Our assignment in the middle of scenario was not efficient either, it was mostly based on the distance between agents and available tasks which sometimes causes congestion in some areas and starvation of agent in other areas. The solution we applied was to divide the map into small partitions that may or may not contain any specific task and assign an agent to each starved partition in order to evenly distribute the agents throughout the map, but greedy assignment did not yield any better results. Our other solution was to utilize Hungarian algorithm for efficient assignment.

We have created partitions based on the number of available agents of each type, using the aforementioned K-means algorithm in Sect. 4, and then provided the agents and their respective partitions as the input for our Hungarian algorithm. Please note that we do the assignment for each type of agent separately, because each agent type has different capabilities that should be usually available in all parts of the map homogenously, but the number of available agent for each type may be different.

On the other hand, the data that is needed for some operations is constant and equal for all agent, therefore by applying the same algorithm to this data for multiple times, we expect that the result of this algorithm should be the same. Using this logic helps us to sacrifice CPU time in rare conditions, e.g. in first 3 cycles of the scenario that agents are frozen and cannot move, in order to preserve communication bandwidth for more critical information.

Partition assignment and partitioning process are functioning based on this fact and they are both calculated by each agent separately.

figure b

Here E is the list of all entities in the map which we want to cluster them as a partition; M is the list of produced clusters; distance is a function to calculate euclidean distance between each element of A and C; H is a function which performs Hungarian algorithm on COST matrix and the result (α) is a vector which contains the indices of assigned partition.

6 Sticky Movement Strategy

The main task of an ambulance agent is to maximize the total number of living civilians by the end of the simulation. Our base strategy is to create partitions proportional to number of available agents in the scenario using the k-means algorithm, assign each agent to a partition using Hungarian algorithm and let the agents search and rescue in their assigned partition. But sometimes despite the fact that our assignment is very efficient, the agents have to travel a long way to get to their partition (Fig. 4(a)), which reduces their utilization factor and efficiency. To utilize ambulance as much as possible even in such situations we added a new strategy called “Sticky Movement” which is simply based on potential field motion planning (Fig. 4(b)).

Fig. 4.
figure 4

(a) Shows aggregation of agents and (b) shows Sticky Movement (Color figure online)

Full size image

If an agent detects a civilian closer than a specific threshold to the path (illustrated by green circle) towards the target partition, the agent tries to rescue the civilian before heading towards the target partition. However, doing this sometimes will result in too many ambulances trying to rescue the same civilian; to avoid such conditions we are utilizing an algorithm based on Monte Carlo method [7] to estimate the remaining time until a civilian dies and therefore calculate the optimum number of ambulances needed to rescue that civilian, then we assign only as many as needed ambulances to rescue task and let the rest to go and reach their target partition. This algorithm uses an arbitrary high value as the starting point for the number of agents needed for a civilian to survive and it will be reduced as each civilian get recued faster than our estimated time that it needs to be rescued before death. We are using this method because of the quantized values that kernel exposes as health point and damage of the civilian.

In Fig. 4(a) aggregation of agents in specific zones forces them to travel a long way to get to their partition. And in Fig. 4(b) you can see Sticky Movement of ambulance from the starting point (yellow circle) to the center of target partition (red cross). The green dashed circle shows the threshold of civilians’ gravitational pull. The ambulance only rescues the civilians that their gravitational pull crosses its main course.

7 Fire Brigades’ Positioning Problem

For situations involving fire it is necessary to act as quick as possible without wasting time on redundant moves. By studying previous results, we have found out that we have lots of redundant moves to find a good place to put the fires off, so we decided to use Maximal Covering [8] to find best positions on the map for fire brigade agents to stand and put the fires off with minimum movement.

To see how it works, you can refer to Fig. 5(a). In this figure you can see three fire points (green, pink and violet buildings) with their corresponding possible positions (colored areas) to put each of them off. Consider how many places can be selected and how many moves can be done to put these fires off.

Fig. 5.
figure 5

(a) Shows fire points in three different positions and (b) shows found point after solving Maximal Covering (Color figure online)

Full size image

Solving Maximal Covering problem for these three points helps agents to find a few places that are best to put the fires off, from them with the least movement. Figure 5(b) shows the result of solving Maximal Covering problem for those three mentioned points in Fig. 5(a). At first glance it looks relatively simple to solve this problem but it is actually associated with NP-hard problems [9] and for cases involving many entities it becomes very complex.

8 Blockade Avoidance

Since police agents have distinctive but indirect impact on the other agent’s performance, most of MRL’s attention was on police agent’s coordination and cooperation with other agents. One of the problems we were facing as a result of using new clear method was about serrated blockades that trap agents (Fig. 6). It’s clear that this problem reduces the agent’s performance drastically.

Fig. 6.
figure 6

An agent caught up in fragments of blockage

Full size image

To overcome this issue and to keep things simple, we tried to clear the blockades so that no jagged blockades be there instead of handling the obstacle avoidance problem. we used Guideline strategy in RoboCup 2014 [10]. In this strategy, a police agent clears the roads along the guidelines to smoothly clear the road without any residues so that the agents can move along faster, without getting stuck. But that was not enough because sometimes we still could find those jagged blockades in some conditions, so in 2015 we introduced another approach alongside the existing one to handle the blockade avoidance.

In this approach, the agent tries to apply following steps to get out of the trap (Fig. 7).

Fig. 7.
figure 7

Ray move of a blocked agent (Color figure online)

Full size image
  1. 1.

    Make a convex hull over the blockade

  2. 2.

    Scale it to one and a half (brown polygon)

  3. 3.

    Find bounded rectangle of the scaled shape (green rectangle)

  4. 4.

    Make rays (lines from the trapping point to all directions)

  5. 5.

    Find the nearest intersection point of the bounded rectangle and those rays that does not intersect with the blockade

  6. 6.

    Try to move to the found point

  7. 7.

    You are likely free to go!

9 Drainage Basin Behavior

As we have mentioned before, police actions have indirect impact on other agents’ performance. One of the cases that highlights the importance of police decisions is at the beginning of the scenario, which the roads are usually crowded with blockages and moving from one part of the map to another is sometimes impossible. In such situations a small building on fire can turn into an inferno in a matter of a few cycles. It is obvious that the sooner the police agents can manage to open a path from different parts of the map to the fire-site, the higher are the chances for the fire brigades to get to the fire-site and put it off timely.

For RoboCup 2016 we added a new strategy to address the aforementioned issue, based on drainage basin that forms rivers, to deliver a quick access to a newly discovered fire site.

Note that we are assigning each active agent to a specific partition in map. In this strategy each police tries to open a path from the center of its assigned partition to the center of a neighbor partition that has a shortest distance based on A* algorithm to the discovered fire site. As a result, there will be at least one path from each partition to the fire site for fire brigades to access the burning area and put the fire off faster. Figure 8 shows the details.

Fig. 8.
figure 8

A tree structure formed from drainage basin behavior of the agents, trying to clear a path from center of their assigned partition to the center of the fire site

Full size image

10 Concluding Discussion and Future Works

As we have mention in the document, MRL team has tried many different approaches from 2010 to 2016. Our current strategy for coordination of agents is based on clustering using k-means algorithm and assigning the agents to the clusters using Hungarian algorithm. We added “Sticky Movement” for ambulance to optimize the performance of agents and “Drainage Basin Behavior” for police agents to open routes to fire as fast as possible. We also mentioned that we use maximal covering problem for optimizing the fire brigades positioning and minimize the time that is wasted by moving between different targets.

The guideline strategy combined with our blockade avoidance algorithm helps us to escape from traps that are created by serrated blockades.

We have also mentioned the Visual Debugger that accelerates the process of development and debugging of the code.

Our future work will be focused on finding and trying newer and more effective approaches instead of Hungarian, Voronoi and maximal covering. We have planned to implement our code using ADF for next year’s competition. We have also planned for implementing a new Move method for the kernel that can solve the problems mentioned in Sect. 8.

As another future work we also want to develop the kernel in order to make it more scalable and bring it closer to its’ primary goal which is to be usable in real world situations. We are planning to use Hadoop platform as our infrastructure in order to provide more processing power and high-availability.