In this section we look at the low-level control software of the AllemaniACs robots. The system uses a classical three layered architecture with an interface layer between the hardware and the control modules on the middle layer, which in turn build the interface to our high-level decision
6.2. ROBOT CONTROL SOFTWARE 145
making with READYLOG. The middle layer comprises modules like navigation, localization, or object recognition. While we have a detailed view on the tasks navigation, localization, and a comparative study of several sensor fusion techniques for merging the ball perception of the robots, we overview tasks like vision, path-planning, and object recognition only briefly. The third layer of the system architecture consists of the world model and the reasoning component READYLOG. The software architecture is shown in Figure 6.1(b). As already mentioned the system consists of three layers. The control flow is as is usual in layered hierarchical architectures from bottom to top concerning data and from top to bottom w.r.t. control commands (cf. e.g. (Murphy 2000)).
Inter-process Communication
For communication between control modules we make use of a blackboard system. Each mod- ule connects to the blackboard system and is able to read data provided by other modules from the blackboard. Inside the blackboard several data sections are separated and access rights are regulated. To avoid dirty reads we make use of a client-server structure to govern read/write per- missions. For each data section in the blackboard only one server process which may write to the respective data section, is allowed. This avoids dirty reads as several writers cannot overwrite data from others. Reader processes have no restriction, several modules may read a data section. For another, to assure atomic read and write operations semaphores are used for reading and writing. The blackboard is realized as a shared memory segment. At start up of a new module it connects to the blackboard and registers the data it is allowed to write, as well as the sections is wants to read data from. By using a shared memory for exchanging data on one host, one meets the real-time conditions closely, as there is basically no overhead in storing the data. There are no time guarantees for accessing the data and all modules connected to the blackboard are running asynchronously. The age of the data are tracked by timestamps. The consumer modules have to decide on their own if a date is too old for their application. Race conditions, though, are mostly avoided by guarding the memory segments with semaphores. For inter-host communication the blackboard offers the possibility to use TCP or UDP connections to communicate with remote blackboards. This is an important feature as our robots are equipped with two hosts over which the several control modules are spread.
Low-Level Interfaces
The low-level interfaces are basically hardware drivers with access to the blackboard. The motor driver provides data like odometry information which are calculated from the wheel encoders and estimates about the velocity of the robot on the one hand, on the other hand it takes driving commands from modules of upper levels. The laser driver takes commands for starting or stopping the LRF, and provides 360 distance measurements per sweep. As the directed camera is with its pan/tilt unit also an actuator it can take commands likemove(ϕ, θ). It provides the vision module with camera images. The omnivision camera only yields raw images. Finally, we have the kicker interface which takes commands actuating the pressure valves of the pneumatic kicking device.
The Middle Layer
The modules on the middle layer work on the data provided by the sensors. A central task espe- cially with fast heavy-weight robots is an effective collision avoidance strategy. We present our approach in Section 6.3 in detail. For successful complex robot operations in dynamic environ- ments a working localization is needed. Here we make use of a Monte Carlo approach which we show in Section 6.4. To endow the robot’s world model with a rich representation of the environ- ment, one moreover needs a good object classification. Here we use the information provided by the vision module, and further we make use of the fact that the robot is localized on its given en- vironment map. Thus it is able to distinguish between static and dynamic obstacles. The dynamic obstacles are classified by their laser signature. For the soccer application, detecting the ball is an important feature. The vision module inspects a camera image on several scan lines. If a suffi- cient number of pixels on a scan line has the appropriate object color we grow a region of interest around these pixels. Each region is then color segmented. The segmentation is based on a color map which is gained in a color calibration process, where the different colors are trained in a super- vision mode on a few sample images. The thresholds for the different colors are found following a Bayesian approach. For finding the ball we apply a randomized circle fitting following (Chen and Chung 2001). The circle fitting is implemented as an any-time algorithm which returns the best fitted circle. With a geometric model of the robot the position of the ball is estimated.
Interfaces to Readylog
Above the middle layer Figure 6.1(b) shows the modules world model, and skills. These are the modules with which our high-level framework READYLOGis connected with. From the point of view of high-level decision making, the skill module encapsulates actuators, the world model has the same function w.r.t. sensor data. The skill module provides the basic actions for READY- LOG. These are for example actions like drive to global position or turn with angleθ or more sophisticated ones like dribble around opponents. While the basic actions are clearly influenced by the soccer application, they are nonetheless useful for service robotics applications as well. In Section 6.6 we give a detailed overview of the different actions available. The world model accumulates all the available data from the sensor systems. This data comprises the location of the robot in the map, the locations of the teammates, opponents and the ball for the soccer application, and also tactical information are calculated and stored here. We come back to world modeling issues in Chapter 7. One can distinguish between local data which are derived from the percep- tion of the robot, or global data which also makes use of information of the teammates that are communicated among the robots. When addressing sensor fusion in Section 6.5 we discuss this matter. While READYLOGis implemented in Prolog and the rest of the software is implemented in C++, we need another interface between READYLOGand the low-level control software. This function has the module HLI, the high-level interface. It translated Prolog calls to appropriate C++ function calls.