Middleware for : A Survey

Nader Mohamed, Jameela Al-Jaroodi, and Imad Jawhar The College of Information Technology United Arab Emirates University Al Ain, P.O. Box 17551, UAE, {nader.m, j.aljaroodi, ijawhar}@uaeu.ac.ae

Abstract—The field of robotics relies heavily on various meets the design and implementation of different challenges of technologies such as mechatronics, computing systems, and technologies is a novel approach to resolve many of the wireless communication. Given the fast growing technological open issues and drastically enhance the development of progress in these fields, can offer a wide range of applications on such systems. applications. However real world integration and application development for such a distributed system composed of many Some research efforts have been done on surveying different robotic modules and networked robotic devices is very difficult. aspect of robotics. [1] surveyed space robotics. [2][3] focused Therefore, middleware services provide a novel approach more on robot programming environments characteristics and offering many possibilities and drastically enhancing the evaluations. [4] focused on surveying vision for application development for robots. This paper surveys the navigation, while [5] presented different current state of middleware approaches in this domain. It techniques. In addition, some research efforts were conducted on discusses middleware challenges in these systems and presents surveying different middleware approaches for emerging some representative middleware solutions specifically designed technologies such as ad hoc networks [6] and wireless sensor for robots. The selection of the studied methods tries to cover networks [7]. However, none of the existing work investigated most of the middleware platforms, objectives and approaches the current state of research on the design and development of that have been proposed by researchers in this field. middleware for robotics. In this paper, we explore different important middleware projects for robotics, and provide a Keywords—robots, middleware, robot system integration discussion of these approaches.

I. INTRODUCTION The remainder of the paper is structured as follows. Section II provides a short overview of robotic applications and outlines the The advances of technology in computing, wireless most relevant challenges that face a middleware design for communication, mechatronics, and sensor technologies is robotics. In Section III, we describe several research projects in pioneering an emerging field of robotics, and offering an middleware for robotics. Section IV, is a discussion of the unprecedented opportunity for a wide array of real time different approaches used and some open research issues. Section applications. Examples of these new applications are Search-and- V concludes the paper. rescue (SAR) missions in dangerous environments or inaccessible terrains, human-assistance for the elderly or physically challenged, and medical/surgical robots. Future robots for II. MIDDLEWARE CHALLENGES FOR ROBOTICS upcoming applications should be modular for easy and rapid While the older generations of robots were designed to implementation, flexible, maintainable, customizable, self achieve specific tasks and manufactured as one unit, the new configuring, self-optimizing, and able to interact with other generations of robots are usually ubiquitous and autonomous. systems like senor networks and enterprise information systems. This is achieved by using modular design and implementation. New robots are composed of heterogeneous interconnected Modern robots are considered complex distributed systems hardware components. These components are usually controlled consisting of a number of integrated hardware and software by software modules developed by different manufactures using modules. The robot's modules cooperate together to achieve different programming languages. These components may also specific tasks. These modules are sensors, actuators, and use different communication mechanisms. Software modules are controllers. Due to their tight integration to the physical world and also needed to process sensor information and control actuators unique characteristics, robots in general pose considerable for performing computational, vision and cognitive tasks like impediments and make the development of robotic applications planning, navigation, and user interaction. non-trivial. There must be new software services that glue all of the components together in an efficient manner, supporting Although modular design has many advantages in concurrency-intensive operations and insuring robustness and engineering, it raises some integration issues such as modularity. A friendly user programming interface that executes communication, interoperability, and configuration. These issues applications and marshals the high level constructs of the could be solved by using a middle layer, middleware. In general, programming language to the low level constructs understandable middleware systems are used in distributed systems to reduce to the operating system should be provided. The middleware development time and cost. This is achieved by providing well- should be customizable to different scenarios, applications and structured and well-tested services for often-needed environments it should also be self-configuring, self-adapting, and functionalities. In addition, it provides some value added self-optimizing. Indeed the need for a middleware layer that fully functions that can not be added to the operating systems such as

978-1-4244-1676-9/08 /$25.00 ©2008 IEEE RAM 2008

