Voting Form
===========
Team name: SBCe_Saviour
Institution: Shahid Beheshti University
Team leader: Eslam Nazemi
Email: Saboorian@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
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: although this is not an important subject today, it seems to
be essential for moving toward an extensible simulation environment.
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.
==>[b] Implement for 2005 but only emulate existing communication functionality
4) Allow messages to be lost during communication in a controlled fashion.
==>[b] Implement for 2006 or later
COMMENT: needs a lot of discussion, "controlled fashion"?
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
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 behavior - i.e. fire agents will have both the
extinguish and move capabilities, ambulances will have move, rescue
and load.
==>[a] Implement for 2005
COMMENT: this feature can make feature (5) more realistic by
considering different factors for damage, buriedness and ... for each
capability. but it can be very hard to implement this feature (for
simulators and agents)
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
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.
==>[b] Implement for 2006 or later
COMMENT: as others said, it can make simulation environment very hard
at a quick pace, so may be it helps to introduce some agents with
capabilities like exploring.
9) Crowd behavior. 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: nice feature, but needs a strict definition
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: of course without letting positionExtra affect line-of-sight!
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: step by step!
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: can lead to unfair situations. see also (8)
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: why not?
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] Do not implement
COMMENT: kernel has lots of work to do already. this can be done at agent-side!
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.
==>[b] Implement for 2005 with rescue agents immune to aftershock damage
COMMENT: not immune, but have more chance to escape from buriedness.
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.
==>[b] Implement for 2006 or later
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.
==>[b] Increase the maximum to a slightly larger number e.g. 20
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.
==>[c] Do not implement
COMMENT: we can make agents decide between aftershock risks and
benefits of extinguishing from inside buildings.
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.
==>[b] Do not allow refuges and stations to burn
COMMENT: may be for 2006 or later!
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
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
COMMENT: it depends on "new agent type". i'm sure if we implement some
agents line water tanker this year, the real result will be shown at
2006 but for something like helicopter we need more details to decide.
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.
==>[b] Implement for 2006 or later
COMMENT: may be with some estimation of civilian or crowd position,
like the real world.... an ambulance knows that there must be lots of
people passing through road x.
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: this only makes debugging easier!
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.
[b] Implement for 2006 or later
COMMENT: needs discussion.
_______________________________________________
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 : Sat 01 Jan 2005 - 21:01:36 GMT