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
Answer: a
Discussion: OK 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
Answer: a
Discussion: OK for 2005, it is a first step to upgrade the perceptions and communications. It doesn't add anything, but it will enable more structured code and it should be easier to change the communications and perceptions wihout touching the kernel, which should be as stable as possible.
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
Answer: c
Discussion: This is nice, but maybe for 2006 only. For now, I don't think we really need that and there are a lot of other changes proposed.
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
Answer: a, but not sure, I need more details about how it will be done.
Discussion: I am still not sure about this one. I agree that in real life communication can be lost, but normally, we know when this happen, because we do not have any response. In other words, I think that if we want to add communications break down, we should find a way to inform the agents that there communications were lost.
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
Answer: a
Discussion: Ok, but the firebrigades should have some protection, because they need to be arround fires. If they are hurt, it should be really little. Also, for all agents, I think they should not be hurt right away. For now, if agents are in a building on fire, they are hurt right away, which is good. If they are near a fire, they should not by hurt that fast, maybe after 2 or 3 turns because they have been too exposed. I think the new fire simulator has a heat transfer functionnality which could be used to simulate the degree of heat a human well equiped could support before being hurt. I don't know if it would be possible because I don't really know the new fire simulator, but it would be more reallistic. Therefore, I think that agents just passing by a fire should not be hurt.
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)
[c] Implement for 2006 or later
[d] Do not implement
Answer: c
Discussion: I think it's nice for the future, because it will enable to have different kinds of agents, but I think it is too complecated 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.
[a] Implement for 2005
[b] Implement for 2006 or later
[c] Do not implement
Answer: c
Discussion: I do not think it is really useful.
8) Seach 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
Answer: b
Discussion: Not for it. We already have to visit the civilians often to update their damage and we need really good scheduling algorithms to save as many people has possible. I think the ambulance team job is already quite hard, because even with the help of all the other agents, it is really hard to save the optimal number of agents. We this proposal, it would be even harder to get good information about the civilians and I do not think we have time in a simulation for that.
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
Answer: b
Discussion: For further years, but not this year. Too complecated to implement realistic crowd behaviors and not necessary for now. I think in future years, if we want to do that, we shoud add an existing crowd module, because they are some researchers doing that and there module would be more reallistic than our module. But for now, policemen have a lot of job to do. In the final rounds of the 2004 competition, none of the teams were able to effectively clear roads.
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
Answer: a, b and c, see comments...
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.
Discussion: I think it is a good idea. It should not be hard to have a matrice of all observable objects from every position. Of course, this matrice should be constructed before the start of the simulation.
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.
Discussion: It could be fine, but it seems a little bit complecated. Agents wiil have to perceive the smoke and has you mentionned, we whould have to simulate the smoke. However, maybe the new fire simulator does that. On the demo, we saw smoke, but I don't know if it was only visual effects or if the smoke was simulatated effectively with its density, its movement, etc.
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).
Discussion: It is already hard to have a good knowledge of the situation, I think that if an agent can see something, it sees it.
10.4) Action observation. This will send updates to agents when they observe another agent taking some action, such as extinguishing a building.
Discussion: Really 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.
Discussion: Why? I do not think it is necessary to have explicit negative observations. If the agent doesn't have a positive observation, then it is already an implicit negative observation.
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 2006 or later
[d] Do not implement
Answer: between a and b.
Discussion: Good if ambulance team agents cannot get trapped. Firebrigade and policemen should get trapped.
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
Answer: b
Discussion: Interresting, but quite complecated for this year. We should keep that for next year.
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
Answer: b
Discussion: Good.
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
Answer: c
Discussion: We can let firebrigade extinguish from inside buildings, but with the aftershock rule. Therefore, agents could take chances but they will take a risk to be trapped if an aftershock happens. In other words, ok if you do not have other choice, but risky.
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
Answer: a
Discussion: OK, they are normal buildings and they should burn. However, I would add a rule saying that they cannot be one of the ignition points. It would be interesting to see agents protecting those buildings. I would be even more tough, if a refuge burned, all agents including rescued civilians should burn like in the other buildings. This will change the behavior of the ambulance team that will have to transport civilians in "safe" refuges.
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
Answer: a
Discussion: Ok, it should not be too hard to implement a capacity based on the area.
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
Answer: b
Discussion: Maybe for next year for the tanker. For the helicopter, we are not ready at all to simulate an helicopter.
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
Answer: a
Discussion: Good.
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
Answer: c
Discussion: No. I really do not see the advantage of such a change.
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
Answer: b
Discussion: No. Really too complicated for this year. Maybe for future years.
Sébastien Paquet
-----------------------------------------------------
Leader of DAMAS-Rescue
http://www.damas.ift.ulaval.ca/projets/RobocupRescue/index.php
-----------------------------------------------------
_______________________________________________
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 : Tue 21 Dec 2004 - 14:34:41 GMT