reliability, security, and abstraction. However, the design and III. DIFFERENT MIDDLEWARE FOR ROBOTICS development of a successful middleware for robots is not trivial. As mentioned above, several researchers and research groups It needs to deal with many challenges dictated by robots are working on middleware solutions for robotics. Some design characteristics on one hand and the applications requirements on principles and research projects have already been proposed and the other hand. These challenges are the following: implemented, while others offer conceptual models and • Simplifying the development process: application development is frameworks for the proposed middleware. In this section, which is not easy for the robotic environment. Middleware should simplify the focus of our paper, different approaches and projects will be the development process by providing higher-level abstractions presented. However, due to the size restrictions, we will limit the with simplified interfaces that can be used by developers and the detailed descriptions to some projects that we view as more middleware should also enhance software integration and reuse. representative of the issues in discussion. • Support communications and interoperability: robotic modules A. Miro can be designed and implemented by different manufactures. Miro [8][9] is an object-oriented middleware for robots Efficient communication and simple interoperability mechanisms developed by University of Ulm, Germany. The main motivation are needed among these modules. Therefore, robotic middleware of using object-oriented middleware is to improve the software should provide these functions. development process for mobile robots and to enable the • Providing efficient utilization of available resources: robots interaction between the robots and enterprise information usually need to execute processing- and communication-intensive systems. Miro is designed and implemented by applying object- tasks in real-time. Examples are vision processing, mapping, and oriented design and implementation approaches using the navigation. Therefore, efficient utilization of robot components and common object request broker architecture (CORBA) standard. resources is needed. The robots may have single or multiple This allows inter-process and cross-platform interoperability for microprocessors, one or more interconnection networks and distributed . Miro is constructed using three layers: several other resources. Middleware should help in efficiently the device, the service, and the class framework. The device layer utilizing these resources for different application requirements. • provides object-oriented interface abstraction for all sensor and Providing heterogeneity abstractions: any robotic system contains actuator devices. This layer is platform-dependant. The service many heterogeneous hardware and software components. layer provides abstractions for devices via CORBA interface Communication and cooperation among these components is an definition language (IDL). The class framework provides a important aspect. Commonly the abstraction of this role is played number of often-needed services such as mapping, self by a middleware which acts as a collaboration software layer localization, behavior generation, path planning, logging, and among all involved modules, hiding the complexity of the low- visualization facilities. The layered architecture and object- level communication and the heterogeneity of the modules. • oriented approach make Miro very flexible and expandable to Supporting integration with other systems: New types of robots support new devices and new services for new robot applications such as ubiquitous robots need to interact with other systems such [10]. Miro was implemented using multiplatform libraries for as other robots, wireless sensor networks, and high-end servers. easy portability. Examples of these libraries are the CORBA- Most of these interactions should be done in an abstract way and in based adaptive communication environment (ACE) [11], used for real-time. Hence, middleware should provide real-time interaction providing object-oriented abstraction layers for many operating services with other systems. systems and communication primitives and the CORBA • Offering often-needed robot services: A great deal of effort is Notification Services [12] used for providing the event-based spent writing new implementations of existing algorithms and communication functionality. control services for robots multiple times. The same algorithm/service may be rewritten several times due to changes in B. Orca the robot’s hardware, the development of new applications, Orca [13] is a middleware framework for developing changes in the operating systems, changes of technical staff, or just component-based robotics. It is designed to target applications for adding new functionalities. These often-needed robot services from single vehicles to distributed sensor networks. The main should be provided by robotic middleware which allows for reuse goal of Orca is to enable software reuse in robotics. Orca enables of the modules offering these functionalities. implementing a distributed component-based robotic system by • Providing automatic recourse discovery and configuration: allowing the user to define interfaces and communication robots are considered dynamic systems due to their modularity and mechanisms. Orca was implemented using CORBA. However, mobility. For example external devices can be dynamically due to the complexity problems faced with CORBA, Ice [14] was available/unavailable for a robot’s use. Hence, automatic and used. Ice is a new approach to object-oriented middleware that dynamic resource discovery and configuration are needed. In offers a much smaller and more consistent API, lighter addition, it should support mechanisms for the robots to be self- implementations, advanced services, and good performance. Orca adapting, self-configuring, and self-optimizing. is an open-source product. • Supporting embedded components and low-resource-devices: robots in many situations use or interact with embedded devices C. UPnP Robot Middleware: that may have several limitations such as limited power, small UPnP middleware [15][16] was developed by Korea Institute memory, limited operating system functionalities and limited of Science and Technology to utilize the Universal Plug and Play connectivity. Handling such resources is usually different from (UPnP) architecture for dynamic robot internal and external handling other regular resources; therefore, the middleware should software integrations and for ubiquitous robot control. UPnP was provide special functionalities to manage the resources as needed. developed to offer peer-to-peer network connectivity among PCs, wireless pervasive devices, and intelligent appliances [17]. The

