RoboCup 2006 Rescue Simulation League Rules
May 23, 2006 Simulation Environment 1. Notication: (a) We focus on improving the stability of simulation environment. Although we should new crowd simulator which wins in 2005s infrastructure competition, due to some stability problems, we decided not to use it for RoboCup 2006 competitions. (b) That kernel 0.49 has some protocol modications which is documented in the ver. 0.49.* simulation package. Participating teams should adapt their agents to these changes. (c) We strongly encourage all participating teams to use the TCP protocol to connect to the kernel. UDP is still available in 2006 but it is deprecated any may be removed from future competitions. 2. Hardware environments: (a) PCs for competitions: We have competitions with 3 clusters. So, we play 3 games in parallel. And 5 PCs are used for 1 cluster. 5 PCs are used as 1 for kernel, 1 for 3D viewer and 3 for agents. (b) Specs. of a PC for kernel and agents: SN85G4,AMD64 3000+CPU, 1Gbyte DDR-DIMM, 80GB HDD Radeon 9600XT AGP, DVD-drive. (c) Specs. of a PC for 3D viewer: SN85G4,AMD64 3000+CPU, 1Gbyte DDR-DIMM, 80GB HDD GeForce6600 AGP, DVD-drive. 3. Software environments: (a) Simulation Environment: A Linux package will be used. (Now we are going to prepare FedoraCore 4) (b) Simulation Package: At the competition a package of the latest version will be used. This package is maintained by Cameron Skinner. Anyone can download the package from http://sourceforge.net/projects/roborescue/ i. Kernel should generate random IDs for units in each simulation. This means that the ID generated for a building in each simulation should be dierent from the next one. ii. The round hp/damage feature has been added. This rounds the values of HP/damage sent to agents to the nearest 1000 or 10 respectively. (c) Firesimulator: i. The initial amount of fuel in the buildings are randomized to some extent. ii. It should be: a new property called temperature representing the temperature of a burning building can be sensed by the agents that are within the radius of 10m from the center of the building. The sensed value is rounded to the nearest 50. 4. Maps: Five maps can be used. The maps to be used are determined by TC. (a) Maps known to all teams i. center of Foligno (Italy) ii. Kobe (1/10, 1/4)(Japan) iii. Virtual City (b) One or more random map prepared at the competition site by the Technical Committee. 5. Agents: Agents shall be implemented by Teams. (a) Numbers: The numbers of agents and ignition points specied in gisini.txt are shown in Table 1. The numbers are open to contestants before games. 6. Civilian Agents: We use Camerons civilian agents which included in the latest simulation package.
Table 1: The number of agents and ignition points speced in gisini.txt Entity Min. Max. Fire Brigade Police Force Ambulance Civilian Fire Brigade Center Police Force Center Ambulance Center Refuge Ignition points The maximum number of initial burning buildings will increase to 30. However these buildings will be grouped into no more than 8 dierent areas - i.e. there will be up to 8 initial res, but they might begin with several burning buildings each. 7. Parameters uses in games: (a) parameters in cong.txt[kernel]: Default parameters are used. Default parameters are used. round_hp_and_damage: true send_voice_synchronously: false # New options for 2005 send_civilians_at_start: false ################################################# # new/modified options for the 2004 competition. # GIS generates random IDs for units in each simulation. random_IDs : true # KA_HEAR_TELL and KA_HEAR_SAY are added to the RoboCup Rescue protocol. additional_hearing : true # The maximum power of one extinguish action. (-1 to unlimit) max_extinguish_power_sum : 1000 # The maximum extinguish power for each nozzle. (-1 to unlimit) max_extinguish_power : -1 # The maximum number of nozzles for one extinguish action. (-1 to unlimit) max_nozzles : -1 max_extinguish_distance: 30000 ################################################ # new options for the 2003 competition. # avoid slowdown for spredding fire. send_far_fire_changed_only : true # notify_unchangeable_informaion : false // Deprecated # avoid that the fire simulator becomes some laps behind. step : 1000 2
# use new synchronization mechanism. # use_gettimeofday : false // Deprecated # An agent can discover a fire within a distance D[m] roughly proportional # to its fieryness, where # D = K * (cycles from the start of burnup) # If fire_cognition_spredding_speed >= 0, K is given by # fire_cognition_spredding_speed. Otherwise, K is infinite. fire_cognition_spreading_speed : 10000 # If simulate_tank_quantity is true, tank quantity properties are # decreased by extinguishments. If tank is empty, extinguishments # should be faild. simulate_tank_quantity : true # Tank quantity properties are increased by tank_quantity_recovery_on_refuge # if the agent is in a refuge. tank_quantity_recovery_on_refuge : 1000 # same as max_extinguish_power # Gives the maximum quantity of a tank. tank_quantity_maximum : 15000

