Chapter 2. Robot middleware

RT-middleware (Robot Technology Middleware) is a technology that implements several key concepts needed for the development of complex robot systems, even in geographically distributed environments. Through a useful API, reusable standardized components and communication channels, and some degree of automatization, RT-middleware helps the user to build easily reconfigurable systems. The behavior of the components and the manner of interaction among them are standardized by the Robot Technology Component (RTC) specification. Until now there have been two implementations of the specification. OpenRTM.NET is written in .NET, while the other implementation, called OpenRTM-aist.

Within the robotics area, the task of robot systems can change quickly. If the job and environmental circumstances change frequently, reusable and reconfigurable components are needed, in addition to a framework which can handle these changes. The effort needed to develop such components depends on the programing language, the development environment and other frameworks used. Many programming languages can be applied for this process, however developing a brand new framework is a difficult task. Applying an existing framework as a base system, such as the OpenRTM-aist in the case of this chapter, the associated development tasks can be dramatically simplified.

Frameworks and middleware are gaining popularity through their rich set of features which support the development of complex systems. Joining together any robot framework and robot drivers can form a complex and efficient system with relatively small effort. In many cases, the task of the system designer is reduced to the configuration of an already existing framework.

On the other hand, when an existing framework requires only a set of completely new features, it can simply be extended with them. Improving an existing framework is an easier job than developing a new one because the design and implementation of such a system requires specialized knowledge and skills (design and implementation patterns). In most cases, the missing functionalities can be simply embedded into the existing framework, nonetheless there are some cases when this is hard to achieve. An existing framework can be improved simply only in case it is well designed and implemented. In spite of this, building a brand new system from is a much longer process that requires much effort.

In the area of robotics, there are many robot parts that share similar features, so the concept of robot middleware as a common framework for complex robot systems is obvious. Probably there is no framework which can fulfill all of the above requirements entirely.

In this section, I explore the requirements of robot middleware technologies in general and examine some existing robot approaches such as YARP, OpenRDK, OpenRTM-aist and ROS.

Robot middleware is a software middleware that extends communication middleware such as CORBA or ICE. It provides tools, libraries, APIs and guidelines to support the creation and operation of both robot components and robot systems. Robot middleware also acts as a glue that establishes a connection among robot parts in transparent way.

First of all, we should define the requirements and the actors of robot middleware. Generally, two actors use such technology: end-users and developers. Every robot middleware has to provide tools and mechanisms to facilitate the work of these actors.

The main use cases of robot middleware are shown in 21. ábra. After the analysis of these use case we can define some functional requirements. The component developers design and implement components. For this development procedure, many programming languages and operating systems should ideally be supported. Tools are needed for the generation of skeletons and semi-working components for quicker development. The main activity of the developer actor should be the generation of semi code, the filling out of business logic, the compilation of binary code and the execution of test cases. Developers also create robot parts as components using their knowledge about programming languages, robot middleware and the specification of the given robot system. Moreover, the person who develops the component has to validate it as an end-user. In summary, from the developer's point of view, the main requirements for robot middleware are as follows:

As opposed to the developer actor, an end-user is someone who has no knowledge about programming languages, as is not interested in developing components. End-users simply want to use components for their own work. In their case only a minimum number of system parameters should be visible, which are sufficient for the creation and operation of the robot system. Nice graphical interfaces and visual aid features are useful to end-users in allowing for the straightforward operation of the robot system. End-users have two main tasks. First, they often create complex robot systems using existing robot parts, and second, they often want to run previously created robot systems. The creation of a robot system can include a search for available robot parts during which the user obtains information about the accessibility of available components. This accessibility information can depend on the specific robot middleware which is applied for the task, and may include IP numbers, or any internal identifiers or symbolic names. Unfortunately, most robot middleware systems only support online components. For this reason, robot parts have to be available during the robot system creation process, i.e. have to be already running and must be registered.

End-users want to register their components in order to share functionalities with other end-users. After registration, the component can be found by all other participants. Usually end-users create custom robot systems using available components, so the second task is to find out which of the components are running. Once the robot systems are running, users will want to control them, i.e. activate/deactivate any or all of the components, and run them with various different parameter sets.

In summary, from the end-user point of view, the main requirements for robot middleware are as follows:

In summary, the key consideration for a robotics middleware system to be useful is that it should provide an efficient API and as much automatization as possible. Additionally, middleware systems also have to support as many operating systems and programing languages as possible. If a framework is applied for a specific task, some efforts will always be needed to understand the relevant concepts and application details.

One distributed environment for robot cooperation is OpenRDK. The concept is detailed by Calisi in [1] . The user’s robot system can be developed using a set of Agents, through a simple process. A Module is a single thread inside an agent process. Every module has a repository in which a set of internal properties are published. Inter-agent (i.e., inter-process) communication is accomplished by two methods: through property sharing and message sending. RConsole is a graphical tool for remote inspection and management of modules. It can be used as both the main control interface of the robot and for debugging while developing software. It is just an agent that happens to have some module that displays a GUI. The framework can be downloaded from [2] .