UPnP has automatic discovery and configuration mechanisms. E. ASEBA These mechanisms are utilized to configure robot components ASEBA [22] is an event-based middleware that supports and to allow ubiquitous robots to discover and interact with other distributed control and efficient resource utilization of devices around them such as cameras, sensor networks, and multiprocessor robots. This middleware is designed for robots electromechanical devices. The new trend for implementing new with several processors that communicate through a shard bus. robots is to assemble a number of robot components that form the Some robots, in addition to the main processor, have several final robotic system. These components are usually created by microcontrollers that are part of or close to the sensors and different manufactures using various hardware and software actuators to control them. Microcontrollers can communicate technologies. A modular robot can be manufactured by among themselves by asynchronous messages called events. connecting multiple components through an internal network. If Messages are only transmitted when relevant events occur. For each component supports UPnP, then the process of linking and example when a specific observation was noticed by a sensor, an configuring multiple robotic components together is simplified. event about that observation will be sent by the corresponding This approach provides a simple scheme for building intelligent microcontroller to another microcontroller or to the main robots with a lot of hardware and software components. It solves processor. This reduces the load on the bus as less data is some implementation issues currently facing the robotic field. transmitted compared to regular robot systems in which periodic The automatic discovery and configuration mechanisms are sensor readings and actuator commands are generated from the also appropriate for dynamic computing environments such as main processor. ASEBA improves the modularity and efficiency ubiquitous robots. Mobile robots can discover the existence of of robots by distributing some of the processing tasks to all the external devices and can configure themselves to interact with microcontrollers and communicating only the relevant data to the them. These devices can be cameras, sensor networks, and main processor. It allows dedicating the main processor for CPU- controllable electromechanical devices. Using UPnP mechanics intensive tasks such as vision processes and higher-level controls. robots are able to configure their internal components to interact Lightweight virtual machines are developed to run on with other external devices based on the specific goals or services microcontrollers. These virtual machines support the they should provide. This is an essential feature for the implementation of the policies for sending events. Policies are implementation of intelligence in robotics. The intelligence described by a simple scripting language called AESL (ASEBA component can be internal or external since software components Event Scripting Language). In addition, ASEBA provides an can cooperate with each other regardless of their location. integrated development environment with an editor, compiler and debugger for implementing distributed controls for robots. D. RT–Middleware F. Player/Stage System RT (Robot-Technology) - Middleware [18] was developed in collaboration between The Japanese Ministry of Economy, Trade Player/Stage system [23] is a middleware platform that and Industry (METI), The Japan Robot Association (JARA), and provides infrastructure, drivers and some algorithms for mobile National Institute of Advanced Industrial Science Technology robotic applications. This middleware has two major components: (AIST). The RT-Middleware is an infrastructure software based Player and Stage. Player is a device repository server for on CORBA implemented using a number of specifications at the actuators, sensors, and robots. Each device in Player is composed distributed middleware interface level and a prototype of a driver and an interface. Interfaces are the part used by the implementation named OpenRTM-aist was produced. The main client to write new applications that get information from a sensor goals of this middleware are to build robots and their functional or control an actuator. Drivers can also implement algorithms that parts in a modular structure at the software level and to simplify receive data from other devices, process it, and then send it back. the process of building robots by simply combining selected Stage is a graphical simulator that models devices in a user modules. These goals are to allow system designers or integrators defined environment. Driver can also generate arbitrary data to build customized robots for a variety of applications in cost when needed. The Player/Stage system is implemented as a three- effective and efficient manners. The components used to tier architecture in which the clients are software developed for construct robotic systems are called RT-Components. There are specific robot applications, the middle tier is Player which some efforts to standardize the architecture of RT-Components in provides common interfaces for different robot devices and the Object Management Group (OMG) [19]. These efforts will services, and the third tier is the actual robots, sensors, and enable fast integration among robotic components implemented actuators. Various client side libraries exist in the form of proxy by different manufacturers. objects for different programming languages to access the services provided by the Player platform. Clients can connect to Another important goal is to make robots more intelligent by the Player platform to access data, send commands, or request distributing their necessary resources over a network. RT- configuration changes to an existing device in the repository. Middleware provides the necessary services to enable Examples of client programming languages supported are C, implementing robotic applications that need these types of C++, Java, and Python. distributed systems. One example of these applications is a network distributed monitoring system for the human assistance Player serves as an interface to many different types of robotic robot system [20]. This application was developed to improve the devices and provides drivers for many hardware modules. Some interaction among the users and local robotic systems. In addition, of the main features of this middleware are the platform-, it enables a remote user to better monitor the local human and the programming language-, and transport protocol-independence; environment. Another application is the development of home open source; and modularity. Player's modular architecture makes integration systems [21]. In this project, multiple home devices it flexible to support new hardware. Players can run on both and appliances can interact with the robot system. regular and embedded Linux, Solaris, and BSD Unix.