# not new, but the subject of the discussion say_max_bytes : 256
################################################ # new options for the 2002 competition. ignore_nozzle_position : true area_per_repair_cost : 20000000 round_down_quantity : false accept_multiple_nozzles : true near_agents_rescuable : true steps_far_fire_invisible : 5 steps_agents_frozen : 3 miscsimulator_supports_load : false : (b) Other parameters: simulation time: 300 steps, range of eyesight is 10m, range of voice is 30m, power of earthquake: shindopolydata.dat, galpolydata.dat Competition: 1. There shall be two competitions: Agent competition and infrastructure competition: (a) Agent Competition: i. The Technical Committee shall design the disaster situations to be used during the competitions. Disaster situations chosen for a competition shall be able to test eciency of agents task in various conditions. ii. Simulations held in each day of competitions shall be divided into Sessions. A Session is a group of Simulations held on a specic disaster situation in a round. 3
iii. Teams shall submit their code/binary before the start of session. iv. Teams shall NOT know the disaster situation (map, gisini, *polydata, random seeds, *.rays) of the session before it starts. v. Teams can either modify their code or submit new code between sessions. vi. Teams shall have all kinds of agents and must connect the correct number of agents as specied for the current session. vii. Precomputation dened as an agents loading and using MAP-SPECIFIC data which has been created and processed by another program and saved in a le is allowed under the following conditions: A. The data should have been generated by a computer program with no human interaction. B. Information for all known maps should have been generated by a single computer program. C. The computer program used for computing data for known maps should work properly if it is given a new map. D. An agent should choose the data le to be used itself. E. Agents should be able to work if no precomputed data is present for a map. F. The source of the precomputation program shall be open after the competition. viii. Number of simulations in each round: In each round there shall be more than one simulation on the same map. The number shall be determined and announced on competition site by TC. The score for that round shall be determined by nding the average of the points for the runs. ix. Evaluation Rule: We will use a new scoring rule of German Open 2005. The scoring was intended to take the new aspects of the re simulation into account. The higher V value for a map, the better rescue operation. V=(P + S/Sint) * sqrt(B/Bint) P: number of living agents, Sint: total HP of all agents at start, S: remaing HP of all agents, Bint: total area at start, B: area of houses that are undestroyed, the following rule was used to compute the value B: 0 no penalty 1,5 1/3 of area counted as destroyed 4 water damage, also 1/3 area counted as destroyed 2,6 2/3 of area considered as destroyed 3,7,8 whole building considered as destroyed x. Valid games: A game may fail with various reasons, although simulation package is debugged. In that case, only ONE more simulation is permitted. When the second game also failed, we judge as follows: A. In the case that the simulation continue to the end, the point of the second game is used. When you try the second game, the point of the rst game is not used. B. In the case that the simulation does not continue to the end, the point is 0. Even if you get the point of the rst game, you cant choose the point. When you try the second game, the point of the rst game is not used. The point at the game is treated on the principle that the continuation should not be in the teams favor. xi. It is the responsibility of teams to ensure that their code works correctly with the provided simulators. Although the technical committee makes every attempt to provide a reliable simulation environment the committee accepts no responsibility for any kind of software failure at competition time. Bugs reported at competition time will be xed at the rst opportunity but generally this will be after the competition has ended. xii. Others: All the conditions for a particular disaster situation, including random numbers, etc shall be identical for all the teams. (b) Infrastructure competition: Improvements in simulation components, such as disaster simulators, GIS, kernel, viewers, civilian agents and so on, are essential in rescue simulations. This competition tests the performance of 4

these components. The awarded team will be requested to provide the component for next years competition. Teams will present their tools in front of all teams. Ranking will be decided with votes from TC members and teams. 2. Open source policy: (a) Source code les must be open immediately after games when other teams request to guarantee fair play and to encourage community activity after competition. (b) Log les and related parameter les will be open.