transparent, platform-independent interfaces. The programmer uses standard distributed systems technology to interface to any device either on the local or a remote robot.
To ensure consistency in the access of abstract robotics devices, a set of required functionality for sensors and actuators has been identified that is to be provided by the service interfaces. The abstraction from the individual properties of the physical devices is especially supported by two design concepts: metainforma- tion provided by interfaces allows client applications to adapt to the properties of an individual device, and interface hierarchies allow to interface to robotics devices on different levels of abstraction. The various design aspects of different service types are discussed in Section 5.
3.3.4 Extensible Frameworks
The higher-level Miro Class Frameworks provide a number of often used func- tional modules for mobile robot control such as video processing, behavior gen- eration, and self-localization. They provide generalizations of existing robotic core functionalities and can be easily extended to the needs of individual robot applications. The higher-level frameworks export their functionalities as ser- vices to other modules of an application by the use of the communication layer. Frameworks provide extensible modules of reusable code and reusable design for the development of applications. Their integration into a middleware- oriented, multi-platform robot software architecture facilitates the development of reusable client applications. Their goal is to provide support for the generic problem set of the application domain, allowing the application programmer to focus on functionalities provided by the respective module targeted by the framework. Thus, the frameworks address the problem of how the requirements for reactivity and response times are met by managing the control flow and or- ganizing the data flow in the sub-domain of the application. They also assist in the handling of resource constraints of robot devices by providing sensor- triggered evaluation models and arbitration methods for concurrent actuator access. The most prominent class frameworks are discussed in Section 6.
3.4
Miro
Support for Real-time Processing
As autonomous mobile robots operate in the real world, real-time constraints are an issue in modern robot control architectures. The requirements of timing awareness vary greatly in an autonomous system. Hard real-time (i.e. guaran- teed) response times in the range of a few µ-seconds are only needed on rare occasions for state of the art autonomous mobile robots. This concerns mostly actuator controllers and can usually be restricted to microcontroller boards or encapsulated in an RT-control kernel.
26 CHAPTER 3. MIRO ARCHITECTURE AND DESIGN Motor commands need to be processed with low latencies and sensor data such as distance information has to be available with little jitter to ensure safe op- eration in dynamic environments. But these requirements on response times currently only lie in the range of milliseconds, since the maximum speed of au- tonomous mobile robots usually is only a few meters per second. For example if the reactive control loop of a robot running at 3 m/s is delayed by 10ms due to OS latencies, the stopping distance will be prolonged by 0.03 m. On the other hand, the controllers’ setpoint can often be altered to a much lower rate, typically to between 30 ms to 100 ms. These response time requirements can be met by modern general-purpose operating systems, if properly supported by the robotics middleware [110].
Real-time constraints need to be met on all levels of an application. Therefore, several points on the different layers of Miro were identified, where the software architecture was able to facilitate the fulfillment of response time requirements and improve the reactivity of its applications.
• On the device layer, all incoming sensor data is time-stamped and these stamps are propagated to the sensor service implementations. This allows to properly align different sensory sources and to compensate for latencies introduced by sensor processing (e.g. image processing). The accuracy of such time-stamps is improved by carefully applying real-time scheduling and thread priorities to the low-level device handlers.
• The communication layer can improve the adherence to real-time con- straints by the use of middleware technology aware of real time and qual- ity of service (QoS) such as RT-CORBA for prioritizing the processing of service interfaces. These features of the underlying implementation of CORBA are currently not used within Miro. The application of this technology within robotics applications is limited by the lack of quality of service (QoS) features in current wireless network technology (WLAN) as used in teams of autonomous mobile robots. WLAN even exhibits large variations in bandwidth, which make it almost impossible to reliably stay within a low network traffic situation where acceptable network latencies could be provided. Miro approaches this issue in the context of team communication on the communication layer.
• Sufficiently quick processing of sensory information favors a push model of communication. Otherwise, a prompt reaction on new input data re- quires excessive polling or frequent context switching to the various wait- ing threads of control. The Miro architecture therefore requires for sensor services to not only support the pull model within their interfaces, but to also actively push sensory information as it becomes available.
• Higher-level frameworks are critical for ensuring the reactivity of an appli- cation and the adherence to reactivity constraints. As these are designed to be extended by the application developers’ code, it is almost impos- sible to assess these properties a priori without severely restricting the
3.5. MIRO SUPPORT FOR DEVELOPMENT 27