Proposals for RoboCupRescue 2003 regulations

From: Morimoto Takeshi (morimoto@takopen.cs.uec.ac.jp)
Date: Fri 27 Sep 2002 - 16:56:02 GMT

  • Next message: Sébastien Paquet: "Re: Proposals for RoboCupRescue 2003 regulations"

    Dear RoboCup Rescuers,

    We propose the following improvement of the RoboCupRescue regulations
    for the 2003 League:
      I. Restriction on Fire Cognition
      II. Restriction on Tank Capacity of Fire Engine
      III. Definition of Messages
      IV. Schedule for Rule Decision
      V. Morimoto's Viewer

    These proposals will make RoboCupRescue Simulation System more
    attractive as a MAS testbed, we hope. We will appreciate your
    comments.

    I. Restriction on Fire Cognition

    We propose a restriction on the cognition of distant fires, because it
    is unnatural in the current rule that every agent can know all fires
    despite of their location and fieryness. Our proposal is that 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)
           K: constant.
    We propose K is 10[m/cycle] by our experimental results. In the current
    rule, we can say that K is set infinite.

    II. Restriction on Tank Capacity of Fire Engine

    We propose a restriction on tank capacity of a fire engine, because it
    is unnatural that every fire brigade can continue on flushing forever
    without refilling its tank. Our proposl is that each fire brigade must
    refill the tank with water when it becomes empty.

    (1) Tank capacity is 15[m^3] for every fire engine. This capacity is
    determined based upon some experiments.

    (2) Each fire brigade can refill the tank at any refuge. The tank can be
        refilled with 1[m^3] water in each cycle when the fire brigade is at a
        refuge; the speed of refilling is the same as the maximum speed of
        flushing in each cycle.

    III. Definition of Messages

    We propose a simple and tentative definition of messages among agents
    toward a common interagent language.

    (1) A center agent can hear up to N sentences in a cycle, where
           N = 2 * (number of its platoon agents).
    So the center agent can play a more important role than before. To sum up,

                    | AK_TELL/SAY | AK_HEAR
      --------------+-------------+---------
      Platoon agent | 4 | 4
      Center agent | 4 | N

    (2) Each agent must completely ignore and discard the messages it
    decides not to hear. It cannot use the information WHO spokes and
    WHO didn't speak, by referencing the messages it ignores.

    (3) A sentence should conform to the following format:

            int id
            int msgSize
            char* msg

    which is not different from the current one of the AK_TELL/SAY's message,
    for the compatibility reason, but the contents of msg is limited definitely.

    (3-1) The id field must be the ID of the sender.

    (3-2) The msgSize and msg is ether one of:

        +---+---+---+
        | 2 | k | k | (2kk format)
        +---+---+---+

    or

        +---+---+---+---+---+---+---+---+---+---+---+---+---+
        | 12| k | k | i | i | i | i | i | i | i | i | i | i | (12kkID format)
        +---+---+---+---+---+---+---+---+---+---+---+---+---+

    where k's and i's are digits from 0 to 9 (ASCII codes 0x30 to 0x39).
    Two digit number kk denotes the kind of sentence, which can be freely
    defined by the agent developer. So at most 100 kinds of sentences can
    be uttered in a team (maybe enough for the Version 0). The numbers 2
    and 12 are integers denoting the message length (msgSize).

    The ten digits number iiiiiiiiii denotes the ID of an object or an agent
    existing on the map. The kernel does not check the validity of the
    denoted ID at run time. However, we hope no one would represent
    something else by this ten digit number.

    If a sentence does not include an ID, the former simple 2kk format should
    be used.

    (4) The half of sentence kinds, that is, sentence kind from 0 to 49,
    are reserved for a common interagent language. The following is
    a tentative plan.

    kk sentence semantic
    -------------------------------------------------------
    00 A human is buried deeply at place[id]
    01 A human is buried at place[id]
    02 A human is buried shallowly at place[id]
    03 Nobody is buried at place[id]

    04 The building[id] start burning
    05 The building[id] is burning
    06 The building[id] is burning strongly
    07 The building[id] is not burning

    08 The road[id] is blocked toward its HEAD and TAIL
    09 The road[id] is blocked toward its HEAD
    10 The road[id] is blocked toward its TAIL
    11 The road[id] is passable toward its HEAD and TAIL
    12 The road[id] is passable toward its HEAD
    13 The road[id] is passable toward its TAIL

    14 Help me
    15 Go to place[id]
    16 Get away from place[id]
    17 Rescue a human at place[id] == Help me at place[id]
    18 Rescue a human[id] == Help me
    19 Load a human at place[id]
    20 Load a human[id]
    21 Extinguish the building[id]
    22 Clear the road[id]

    23 We are at place[id]
    24 We are rescuing a human at place[id]
    25 We are rescuing a human[id]
    26 We are loading a human at place[id]
    27 We are loading a human[id]
    28 We are extinguishing the building[id]
    29 We are clearing the road[id]

    30 We will go to place[id]
    31 We will rescue a human at place[id]
    32 We will rescue a human[id]
    33 We will load a human at place[id]
    34 We will load a human[id]
    35 We will extinguish the building[id]
    36 We will clear the road[id]

    37 We have already rescued a human at place[id]
    38 We have already rescued a human[id]
    39 We have already loaded a human at place[id]
    40 We have already loaded a human[id]

    [More to be added.]

    IV. Schedule for Rule Decision

    For agent researchers to develop agents with stable conditions and
    environment, we propose moving forward the schedule for rule decision.

    2002
    September: deadline of proposals
    October: deadline of prototype submission
    November: voting for proposals
    December: announcement of rules (first version)

    V. Morimoto's Viewer

    We propose adopting the Morimoto's Viewer as one of viewers used on
    competitions. This viewer highlights agents' action by animating, and
    demonstrated on RoboCup2002. For details to:
      http://ne.cs.uec.ac.jp/~morimoto/

    --
    Prof. Ikuo Takeuchi,
    Takeshi Morimoto,
    Hiroki Endo
    The University of Electro-Communications, Japan
    


    This archive was generated by hypermail 2.1.4 : Fri 27 Sep 2002 - 17:40:11 GMT