Simulator Composition

From SIMA wiki
Jump to: navigation, search

Simulation setup and organisation

The starting point of a simulation is the scenario file. Each simulation scenario is defined by such a file, which is basically a list of all properties and entities that make up a particular scenario. When the Scenario Selector GUI is called, it scans all the available scenario files and gives a list with descriptions. The user can then select a scenario and start the simulation by clicking on Start Scenario. This calls the class SimulatorMain which takes care of the simulators graphical interface and calls clsMain to handle the non graphical simulator background.

SimulatorMain and clsMain both extend modules of the MASON multiagent simulation toolkit that provides the simulation framework. The central module that MASON supplies is the scheduler. Before starting the simulation, the scheduler invokes a start procedure in clsMain which is configured to call clsSimplePropertyLoader to manage the scenario setup (create all entities decision units etc. and apply properties according to the scenario file). Everytime a entity is created, it is registered at the scheduler. Once the simulation is running, the scheduler calls 4 procedures (one after another for all registered objects) for each simulation step. The following diagram shows the principle


Fig. 1: Scheduler principle

clsSimplePropertyLoader

This class sets up the simulation according to the selected scenario file. Most important, it manages the creation of the memory(s), decision unit(s) and entities. This process happens in 3 steps. If the entity that is to be created is a ARSIN, than it creates a instance of the memory (clsSearchSpaceManager and clsLongTermMemoryHandler), otherwise this step is skipped. Then a decision unit (which one is defined by the scenario file) is created and for the case ARSIN the memory handlers are passed to the DU. Last the entity is created and if needed the DU is passed to it. When a entity is created, it is registered at the scheduler. The following diagram shows the simplified principle (in reality the creation and registration is performed via factories)


Fig. 2: SimplePropertyLoader

Entities

The entities that are currently available in the ARS simulator are


clsApple clsAppleGreen clsBase clsCake clsCan
clsCarrot clsFungus clsFungusEater clsHare clsLamp
clsLynx clsPlant clsRectangleStationary clsRemoteBot clsRemoteBotOrientationTest
clsSchnitzel clsSchnitzl clsSelf clsSmartExcrement clsSprout
clsSpeech clsStone clsToilet clsTomato clsUnrealHealth
clsUraniumOre clsWallAxisAlign clsWallHorizontal clsWallVertical


For further information see Entity Hierarchy. In order to interact with the simulator and the other simulated objects, every entity has a body (implemented via a member clsBaseBody).

Body

There are three types of bodies available. The diagram shows the body hierarchy and the most important members


Fig. 3: Body hierarchy

SimpleBody: Just a simple Body with no External or internal Sensors, and no Actuators.

MeatBody: Basically the same as SimpleBody, but implements a flesh and has a weight. Entities with a MeatBody can be consumed by e.g. an ARSIN.

ComplexBody: A sophisticated body that implements internal and external IO's, a biological system and a brain.