From: Mazda Ahmadi (mazdaah@hotmail.com)
Date: Sat 12 Oct 2002 - 16:24:01 GMT
Dear all,
I wrote a complete proposal, but since the deadline passed, I'm not going to
send it to the list. Thanks for seting a deadline at Fukuoka, not mentioning
anything about it. And at the last days we see a proposal in the mailinglist
and the deadline is over!!
Once again I want to admit that the rule proposal is specially good for our
team. I mean by 'good', that these rules can be easily integrated in our
architecture.
But still the proposal has lots of shortcoming in sense of a good test-bed
for multi-agent research and also simulating rescue mission. I know we can
use RoboCupRescue as we want for multi-agent research, but it's good that
the reseach can also be used in rescue competitions.
The main and most important shortcoming is the 12kkId. As you may know, ACL
is one of the most important issues in multi-agent systems. defining such a
restrictive ACL, is kind of estrange. Where in the world of multi-agent
systems you can find such a restrictive ACL?
Takeshi, please please don't try to set the rules for your team. We know
that your team (YabAI or YowAI) uses 12kkId as communication language. But
be realistic and indicate a multi-agent test-bed that uses such an
restrictive ACL.
I'm not going to discuss more about the proposal, since Prof. Takahashi has
made decision to set the rules.
Regards,
-Mazda
>From: Morimoto Takeshi <morimoto@takopen.cs.uec.ac.jp>
>To: r-resc@ISI.EDU
>CC: Sébastien Paquet <spaquet@iad.ift.ulaval.ca>
>Subject: Re: [rescue:5532] Re: Proposals for RoboCupRescue 2003 regulations
>Date: Sat, 12 Oct 2002 23:33:10 +0900
>
>Dear RoboCup Rescuers, and Sebastien,
>
> > The structure seems relly restrictive.
>
>We agree that our proposal II is very restrictive. It is important
>for us to discuss with a message definition, so we would like to
>counter with slightly modified another proposal, although, we do not
>back down on our proposal II.
>
>Of course, we understand that the deadline of proposal for the
>RoboCup2003 has already been over, and this alternative proposal may
>be rejected immediately. However, we think this kind of discussion
>will be fruitful for future RoboCupRescue. We will appreciate your
>comments.
>
>Definition of Messages --- Less Restrictive Version
>
>Differences of this proposal from the previous one are:
> - A message can specify its receiver, and
> - A message can contain a numeric value for arbitrary usage
> besides an ID.
>It is a major premise that this proposal does not change the current
>kernel.
>
>(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) 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 compatibility, but the contents of msg is limited
>definitely.
>
>(2-1) The id field must be the ID of the sender.
>
>(2-2) The msgSize and msg is ether one of:
>
> 12rk format: {12, "rrrrrrrrrrkk"},
> 14rkd format: {14, "rrrrrrrrrrkkdd"},
> 22rki format: {22, "rrrrrrrrrrkkiiiiiiiiii"}, or
> 24rkid format: {24, "rrrrrrrrrrkkiiiiiiiiiidd"}.
>
>where k's, i's, r's, and d's are digits from 0 to 9 (ASCII codes 0x30
>to 0x39).
>
>(2-2-1) 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 12, 14, 22, and 24 are integers denoting the message
>length (msgSize).
>
>(2-2-2) 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.
>
>(2-2-3) The ten digits number rrrrrrrrrr denotes zero or the ID of a
>receiver agent. Zero means the message is sent to unspecified
>receivers. The receiver ID may be used as the subject of the message.
>
>Each agent can decide either to hear or not by knowing the sender and
>receiver ID. Additionally, each agent does not need to forget the
>sender and receiver, even if the agent decides not to hear the
>message.
>
>Note that if the receiver denotes a different kind of platoon agent,
>the message told by an agent cannot be passed to the receiver
>directly, because there is no means for an agent to tell a different
>platoon agent directly. Moreover, civilian agents do not use the
>receiver ID (i.e. they must set zero to the receiver ID, and must not
>refer one), because it is unnatural that they know IDs of platoon
>agents.
>
>(2-2-4) Two digit number dd denotes the adjunct which can be freely
>used by agent developers. For example, dd may mean a time, a
>buriedness, an ID abbreviated through agent's negotiation.
>
>(3) 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, where "ii" and "rr" are iiiiiiiiii and rrrrrrrrrr, and
>"d1"/"d2" is the first/second digit of the dd.
>
>kk sentence semantic
>-------------------------------------------------------
>00 There is a human at place[ii], whose buriedness is [dd].
> [rr], there is a human at place[ii], whose buriedness is [dd].
>01 Nobody is buried at place[ii].
> [rr], nobody is buried at place[ii].
>02 The fieryness of the building[ii] is [dd].
> [rr], the fieryness of the building[ii] is [dd].
>03 The road[ii] has [d1]/[d2] passable lines toward its HEAD/TAIL.
> [rr], the road[ii] has [d1]/[d2] passable lines toward its HEAD/TAIL.
>
>04 Go to place[ii].
> Agent[ii], go to place[ii].
>05 Get away from place[ii].
> Agent[ii], get away from place[ii].
>06 Rescue a human[ii]. == Help me.
> Agent[ii], rescue a human[ii].
>07 Rescue a human at place[ii] == Help me at place[ii].
> Agent[ii], rescue a human at place[ii].
>08 Load a human at place[ii].
> Agent[ii], load a human at place[ii].
>09 Load a human[ii].
> Agent[ii], load a human[ii].
>10 Extinguish the building[ii].
> Agent[ii], extinguish the building[ii].
>11 Clear the road[ii].
> Agent[ii], clear the road[ii].
>
>12 [rr] is at place[ii].
>13 [rr] are rescuing a human at place[ii].
>14 [rr] are rescuing a human[ii].
>15 [rr] are loading a human at place[ii].
>16 [rr] are loading a human[ii].
>17 [rr] are extinguishing the building[ii].
>18 [rr] are clearing the road[ii].
>
>19 [rr] will go to place[ii].
>20 [rr] will rescue a human at place[ii].
>21 [rr] will rescue a human[ii].
>22 [rr] will load a human at place[ii].
>23 [rr] will load a human[ii].
>24 [rr] will extinguish the building[ii].
>25 [rr] will clear the road[ii].
>
>26 [rr] have already rescued a human at place[ii].
>27 [rr] have already rescued a human[ii].
>28 [rr] have already loaded a human at place[ii].
>29 [rr] have already loaded a human[ii].
>
>[More to be added.]
>
>(4) We wish civilian agents to speak more kinds of sentences in the
>above syntax, for example:
> "There is an injured at ...",
> "The building ... is burning.",
> "The road ... is blocked.",
> "I loose my way.",
> "I am hungry." and other non-informative sentences etc.
>So civilian agents can play a more important role as information
>sources than before, but some information are not useful for search
>and rescue.
>
>--
>Prof. Ikuo Takeuchi,
>Takeshi Morimoto,
>Hiroki Endo
>The University of Electro-Communications, Japan
Mazda Ahmadi
http://ce.sharif.edu/~m_ahmadi
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
This archive was generated by hypermail 2.1.4 : Sat 12 Oct 2002 - 16:48:31 GMT