Re: Proposals for RoboCupRescue 2003 regulations

From: Sébastien Paquet (spaquet@iad.ift.ulaval.ca)
Date: Wed 09 Oct 2002 - 20:20:24 GMT

  • Next message: Morimoto Takeshi: "Re: [rescue:5532] Re: Proposals for RoboCupRescue 2003 regulations"

    I have a question about the rules. It's about the item III Definition of
    Messages.

    The structure seems relly restrictive. I know those communications are
    supposed to be by radio, so we cannot send a lot of information, but why
    there is no field for the receiver. There is no way to tell an other agent
    to do an action. (ex. Agent 5, go extinguish the fire at the building 10). I
    think this kind of messages is important and reallistic. In real life,
    people ca tell to which person they are speaking to. This simple addition
    will also help when choosing whitch message to read.

    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 : Wed 09 Oct 2002 - 20:49:02 GMT