Player/Stage system was started at the University of Southern computing functions. The Component layer is used to add California in the late nineties and moved to Source Forge in 2001. components for often-used services and to support domain- specific concepts. The Application layer contains useful services G. The PEIS Kernel and tools to build and manage integrated applications. MARIE The PEIS Kernel [24] is based on a collaborative research middleware provides some services that allow the adaptation of project between the Electronics and Telecommunications different communication protocols and applications which make Research Institute (ETRI), Korea, and The Centre for Applied it very flexible. The integration aspect of MARIE uses the Autonomous Sensor Systems, Sweden. This middleware is Adaptive Communication Environment (ACE) communication designed toward the concept of Ecology of Physically Embedded framework [11]. A variety of software components can be Intelligent Systems, or PEIS-Ecology, in which many robotic connected in MARIE using a centralized component. In addition, devices, pervasively embedded in everyday environments such as there are four functional components: application adapters, our homes or offices, cooperate in performing some tasks in the communication adapters, communication managers, and service of people. In this approach, complex robotic application managers. Application adapters act as proxies functionalities are not achieved via the implementation of between the central component and the applications. The data extremely advanced robots, but rather through the cooperation of exchanged among application adapters is translated by many simple robotic components. The main aim of this communication adapters, while communication managers create middleware is to provide a common communication and and manage the connections. Finally, application managers cooperation model that can be shared among robotic devices such instantiate and manage components locally or across distributed as mobile robots, static sensors or actuators, and automated home processing nodes. MARIE follows the mediator design pattern in appliances. With this middleware, any robotic device with which it provides mediator interoperability layers among adapters software control in the environment is defined as PEIS. Each and managers. The key features of MARIE are the PEIS is a set of inter-connected software components developed interoperability and reusability of robotic application components. to control sensors or actuators. All PEIS devices are connected by a uniform communication model, which allows the exchange of J. RSCA information among PEIS devices and allows dynamic joining and The RSCA ( Communication Architecture) leaving of PEISs. All PEIS devices can cooperate using a uniform [28] is a QoS (Quality of Service) -Aware middleware for cooperation model. In this model, each participating PEIS can use networked service robots developed by Seoul National functionalities from other PEISs in the ecology in order to University. The key strength of RSCA is the real-time support. complement its own. For example, in a home environment, an RSCA provides a standard operating environment and autonomous vacuum cleaner (PEIS device) can use a localization development framework for robot applications. The operating function provided by an overhead tracking system (PEIS device) environment consists of a Real-Time Operating System, to know its position. The PEIS Kernel provides a shared memory communication middleware, and deployment middleware. The model, a simple dynamic model for self-configuration and operating system is compliant with the PSE52 in IEEE introspection, and supports heterogeneous devices. Both tiny POSIX.13. It provides an abstraction layer that makes robotic embedded devices and complex large robots are supported [25]. applications both portable and reusable on different hardware. The communication middleware is compliant to minimum H. ORiN CORBA and RT-CORBA v.1.1 [29] and provides mechanisms ORiN (Open Robot Interface for the Network) [26] is an for distributed heterogeneous components to communicate in interface developed to provide standard methods for accessing real-time. The deployment middleware provides frameworks for and controlling robotic systems from windows-based PCs. ORiN program execution in distributed environments, dynamic program is based on HTTP and other web technologies such as XML and deployment, real-time support, QoS, and a management SOAP. It was developed to target industrial robots. This interface capability for limited resources and heterogeneous hardware. provides separation between the specifications and the implementations and enables third parties to develop robotic K. The Middleware of AWARE applications that are controlled by PCs. Therefore low cost mutli- This platform [30] is a data-centric middleware for the vendor systems can be easily developed. The interface is based on integration of wireless senor networks and mobile robots the distributed object model which provides network transparency developed by the University of Seville, Spain and the University and language independence. In this system, various types of of Stuttgart, Germany. The main aim of this middleware is to robotic specifications are allowed and vendors can define unique provide simplified mechanisms for integrating information options using XML. gathered by various types of sensors including wireless sensor networks (WSN) and mobile robots. This type of integration is I. MARIE needed for applications where robots are used to obtain and MARIE (Mobile and Autonomous Robotics Integration process data from its environment through a WSN. This data can Environment) [27] is a middleware framework created for be temperature, light level, or humidity for example. Another developing and integrating new and existing software for robotic application is to allow a robot to locate itself in an environment systems. MARIE aims to create a flexible distributed components where GPD (Geographic Positioning Device) service is not system that allows robotics developers to share, reuse, and available. This middleware provides data-centric capabilities in integrate robotic software programs for rapid robotic application which users can access data in an abstract way. Any user of the development. MARIE is implemented in three layers: Core, network can make references to objects that exist in the Component, and Application. The Core layer consists of services environment, such as a fire, a car, or an animal. The user has to for communication, low-level operating functions, and distributed provide the conditions that define the targeted object. These

