Proposals for RoboCupRescue 2002 regulations (First draft)

From: Ikuo Takeuchi (nue@nue.org)
Date: Tue 27 Nov 2001 - 10:55:36 GMT


Dear RoboCup Rescuers,

[The following proposals are a little updated version which we posted
in Japanese at this noon.]

We propose the following improvement of the RoboCupRescue regulations
for the 2002 League. T. Morimoto is now remaking the problematic
traffic simulator in Java from scratch. He does take only a couple of
days to get the new simulator to start running! We hope the 2002
League will use this new traffic simulator. But we welcome criticisms
and discussions.

We expect agent developers will not be much affected by this change.
But it will be useful to know the internal model of Morimoto traffic
simulator. So we describe it in some details.

Other than the traffic simulator, we propose improvement of some rules
related to the blockade simulator, fire simulator, miscellaneous
simulator, civilian agents, and kernel. So far, almost all proposals
are proved to be feasible for implementation; it has been clarified
where and how program code should be changed.

These proposals will resolve almost all problems revealed in the 2001
League, we hope. Note that our proposals are only related to the
Version 0 Simulation System, not the Version 1, which will be used from
the 2003 League.

I. Traffic Simulator

Command level compatibility with the current traffic simulator is most
significantly regarded on remaking the simulator. However, a few may
affect agent developers in conjunction with their movement strategy.
So we describe the internal modeling of the traffic simulator in some
details.

Morimoto is now working to make the modeling more precise and rigorous.
It will be soon reported.

(1) There are traffic lanes on every road.

We wish the viewer can display lanes if required (Morimoto's simple
viewer can display them individually discriminating passable or
blocked). If one of the lanes, usually outer lane, is blocked, a car
on the lane should change the lane at the blockade. A car selects
the lane randomly except for its target road.

(2) Signal lights and restrictions on left or right turn are not
considered.

All signal lights are turned off in the disaster. We propose to
restrict in the Version 0 that cars in the map are only for polices,
ambulances and fire brigades. No civilian agent drives a car. So we
need not consider these restrictions.

(3) Central strip of a road and width of a side walk are not
considered.

The current simulator also ignores them.

(4) The velocity of a car is calculated on the following model at every
second (or at every t seconds, where t is a divider of 60).

A car moves at the highest possible speed, keeping a safe distance
from an object before it, so that, typically, distance between the
successively running cars equals to the moving distance.

    dx = forward.x - x; /* distance from the forward object */
    A = MAX_ACCELERATION;
    B = MIN_SAFE_DISTANCE(forward.ObjectType);
    double a = (dx >= B) ? A * (Math.sqrt(1 + 2 * (dx - B) / A) - 1) - v
                         : 0; /* - v for braking distance */
    if (a > MAX_ACCELERATION) a = MAX_ACCELERATION;
    double result = v + a;
    if (result > MAX_VELOCITY) result = MAX_VELOCITY;
    return result;

A car should stop if it encounters one of the following objects.

     Stopped moving object such as fire brigade now busy in extinguishing
     or ambulance now digging buried civilian.

     Node at which the target building stands.

     Crosspoint where the road in front of the car is wider than or
     equal to the road on which the car is now moving and exiting.
     (If there are more than one car at a crosspoint of roads of same
     width, which car starts first is randomly selected.)

     Blockade by debris on the road, which is located at the midpoint
     of the road.

MAX_ACCELERATION is determined so that a car gets to its maximum speed
within 5 seconds.

(5) A blockade is assumed to be located at the midpoint of a road, so
that agents can see it even if the road is longer than 20 meters
(double of agent's sight range).

(6) An agent can stop at any node or at any point of a road. However,
it is assumed that an agent can stop at a node only if it is the
target of the agent (otherwise, it can stop on a node only
incidentally by the double floating arithmetics). So protocol for
agent movement commands is not changed.

   *** For implementation clarity, additional remark may be
   proposed in a few days, in conjunction with the case a number
   of cars want to move to a same target ***

(7) Any building can be immediately entered when an agent reaches the
associated node, because there is no means to represent an intermediate
position between the node and the entrance.

(8) A car can stop immediately in a turn. That is, the traffic
simulator tries to simulate the traffic smoothly at every second as
far as possible, but it cannot cope with a sudden agent decision to
stop at a location at the beginning of the next turn, so that a car
running at its top speed till 59th second seems to stop at 60th second
suddenly. However, from the viewpoint of a minute-level resolution
observer, it can be understood that a car which finds something urgent
over-accelerates at the last moment and makes full braking in a
violent but physically admissible manner. This phenomenon rises from
the resolution discrepancy between the traffic simulator and the whole
simulation system of Version 0.

(9) Civilians do not either use cars or run in the terrible disaster;
they walks. There are alternative two plans, but the latter plan 2 is
desirable.

 (plan 1) Civilian's walk is independent of car traffic.
 (plan 2) Cars for rescue are prioritized in the traffic, so civilians
          have to stop to cross a road if such cars are passing the road.

Civilian can walk at 4km/h, or it stops (i.e., 0km/h). We hope civilians
should turn if they encounter a blockade.

(10) When an agent finds it cannot move as it desires, it can get the
reason by sensing the visual information supplied by the kernel.
Currently, an agent cannot know by which reason it cannot enter a long
road, traffic jam or blocked. In addition, the new traffic simulator
will provide information why it cannot move to its target on a tracing
file for agent developers' debugging convenience.

(11) The format of positionHistory of an agent will be changed so that
it represents the full transport path of the agent in the last turn,
or empty if the agent didn't move. (If the viewer depends strongly on
the current format, we will not change the format, however.)

