Decision Unit Framework
While the ARSIN world is the platform for the use-cases, the decision unit framework is the interface to the different control architectures which should be evaluated by these use-cases. This framework provides an abstraction of the whole ARSIN world and the body the decision unit should control. The sensor data and the actuator commands are passed through a temporal firewall. Thus, it is not possible to access anything else than the provided data from the decision unit. For example, direct access to objects from the simulator is prohibited. This eases the task of implementing several control architectures for the same setup by providing a well-defined interface with no side effects.
The decision unit framework is divided into two projects: DUInterface and Decision Unit. The first project resembles the temporal firewall and the interface between the body and the control architecture. The second project contains the implementations of the various control architectures.
Figure 1 depicts the UML class diagram of the main classes and interfaces involved in the framework. The project frames are added to show the assignment of the classes to different projects. The abstract class BaseDecisionUnit needs two lists: the current sensor data and current actions. The first one is update by ARSIN Agent during the sense phase. The latter is updated at the end of the process phase. The actions in this list are then executed by ARSIN Agent during the execute phase. ARSIN Agent creates the instances of SensorData and ActionCommands and passes the references to BaseDecisionUnit through the interface DUInterface. Now both objects (ARSIN Agent and BaseDecisionUnit) work with the same instances of the above described lists. The specializations of the classes SensorExtern, SensorIntern, and Commands correspond with listed abilities of the simple and the rich bodies.
The interface DUInterface provides two public methods: update and process. The first one tells the decision unit that the update of the sensor data has been finished. The second one starts the current iteration of the control loop - the processing of the sensor data and generation of the next actuator commands.
The three classes PsychoAnalysis, BDI, and Subsumption are implementations of the abstract class BaseDecisionUnit. Class PsychoAnalysis is the implementation of the model described in the previous chapter and will be explained in the next chapter. The other two are sample and reference implementations of existing AI architectures. One is based on Brook's subsumption architecture [Brooks1986] and the other one is based on the BDI model described by Bratman in [Bratman1987].
The setup chosen for the subsumption architecture is based on Toda's Fungus-Eater. The implementation of the ARSIN Agent is changed to fit the description of the Fungus Eater. They can sense and collect fungi and have a special sensor which shows them the direction to the base station. The control architecture is consisting of several layers as described by the subsumption architecture.
The BDI implementation utilizes the Jadex framework (see [Braubach2003]). In Jadex, the believes, desires, and intentions are stored in XML based files and in Java code. A BDI interpretor applies them to the currently incoming sensor data and returns the resulting action commands. Thus, the class BDI is a wrapper which instantiates and operates the Jadex framework. The setup for testing and developing BDI related control architectures is a hunter/prey situation. Hunter and prey agents are equipped with BDI based controllers and have to survive as long as possible.
For the time being, no AGI reference implementation exists. To identify which model to choose and to produce a working implementation of it, is a project on its own and would exceed limitations of this thesis. In the next section, the implementation of the psychoanalytically inspired decision unit is discussed.
