Voting Form
===========
Team name: S.O.S.
Institution: Amirkabir University of Technology
Team leader: Arash Rahimi
Email: rahimi@ce.aut.ac.ir
Implementation changes
======================
1) Extending the communication protocol to include a length field for
each property element.
[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.
[c] Do not implement
Discussion: We do not agree for two reasons. First of all, is its
implementation effort. We're not sure whether or not it takes just
minor changes to the kernel. We think that in order to do this, we
have two choices:
1- Implementing Comm. and Perception modules as seperate modules
that communicate directly with the agent. Is it the case? If
so, it needs modifications to agent codes and also designing
a new protocol to do so.
2- Implementing Comm. and Perception modules as seperate modules
communicating with the kernel and causing it to send the data
they indicate to the agents. Here, a new protocol is needed
for communication of kernel and these modules. Also, take into
account the communication overhead. Agent sends a message to
the kernel. kernel sends it to Comm. Module. Comm. Module
decides who hears the message and sends it to kernel. Kernel
sends it to the agent. Are all these routings neccessary?
Now, the question is whether it is really necessary to do so or
not. We think that the only merit of doing so is more modularity.
But there are certainly other ways to achieve more modularity.
Nevertheles, if it is to be implemented, We strongly prefer the
first choice.
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
4) Allow messages to be lost during communication in a controlled
fashion.
[a] Implement for 2005
Discussion: Good Point! Our suggestion is letting the agent who sends
a message know whether or not his/her message is lost at the end of
the cycle, when he/she uses the communication line(i.e. TELL command).
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
Discussion: As other friends say, the important point is the degree
of vulnerability of each type of agents to each kind of damage.
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)
Discussion: Excellent Point! A suitable way to add more modularity
to the system. As we move towards a more complex system, We think
that this modification is necessary. We don't think that it needs
a significant effort if we want to simulate the existing system
for this year.
7) Allow AK_MOVE to include positionExtra. This will require
modification of the traffic simulator and possible minor changes to team
code.
[c] Do not implement
Discussion: Currently, the traffic simulator automatically positions
the agents on roads, based on a set of rules regarding the capacity
of the road. If we want to let the agent choose the position itself,
what should we do with these rules? Should we ignore them? We don't
suggest to do so. Should we enforce them with the new system. We are
afraid it is hard to do so. Moreover, considering these rules, Many
attempts of agents to go to a certain position in a road would not
result any movement at all.
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
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.
[b] Implement for 2006 or later
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.
[b] Implement for 2006 or later
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
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).
[c] Do not implement
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
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
Discussion: Let's take into account the cost of implementing these
sensing conditions. Also, there is another suggestion: When an agent
move, it does not percept the objects on his/her path. Perception is
made just on start and end points of the traversed path. A suggestion
is adding a less accurate perception of objects along the path.
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
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
Discussion: Current system does not have the capability of implementing
these relationships efficiently. May be next years.
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
Discussion: As long as the number of regions on fire are not more than
8, increasing the number of fires on each region is a good idea. This
helps making more challenging situations in order to evaluate the
performance of agents.
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
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
Discussion: In the real world, these kind of buildings have special
capabilities to avoid damages caused to normal buildings.
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
Discussion: Good Point! We suggest 1 or 2 for fire brigades and 5 for
ambulance teams.
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.
Water Tanker:
[b] Implement for 2006 or later
HelliCopter:
[c] Do not implement
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
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
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
Discussion: Hard to Implement! A lot more details is needed.
_______________________________________________
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 25 Dec 2004 - 09:28:28 GMT