Hi everyone, here are my comments...
(Past suggestions are in blue, my comments are in black) (I hope you see the colors!)
I divided the proposals that I think sould be considered for this year and those that I think should be for subsequent competitions.
Changes for the 2005 competition
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.
I think a good maximum number of fires should be 50. This will enable to have really hard maps, but still controlable maps. However, I think in most maps, we should start less fires, but it is good to have the opportunity to have difficult maps wihtout having to block all the roads.
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.
This is good, I am anxious to try that.
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.
I think that it is interesting to change the dynamics of the simulation by adding aftershocks. Civilians could be injured more, fires could start, roads could be blocked, but I think that our agents should not be trapped after the initial settings. The reason is that ambulance teams are most of the times in the same building and if that building collapse, all the ambulance teams would be trapped, and no agents would be left to save them. I think that for this year competition, we could let our agents "escape" aftershocks. However, they will have to adapt to new fires, new blocked roads and different civilian damages.
A. Limited space in buildings and prohibition of extinguishing from
inside houses: It's unrealistic that there is no restriction on the number of agents,
esp. platoons, in buildings. It's even more unrealistic that fire
brigades can extinguish from inside buildings.
Of course, if we make such restrictions, we'll have big traffic jam
problems. So probably there should be a way to give platoons, esp. fire
brigades some more freedom to position themselves. For instance,
1. agents could specify not only a road where they want to move to, but
also a positionExtra on that road, allowing several fire brigades to
choose good positions on the same street that are still in extinguishing
range for a specific building
2. blocking the movements of other agents could be relaxed: each platoon
should only block one *lane*, not the whole road.
This is a good proposal. The first time I participated in the competition, my agents were not going in buildings to extinguish. Therefore, I know that agents can have some spreading strategies around fires to minimize traffic jam. Thus, I think we should prohibit agents to extinguish a building from inside a building. The only concern is that I think that there are some buildings on some maps that are not at extinguishable distance from a road, but for me, it is not a problem. The building will burned and the agents could just extinguish the next one.
B. Refuges and stations burn like other buildings
Apart from being much more realistic, this also emphasizes that
civilians must be protected during the whole simulation and that the
centers as a, well, central part of a team are in danger, too. By the
way, the new fire simulator allows this feature to be switched on and off.
This is good. This should really be done for this year competition. This will force teams to protect refuges and stations. Also, teams will have to be able to adapt to the "death" of a station.
C. Unknown number of civilians
It is an unrealistic feature of the simulation that agents know the
number (and IDs) of civilians in advance. To change this, an upper
bound on the number of civilians could be given to the agents. Thus,
there could be a fixed set of IDs reserved to civilians. Only when a
civilian is actually sensed for the first time, it would become known to
an agent that this civilian really exists.
For me, I don't think it is a great deal that the agents know the number of civilians since they don't know where they are.
D. Damage on the streets
Both civilians and platoons are quite save on the streets in the current
simulation. If we wanted to change that here's a couple of possibilities:
- small injuries near burning buildings. The new firesim computes heat
distributions also for the streets, so this would be easy.
I think this would make the job of the fire brigade a little bit too complicated.
- civilians being trampeled down during a mass panic. Easy to implement
with a network flow model (as proposed), but maybe also possible in the
old model
This goes with the new civilian simulator. Below I say that this new civilian simulator should be presented at the 2005 simulator competition.
- if we had aftershocks, people on the entrance nodes of collapsing
buildings or streets nearby would be in danger of being hit.
Thats interesting, we could had that if we add the aftershocks. However, to remove some randomness, agents should be able to predict a little bit which buildings are more dangerous for them.
1. A possible solution could be the computation of specific visibility
> areas for each position on the map by some simplified for of ray
> tracing. Details are open to discussion, but having the GIS information
> it is not too difficult to calculate which objects are visible from a
> certain point on the map. If we had the height of buildings (or the
> number of floors) we could even describe that one can see a big building
> behind a small one, but not vice-versa.
We can probably pre-cache a set of all fixed objects that could be
visible from each other fixed object (road, node, building). That would
take a lot less CPU time during simulation.
This is a good idea, it should be done for this year.
>
> A nice additional feature could be that visibility goes down in areas
> where there is a lot of smoke.
Perhaps a first approximation would be to reduce the maximum visible
radius if the agents are downwind of a burning building. If we sort the
pre-cached set of potentially visible objects by distance then this will
also be fast.
Good idea, again I am for it for this year competition.
>
> 2. To find buried civilians, agents should go into the buildings.
> Finding the civilians should also *take time*, depending on the size of
> the building, its degree of destruction, its fieryness, the number of
> people hidden there, maybe the floor on which they were before the
> building collapsed etc.
That would be nice. Perhaps we should add a SEARCH action? Obviously
agents might be able to find civilians just by walking past, but
searching for them is a whole different activity.
I think it is a good idea to force the agents to go into buildings to search for civilians. However, I think that it would be hard if we add time for search. Saving civilians is already hard, because their damage is always changing. Maybe, we could add a search action, but if we do, we should reduce the rescuing time.
Addition:
From research point of view I would also like to add rescue agents halfway
a simulation, so that the teams have to be reconfigured.
It would be interresting to have that, but I think it would be hard to do, because the new agents would have to connect to the kernel. One way to go arround that would be to connect the agent at the beginning and tell it to act only at some time. But, I don't really like that.
Changes for further competitions
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.
This seems to be a good idea to make the communications more flexible, but I think it is too late to add that for this year competition, because all the simulators and all the teams would have change their communication code.
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.
This goes with the proposal before. I am for a restructuration in modules of the kernel, but I think we should do it for 2006. For this year, I think we won't be able to have a stable kernel which is primordial during the competition.
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.
Good idea in the future communication module.
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.
This is really interesting and it should be done for 2006.
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 am not sure how it could work. Michael Brenner explained it in an email to the list, but i am still not sure about the feasibility of this. It is a good idea to try to have a more fined grained planning. However, I think that such a plugin would be a really hard task. It would be hard to synchronize the world model of each agent and the pluggin. Maybe a first step would be to allow conditional planning. Instead of a path, the agent could send a path tree. We would have to change the traffic simulator to manage those path tree, but I think it would be less dificult than the pluggin, because the agent stays in control of the planning. After a time step, the agents could receive in their sense message, some informations about the roads visited.
We propose a new model of civilians to capture a number of features
missing in the current simulation:
* realistic numbers of (unhurt) people (from an unrealistic few dozens
of civilians to a several hundreds or thousands).
* phenomena such as mass panics, fleeing from fires, crowds blocking roads
* a new job for police agents: directing streams of civilians to refuges
Good, this should be presented in the simulator competition of 2005.
Sébastien Paquet
-----------------------------------------------------
Leader of DAMAS-Rescue
http://www.damas.ift.ulaval.ca/projets/RobocupRescue/index.php
-----------------------------------------------------
This archive was generated by hypermail 2.1.3 : Tue 16 Nov 2004 - 16:34:18 GMT