Hi all,
We are just begining to work on RoboCupRescue. We have followed the
discussion closely over the past few weeks and have come to the following
conclusions.
Voting Form
===========
Team name: Kshitij
Institution: IIIT, India
Team leader: K Ramachandra
Email: ramachandra@students.iiit.net
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] 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
[b] Implement for 2006 or later
[c] Do not implement
[a] Implement for 2005
COMMENT: gives better modularity and would also help in the future if
changes in perception or communication are required.
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 cummunication
functionality (this will not require major changes to team code)
[c] Implement for 2006 or later
[d] Do not implement
[b] Implement for 2005 but only emulate existing cummunication
functionality (this will not require major changes to team code)
COMMENT: I think more discussion is neccessary on how the channels would
function and their limitations etc.
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
[c] Do not implement
COMMENT: How is the controlled fashion defined? Will all the teams lose
the same percentage of messages? Are there any problems if we continue the
current protocol?
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] Implement for 2005
COMMENT: Makes it more realistic.
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] Implement for 2006 or later
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] Implement for 2005
COMMENT: Again, it would make it more realistic.
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] Implement for 2006 or later
COMMENT: More discussion maybe required on this command's utilities.
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] Implement for 2005
COMMENT: We find that the police agents are currently entrusted with
relatively easier tasks compared to the other agents.
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
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] Implement for 2005
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: More discussion is required on how this probabilistic manner
would function. Currently the agent doesnt obseerve anything while its in
motion, so maybe some discussion is required on that also.
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
COMMENT: Though, such a thing can be easily done by the agents themselves.
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
[b] Implement for 2005 with rescue agents immune to aftershock damage
COMMENT: Makes it more realistic. Also the rescue agents must be capable
enough to escape in such cases. But we do find in real life, that a large
number of rescue agents are injured while carrying out rescue operations.
Hence we are not very confident about our choice.
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] Implement for 2005
COMMENT: It is one of the important factors in real time situations. Hence
we feel that this should be implemented.
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
[c] Leave the maximum at 8
COMMENT: 50 or 20 would be high for the current map sizes.
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] Implement for 2005
COMMENT: This in unrealistic and should be done away with.
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] Do not allow refuges and stations to burn
COMMENT: Generally care would be taken to see that such critical places
are not affected. So, no point in burdening the fire agents.
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
[b] Implement for 2006 or later
COMMENT: Looking at it realistically, buildings must be much larger than
agents.
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] Implement for 2006 or later
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] Implement for 2005
COMMENT: Makes it more realistic.
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
[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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
[b] Implement for 2006 or later
=================================
Thank you
Ramachandra
IIIT Hyderabad
India
--
Ingenuity is the father of invention
_______________________________________________
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 : Mon 03 Jan 2005 - 07:27:41 GMT