An Intelligent Robot Architecture based on Robot Mark-up Languages

An Intelligent Robot Architecture based on Robot Mark-up Languages Jun-young Kwak, Ji Young Yoon, and Richard H. Shinn IEEE Conference Publishing (IEEE ICEIS’2006) Intelligent Robot Architecture Team of Intelligent Robotics Lab, Bonavision, Inc. 301, Auto Industries Association B/D 1638-3 Seocho-Dong Seocho-Gu Seoul, 137-725, Korea Abstract ⎯ An intelligent robotic system is built by integrating a number of component systems. Building an intelligent robot thus requires a tremendous effort, as well as time and money to integrate component systems developed by various researchers. It is critical for success to build a system in a development environment where time and money can be budgeted properly. In order to integrate the robotic components correctly and complete the entire task within a limited budget and time, it is critical to find a good architecture where all the development processes are conducted efficiently. One of the design goals of our software platform is to provide an open and generic atmosphere where developers have freedom to mix and match their preferred technologies today as well as tomorrow. Within this framework, any program module can be plugged into the platform so that it works with other program modules. As an effort in achieving our goal, we propose a Robot Mark-up Language approach based on standard XML technology. Acknowledgment ⎯ This research (paper) was performed for the Intelligent Robotics Development Program, one of the 21st Century Frontier R&D Programs funded by the Ministry of Commerce, Industry and Energy of Korea. Keywords ⎯ Robot Mark-up Language, intelligent Robot Software Platform, Integrated development environment, Robot Middleware, Interoperability, Service-oriented architecture, Component-Based Architecture, Generic Architecture, Multi-agent system

1. Introduction Developing an intelligent robot requires working with a broad spectrum of issues from theoretical to practical. First, many robotic systems built to handle, in particular, humanitarian tasks, are aimed at being intelligent. Intelligent robot activities include problem solving and planning, learning from humans as well as from experiences, storing experiential knowledge in memory for later use, and the ability to execute intelligent interactions with humans as well as other robots. Finding and combining intelligent activities relevant would solve many robotic tasks intelligently. However, building an intelligent robot is an expensive process requiring enough time and money. It is costly and time-consuming to build robotic parts in reality in order to find out if it works as designed. A robotic system is developed by

integrating a number of subsystems created by many different experts. The process involves a number of people performing a variety of tasks in different environments. Efficient integration of various system resources often employs reliance on middleware. This ensures interoperability among different program components written in different programming languages such as C/C++ or Java. Successful integration of software components is required to be tested. In order to integrate the robotic components cost-effectively, it is critical to find a good architecture where all the development processes are conducted efficiently. This paper proposes an approach based on Robot Mark-up Language to efficiently integrate different software parts in a heterogeneous robotic system environment. We currently develop robotic systems to aid elderly persons, who are physically handicapped and/or sick, and to service and to guide them providing with needed information interactively.

2. Overview of Robotic Software Architecture Developing a robotic system is a complicated process of building and integrating a variety of software programs to run on top of robotic hardware. In order to build such a system efficiently, it is desirable to utilize a software platform where all software programming activities are executed. In this paper, our software platform for the intelligent robot is called Intelligent Robot Software Platform (iRSPTM). iRSPTM provides a tool to create software components, assemble and integrate them, to see if it works as desired. In our component-based architecture, a robotic system is composed of standard modular software components. This is to enhance maintainability as well as to accomplish rapid development. A robotic system supports a layered architecture (Figure 2-1). Our software platform, iRSPTM, resides on the CORBA middleware, running on a Linux operating system.

The Software Component Executor executes programs by using the Robot Runtime Module (RRM). RRM parses the assembled program and then executes the services of the software modules by linking with the CORBA middleware. (Figure 2-5)

Figure 2-1. Layered Architecture

iRSPTM is composed of four major subsystems: S/W Component Browser, S/W Component Assembler, S/W Component Simulator, and S/W Component Executor with Configuration Tool. (Figure 2-1 and Figure 2-2)

Figure 2-2. Subsystems of iRSP

TM

The S/W Component Browser provides browsing capabilities for currently available software components in the repository. The S/W Component Assembler, given a robot task, helps pick a sequence of software components and assembles them into a connected network following the syntax of our Robot Mark-up Language (Figure 2-3).

Figure 2-4. S/W Component Assembler & Simulator

Figure 2-5. Simulation and Execution Process

The Configuration Tools help developers set parameters to initiate the program. This connects to the middleware of the robot and identifies the memory to save RML (Robot XML). As shown above, iRSPTM provides the full capability of browsing of software modules, combining and simulating them within convenient user interface. iRSPTM, in addition, provides its users with an efficient capability of browsing for hardware devices such as device drivers and resource checking. iRSPTM is a software platform where users can provide efficient access not only to all robotic hardware devices but also to all software resources (Figure 2-6). Without iRSPTM, users and developers would not have the capability of accessing and managing hardware and software facilities. iRSPTM is an open and generic architecture where all software tools used follow standards such as Linux, standard CORBA middleware, Java and C/C++ programming languages.

