Re: [robocup-rescue-s] Complaint: Reply from Technical Committee

Dear all,
About the civilian rescue operation I think that stopping rescuing civilians
behaviour will continue even with this change. Because the score is
calculated mainly by number of humans living in the map. Not the number of
civilians carried to the refuge. Therefore from the score point of view
there is very small value for digging out a civilian if it is estimated that
the civilian will not die.
If the hp loss is punished more than today the behavior of the agents will
going to change according to the new score. However this is very detailed
issue and my suggestion is the TC may decide to investigate better score
calculation to remedy a spurious behavior which we dont have in real life...

Note that I am supporting the sense changes for both fire and civilian in
49.* which force the teams building better algorithms that can cope with
noise.

On 5/11/06, Cameron Skinner <cam@cs.auckland.ac.nz> wrote:
>
> To all Robocuppers,
>
> The changes to the kernel and simulators made in 2006 have been almost
> entirely for purposes of stability and reliability. There are a small
> number of exceptions which are detailed below:
>
> 1) HP and damage rounding. This feature was introduced on 31/1/06 in
> version 0.49alpha to prevent teams from having a perfect "estimation" of
> the state of a civilian. In 2005 it was noted that at least one team
> stopped rescuing civilians when they had determined that no more
> civilians would die. This is a totally unrealistic situation. In a real
> environment it is not possible to *completely* determine the state of
> any object in the world.
>
> To make the simulation more realistic it was decided that rounding the
> HP/DAMAGE values sent to agents would make it difficult to determine the
> exact state of a civilian, as would be the case in real life.
>
> It is the opinion of the technical committee that this change is not a
> major one and teams should not be significantly disadvantaged by this
> change.
>
> The committee also notes that this feature was released 5 months before
> the competition. We feel that this is sufficient time for teams to adapt
> to the new environment.
>
> 2) Randomised fuel loads and fuel consumption. Similar to the rounded
> hp/damage, this feature was introduced to make it more difficult to
> determine the state of the fire simulator. It changes the fire simulator
> from a completely deterministic process to a stochastic one. Again, the
> technical committee notes that this is more realistic and that the
> change is minor and should not significantly disadvantage any teams.
>
> 3) The next version (0.49.6) which is due to be released soon contains
> one additional building property: building temperature. This is a
> discretised value taken directly from the fire simulator. Teams are free
> to ignore this property if they wish.
>
> The technical committee wishes to stress that this feature does *not*
> affect the way any of the simulators function. It will not affect the
> fire model, nor will it affect any of the other data sent to agents.
> This extra property provides some additional information that teams may
> or may not find useful.
>
> 4) The remaining changes in the 0.49.x release series are all bug fixes
> or architecture changes. The only significant change that will affect
> teams is the communication protocol change. The technical committee
> estimates that it would take at most 5 hours work for teams to modify
> their communication libraries to work with the 0.49.x architecture. The
> librescue and rescuecore libraries provide reference implementations of
> the protocol in C++ and java respectively.
>
>
> You can see that there are really only three changes that affect teams.
> These changes are all minor and are aimed at enhancing the realism of
> the simulation and at making the simulation software more stable.
>
> *There will be no more functional changes to the kernel or simulators
> before the 2006 competition.* Bug fixes will still be made and further
> releases beyond 0.49.6 are possible if major bugs are discovered.
>
> The technical committee's goal is to run a fair, open and interesting
> competition and to work towards the Simulation League goal of eventually
> performing *real* urban search and rescue missions. The changes that
> have been made in 2006 are aimed at achieving these goals.
>
> Finally, the committee notes that the 0.49.x series of releases have
> been available since 31/1/06. Teams have been notified of each release
> and asked to test each version. To date, 6 bugs have been reported since
> 31/1/06.
>
> Teams should be aware that the version used at the 2006 competition will
> be from the 0.49.x release series and *will* use the new communication
> protocols. It is the responsibility of teams to ensure that their agents
> work with this version of the kernel.
>
> Regards,
> The Technical Committee.
> _______________________________________________
> robocup-rescue-s mailing list
> robocup-rescue-s@mailman.cc.gatech.edu
> https://mailman.cc.gatech.edu/mailman/listinfo/robocup-rescue-s
>

_______________________________________________
robocup-rescue-s mailing list
robocup-rescue-s@mailman.cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-rescue-s
Received on Thu May 11 12:52:01 2006