conditions can be, for example, high temperature for a fire object. of small, interconnected components. WURDE utilizes a message Then, the user can address any specific object in the environment passing protocol as its distributed computation mechanism. In in order to obtain data from it. In this platform, the middleware addition, WURDE uses asynchronous communication and wraps components are executed on all sensor and robot nodes. Sensor the communication mechanism to simplify the process of nodes use TinyOS operating system designed for devices with supporting new communication protocols. However, WURDE limited resources. dose not provide any security for controlling access to the modules. Another module built with WURDE is the RIDE L. Sensory Data Processing Middleware interface that provides multi-robot tasking and control This middleware [31] is developed at The University of mechanisms. It has interactive display environments. Tsukuba in Japan to provide abstracted services for accessing sensor information to support service mobile robots. Two types of IV. DISCUSSION AND OPEN ISSUES services were implemented to provide obstacle information and to localize the robot position using landmark observations from In the previous section we surveyed different existing multiple external sensors. This middleware provides a unified middleware approaches for robotics. The general observation is model for different configurations of external sensors on a service that all the projects target some form of enhancement to the mobile robot. The unified model abstracted from sensors can be robotics systems both at the development and the utilization used in any service mobile robot application independent of the levels. In addition, it is also clear that we cannot provide a clear sensors configuration. The developed services can be reused in set of distinct classification criteria that distinguish between the multiple applications without dealing with individual sensors. different projects and provide a solid basis for comparisons. However, we define here a set of main objectives each of which M. Distributed Humanoid Robots Middleware match a few of the projects listed above. These objectives are: This communication middleware [32] is developed by Honda 1. Enhancing the development process by providing some form of Research Institute with other organizations to facilitate modular design mechanisms, high level abstractions, and communication among the modules of distributed humanoid component-based development. Many projects have this goal in robots. In humanoid robots, a number of modules are needed such sight, for example, Micro, Ocra, RT-Middleware and WURDE. as sensors, actuators, planning modules, decision making 2. Reusability of existing components where developers and robot modules, movement controllers, etc. The performance quality of designers are provided with ready made components and software humanoid robots is completely dependant on the collaboration modules that can be put together to create new robot devices and and communication performance among these modules. The applications such as Ocra, UPnP Robot Middleware and MARIE. developed communication middleware serves various functional 3. Better utilization of resources and real-time support, where robots roles using three different communication subsystems: the are equipped with the capabilities to optimize resource utilization Cognitive Map (CogMap), Distributed Operation via Discrete and support real—time functions such as UPnP Robot Events (DiODE), and Multimodal Communication (MC). The Middleware, RT-Middleware, ASEBA, RSCA and Distributed CogMap allows for sharing and transforming information streams Humanoid Robots Middleware. dynamically among modules. DiODE provides direct connection 4. Integration with external systems where robots become capable of between two modules for direct and fast communication. Finally, MC provides service to stream raw sensory data to other modules. communicating and utilizing external resources like sensors, devices controllers and GPS systems. Some examples are: PEIS N. A Layer for Incorporations among Ubiquitous robots Kernel, ORIN, the Middleware of AWARE, Sensory Data This layer [33] is developed by Korea Advanced Institute of Processing Middleware and Middleware Layer for cooperation Science and Technology to enable communication among among Ubiquitous Robots. ubiquitous robots which are usually of different types. These 5. Flexible enhancements and expansion of functionalities, where it is types can be software robots, mobile robots, and embedded easy to enhance functionalities and incorporate new ones in robots. Software robots are similar to mobile agents while mobile existing robot systems such as Micro, Player/Stage and MARIE. robots are usually hardware robots controlled by software. This Although we listed examples for each objective, many middle layer is mainly designed to allow software robots and projects cover several of these objectives with varying degrees. mobile robots to communicate even when they use different Consequently, the examples given are mostly based on the main communication mechanisms. The middle layer consists of two objective of each project. As for the technologies or standards mappers: sensor mapper and behavior mapper. The senor mapper used in these projects we observe that many tried to follow well helps software robots get physical sensor information from defines and common technologies like CORBA, ICE, XML, and mobile robots; while the behavior mapper helps software robots virtual machines. Table 1 includes a list of all the projects make physical behavior using the actuators of the mobile robots. surveyed in the paper with a brief list of their objectives and O. WURDE technologies/standards used. The WURDE (Washington University Robotics Development As mentioned earlier, it is obvious that there is no clear Environment) Middleware [34] provides a set of utilities to definition or common understanding of what middleware for simplify interfacing with robotic components and software robotics should or should not provide, and how to provide them. development. The main goal of WURDE is to allow rapid It is apparent that different researchers and practitioners view the development of robotic applications by having clean levels of issues in different ways. As a result, the target of reaching a single abstraction. WURDE enables modular robotic applications to be middleware infrastructure that will solve all the problems of implemented in which robot software can be written as a number robotics systems is not realistic. There are many issues, technical

