We
arrived in the afternoon. We shared the room with the Soccer simulation, what
meant that we had to be careful with the fileserver / network. The resources
were excellent: GHz computers equipped with Suse 8.1 Linux.
The
Freiburg team had already installed the kernel (version 4.2beta), and was
assisting the Arian team with getting their code compiled for this environment.
After two hours we also had our code running (we had developed our code with
gcc 2.96).
In a
teamleader meeting we decided use the Saturday to explore a number of maps and
settings, and to decide on the end of the day what the most challenging final
would be. At that moment we assumed half an hour running time per scenario, so
for four teams we proposed the following schedule:
10:00
Virtual City (sf1 from Fukuoka 2002)
12:00
Kobe (final from Fukuoka 2002)
14:00
Freiburg
16:00
Amsterdam
18:00
Foligno
Freiburg
was an experimental map developed by a student of the Freiburg team.
Later we
found out that he had spent 20 hours to create this map, which made the
creation of an Amsterdam-map during the weekend impossible.
Saterday 12 April
The Arian
team had been working hard to create binaries for the GO environment.
Initial
runs showed that they were loosing cycles and messages, which they couldn't
solve remotely.
Also
Freiburg had a lot of performance problems. At the end they found out that
their simulation only worked when the kernel and agent SW ran on the same
machine, otherwise they were loosing messages. With our SW it was vice versa.
We needed at least two machines, otherwise we were losing cycles.
After a
while we realized that the latest version of the kernel had problems with the
settings of the 1st semi-final of Fukuoka 2002. The first game we played
with the standard settings (delivered with the kernel) of the Virtual City,
although the number of agents there are not enough to seriously rescue the City
and its Civilians. Later we found that the kernel was able to run with the
settings of the 2nd semi-final (sf2). The Virtual City run took 9 hours to
complete.
|
|
UvA Rescue C2003 |
ResQ Freiburg |
The next
game we played with the Kobe map. In principal we used the settings of the
final ofá Fukuoka 2002. The
Freiburg team had made a slight modification: they changed the location of one
FirePoint to make it more challenging. We were at that time far behind
schedule, because the kernel becomes terrible slow when the fire spreads. The
running times was in the order of 2 hours.
|
|
ResQ Freiburg |
UvA Rescue C2003 |
The
kernel had problems with the Freiburg map. There are some blank spaces in the
center of the city, but we didn't had time to analyze if we had maybe an old
version of the map.
We spent
a lot of time to modify the Foligno map. Scaling inside JGISedit doesn't scale
the properties of the buildings, so we tried to make a program that reads in
the building.bin and scale its properties. Unfortunately, that tool was not
ready on Saturday.
In the
mean time we had manually modified the building properties in the South/East of
the city. By restricting the firepoints to the South/East we could simulate a
fire that burned down the modified buildings (1/3 of the City). We decided to
use this map for the Final.
Sunday 13 april
10
minutes before the final the automatic scaling program was ready. No time to
test, so we stayed with the manual scaled map. The Foligno map is quite
challenging, because in principal there are not enough agents to seriously save
the city. Yet, some of the reported problems (distances too large to travel)
were not really a problem. The difficulty with the larger distances is more
related with perception, and forces the agents to actively explore the
environment.
With the
ambulances this situation was extreme, the ambulances didn't hear the Civilians
plies for help inside buildings, even when they were in front of the building.
This was
not really a problem of distance, because for most buildings to distance
between center and road is less than the hearing threshold of 30m.
|
|
ResQ Freiburg |
UvA Rescue C2003 |
Because
of performance problems we decided for a second run. In the mean time the
Freiburg team had changed the behavior of their ambulances. In the second run
their ambulances went actively inside buildings to look for Civilians. By doing
this, they were quickly loosing health. So it became exciting who would win the
final, because the points they won with more efficient firefighters they lost
with the daring behavior of their ambulances (differences in score of 0.07). They
won the game when finally their hero-ambulances rescued a Civilian that died in
our simulation (difference in score of 0.97).
Conclusion
The
participation in the German Competition was a real experience. The organization
was really good, and allowed the participants to work 24 hours/day. The current
simulation environment is not very stable, we needed a rerun for every game.
Recommendations:
1. The
performance of the simulator drops exponentially when the fire spreads, causing
a lot of problems. Somebody has to look at the fire-simulator.
2. Rule
25 'Valid Game' has to be more specific. There are two possibilities for a
rerun:
    1. A rerun with the same code, but with
different configuration (computing resources, random seed, cycle time).
    2. A rerun with the same configuration
with modified code (reduced communication, reduced computation).
When you allow the rerun of one team, you
must allow the other teams a rerun.
In case 1 this has to be done with the
same configuration. In case 2 you have to put a deadline on the debugging (one
hour?).
3. Rule
31 'Agents' is too restrictive for other maps than Kobe/VC. Yet, the number of
agents allowed is already high. Foligno has 52.776 inhabitants, which is
comparable with the Dutch city Capelle a/d IJssel (65.000 inhabitants). The
firebrigade of Capelle has 10 vehicles, half of them to be used to battle fire.