Re: Proposal[Part #2: Simulation Rules]

From: bibaj@feld.cvut.cz
Date: Mon 15 Dec 2003 - 12:41:44 GMT


Dear Mohsen Izadi,

I reply on proposals concerning Simulation Rules.

I am missing any mention about inter-agent communication.
The rules for number and length of messages are very retrictive,
but I think it is useful for developing other strategies of
coordination and cooperation than in common MAS (even though
I think that the length of messages restricted to 80 charaters
is too exacting - what about 256 characters (standard Pascal String)?).

Next issue, proposing to discusion, is message format.
What about to allow message format from FIPA-ACL (mayby a bit modified)?
FIPA has been becoming a standard also in industry applications
and it is expectable, that for real application would be used!

To be honest, I have been unable to get why the message format was
restristed to: "senderID+messaga_content" with restriction, that agent can
choose messages only according to senderID. If we suppose digital communication
among robots and terrain systems of digital assistence, it is clear, that
the message eigher comes OK or not. And if comes undamaged, I think it is
nonsense to give such restrictions on it's content. If the authors wanted to
prevent a possibility of smuggling informations through message header, that
agent are allowed to read by every message, I think they succeeded, but
I think that such behaviour of agents could be treated as contravening of
communication rules as good as e.g. complete reading all the messages.

I propose to allow deviding the inter-agent communication message to "message
header" and "message content". The "message_content" would agree to
FIPA "content" and the "message_header" would contain the rest of FIPA
specification items, like "receiver", "conversation-id", "ontology", "language"
and so on, or optionally some message header extensions. These items from the
header could agents use ONLY for determination whether the message is to be
read or not. No storing of all incomming messages or their parts (except those
chosen for reading) or reasoning above all the incomming messages (except some
simple algorithm choosing messages for reading) would be allowed. All the
messages chosen not to be read would be immediatelly damaged. Any other
behaviour would be treated as contravening the rules and would cause
disqualification of the team.

I propose above mentioned inter-agent specification to discussion.

Best regards,
Jiri Biba
BB_Agents

> -------------------------------------------------------
>
> b) Simulation Rules
>
> b-1) In 2003 Competitions, there was a lower and upper
> limit on number of agents from each kind which is
> allowed in a gisini configuration. A proposal is
> to omit the lower limit, which means that we can
> have simulations with no FireBrigades or without
> any center agent.
>
> b-2) Simulations held in each day of competitions
> should be divided into Sessions. A 'Session' is
> a group of Simulations held on a specific disaster
> situation in a round. There are some rules about
> each session :
>
> 1)Teams should submit their code/binary before the
> start of session.
>
> 2)Teams do NOT know the disaster situation(map,
> gisini, *polydata) of the session before it
> starts.
>
> 3)Teams can [modify their codes]/[submit new code]
> between sessions.
>
>
> b-3) In 2003 competitions, the choice of disaster
> situations on a specific map was made by random.
> There, two teams A and B were chosen by random
> and a gisini from team A and *polydata from team
> B made the disaster situation.
> As all of us know, combining two randomly chosen
> units of a disaster situation may result in
> situations which is very easy(all teams get high
> scores) or impossible to solve(all teams get low
> scores). Furthermore random choice and
> combination may result simulating on similar
> situations in a round which is a waste of time.
> So we think that this process is not suitable
> and has a negative effect on quality of
> competitions.
> As a substitute for this process we propose the
> following choices :
>
> 1) There should be a committee having the task of
> working on and designing disaster situations for
> competitions. Disaster situations chosen for a
> competition should be able to test efficiency of
> agents' task in various conditions.
>
> 2) Teams should be divided into groups and all
> teams in a group should perform simulations on
> disaster situations prepared by the other
> groups. Here, there is no need to combine a
> random gisini and *polydata.
>
> We prefer the first choice.
>
> b-4) Its good to have sessions with maps which has
> not been released before competitions. We propose
> that there would be at least one new map which
> has not been seen by any team in 2004
> competitions. Blacksheep's MapGenerator, if
> improved, can be used to build such a map.
>
> b-5) Precomputation: An important point to be
> discussed and decided is whether precomputation
> is valid or against the rules.
> 'Precomputation' means 'An agent loads and uses
> MAP-SPECIFIC data which has been created and
> processed by another program and saved in a file.'
> (So if an agent loads and uses data which is not
> map-specific, it doesn't use precomputation.)
>
> We propose the following choices:
>
> 1) Any kind of precomputation is valid. Suppose
> that we have real rescue robots and we want to
> prepare a team of them to perform rescue
> operations in a specific city. So it's very
> logical if we give them some informations about
> this city which help them perform better rescue
> operations.
>
> 2) An agent can use precomputed data only if it
> has the following conditions :
>
> a) The data should have been generated by a
> computer program with no human interaction.
>
> b) Information of type A for all maps should
> have been generated by a single computer
> program.
>
> c) The computer program used for computing data
> of type A should work properly if it is given
> a new map.
>
> d) An agent should choose what data file to use,
> itself.
>
> e) Agents should be able to work if no
> precomputed data is present for a map.
>
>
> The task of checking whether a team's precomputed
> data satisfies these conditions or not, can be done
> by Technical committee. It also can be a Fair-Play
> Rule.
>
> 3) Any kind of precomputation is against the rules.
>
> We propose the second choice.
>
> b-6) Number of simulations in each round: In each
> round we should have as much number of
> simulations as possible.
> It's really impossible to compare two teams by
> comparing their scores in one or two simulations
> as there are many criteria which should be used
> to determine if team A is better than team B and
> it's almost impossible to check all these
> criteria using only one simulation in a single
> disaster situation.
> This fact becomes more serious as teams advance
> to semi-final and final rounds. There we need
> more simulations to determine the [nearly]
> correct rankings.
> For 'Final Round' We propose to have at least 5
> or 6 simulations on carefully prepared (not
> randomly chosen) disaster situations.
>
> b-7) Currently, teams, for testing their agents on
> their desired disaster situations, should make
> *polydata files as a source for determining which
> roads are blocked and which buildings are
> collapsed and to what extent.
> Here the problem is that most of us do not know
> exactly how to generate this files and how do
> these polygon regions in these data files affect
> the way buildings collapse and roads being
> blocked. We propose that the developer(s) of
> blockades and collapse simulator prepare a manual
> which discusses the relationship between the data
> in these files and the resulting collapse or
> blockades clearly.
>
> b-8) Regarding previous rules, the only set of agents
> that a team should have, is FireBrigades. It
> means that a team can perform a simulation
> without e.g. PoliceForce agents. This year we
> have two choices :
>
> 1) All teams should have all kinds of agents.
>
> 2) Like previous years! Here there are some
> points :
>
> a)If a team does not have a specific set of
> agents, what is connected to kernel instead
> of these agents to start the simulation?
> Here, also we can have 2 choices :
>
> a-1) Connect a sample/standard agent instead
> of these agents.
>
> a-2) Omit these agents from gisini file.
>
> b) If we decide to use a sample/standard agent
> instead of these agents, then what is the
> behaviour of this sample/standard agent? It
> should be defined in detail.
>
> c) Is it possible for a team to use a set of
> agents in simulation (i) and then decide to
> use sample agents instead of its own in
> simulation (i+1)?
>
> c-1) No! Each team requesting to connect sample
> agents instead of a set of agents should
> submit its request to technical committee
> before the competitions.
>
> c-2) Yes! But it should submit its request
> before the start of session (i+1).
>
>
>
> __________________________________
> Do you Yahoo!?
> New Yahoo! Photos - easier uploading and sharing.
> http://photos.yahoo.com/
>
>
>
>
>



This archive was generated by hypermail 2.1.3 : Mon 15 Dec 2003 - 12:42:39 GMT