Figure 2-3. S/W Component Assembler (Packaged components)

The S/W Simulator helps simulate the components assembled to see if it behaves as expected. (Figure 2-4)

Figure 2-6. Why iRSPTM? Figure 3-2. CORBA ORB Architecture

4. Robot Mark-up Languages 3. Middleware for a Distributed Robotic System Many robotic programs are developed in heterogeneous system environments including multiple programming languages such as C/C++ and Java, multiple network protocols such as TCP/CP and RPC, and multiple knowledge representation formalisms. Integrating a number of different systems at multiple levels is a considerable issue. (Figure 3-1) In order to support the interoperability, middleware such as CORBA is used. In such an environment, all Java and C/C++ programs are implemented as class objects. Each program module is transformed into a CORBA object. (Figure 3-2) In CORBA, program modules are identified by IDL (Interface Description Language).

Figure 3-1. Middleware

A. Introducing Robot Mark-up Languages XML is simple but powerful enough to express as much as modern programming languages. It is also flexible in accommodating web service technology. On top of XML, we have developed our Robot Mark-up Language (RML) as a subset of XML with its tags specialized in the robotic domain. Depending on their tags, RML is divided in two parts: Robot Service Mark-up Language (RSML) and Robot Plan Mark-up Language (RPML). RML can be viewed as a higher level language, but it ensures interoperability among the high level languages, Java and C/C++. B. Why Robot Mark-up Languages (RMLs)? In conventional AI implementation, a plan is written in AI language such as LISP or Prolog. A plan is found to be usually as a sequence of operators. In our framework, a robot program is a collection of component programs written in either Java or C/C++ languages. In the programs, each program module is represented by a class while functions or operations are represented by methods in the class. No matter what language is used, classes and methods are written in the same RML logic. Thus, in our model, a plan is represented by a sequence or network of methods. Thus, the role of RML is to seamlessly integrate a number of program modules written in different languages. C. Using RSML (Robot Service Mark-up Language) In the framework of the component-based architecture, each program unit is called either a software component or software module. In the context of service-oriented architecture supporting the web service concept, a software component is presented as a service in RML as part of XML.

Combining the two together, each software component is mapped into a service concept in XML. (Figure 4-1) Given a software component, RML thus creates the corresponding interface in terms of method and input/output parameter information, and description.

Figure 4-3. Example of plan defined in RPML

Figure 4-1. RSML Tags

D. Why RPML (Robot Plan Mark-up Language)? RPML (Robot Plan Mark-up Language) was invented to describe a plan in terms of a network of operations as a solution to a given task. (Figure 4-2) RML is capable of expressing all possible control flow so that a plan is represented as a various sequence of operations.

E. Implementation Details Our framework has been developed to provide developers a common platform where software products can be used together. The framework supports the development of intelligent robots at many different levels. Our robotic system aims to interact with humans, particularly elderly people, aiding them with a variety of services in different forms. First, each program module is wrapped into a CORBA object using CORBA’s IDL (Interface Definition Language). (Figure 4-4)

Figure 4-4. Example of software module “CmNavigationMap” in CORBA IDL

Second, CORBA objects in its IDL form are mapped into RML objects (Figure 4-5 shows). Note that, in the case where middleware is replaced by a new middleware, all plans in RPML and in RSMLs remain with no changes.

Figure 4-2. RPML Tags

Plans described in RPML are used later to simulate the behaviors and/or to execute the plan on a robot. (Figure 4-3) Figure 4-5. Example of software module “CmNavigationMap” defined in RSML

F. RML (RSML/RPML) Parser RSML Parser parses CORBA IDL to derive RML interface. RPML Parser parses plans to generate RML objects and then passes the plans to the Execution module. We utilize Jakarta Digester to simplify parse XML source to Java objects.

5. Related work As mentioned earlier, it is necessary to employ a middleware to integrate different programs developed in different program environments. Since our project includes different research groups relying on multiple programming languages such as C++ and Java, multiple operating systems such as Linux and MS Windows, and different network protocols, we also found that the use of a middleware is desired in integrating the heterogeneous systems. One of the middlewares frequently used in the robotic community is CORBA. Many research groups including OpenHRP adopt CORBA as their standard middleware. On the other hand, ERSP is similar to our model in that it defines behavior schemas and networks in XML (Figure 5-1). However, a behavior schema in ERSP corresponds to a method within the class, whereas a service in RSML corresponds to a class object. In ERSP, a behavior network composed of primitive behaviors corresponds to a low-level plan in RPML (Figure 5-2). ERSP targets to build a low-level task on a single level plan. However, RPML supports multi-level planning: RPML allows a plan to be written at any level by packaging it in the form of macro routines. Thus, RMLs are very flexible in supporting planning at multiple levels.

