Re: Proposals for RoboCupRescue 2003 regulations

From: Sébastien Paquet (spaquet@iad.ift.ulaval.ca)
Date: Fri 27 Sep 2002 - 19:46:46 GMT

  • Next message: Jiri Biba student: "Re: Re: [rescue:5501] Questions about kernel"

    I have one comment about the rules. It's about the rule number II.
    Restriction on Tank Capacity of Fire Engine.

    I haven't try to use this rule, but at first sight, it seems to me that the
    refilling time is quite long (15 cycles to refill the tank). Also, if there
    were only one refuge, it could take a long time for the fire brigade just to
    go to the refuge to refill its tank.

    In reallity, a fire brigade doesn't have to stop extinguishing a fire to go
    refill its tank. Normally, there are fire hydrant in the city, so the fire
    brigade can plug there hoses in it an get water. Maybe the agent could loose
    some time pluging its hose and unpluging it, but it wouldn't have to stop
    extinguishing to go refill its tank. I don't know the complexity of adding
    fire hydrant in the simulation, put for me it's more reallistic. Of course,
    some fire hydrant could be broken by the earthquake, but not all of them.

    Maybe I'm completly wrong and I haven't visit the right cities, but for me
    using fire hydrant is more realistic than going to a refuge to refill a
    tank.

    Sébastien Paquet
    -----------------------------------------------------
    Ph.D. student (DAMAS laboratory)
    Département d'informatique, Pavillon Adrien-Pouliot
    Université Laval (Québec), Canada, G1K-7P4
    1-418-656-2131 ext. 4505
    www.damas.ift.ulaval.ca/~spaquet
    -----------------------------------------------------

    ----- Original Message -----
    From: "Morimoto Takeshi" <morimoto@takopen.cs.uec.ac.jp>
    To: <r-resc@ISI.EDU>
    Sent: Friday, September 27, 2002 12:56 PM
    Subject: 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 - 20:16:14 GMT