Development of Your Own Agents/Simulators

Hardware & Software Requirements

For debugging at the first stage and testing behaviors, the 1/100 map model with the sample simulators is convenient because

For behavior development at the final stage and tuning, the 1/10 model with the real simulators is necessary because it is the competition environment. It requires three PCs at least as follows.

When the Linux version of fire simulator is available at the end of 2000, you might not need the Windows NT machine, but maybe requires one more Linux machine.

You should set parameters according to the final rules.

Knowledge for Development

Necessary information for development is written in the manual.

Models and algorithms of disaster simulators are written in the documents.

Protocol

The following communication protocol is defined between modules. Issuing messages by modules (agents, simulators, GIS, viewers) realizes all state transitions and functions, e.g. agent motion, auditorial communication, and fire spread.

The detail of the protocol is written in the manual.

Agents

In this virtual world, the following agents are defined and should work.

  1. Moving agents: civilian, fire-fighter, rescuer, police
  2. Static agents: fire station, police station, hospital, refuge, etc.

You program agent behavior of sensing-action loop by using the protocol. Sample codes by pioneering developers in the web page are useful for the development. ADK by Michael Bowling will also be helpful.

There still exist bugs in the code. The bug report should be sent to the mailing list.

Simulators

All the state change in this virtual disaster world occurs by Issuing message to the kernel. All the global state variables that are effected by multiple modules are managed by the kernel module. Therefore, simulation should proceed in the following manner.

  1. Prepare the necessary state values using the protocol defined in the above for the global variables, and the internal values for the local variables.
  2. Compute the state of the next time step.
  3. Change the global variables by sending messages to the kernel as well as the local variables
  4. Note that the global variables are effected by multiple modules. Therefore, the result of simulation usually is not maintained until the next time step.

Existing simulators can be integrated into the RoboCup-Rescue simulator by adding the network communication part. The first and the third points above are different from conventional centralized simulators. However, code change is limited to very small part: only the state renewal part. The transporting efficiency has been proved by the fact that the integration of the four simulators in the version 0 was completed in a short time.

However, adding new state variables need to modify the kernel code.

Geographical Information Systems

Any GIS can be connected to RoboCup-Rescue simulator. The necessary point is to have communication ability conforming to the protocol specification.

The design of the GIS related protocol was done carefully independent from the DiMSIS data structure so that any GIS can be integrated.

However, adding new state variables need to modify the kernel code.

World Maps

You should be able to input the map of your city. It is planned to open DiMSIS to the public. According to its manual, you would be able to modify the map freely.

If you integrate another GIS such as ArcInfo, you will be able to use maps of other cities.

Kernel

The kernel module is maintained by Tetsuhiko Koto. It is difficult to open this development to the public. However, discussion and contribution are welcome.

Viewers

Simulation result viewer is an important issue not only for competition but also for practical application.

The fundamental algorithm of the viewer is as follows.

  1. Request the kernel to send necessary information.
  2. Receive the information from the kernel.
  3. Present the information to human in visual ways, auditorial ways, etc.

Any human interface can be developed by the above way. But kernel code modification is necessary if new state variables are necessary.

Bi-Directional Human Interface, Sensor Interface, Controller Interface, Robot Interface, etc.

Various interfaces of the real-world interface and mission critical man-machine interface are important issues for the future development aiming at practical applications.

Discussion should be necessary for this development. Your participation in the mailing list is welcome to start discussion.

Simulation Project RoboCup-Rescue Project