Introduction
Motivation	For the effective development and realization of different robot prototypes the use of transferable software components is a very important aspect. Reusable components with standardized interfaces lead to extendable architectures. MCA2 is a modular software framework that is developed to satisfy these topics. The effort at software implementation should be restricted to new components and control methods that are not implemented so far. If parts of a whole controle system are organized in small standardized modules, these modules can be reused in other projects. Communication between and synchronization of the different parts of the software have to be done by the framework, i.e. the project developers can focus their work on the methods that are necessary for controlling the robot. Beside the reusability of controlling mechanisms for other prototypes the short training period of new students as well as the uniformly software appearance on all levels have played an important role during the development of MCA2. Therefore C++ as programming language has been chosen. To fulfill eventual real-time requirements RTAI/LXRT is used. RTAI/LXRT combines real-time functionality with the advantages of a stable Unix system. In RTAI/LXRT a real-time scheduler executive the common non-real-time kernel as its lowest priority task.
What is it?	MCA2 is a software framework with realtime capabilities. Its target applications are control programs especially for the control of autonomous robots. MCA2 is neither an automatic code generation tool nor does it contain a visual programming tool (click modules together and generate programm code). Although its named an architecture, MCA2 is not an software architecture. The reason for its name lies in history: The first version of MCA war strongly associated with a special hardware architecture. Its aim was only to provide a software framework that supports this hardware architecture. The second version of MCA2 is no longer coupled with it.
Realisation	In MCA2 all methods are realized by simple modules with standardized interfaces. They are connected via data transporting edges which is how the communication between the single modules is realized. The module interfaces are represented by simple arrays of floating point values. Edges just copy values from output to input interfaces. Modules are combined into groups, which act like any other module but with more complex behaviour. Modules Every module is structured in the same way. It has five communication interfaces : four interfaces enable the connection via edges to other modules that are arranged either above or below the module. In every direction (above and below) is an interface to receive data (input) and to send data (output). These interfaces can be interpreted as data vectors of certain dimensions. Edges can take any part of an output vector and permute and copy it to an input vector of another module. An additional fifth interface can be used to read and change internal parameters of a module even while the software is executed. Every module consists of two functions: Sesne() and Control(). These functions contain the actual functionality of a module. While Sense() is responsible for the processing of sensor data Control() has to handle control data. E.g. the inverse kinematics of a kinematical module would be implemented in Control() and the direct kinematics in Sense(). Groups For clarity reasons modules are united to module groups. These behave like normal modules with more complex functionality. They organize their included modules and edges in a hierarchical structure. Within a group modules and edges are executed iteratively level by level. Calling the Control() function of a group will result in an execution of all down-edges and Control() funtions of all modules from top to bottom. The Sense() function executes all up-edges and Sense() functions of the modules from bottom to top. Edges As input and output interfaces are realized by arrays of floating point values (c-type double), edges just copy single values, a part of an array or even the whole array of an interface of one module to an interface of another module. Copying is only done if values of the source array changed, otherwise not. Copying a whole array or a part of it is very fast; the transfer of single values with specific indices allows flexible permutation of values. Different kinds of edges enable both strategies. The latter type of edge is even transformed into the first one if possible. Parts More complex behaviours are realized by combining modules and groups to more complex groups. This leads to a hierarchical structure. An executable program that uses such a (more or less complex) hierarchical structure is called "mca part". A part manages one module (in most cases a group) and executes its Sense() and Control() functions in a loop. Before every execution of these functions it waits for a given period time beeing elapsed. If necessary every module in a group can be executed within an extra thread. Such a module is encapsulated in socalled ThreadContainer, which manages all necessary synchronization between the asynchronously running modules (The module itself and the goup, where the module is include). In order to be able to combine parts that are developed seperatly like e.g. a vision system and the basic control strategy of a mobile platform MCA2 submits so called interpart connections. These use TCP/IP connections to realize data transfer. Hence, control applications can be distributed over several PCs. Of course, realtime performance cannot be garanteed beyond this point.
Features	Common modules like e.g. sensor value filters or standard controllers can be used by all devellopers without reimplementing and testing procedures. Beside such simple modules more complex parts of control systems like e.g. path planers or image processing can also be transferred easily from one robot to another. Comparing different methods can be done by replacing modules through equivalent ones of the same functionality but other methods. Even multiple modules with the same functionality, can parallely be integrated and effortlessly compared by activating one and deactivating all others without stopping or even recompilating the program. Blackboards As the very simple module interface only provide arrays of floating point values there is a need for an additional mechanism in order to support more complex data structures like pictures from a frame grabber device or laser scan data. Blackboards im MCA2 are network transparent shared memeory areas. They are organized as single arrays. Multiple access modes are available in order to provide efficient and fast read and write methods to the stored data. mcagui The whole architecture contains interfaces that can be used via ethernet. In this way all sensor values of a machine can textually or graphically be presented on a second PC. A common graphical user interface has been developed to simplify the procedure. Even 3D-illustrations of robots are implemented. As this GUI can be executed on every PC within a LAN the controlling PC is not burdened by it. The below picture shows an example of an user interface. This interface was build within 5 minutes just by doing a few mouse clicks. mcabrowser The internal module parameters can also be changed via ethernet. That means different parameter settings can easily be tested and compared without recompiling or restarting of the system. The complete controller architecture is therefore read and graphically displayed in a tree-like structure. The user can navigate through the hierarchy with only a few mouse-clicks, select certain modules and act on its parameters. The below picture shows a screenshot of one module group displayed by the mcabrowser tool. Beside the graphical representation of the executed program mcabrowser enables the user to manipulate all IO and Parameters of all Modules and even prevent single or all modules from their execution. Moreover profiling information (How much cpu time is spent for the execution) about the modules and groups can be shown.