limitations and difficulties that need to be addressed to achieve a and difficulties of robotic systems such as high levels of good middleware-based solution. Some of these issues are: heterogeneity, limited resources, and high probabilities of failures that make the development of a common middleware a very 1. Current middleware systems provide very limited often-needed complicated task. Here we also identified some lacking features advanced services that can be used to simplify the development and open issues that current middleware approaches did not process and to enhance resource utilization. In addition, many of address. However, we view the difficulties and the open issues as the available services are not standardized, which make it difficult the motivations for working harder to design flexible and efficient to achieve interoperability between different robotic systems. middleware solutions for robotic systems. This may be one 2. The availability of self-adaptation and self-configuration common middleware or several middleware components which mechanisms is very limited. Since the target is to develop address different issues. In the end, the goal is to reach a useful autonomous and ubiquitous robots, these mechanisms are very solution, which we view as a hard, but achievable task. important to enhance the performance of the robotic applications. 3. The security mechanisms within the middleware solutions for V. CONCLUSION robotics are inadequately investigated. As the use of multiple robots and distributed robotic components increases, the need to In this paper, we surveyed several projects for middleware in secure their communication and collaboration becomes essential robotics and discussed some of the main issues that face the for their operations. However, researchers seem to steer away design and the development of such middleware solutions. Many from this issue. projects have different objectives such as simplifying the 4. There is very limited work towards providing high level development process, reusability, integration and flexibility. In abstractions for coordination and collaboration among multiple addition different projects used different technologies like robotic applications. Therefore, application developers working on CORBA, ACE, Virtual machines, XML, and message passing to collaborative robotic systems must start from lower, more achieve their objectives. Furthermore, we examined the current primitive levels. projects to determine what were the limitations and open issues 5. There is very limited work towards providing automatic that were not addressed well. As a result we identified several mechanisms for efficient utilization of the availability and the open issues that need to be addressed to be able to design a heterogeneity of multiple robots working on the same task. In comprehensive middleware solution for robotics systems. We some cases, tasks need to be distributed among the robots to be arrived at a general conclusion that it is very hard to have one completed in parallel rather than being done by individual robots. middleware platform that will solve all the problems and address While in other cases, the existence of multiple robots that have all the issues because that will basically result in a very complex heterogeneous resources provides a great opportunity to redirect system. In addition, many robotics systems do not need all the tasks to the robot with the most suitable resources. functionalities and features together. Therefore, we envision a modular or component-based middleware that provides As the author of [35] tries to answer the question: “Is a customizable solutions based on the integration of the needed Common Middleware for Robotics Possible?" He lists the issues components to design and develop the required robotic system.