(12) A building cannot be passed through, at least, by a car. The current
GIS does not include a building with more than one entrance (certified by
S. Endo). Alternative idea is that a building which can be passed through
can have more than one entrance. [GIS matter]

(13) The maximum speed of a car is lowered from 57km/h to 30km/h or
40km/h, which is more natural in the disaster environment.

(14) If a car wants to turn back when it encounters blockade or
something, it has to stop and then turn. If a car wants to change the
lane, it has to make sure there is no car moving behind the target
lane. If there is one, it has to stop and then change the lane.

(15) Currently unused positionOffset is validated in order to locate
agents more precisely on a road. This will necessitate a little
change in the kernel. We certified no other simulators use
positionOffset.

II. Blockade Simulator

There is one unnatural point in this simulator. We propose to modify
it as follows. The modification point is known.

(1) Let repairCost be proportional to the road length, that is, blockade
on a longer road takes much time to remove.

    repairCost = (block * roadLength + (CONST - 1)) / COSNT
       where, for example, CONST = 10000 * 2000

To maintain the compatibility, CONST will be determined so that
typical blockade on a 2m wide and 10m long road takes one minute. (It
seems still too short but it is a typical value of the current
simulator.)

III. Fire Simulator

In the current fire simulator, water quantity 1000 (= extinguishing
power) has drastically different power than 999; that is, 999 water
has no effect for extinguishing. This is a known bug. But even if
the bug is fixed, it does not yield any interesting AI problem,
because there is no limitation of total water supply in the Version 0.
A fire brigade can always use maximum amount of water if it wants.

However, we propose the following complication in the Version 0
simulator.

(1) Multiple Hoses to different directions (proposed by S. Kanazawa)

A fire brigade can extinguish two fires simultaneously by splitting
its extinguishing power 1000 into two 500's. Extinguishing power 500
is not enough for a big fire, but efficient for an early small fire.
So if a fire brigade decides to split its extinguishing power for near
two early fires, it can extinguish both fires twice as quick as it
cascades the full power to the both.

This improvement needs further investigation of the program code,
though we already found some of relevant places.

IV. Miscellaneous Simulator

This simulator governs the destiny of the victims. This is suspected
to be a source of the known low repeatability of the total simulation
result. Damages of buried victims are fluctuated by using random
numbers throughout the simulation. So, if an ambulance helps a
victim, this randomness affects other buried people's destiny. We
propose to eliminate this kind of random function usage in several
places of the miscellaneous simulator to stabilize the result, so
that, in principle, initial setting determines all victim's damage
history other than that caused by fire. (In our primary experiment,
simulation results become more stable.)

In addition, we propose the following:

(1) An ambulance can AK_RESCUE or LOAD a victim on the same place or
near position in a neighbor place (Here, place denotes road or node).
Currently it is allowed to do so only for a victim on exactly the same
place.

(2) A damaged rescue agent cannot immediately restart its activity
even if it has run into a refuge or hospital. How long it cannot
restart depends on the amount of damage; for example,

  time for restart = damage when it runs into refuge / CONST

where CONST is adjusted so that seriously damaged agent can restart
at least after 10, or more plausibly 20 turns.

V. Civilian Agents

The current civilians are too verbous and stupid to be rescued. We
propose a new set of civilians which is now being developed by
K. Shinoda, or if it can't be in time, simple civilians developed by
T. Koto.

VI. Kernel

There are a few problems that can be coped with only by changing the
kernel. We propose the following. Agent developers who utilized the
"hole" of the kernel must be careful. All changes are declared to be
feasible by T. Koto, the kernel developer.

(1) An early fire cannot be discovered immediately by a distant fire
brigade; that is, it takes a couple of turns for a fire brigade to
discover a distant early fire. An early fire more than, say, 100m far
away takes 2 or 3 turns to be discovered. However, the current kernel
structure has little room to realize this change in a full
specification. So, we propose that an early fire at clock 0 can be
sensed by a fire brigade more than 100m far away, only after clock 3
or 4.

(2) Any agent cannot know other agent position at the beginning. (The
current regulation is unbelievably unusual!)

(3) Any agent cannot know other agent positionHistory. (This is a
little controversial, but if we want to allow an agent to know another
agent's most recent positionHistory within the sight range of the
agent, the kernel has to do a big work to cut off invisible part of
the positionHistory.)

(4) So called "start dash" is inhibited. That is, no agent can run
through the road before it is blocked at clock 0. (This is a sort of
bug of the kernel.)

              Tetsuhiko Koto, Takeshi Morimoto,
              Sin'ichi Miyazawa, Satoshi Endo,
              Susumu Kanazawa, Tomoyuki Takai,
              Prof. Ikuo Takeuchi
              Takeuchi Lab in the University of Electro-Communications



This archive was generated by hypermail 2.1.4 : Sun 22 Sep 2002 - 18:52:58 GMT