Hi everyone.
Over the last couple of weeks the technical committee have been discussing
various proposals for rule changes and simulator extensions for 2005. We
would now like to open the discussion to the general community, and will
prepare a set of proposals for voting on December 6. Teams will be able to
vote for rule changes and which simulator extensions to include until
January 3, followed by the announcement of the official rules for 2005 on
January 10. The kernel and simulator code will be frozen on March 22,
leaving 16 weeks for teams to make sure their agents work well with the
new simulator.
All these dates and the various proposals for discussion will be available
from the official 2005 web page http://kaspar.informatik.uni-freiburg.de/~rcr2005/index.php at some point.
Now, the proposals:
1) More fires
It was suggested that the maximum number of initial fires be increased
from 8 to a higher number. The suggestions ranged from 30 to 100. The
intention of this suggestion is to make sure that teams really do not know
much about the state of the world when the simulation begins, just as they
would in real life. There was concern than having up to 100 fires to begin
with might result in essentially random scores for the teams because the
situation may be simply impossible.
2) TCP/UDP
Implementation of TCP instead of UDP for communication is under way. A new
version of the kernel and simulators, along with libraries for
communicating with the kernel, will be out at some point for testing.
3) Modificaiton of communication protocol
It was suggested that the communication protocol should be modified to
include a length field for each property. This would allow simulators and
agents to ignore properties that they do not know or care about by simply
discarding the appropriate number of bytes from the input stream.
Currently, if a new property is added (for example a z-coordinate) all the
simulators must be updated to cope with the new data. Adding the length
field will allow all modules to handle new data automatically.
4) Deterministic message loss
Adding the ability to deliberately lose messages in order to simulate
poor communication channels was suggested. There was some concern that
this will have to be implemented in a fair manner to avoid disadvantaging
teams that happen to lose important messages just because they are
"unlucky". Perhaps extending the simulator to include a communication
module, instead of handling it all inside the kernel, would be a solution.
Similarly, perception (generation of KA_SENSE messages) could be moved
into a seperate module.
5) Aftershocks
These were supposed to be included in 2004. Hopefully they will actually
arrive in 2005. Concern was raised that buildings may collapse during an
aftershock, potentially trapping all ambulance agents halfway through the
simulation. This will cause that team to perform particularly badly,
simply due to "bad luck". It was suggested that perhaps the collapse
simulator could be modified to reduce or eliminate the risk of agents
being trapped by aftershocks.
6) Communication channels
It was proposed that the communication model be changed from the current
situation where fire agents can only talk to other fire agents (and their
station) to a more fine-grained model based on the idea of "channels".
Each channel has a specified bandwidth, but any number of agents can
listen to each channel. Each agent can listen to a small number of
different channels. The channels can represent different forms of
communication - radio, cell phone, talking, laptop with wireless etc.
For example, we might have 10 different radio channels, each of which can
send 1024 bytes per timestep. Fire agents might be able to listen to one
radio channel at a time whereas fire stations could be able to listen to
and broadcast on 6 channels simulataneously.
In this way teams of different types of agents can be formed without any
message lag.
7) Capabilities
It was suggested that the abilities of agents be changed from the current
system to a "capability based" system. Instead of having "fire agents" and
"police agents", for example, each agent would have a set of capabilities
that describe what actions they can take. Thus, the ten fire agents would
become, for example, 6 agents that can extinguish fires using 1000 units
of water per timestep, 3 agents that can extinguish fires using 2000 units
of water per timestep and one "tanker" agent that holds 50,000 units of
water and can replenish other water-carrying agents at a rate of 5000
units per timestep.
This would allow new types of agents to be defined easily - we simply
change the capability descriptions to generate new agents that can do
different things. Simulators will have to check that the agent can
actually perform the actions it wants to.
8) Extension of AK_MOVE
It was proposed that the AK_MOVE command be modified to allow for agents
to change their movement orders during the timestep. This is to alleviate
the current problem where an agent simply stops for the rest of the
timestep when it hits a blocked road, whereas in real life it should
immediately turn around and try a different path. A potential solution is
for agents to send a function that returns the path they wish to travel
instead of simply sending one path, or to use a "plugin" based system.
I think that is all for now. Please discuss these proposals, and any other
ideas you might have, until December 6. The Technical Committee will then
collate all the discussions and decide on the options for voting.
Cheers,
Cameron Skinner
2005 Technical Committee chair
-- Cameron Skinner Artificial Intelligence Group Department of Computer Science The University of Aucklandemail: cam@cs.auckland.ac.nz phone: +64 9 3737599 x82924
This archive was generated by hypermail 2.1.3 : Tue 09 Nov 2004 - 01:50:26 GMT