Figure 5-2. Behavior Network Tags of ERSP

AIBO Master Studio operates on top of R-Code, which is similar to a plan in RPML. R-code is a script language that controls behaviors of AIBO. AIBO Master Studio is composed of a behavior arranger and an action composer. The behavior arranger creates behaviors and integrates fifty voice commands or sensors information into them (Figure 5-3). The behavior program is then converted into R-code script. The action composer creates actions and then integrates them in behavior arranger or AIBO navigator.

Figure 5-3. Example of R-Code defined in AIBO Master Studio

6. Future Directions Figure 5-1. Behavior Schema Tags of ERSP

Within our robotic software framework, we have demonstrated the utility of XML-based Robot Mark-up Language and the benefits of its usage on the CORBA middleware. In sum, it provides plenty of freedom neutral to

particular programming languages chosen by different researchers depending on their applications. In addition, the use of RML takes advantage of the many XML capabilities, which are both flexible and extendible to web service and semantic web technologies. We are currently considering adopting a service-oriented architecture that uses a more dynamic middleware than CORBA. Since RMLs inherit their properties from XML, maintain all capabilities, it is thus usable with web service technologies. iRSPTM based on RMLs also extends its capabilities in three directions. First, it supports a full life cycle of development (Figure 6-1). Currently, it provides a capability of integrating multiple software modules. It expands to cover full life cycles including planning, execution, and monitoring. Simulation capabilities will also be included to generate virtual components to enable simulating the functions with the components not yet available. Second, layered architecture is employed to better accommodate levels of software abstraction. Third, it will be a tool for users as well as for developers. Currently, iRSPTM is mainly for a developer’s workbench: however, it will become a programming shell for users as well. Thus, it will include user programming, training, and personalization of the robot, run service for a user.

entity such as another human being. Thus, a robot is better described as an intelligent agent (Figure 7-1). As an effort in achieving these goals, we propose a Robot Mark-up Language approach based on standard XML technology running on a distributed middleware.

Figure 7-1. Agent Conceptual Architecture

REFERENCES

Figure 6-1. Integrated Development & Verifying Cycle

7. Conclusion One of the design goals with our software platform, iRSPTM, is being open and generic so as to provide developers with freedom to mix and match their preferred technologies today as well in the future. In this framework, any program written in any language is in general a software module. For example, even a planner is a basic software module. Any program module can be plugged into the platform so that it works with other program modules. Thus, we will be able to enjoy advantages of a component-based architecture. In this way it will be easier to implement the intelligent aspects within the standard framework. Another design goal of iRSPTM is to make it an intelligent tool. A tool to develop an intelligent robot needs also to be intelligent to better reflect its intelligent behavior. As part of the effort, an AI type planner will be attached to recommend a desired solution plan. In addition, to be an intelligent robot, the robot should be able to interact with humans as an autonomous

[1] Bakken, D. 2001. Middleware. In Urban, J., and Dasgupta, P., eds., Encyclopedia of Distributed Computing. Kluwer.to appear. [2] Center for Distributed Object Computing. Washington University. TAO: A High-performance, Real-time Object Request Broker (ORB). www.cs.wustl.edu/≫schmidt/TAO.html. [3] Gill, C. D.; Cytron, R.; and Schmidt, D. C. 2002. Middleware Scheduling Optimization Techniques for Distributed Real-Time and Embedded Systems. In Proceedings of the 7th Workshop on Object-oriented Real-time Dependable Systems. San Diego, CA: IEEE. [4] Schmidt, D. C.; Stal, M.; Rohnert, H.; and Buschmann, F. 2000. Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Volume 2. New York: Wiley & Sons. [5] Philip E. Agre and David Chapman. Pengi: An implementation of a theory of activity. In Proceedings of the National Conference on Artificial Intelligence (AAAI-87), pages 268{272, Seattle, WA, 1987. Morgan Kaufmann, San Mateo, CA. [6] Ron C. Arkin. Motor schema-based mobile robot navigation. International Journal of Robotics Research, 8(4):92{112, 1989. [7] Ron C. Arkin. Integrating behavioral, perceptual and world knowledge in reactive navigation. Robotics and Autonomous Systems, 6:105{122, 1990. [8] Tadao Murata, Petri Nets: Properties, Analysis and Applications, Proceedings of the IEEE, Vol. 77, No. 4, April 1989. [9] Adam Cheyer, Luc Julia, and Jean-Claude Martin. 1898. A unified framework for constructing multimodal applications. In Proceedings of the 1998 Conference on Cooperative Multimodal Communication (CMC98), San Francisco, California, January. [10] Philip R. Cohen, Adam J. Cheyer, Michelle Wang, and Soon Cheol Baeg. 1994. An open agent architecture. In O. Etzioni, editor. Proc. of the AAAI Spring Symposium Series on Software Agents, pages 1-8, Stanford, California, March. American Association for Artificial Intelligence.