Hello Everyone,
Here are my opinions about these proposals and simulation goals.
1. More fires
The map settings in RCR competition should follow the real situation.
I don't know whether we already have the real disaster
categorizations. If not, it is time to make this categorization. If we
have this categorization, for example, 4 real major disaster types,
the RCR competition just uses 4 settings similar to those 4 real types
with a full or proportional map.
2. Deterministic message loss
I vote for it. But we need careful design to avoid "bad
luck"/unfairness for rescue teams. Simulation design of communication
physical layer depends on the real (wireless?) communication
technologies, whose future might be hard to forecast.
How about dividing messages, for example, one message could be 100%
transferred and three messages are transferred with some probability
(say 50%)?
3. Extension of AK_MOVE
I agree some team's points that the simulation cycle, simulating one
minute in the real, may be too long. If one cycle represents one
second in the real, this problem becomes minor.
>From this problem, I feel the need to distinguish the design of
simulator systems and agent systems. To my understanding, a pure
simulation system strictly mimics the real environment excluding
agents without adding agent-related components. Path planner is not a
part of a pure simulation system. However, a simulator may consist of
a pure simulation system and an agent-assistant system. Path planner
is a kind of agent-assistant module to facilitate agent developing, if
we have a good path-planner for every team.
I propose a hierarchical software system design: agent
system(outside)<->agent-assistant system(optional)<->pure simulation
system(kernel).
If an agent-assistant system is mature enough, simulator developers
can add it on top of a pure simulation system to reduce workload of
agent developer.
If not, agent developers should work on (several) agent-assistant
systems by themselves.
I agree with some teams that a simulation system should be MODULAR and
it should also be HIERARCHICAL like network layers or
driver/OS/application layers in computer systems.
4. Limited space in buildings and prohibition of extinguishing from
inside houses.
This case should follow real rescue situations with which I have no
much experience. But I have several general questions:
a) Could fire brigades extinguish fires at the location of other
buildings (inside, top etc)?
b) If fire brigades must be on roads to extinguish fires, does the
real traffic jam is serious as current RCR simulation? It seems real
fire vehicles can placed well to mitigate the jam. For example, two
real vehicles hardly block a two-lane road.
5. Refuges and stations burn like other buildings
It would be an interesting test. But I agree with other teams' points,
the stations and refuge are so important that they should be fortified
in the REAL world.
Actually, it introduces an interesting topic: strategies/lessons of
software/physical robot rescue may change the policies of the real
human world rescue.
In rescue domain, I would against the damage of refuge and stations.
In other adversary domains, it might be a good choice.
Since there are unlimited changes to mimic the real world, we need to
proceed step by step with clear goals.
The ultimate rescue simulation goals with my understanding are:
1. Help to build real rescue robots with algorithms, strategies,
lessons obtained in simulation. In the short period (10 years), rescue
robots would be human rescue assistants. In the long period (around 50
years), rescue robots are fully autonomous without human intervene.
2. Help to change real human world policy. For example, we may build a
damage-free rescue center in the real world because refuge and
communication stations are crucial in simulation/real rescue. This
center (Central Rescue Bureau) will have central role in macro-rescue
tasks while individual rescue agents are mostly autonomous in
micro-rescue actions. Another example is locating buried persons. It
is hard to find person without any clue or feeble voices. Persons may
carry on small wireless devices so that rescue teams can easily locate
them with signals from devices.
3. Extending rescue domains to other domains, if possible. If there is
no fire, rescue problem becomes foraging/exploration problem. If
refuges/stations could be damaged, rescue problem becomes adversarial
attack problem.
Zijian Ren
Phoenix Team
Email: zijian.ren@gmail.com
URL: www.geocities.com/zijian_ren/
This archive was generated by hypermail 2.1.3 : Sat 20 Nov 2004 - 17:35:18 GMT