TABLE 1. A SUMMARY OF THE OBJECTIVES AND TECHNOLOGIES OF THE DISCUSSED PROJECTS. Middleware Main Objectives Standards and Technologies Used Miro To improve the software development process for mobile robots and enable interaction CORBA between robots and enterprise systems using the distributed object paradigm. Orca To enable software reuse in robotics using component-based development. Ice UPnP Robot Middleware To enable automatic discovery, configuration, and integration for robot components in UPnP both modular and ubiquitous robots. RT–Middleware To make robots and their functional parts in a modular structure at the software level CORBA and to simplify the process of building robots by simply combining selected modules. ASEBA To allow distributed control and efficient resources utilization of robots with Event-based middleware, Virtual multiprocessors. machines Player / Stage System To provides a development platform that supports different robotic hardware and Three-Tier Architecture provides common services needed by different robotic applications. Proxy Objects The PEIS Kernel To provide a common communication and cooperation model that can be shared among A shared memory model multiple robotic devices. ORiN To provide an interface for accessing and controlling robotic systems from PCs. HTTP, XML , SOAP MARIE To create flexible distributed components that allows developers to share, reuse, and Mediator Interoperability integrate new or existing software programs for rapid robotic application development. Technology, ACE RSCA To provide real-time support for robotic applications and to provide abstractions that PSE52 in IEEE POSIX. 13, makes robotic applications both portable and reusable on different hardware platforms. CORBA, RT-CORBA v1.1 The Middleware of To provide data-centric capabilities for the integration of wireless senor networks and TinyOS, TinySchema, AWARE mobile robots. Publish/subscribe Sensory Data Processing To provide abstracted services for accessing external sensor networks information to N/A Middleware support service mobile robots. Distributed Humanoid To facilitate communication among the modules of distributed humanoid robots. Publish/subscribe, TCP & shared Robots Middleware memory. Stream communications Layer for Incorporation To enable communication among ubiquitous robots which are usually of different types. Sensor and behavior mappings WURDE To allow rapid development of robotic applications by having clean levels of abstraction Communication wrapping, Massage and modular development. passing,

