Hi all,
we have discussed and settled for a preliminary voting here in Freiburg.
We'd like to keep discussion running not only internally, so we post our
votes here hoping that other teams will do the same.
We have also indicated the points that we are willing to implement (or
have already made efforts to implement). It would be helpful to know if
for the other proposals there are people willing to implement them. At
some point, we must decide which of all these proposals will really be
used and for this we must know people that are committed and responsible
for implementing the changes. So, when you post your votings, please
indicate what you are willing to implement, too.
By the way, merry christmas to those of you celebrating it - and a happy
new year to everybody. If in your country you don't even move on to a
new *year* during the next two weeks, I can just wish you, well, happy
next two weeks!
michael
ResQ Freiburg
Voting Form
===========
Team name: ResQ Freiburg
Institution: Albert-Ludwigs-University Freiburg, Germany
Team leader: Michael Brenner
Email: brenner at informatik.uni-freiburg.de
Implementation changes
======================
1) Extending the communication protocol to include a length field for
each property element. This will be easy to implement and will not
affect team code aside from minor modifications to the communication layer
.
[a] Implement for 2005
COMMENT: This is a minor change that will prepare us for future
extensions. We'd like to have it, but as long as there is no direct need
for the feature could also live without it.
2) Move communication and perception code out of simulator kernel and
into seperate modules. This will require a small amount of effort to
implement but will not affect teams at all. The initial implementation
will simply move the existing functionality into seperate modules.
[a] Implement for 2005
COMMENT: especially when moving to a different perception and/or
communication model this will be very beneficial.
Design changes
==============
3) Extend communication design to include the idea of "communication
channels". This will involve a significant programming effort but will
not affect teams to a large degree if option b is chosen. Option a
involves defining a set of channels each with their own bandwidth and
(optionally) reliability. Agents will be allowed to listen to some small
number of channels (e.g. 1 or 2) and send on only one channel at a time.
Centers will be able to both listen to and send to more channels than
individual agents. Agents will also have an extra command available for
specifying which channels they are listening and sending to. This option
is closely linked to option 2 above.
[c] Implement for 2006 or later
COMMENT: We discussed this proposal a lot, and are in favour of it, but
would prefer to introduce it in 2006 after careful discussion,
implementation, and presentation at the Infrastructure Competition in
Osaka. This is a major feature influencing each single agent, the
centers, and the team strategy as whole. There is still a lot to
discuss about the communication concept we adopt for this league, and,
probably, some research to do about the features and problems of
communication in real rescue scenarios.
4) Allow messages to be lost during communication in a controlled fashion.
[a] Implement for 2005
COMMENT: This could be a first step to a richer communication model, so
we are pro. Easy to implement, so we still have time to discuss what
and why it is lost.
5) Damage on streets. If an agent is next to a burning building or a
building collapses when the agent is nearby then they may suffer damage.
[a] Implement for 2005
COMMENT: Since we also advocate larger numbers of civilians (9) and
simulating mass panics this would be another good feature forcing the
rescue agents to lead civilian flow away from dangerous areas. Our
proposal is that platoons may be get damage but not be buried on the
streets. We propose the same in case of aftershocks (11).
6) Introduce the concept of "capabilities" for describing what different
agents can do. Initially this will involve only a few capabilities
(extinguish, move, clear, rescue, load etc) that emulate the existing
simulator behaviour - i.e. fire agents will have both the extinguish and
move capabilities, ambulances will have move, rescue and load.
[b] Implement for 2006 or later
COMMENT: This is a good feature allowing for indivual agent capabilities
and new agent types, so we are generally pro. But for this year, we
believe there are more important and also more visible changes to be
made, so we vote for postponing. As another drawback, capabilities will
be hard to visualize.
7) Allow AK_MOVE to include positionExtra. This will require
modification of the traffic simulator and possible minor changes to team
code.
[a] Implement for 2005
COMMENT: This will be important if we forbid extinguishing from inside
buildings (14), because groups of fire agents have to be more tactical
about their positions.
8) Search command. This will add a SEARCH command for agents and will
require the perception code to be altered. This proposal is closely
linked to option 10 below and does not make sense unless 10 is also adopted.
[c] Do not implement
COMMENT: As long as we do not have a more complex building model this is
not really important. So we vote against. However, we *should* think
about introducing a better building model, linking our league with the
Real Rescue League (and the real world).
9) Crowd behaviour. This will involve adding a new kind of object to the
simulator (a crowd object) and an action for police to direct the crowd.
The traffic simulator will need to be modified to allow crowds to affect
the movement of vehicles.
[a] Implement for 2005
COMMENT: As pointed out in our mail from November 9, we think that the
small number of civilians is one of the most unrealistic features of the
simulation. We have started to implement a new civilian simulator that
does *not* model civilians as individual agents but (in contrast to what
the above description says) as properties of roads and crossings (this
means only minimal change in the team code to model the new perception
info). Each node stores some numbers describing its maximal capacity
and the current number of civilians on it. Objects on the map exert
attractive (i.e. refuges) or repulsive (i.e. fires) forces on civilians,
thus leading to a natural flow of civilians through the map. Police
agents standing on a crossing can change the flow at this crossing with
a command like "CONTROL-FLOW 1,2,#,3,4" meaning that adjacent roads 1
and 2 will be forbidden, but 3 and 4 are open for civilians. (Of course
this is not necessarily the final syntax.) If the community is in
favour of this proposal we will present a prototype in January.
Simulator changes
=================
10) More accurate perception model. This will change the perception to a
model with the ability to reduce the range of perception dependant on
factors such as smoke, buildings in the way, blocked roads etc. There
are several aspects to this, so please choose one of the following
options for each aspect:
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
10.1) Line of sight calculations. This will calculate perception based
on what the agents can actually see. This is computationally expensive,
but line-of-sight can be calculated at start-up and cached.
[a] Implement for 2005
COMMENT: We are very much in favour of this - and also willing to
implement it.
10.2) Smoke. This will reduce the range of perception if an agent is
inside a smoke cloud. This will also require a definition of how smoke
behaves.
[b] Implement for 2006 or later
COMMENT: Smoke is not really implemented in the firesimulator yet. So we
propose to introduce smoke and how it changes perception in 2006.
10.3) Probabilistic perception rather than deterministic. This will
generate sensory information in a probabilistic manner - for example, if
an agent is moving quickly then it might not observe some things as well
as if it is stationary. This is closely related to the search command
proposal (number 8, above).
[b] Implement for 2006 or later
COMMENT: This again will change the simulation fundamentally, so we
propose to postpone the change for now. By the way, the example given
in the description is beyond the current capabilities anyway, since
nothing is observed while moving.
10.4) Action observation. This will send updates to agents when they
observe another agent taking some action, such as extinguishing a building.
[a] Implement for 2005
COMMENT: pro. We'd also implement this. A conceptually related point is
observation of movements of other agents. One rather simple way to
achieve this would be to add a "direction" to each agents which is the
first node on the tail of its last AK_MOVE path, i.e. the node the agent
could not reach anymore. Alternatively, it could be the node the agent
was coming from. This might help plan recognition.
10.5) Negative observations. This will send updates when you do not
observe something. For example, if this agent cannot see ambulance team
4 then an update will be sent with a zero position for ambulance team 4.
[a] Implement for 2005
COMMENT: We are in favour and would also implement the new feature.
However, probably we should restrict this somehow to observations that
in a positive form have been made in the last cycle. Otherwise we will
have complete overload with negative information.
11) Aftershocks. There is the potential for an aftershock to bury all
rescue agents which would make it impossible to take any further actions
during the run. We can either allow this or make the rescue agents
immune to this kind of effect.
[a] Implement for 2005 with potential damage/buriedness for all agents
OR[b] Implement for 2005 with rescue agents immune to aftershock damage
COMMENT: Our proposal is that platoons may be get damage but not be
buried as result of an aftershock. This is in accordance with our
proposal for damage on the streets (5).
12) Causal relationships. This includes various features such as
buildings collapsing due to fire, collapsing later in the simulation
just because they are unstable, roads becoming blocked during the run
due to building collapse, fires starting during the simulation due to
collapse.
[a] Implement for 2005
COMMENT: This introduces more dynamics to the simulation, while on the
other hand giving agents ways to reason about where fires are going to
start next, where people are in danger of being buried etc. More
dynamics plus more possibilities for acting deliberatively is good!
Rule changes
============
13) More fires. At the moment the maximum number of initial fires is in
the range [2,8]. We can increase the maximum number of starting fires to
make it harder for teams to know when they have extinguished all the fires.
[none of the above] We suggest to postpone this decision since we all
have some more experience with the new fire simulator, especially with
"preemptive extinguishing", i.e. protecting not-burning buildings. This
can be decided in May or June.
14) No extinguishing from inside buildings. Currently fire agents can
execute an extinguish command from inside a neighbouring building. This
rule would modify the fire simulator so that such actions are not
executed. If option 16 below is adopted then this may not be necessary.
[a] Implement for 2005
COMMENT: this is clearly not realistic; so let's forbid it as soon as
possible. But allow more precise positioning of agents (7).
15) Burning refuges / stations. Currently refuges and stations cannot
burn. The ResQ-Freiburg fire simulator allows for these buildings to be
burned but this feature can be turned on or off.
[a] Allow refuges and stations to burn
COMMENT: protecting the refuge is a nice new job for the fire agents -
and, of course, this is more realistic, too.
16) Limited space in buildings. Currently any number of agents can
occupy a building. Refuges and stations will still have infinite
capacity. We will also have to decide how many agents can fit inside a
building.
[c] Do not implement
COMMENT: Our opinion is that having (14) solves the most pressing
problems of agents in buildings.
17) New agent types: water tanker and helicopter. This will require
modification of the kernel and misc simulator. Water tankers will be
able to transfer water to fire trucks via a new command. Helicopters
will have a large perception area.
[b] Implement for 2006 or later
COMMENT: this is important and should come, but other changes are more
pressing this year.
18) Do not send all IDs at startup. Currently the simulator sends the ID
of every object in the world when agents connect, allowing teams to
easily know when they have rescued (or at least found) all civilians.
This rule would require the modification of the kernel to only send IDs
when the civilians are observed. Fixed objects (nodes, roads, buildings)
will still be sent as normal. Teams may need to modify their code.
[a] Implement for 2005
COMMENT: Reasoning along the lines of "now we have found 65 per cent of
all civilians" is unrealistic, so we are in favour of this one.
Additionally, our proposal for a new civilian simulator (9) would
require this feature, too, since it "creates" individual civilians (with
IDs, damage, hitpoints etc.) only when damage is done to them the first
time. This is in line with agent teams not caring about healthy, moving
civilians, anyway, currently.
19) Addition of rescue agents part way through. Currently the number and
type of rescue agents is fixed at the start of the simulation. It would
be possible to allow more agents to join the simulation part way through
the run. This will require significant modification of the kernel and
team code.
[c] Do not implement
COMMENT: not very important to us right now.
20) Path planning plugin. This proposal would allow teams to provide a
"path planning plugin" instead of sending move commands as a list of
IDs. This proposal will be difficult to implement and will require major
changes to the traffic simulator, kernel and team code.
[c] Do not implement
COMMENT: Although we proposed the concept ourselves, we do not see how
it can be reasonably implemented currently. Instead, we should aim to
run the simulation in more fine-grained time frames, i.e. changing
speeds etc. such that, for example, one cycle models 10 seconds. For
this to be interesting, we should go back to 1000ms cycles (at least).
_______________________________________________
robocup-rescue-s mailing list
robocup-rescue-s@mailman.cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-rescue-s
This archive was generated by hypermail 2.1.3 : Tue 21 Dec 2004 - 11:28:45 GMT