[robocup-rescue-s] KA_HEAR and research challenges

Dear Cameron (and everyone),

>Agents can hear 4 messages per timestep, centers can hear 2n messages where
n is the number of platoon
>agents controlled by the center (e.g.
>if there are 8 fire brigades then the fire station can hear 16 messages).

>If an agent receives 4 messages from the center then it will not be able to
listen to any nearby
>civilians.

Thanks for clearing this up.

Now, regarding the discussion about the research challenges - I was not
talking about getting an agent up and running but pointing out the core
issues of robocuprescue:
1. Path planning
2. Coordination between platoons
3. Communication protocols
4. Forecasting methods
5..... Others.

Under each of these items, there are already mechanisms developed by various
teams, (e.g. ResQFreiburg, Impossibles, Caspian, etc...) which seem very
good and appropriate for the problem at hand. It is a very hard problem to
find out about how they implemented these while factoring in all the
constraints of the domain. The team description paper that describes all
these winning strategies is usually prepared well in advance of the final
submission (as we will do again this year) and therefore does not provide
any real clue as to how things were really implemented (ResQFreiburg might
be an exception to some extent). Moreover, new things might have been added
or removed - you never know. And therefore, one is never sure why one
strategy is better than another in the end.

To make this better, winning strategies should probably be made to document
their work and put it on a general web site (BTW - there seems to be a
number of websites for different years - with different logfiles,
documentation) which contains all relevant information about robocup rescue.
Then researchers would know what they are up against when entering this
domain. Winning teams might not want to reveal everything but core
techniques should be discussed.

Now, having said that, regarding highlighting the research challenges - a
new entrant should be told what are the problems one might want to look at
(from the above list for example). For example - for one year, the
communication could be subject to noise and roads becoming blocked in real
time - this would allow someone to do some work on robust communication
protocols or path planning under uncertainty... Right now, there are so many
issues to tackle in robocup rescue that it is very difficult for any new
entrant to participate actively or compete...

This mailing list remains our lifeline :)

Thanks for your quick responses.

Gopal

-----Original Message-----
From: Cameron Skinner [mailto:cam@cs.auckland.ac.nz]
Sent: 02 February 2006 20:51
To: Sarvapali Ramchurn; robocup-rescue-s@mailman.cc.gatech.edu
Subject: Re: [robocup-rescue-s] KA_Hear

Hi.

Sarvapali Ramchurn wrote:
> Hi all,
>
> Regarding the humanoids' hearing capabilities. As far as i've read,
> the humanoids can only hear 2 messages. Does that mean that if an
> agent has received 2 messages from its center, it won't be able to
> hear civilians which are shouting for help around?

Agents can hear 4 messages per timestep, centers can hear 2n messages where
n is the number of platoon agents controlled by the center (e.g.
if there are 8 fire brigades then the fire station can hear 16 messages).

If an agent receives 4 messages from the center then it will not be able to
listen to any nearby civilians.

> It would also be great if particular research challenges were clearly
> laid out for some parts of the simulation competition - and the code
> be provided for other non-challenging parts - so we don't end up
> re-coding whatever has been done for these non-essential parts.

There are development libraries for C++ and Java that can make it easier to
get started. The "librescue" package (part of the simulator
distribution) is a C++ library that will handle communication and world
modelling. You can create a subclass of Agent and implement the sense() and
hear() functions to create your own agent.

There are at least three Java packages that achieve the same goal:
YabAPI, rescuecore and rescuebase.

YabAPI is available from
http://ne.cs.uec.ac.jp/~morimoto/rescue/yabapi/ but it might be a little out
of date - the communication protocols have changed in the latest version
(version 0.49) and I don't know if anyone actively maintains YabAPI.

Rescuebase
(http://www.informatik.uni-freiburg.de/~rescue/sim/downloads/rescue_base.tgz
)
is maintained by ResQ Freiburg and includes "a sophisticated communication
system and a highly efficient path planner"
(http://r-resc.a-eskwadraat.nl/archive/2005/12/1321.html).

Rescuecore (http://www.sf.net/projects/rescuecore) is maintained by The
Black Sheep team. Rescuecore implements all the kernel communication
protocols and also has path planning, visualisation, map and scenario
generation tools, and a powerful debugger.

All four of these packages essentially do the same thing and I don't know if
there are any major differences between them or not.

If you use one of these packages (or any others that might be out there)
then you can focus on your research without having to figure out how to send
commands to the kernel.

Cheers,
Cameron.

--
Cameron Skinner
Artificial Intelligence Group
Department of Computer Science
The University of Auckland
email: cam@cs.auckland.ac.nz
phone: +64 9 3737599 x82924
fax: +64 9 3737453
Post:
Department of Computer Science
The University of Auckland
Private Bag 92019
Auckland
New Zealand
_______________________________________________
robocup-rescue-s mailing list
robocup-rescue-s@mailman.cc.gatech.edu
https://mailman.cc.gatech.edu/mailman/listinfo/robocup-rescue-s