Networked Robot Systems Development -", SICE-ICASE International REFERENCES Joint Conference 2006 (SICE-ICCAS 2006), pp.2633-2638, Oct. 2006. [1] L. Pedersen, D. Kortenkamp, D. Wettergreen and I. Nourbakshk, " A [20] S. Jia and K. Takase, "Network Distributed Monitoring System Based Survey of Space Robotics," in The 7th International Symposium on on Robot Technology Middleware," International Journal of Advanced , Robotics and in space (i-SAIRAS- Robotic Systems, Vol. 4, No. 1, pp. 69-72, 2007. 03), 2003. [21] Y. Hada, S. Jia, K. Takase, H. Gakuhari, and T. Ohnishi, "Deveopment [2] G. Biggs and B. MacDonald, "A Survey of Robot Programming of Home Robot Integration System Based on Robot Technology Systems," In Proc. of Australasian Conference on Robotics and Middleware," The 36th International Symposium on Robotics (IRS), Automation (CSIRO), Dec. 2003. Japan , 2005. [3] J. Kramer, M. Scheutz, "Development Environments for Autonomous [22] S. Magnenat, V. Longchamp, F. Mondada, "ASEBA, an event-based Mobile Robots: A Survey," Autonomous Robots, Volume 22, No. 2, pp. middleware for distributed robot control" Workshops DVD of 101-132, Feb. 2007. International Conference on Intelligent Robots and Systems (IROS), [4] G. N. DeSouza and A. C. Kak, "Vision for Mobile : A Oct.-Nov. 2007. Survey," IEEE Transactions on Pattern Analysis and Machine [23] M. Kranz, R. Rusu, A. Maldonado, M. Beetz, A. Schmidth, "A Intelligence, Vol. 24, No. 2, pp. 237-267, Feb. 2002. Player/Stage System for Context-Aware Intelligent Environments," in [5] S. Thrun "Robotic Mapping: A Survey," Technical Report CMU-CS- Proc. of the System Support for Workshop 02-111, School of Computer Science, Carnegie Mellon University, Feb. (UbiSys), Sep. 2006. 2002. [24] M. Broxvall, B.S. Seo, W.Y. Kwon, "The PEIS Kernel: A Middleware [6] S. Hadim, J. Al-Jaroodi, N. Mohamed, "Trends in Middleware for for Ubiquitous Robotics," in Proc. of the IROS-07 Workshop on Mobile Ad Hoc Networks," The Journal of Communications, Vol 1, No. Ubiquitous Robotic Space Design and Applications, Oct. 2007. 4, pp. 11-21, July 2006. [25] M. Bordignon, J. Rashid, M. Broxvall, A. Saffiotti, "Seamless [7] S. Hadim and N. Mohamed, “Middleware Challenges and Approaches Integration of Robots and Tiny Embedded Devices in a PEIS-Ecology," for Wireless Sensor Networks,” in IEEE Distributed Systems Online, in Proc. of the IEEE/RSJ Int. Conf. on Intelligent Robots and Systems Vol. 7, No. 3, art. no. 0603-o3001, March 2006. (IROS), Oct. 2007. [8] S. Enderle, H. Utz, S. Sablatng, S. Simon, G. Kraetzschmar, and G. [26] M. Mizukawa, H. Mastsuka, T. Koyama, T. Inukai, A. Nodad, H. Palm, "Miro: Middleware for autonomous mobile robots," IFAC Tezuka, Y. Noguch, and N. Otera, "ORiN: Open robot interface for the Conference on Telematics Applications in Automation and Robotics, network," In SICE, pp. 925-928, 2002. 2001. [27] C. Côté, Y. Brosseau; D. Létourneau; C. Raïevsky, F. Michaud, [9] H. Utz, S. Sablatng, S. Enderle, G. Kraetzschmar, "Miro – Middleware "Robotic Software Integration Using MARIE," International Journal of for Mobile Robot Applications," IEEE Transactions on Robotics and Advanced Robotic Systems, Vol. 3, No. 1, pp. 55-60, March 2006. Automation, 18(4):493-497, Aug. 2002. [28] J. Yoo, S. Kim, and S. Hong, "The Robot Software Communications [10] D. Krüger, I. Lil, N. Sünderhauf, R. Baumgartl, P. Protzel, "Using and Architecture (RSCA) QoS-Aware Middleware for Networked Service Extending the Miro Middleware for Autonomous Robots," Towards Robots," in Proc. International Join Conference SICE-ICASE, pp. 330- Autonomous Robotic Systems (TAROS), Guildford, September 2006. 335, Oct. 2006. [11] D. C. Schmidt, "ACE: An Object-Oriented Framework for Developing [29] D. C. Schmidth, A. Gokhale, T. Harrison, and Parulkar, "A Higher- Distributed Applications," Proceedings of the 6th USENIX C++ Performance Endsystem Architecture for Realtime CORBA," IEEE Technical Conference, April 1994. Communication Mag., Vol. 14, Feb 1997. [12] T. H. Harrison, D. L. Levine, and D. C. Schmidt, "The Design and [30] P. Gil, I. Maza, A. Ollero, P. Marrón, "Data Centric Middleware for the Performance of a Real-Time CORBA Event Service," in Proc. Integration of Wireless Sensor Networks and Mobile Robots," in Proc. OOPSLA'97, pp. 184-200, Oct. 1997. 7th Conference on Mobile Robots and Competitions, ROBOTICA 2007. April 2007. [13] A. Makarenko, A. Brooks, and T. Kaupp, "Orca: Components for Robotics," In International Conference on Intelligent Robots and [31] E. Takcuchi and T. Tsubouchi, "Sensory Data Processing Middlewares Systems (IROS), pp. 163-168, Oct. 2006. for Service Mobile Robot Applications", in Proc. International Join Conference SICE-ICASE, Oct. 2006. [14] M. Henning, "A New Approach to Object-Oriented Middleware," IEEE Internet Computing, pp. 66-75, Jan.-Feb. 2004. [32] V. Ng-Thow-Hing, T. List, K.R. Thórisson, J. Lim, J. Wormer, "Design and Evaluation of Communication Middleware in a Distributed [15] S. Ahn, J. Lee, K. Lim, H. Ko, Y. Kwon, and H. Kim, "Requirements to Architecture," IROS '07 Workshop Measures and UPnP for Robot Middleware," in Proc. of the IEEE/RSJ Int. Conf. on Procedures for the Evaluation of Robot Architectures and Middleware, Intelligent Robots and Systems (IROS), Oct. 2006. 29 Oct. - 2 Nov. 2007. [16] S. Ahn, K. Lim, J. Lee, H. Ko, Y. Kwon and H. Kim, "UPnP Robot [33] T. Kim, S. Choi, and J. Lim, "Incorporation of a Software Robot and a Middleware for Ubiquitous Robot Control," The 3rd International Mobile Robot Using a Middle Layer," IEEE Transactions on Systems, Conference on Ubiquitous Robots and (URAI Man, and Cybernetics, Part C: Applications and Reviews, Vol. 37, No. 2006), Oct. 2006. 6, pp. 1342-1348, November 2007. [17] UPnP, www.upnp.org [34] F. Heckel, T. Blakely, M. Dixon, C. Wilson, and W. D. Smart, "The [18] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, W. Yoon, "RT- WURDE Robotics Middleware and RIDE Multi-Robot Tele-Operation Middleware: Distributed Component Middleware for RT (Robot Interface," AAAI Mobile Robotics Workshop, 2006. Technology), IEEE/RSJ International Conference on Intelligent Robots [35] W. Smart, "Is a Common Middleware for Robotics Possible?," In and Systems (IROS), pp. 3555-3560, Aug. 2006. Proceedings of the IROS 2007 workshop on Measures and Procedures [19] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, "RT(Robot Technology)- for the Evaluation of Robot Architectures and Middleware, Oct. 2007. Component and its Standardization - Towards Component Based