[robocup-rescue-s] 5Rings Voting Form

From: Paulo Trigo (ptrigo@deetc.isel.ipl.pt)
Date: Thu 30 Dec 2004 - 13:55:26 GMT


Voting Form
===========

Team name: 5Rings
Institution: Instituto Superior de Engenharia de Lisboa / Faculdade de
Ciências de Lisboa
Team leader: Paulo Trigo Silva
Email: ptrigo@isel.ipl.pt

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
Vote: [a]
Justify: Although I think it will enable to get ready for future protocol
format extensions I don’t know if this is the right format to consider in
future.

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
Vote: [a]
Justify: Cleaner (higher cohesion) kernel.

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
Vote: [c]
Justify: I would like to better understand how this extension (of current
communication limitations) relates to the real world problem.

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
Vote: [a]
Justify: I vote for the “controlled lost” which I think also means TCP
instead of UDP; otherwise I think we would have the “uncontrolled lost” via
UDP plus the “controlled lost” via simulation.

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
Vote: [a] and [b]
Justify: “an agent is next to a burning building”: vote [b] – a real fire
brigade knows what is a “safe” extinguish location considering his
equipment. I think that simulation of equipment and its degradation is
necessary in order to consider fire brigade damage. I also think that this
implies the capability to communicate and instruct civilians (regarding
safety) which is an important feature but we do not vote for that yet.
Justify: “a building collapses when the agent is nearby”: vote [a] –
although the fire brigade knows about safety, something can happen (random
occurrence) that he is not waiting for. Nevertheless I think that this
implies a closer relation to the real fire brigade characteristics. An
experienced fire brigade might “sense” danger from visual clues related to
the collapse of the building. Maybe additional building properties are
necessary in order to sense such “danger”.

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 (this will require significant effort to recode the
simulators and team code)
[b] Implement for 2006 or later
[c] Do not implement
Vote: [b]
Justify: Very important for future evolution of the system.

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
Vote: [b]
Justify: I think this is important if 5 (Damage on streets) is implemented.

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
Vote: [c]
Justify: I do not understand the semantics of this command; the details of
its mapping to the real world search effort.

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
[b] Implement for 2006 or later
[c] Do not implement
Vote: [b]
Justify: Being able to instruct and communicate with civilians is important
but we do not vote for that yet.

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.
Vote: [a]
Justify: I think it may get computationally expensive if 7 (Allow AK_MOVE to
include positionExtra) is also implemented.

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.
Vote: [b]
Justify: It implies smoke perception its behavior along wind influence and I
think calls for implementation of 7 (Allow AK_MOVE to include
positionExtra).

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).
Vote: [a] and [b]
Justify: Vote [a] – I think this feature also relates to 5 (Damage on
streets) regarding the occurrence of random events (building collapses).
Justify: Vote [b] – I don’t understand if the probabilistic feature happens
in predefined situations (e.g. during movement, under smoke, etc); or if it
may happen in any situation and is related to some agent characteristics
(e.g. focus of attention, tiredness, etc); or if it may happen in both cases
(predefined situations and agent characteristics).

10.4) Action observation. This will send updates to agents when they observe
another agent taking some action, such as extinguishing a building.
Vote: [a]
Justify: Good.

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.
Vote: [a]
Justify: Simplifies the agent’s update of the world state.

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
Vote: [d]
Justify: I don’t know if this turns everything too much random. And if some
agents do not get damaged it seems too strange.

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
Vote: [b]
Justify: Such realism is important but we do not vote for that yet.

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
Vote: [c]
Justify: Such realism is important but we do not vote for that yet.

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
Vote: [a]
Justify: I think this is a necessary realistic feature.

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
Vote: [a]
Justify: I think this is a necessary realistic feature.

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
Vote: [c]
Justify: I don’t understand the real scenario counterpart. Is it an
important issue that needs to be managed?

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
Vote: [b]
Justify: Such realism is important but we do not vote for that yet.

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
Vote: [a]
Justify: I think this is a necessary realistic feature.

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
Vote: [b]
Justify: Such realism is important but we do not vote for that yet.

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
Vote: [b]
Justify: I think it is an important future issue as a way to build agents
over proven solutions.

 --------------------------------------------
IPLNet WebMail http://www.net.ipl.pt/mail
 --------------------------------------------
Validação SPF anti-spam em todo o .ipl.pt
Detalhes: http://spf.pobox.com/index.html
        http://www.microsoft.com/senderid
 --------------------------------------------
_______________________________________________
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 : Thu 30 Dec 2004 - 14:23:42 GMT