Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
1 Introduction
Programming a software for robotics is a non-trivial task; it requires a significant iteration and coordination of hardware and software elements. The aggregation of a large number of sub-systems must be based on a solid software architecture, for this way be possible realize the ambitious objectives of robotic research. In addition, we need to guarantee a certain level of flexibility, performance and reusability of both hardware and software and support the requirements of heterogeneous modern robotic system that can be briefly summarized as: hardware abstraction, scalability, modularization, support for multiple operating systems, extendibility, simplicity, limited runtime, networked computing, completeness, etc. Systems for robotics are becoming more and more complex, increasing the number of constitutional parts that make up current robotic, as multiple sensors for perception, torque, radar, laser based on sensors or vision systems including cameras as different as low-cost web-cams and high-dynamic-range cameras. Moreover, there are required and desired features for a robot software. In an academic perspective there are required features as; support for multiple components, communication between components, easy way to write own components, possibility to replace individual components, easy to extend, means for data logging and debugging and support for decentralized components. Desired features are; robustness, hardware abstraction, open access (open source would be the ideal case) and hardware and operating systems independence.
In this scenario, of many hardware and software components needing to communicate and collaborate to each other to reach a goal, a plenty of required and desired features that need be covered, is exactly where a middleware can help improving the organization, the maintainability and the efficiency of the code. In this report I will introduce the meaning of middleware, what is a middleware, how a middleware can help us in the development of software for robots, how is the middleware architecture and where we fit the middleware in our system.
2 Middleware
2.1 Middleware Origins
Middleware is a relatively new concept in computer science. It gained popularity in the 1980s as solution to wrap legacy system and interface them with newer application. However, the introduction for the term Middleware can be dated o f 1968 [1], when dAgapeyeff used it for the first time to identify the part of the software that could be shared between different applications. DAgapeyeff described an inverse pyramid (Figure 2) that describes a primitive software architecture in which the high-level applications are build using a set of middle level routines, so from this description comes the name middleware.
In general, on each robot runs a software that is responsible for reading sensors data, extracting the needed information from them, computing the sequence of actions to accomplish a given task and controlling the actuators to execute the actions. In a custom approach, there will be a single application that will handle all these tasks, making code maintenance, code reuse extremely hard and preventing any form of code sharing between different projects. In this scenario, with many hardware and software components that needs to communicate and collaborate to each other to reach a goal, is exactly where a middleware can help improving the organization, the maintainability and the efficiency of the code. Different components can exchange data using a common communication channel provided by the middleware, using interfaces that are consistent between different applications. In this way, it becomes easy to share and reuse code among different projects, since is only necessary to keep the same interface. As an example, if we need to switch from a proximity sensor to another, it is possible to write a new component that share the same interface and update it without modifying the rest of the application. This concept can be extended to large and complex applications, in which using a middleware can clearly improve the overall code organization and reduce the programming effort.
distributed architecture developers can re-use the robotic elements, and boosts the reliability of the robotic system. RT-middleware is just standard of the Robotics platform software. Therefore, there are several implementations of RTM. RT-middleware does not assure the communicability between the RTM implementations, however, the bridging tools that intermediate the communication can be easily created because the state machines and their programming model is defined. As example: OpenRTM.NET is an implementation of the RT-middleware for the .NET Framework platform. [7] "RTM on Android" is an implementation on Android OS that is communicable with OpenRTMaist. [7] "RTC Lite" is a modified RT-middleware for embedded or small-resource systems such as PIC (Microchip), ARM, H8 (Runesus), etc. [7] MIRO: MIRO uses an abstract machine model; the system is divided into several distinct layers. The higher layers can only access the lower layers via their interfaces. In case of MIRO, these layers are: MIRO device layer: this layer provides classes to interface hardware and abstract the lowlevel hardware details, these classes enable access to hardware resources via simple procedure calls. MIRO service layer - this layer provides service abstractions for sensors and actuators by means of the CORBA interface definition language. These services are implemented as network transparent objects/CORBA objects. The classes in this layer present the sensors and actuators as generic services. For example, the RangeSensor class defines functionality common to the sensors, which return range readings such as sonars, lidars and other type of range finders. MIRO framework layer - on this level functional modules specific to robotics are provided. Examples are mapping, localization, path planning and similar facilities. For communication purposes, MIRO relies on a TAO middleware C++ implementation of the CORBA standard. Subsystems/Objects communicate according to a client-server model, which is an example for a distribution model. With respect to the time properties, both synchronous and asynchronous modes of communication are utilized. The system also supports event driven communication.
As requirements that are not meet, we can cite: performance and memory usage, the fact of the software does not have dynamic memory allocation, does not have callbacks and there is no large external libraries.
The Decision Layer uses a declarative-based model while the Functional Layer uses a procedural-based model. Because the Functional Layer provides an adaptation to a physical or simulated system, all specific model information is collocated in the system adaptations. The Decision layer receives this information by querying the Functional Layer for predicted resource usage, state updates, and model information. The Decision Layer accesses the Functional Layer at various levels of granularity (Figure 3). The architecture allows for overlap in the functionality of both layers. This intentional overlap allows users to elaborate the declarative model to lower levels of granularity. However, is also allows the Functional Layer to build higher-level abstractions (e.g. navigator) that provide mid-level autonomy capabilities. In the latter case, the Decision Layer serves as a monitor to the execution of the Functional Layer behavior, which can be interrupted and preempted depending on mission priorities and constraints. [8]
5 Conclusion
Having researched about middleware, understood how it works and how it can help us to develop a robotic software. I can notice that using a proper middleware our work becomes easier, for controlling all the sensors, for replacement of any sensor in a different one, for sharing code between different projects and for maintenance of the code. However, we must be sure about what must be done in the project. As cited, in some situations using a middleware is not the best solution, so we need appeal to other approach. As in the example of special robot or flying robot, using a middleware we may not reach the proposed goals, so we can appeal for the usage the CLARaty approach, which works in a different way, in a double layer and not in a three-level architecture. I can also notice that this research field is far from state of art, we are just in the beginning, and there is still a long way to roam when the subject is software architecture for robotics.
References
[1] Report on a conference sponsored by the NATO SCIENCE COMMITTEE. Garmisch, Germany, 7th to 11th October 1968 [2] Simone Ceriani and Martino Migliavacca. Report for Advanced methods of information technology for autonomous robotics, Milan, Italy [3] Thomson Course. Operating Systems and Middleware: Supporting Controlled Interaction. , California, USA, October 18, 2005 [4] C.D. Gill and W.D. Smart. Middleware for robots? Proceedings of the AAAI Spring Symposium on Intelligent Distributed and Embedded Systems, 2002. [5] Noriaki ANDO, Takashi SUEHIRO, Kosei KITAGAKI, Tetsuo KOTOKU, Woo-Keun Yoon, "RT-Middleware: Distributed Component Middleware for RT (Robot Technology)", 2005, Edmonton, Canada [6] Object Management Group (OMG). Robotics Technology Component Specification version 1.1 [7] OpenRTM-aist, [http://openrtm.org/] [8] I. A. D. Nesnas, A. Wright, M. Bajracharya, R. Simmons, T. Estlin, and W. S. Kim, Claraty: an architecture for reusable robotic software, in Space Robots, vol. 5083 of Proceedings of SPIE, April 2003.