Alternative important robot middleware platform is Yet Another Robot Platform (YARP). Communication in YARP generally follows the Observer design pattern (for more details see [3] ). Every YARP connection has a specific type of carrier associated with it (e.g., TCP, UDP, MCAST (multi-cast), shared memory, within-process). Ports can be protected by SHA256 based authentication. Each port is assigned a unique name and it is registered into a name server. The YARP name server, which is a special YARP port, maintains a set of records, the keys of which are text strings (the names of the ports). The remainder of each record contains whatever information is needed to make an initial connection to a given port.

The third important robot middleware technology is OpenRTM-aist (documentation about it can be found [4] ), which is a convenient modular system also built on the Common Object Request Broker Architecture (CORBA). This concept uses the distributed components approach, where the components have to be registered into central naming service. (The openRTM-aist uses the name server of CORBA system.). The whole concept is detailed by Ando et al in [5] , [6] and [7] . The components can contain modules what can be loaded any time. The framework is implemented using design patterns, robust software system, which provides huge feature set, more than previously mentioned ones. The components of robot system have same rights no central logic (except the naming service). Each RT-Component has an interface (a "port") for communication with other components. The RT system is constructed by connecting the ports of multiple components to each other in order to aggregate RT-Component functions. The advantage of OpenRTM-aist is that it provides a simple way to create and co-operate various robot parts. Two kinds of port can be used the service port and the data port. The data ports provide the asynchronous messages and the service port establishes the synchronous communication. The usage of service port is complicated because we have to know the CORBA technology that is an out of date system. The connection among components has to be established at runtime by the end-user using a graphical interface. A comfortable state machine concept is provided i.e. the developer has to override the appropriate methods only. More programing languages and mostly used operating systems are supported. This is the second popular robot framework in the world. (The most popular in Japan.)

The final investigated robot framework is the ROS (Robot Operating System), that seems a basic operating system, but it provides similar features as previously mentioned (available at [8] ). The concept is detailed by Quigley in [9] . The items of robot system have to be registered a central server as well, but this component is called ROS node in this case. This node is the basic structure that can not be divide more parts in official ROS, but a 3rd party component exists called nodelet which support run more algorithm in one process (node). A central process has to be run (one roscore file creating a ros master and rosout nodes) providing the central log opportunity and a distributed parameter set. The connections among node are established automatically, i.e. if a component is running that advertises the topic and the other which subscribe to the topic, then the two nodes store information about the other using the roscore API. The developers' work is assisted completely, but only few tools are available end-user. This is the most popular robot middleware all over the world.

In the case of all investigated robot framework a concept is handled as distributed entity that is an agent or a port or a component or a node. The YARP provides more communication possibility nevertheless it has poor set of tools. Unfortunately the development of YARP and OpenRDK is broken. Only two robot frameworks are used nowadays, the OpenRTM-aist and the ROS, which is in progress so in the later part these robot system will be compared and detailed.

In this section the ROS and the OpenRTM-aist robot middleware are investigated in point of view of developer. The complexity of significant procedures are compared and additionally the helper tools.

The OpenRTM-aist robot framework is responsible for more services for the end-user than other ones. It supports the substitution of component, robot system creation, change of parameters of the robot, and the control of the component. Some command line tools are presented in rtc_shell package which are Python scripts. In addition, a graphical system editor is shipped as Eclipse plugin. The size of this system editor (and the Eclipse itself) is too large and the graphical capabilities are limited, but it is an effective supervisory interface of the system (the graphical interface is shown in the 24. ábra.)

In the left side of the window the end-user can browse the online components in the middle part the actual robot system is shown. In the right side the main parameters of the component are shown. The end-user can start or stop the robot system or any component of the system at any time. If this GUI is not sufficient, than a new tool should be created. Unfortunately, the detailed documentation of OpenRTM-aist system is missing so the source code investigation is needed.

Exiguous amount of tool exist in ROS aiding the end-user. Some graphical tools are implemented in qt helping to view the log messages and draw the structure of robot system. Moreover, we should mention a promising tool that runs in a browser called Robot Web Tool. This is a Java script collection communication to the Python server application (a bridge to ROS) but additional development is necessary.

The OpenRTM-aist contributes more features to end-users via graphical interface, but more knowledge is needed for developer. In the case when the researcher would like to try more solutions i.e. varying the component the OpenRTM-aist is better than ROS.

It supports more programming languages and operating systems also, so it is easy to integrate it into the existing topology and easy to develop the new system. Unfortunately, the documentation is poor and some of them are exist in japan only which is not popular except in Japan. The support of more operating systems is mentioned as advantage, but it is drawbacks also, because it can lead to complicate and heterogeneous robot topology. If our robot system requires components which are found, however that components can be run only different operating system, it requires additional PC-s. The OpenRTM-ais provides more tools and features to developers, but more knowledge and experience are needed, nevertheless the documentation of the system is poor. More useful code can be found in the sample projects complementing the missing documentation, however the developer has to search it and has to try it with different parameters. An active community of OpenRTM-asit exists in Japan, nevertheless the questions and the replies are presented in Japanese language only in most cases.

The ROS is suggested in the case of autonomous system when the connection of robot parts is mandatory. In this case the graphical editor is not necessary. Because of huge number of existing components, probably one or more component exists which fulfil our requirements which are small, so the understanding and the modification are an easy task. It is easy to create a new project from the scratch (easier than OpenRTM-aist) because the creation of classes is optional we have to use existing classes and methods only. The development of the ROS core is continuous by a community, the seventh version is in progress. There are a lot of information about it and a lot of questions and answers on the web page.