Voting Form
===========
Phoenix Team
Zijian Ren
zijian.ren@gmail.com
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
[b] Implement for 2006 or later
[c] Do not implement
<a>
2) Move communication and perception code out of simulator kernel and
into separate 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 separate modules.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<a>
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.
[a] Implement for 2005 with full functionality
[b] Implement for 2005 but only emulate existing communication
functionality (this will not require major changes to team code)
[c] Implement for 2006 or later
[d] Do not implement
<b,c>, depending on the time and work load.
4) Allow messages to be lost during communication in a controlled fashion.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<a>
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
[b] Implement for 2006 or later
[c] Do not implement
<a>
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.
[a] Implement for 2005 (this will require significant effort to recode
the simulators and team code)
[b] Implement for 2006 or later
[c] Do not implement
<b>
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
[b] Implement for 2006 or later
[c] Do not implement
<a>, along with (9) and (14), we need more accurate traffic simulator.
It seems a bug in current traffic simulator: when an agent is located
at the node (0 lane) connecting two roads, it blocks the traffic
through two roads.
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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<b,c>, need more time for consideration.
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
[b] Implement for 2006 or later
[c] Do not implement
<a,b>, depending on the time and work load.
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
The more fidelity the perception, the better the system.
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.
<b>, Before adopting it, testing this expensive calculation.
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.
<a>
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>, in a fair and controlled way.
10.4) Action observation. This will send updates to agents when they
observe another agent taking some action, such as extinguishing a
building.
<a>
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.
<c>, Current sensing objects' time stamps seem sufficient.
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
[b] Implement for 2005 with rescue agents immune to aftershock damage
[c] Implement for 2005 with ambulance agents immune to aftershock damage
[d] Implement for 2006 or later
[e] Do not implement
<c,d>, need more time for consideration.
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
[b] Implement for 2006 or later
[c] Do not implement
<a,b>, depending on the time and work load.
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.
[a] Increase the maximum to a large number e.g. 50
[b] Increase the maximum to a slightly larger number e.g. 20
[c] Leave the maximum at 8
[d] Change the maximum to some other number
<d>
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
[b] Implement for 2006 or later
[c] Do not implement
<a> with forbidding fire and police agents into any building (Because
these agents are only on roads, We need more accurate traffic
simulator) OR <c>.
This is really a difficult choice for mimicking real fire
extinguishing and vehicle-building relations.
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
[b] Do not allow refuges and stations to burn
<b>, before adopting [a] in this international competition, testing it
at informal and regional competitions.
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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<a>
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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<b>
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
[b] Implement for 2006 or later
[c] Do not implement
<a,b>, depending on the time and work load.
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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<b>
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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
<b,c>, need more time for consideration.
_______________________________________________
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 : Sun 26 Dec 2004 - 17:41:41 GMT