involves many different researchers with different programming needs, levels of ..... [10] Intelitek. http://www.intelitek.com/default.asp. [11] Lynx Real-Time ...
Integrating Heterogeneous Robotic Software J.A.Fernandez-Madrigal, C. Galindo, and J. Gonzalez System Engineering and Automation Department University of Málaga.Campus Teatinos - Complejo Tecnológico 29071 Málaga (Spain) e-mails: {jafma,cipriano,jgonzalez}@ctima.uma.es Abstract— Software development for large robotic projects involves many different researchers with different programming needs, levels of mastery, and areas of research. Integrating such heterogeneous software while maintaining requirements like realtime, dependability, intensive access to hardware, etc., is a challenge in any long-term effort of this kind. A step forward along that way is the BABEL development system that supports heterogeneous programming languages (C, C++, JAVA), communication middleware (CORBA, TCP/IP connections), and platforms (RT-operating systems, MS-Windows). This paper focuses on the core of BABEL: the Aracne specification that covers the design phase of the robotic application lifecycle. Index Terms—Robotic Software, Software Development, Distributed Software.
BABEL development system: the Aracne specification, that covers the design phase of a robotic software application and provides the basis to solve the RSIP. The key point in Aracne is flexibility: it must be able to integrate both very dependable and little (or non at all) dependable software, to support different implementations and executions platforms, to provide facilities for integration of networking or not, to exhibit capabilities of designing both large and small applications, etc. PORTABLE ENTITIES Structural Portable Entities Application
NON-PORTABLE ENTITIES
Codification Portable Entities General Platform Module Code
I. INTRODUCTION
T
RADITIONALLY, software development issues have not been widely addressed in robotics literature. However, in the last years, because of the increase in complexity of robotic applications and an also increasing flow of ideas from software engineering into the robotics arena (software analysis, design, validation; real-time systems; distributed systems), producing high quality robotic systems has become an important aspect. Some of these topics have been studied in depth: distributibity, dependability, real-time, or intensive hardware interaction. In this paper we focus on those others commonly present in software engineering but rarely addressed in robotics: reduction of development cost, reusability, maintainability, etc. There is a point that has a great influence in these latter topics: robotics research has a high degree of multidisciplinarity, that is, it involves very different areas, creating the necessity of integrating a variety of disciplines into working, robust, efficient applications. This is what we call the robotic software integration problem (RSIP). This paper presents Aracne, a specification for the design of heterogeneous applications that provides a first approach to the RSIP. Aracne is the core of the BABEL development system [1],[2] (an extension of a previous system called NEXUS [3],[4]), that also contains tools to facilitate the implementation, execution, debugging, and maintainance of robotic applications [5]. Following sections illustrate the features of Aracne through a real robotic application. Some conclusions and future work are also outlined.
II. THE ARACNE SPECIFICATION We focus on the issue of integrating heterogeneous software without jeopardizing characteristics such as dependability and efficiency. For that purpose, we present the core of our
1 1..*
1
1
1..*
1
1..* Particular Platform
Conceptual Unit Interfaced Code
1 2
1..* Module
1
1
1
1
Nested Code
1..*
1
2 Interface Bridge
PURE NON-PORTABLE RELATIONS Support
1 0..*
1..* Services Group Code Atom
Nested Code
INTERMMEDIATE RELATIONS
1 Configuration
1..* Service
PURE PORTABLE RELATIONS Communication
Codification
Composition
Fig. 1. Pseudo-UML class diagram of the entities and relations of the Aracne specification. This diagram does not fit the UML specification strictly: a) generalization relations are shown as grey-filled regions; b) the recursive composition of nested code entities is denoted by repeating the nested code class; c) other relations existing between entities, that are not of a composability nature, are included as additional components of Aracne: pure portable relations (only relate portable entities), pure non-portable relations (only relate non-portable entities), and intermediate relations (relate portable to non-portable entities).
In general, the structure of the Aracne specification consists of entities connected by relations (see fig. 1). Aracne’s entities can be portable or non-portable. Portable entities are the part of the application not tied to a particular implementation, while non-portable entities can vary from one implementation to another. This division encourages the reuse of software, and also greatly helps in allowing the programmers to focus on the functionality of the robotic application rather than in low-level details (hardware, operating systems, communications, etc.). The rest of the paper describes more deeply Aracne entities and their relations. These concepts, and in particular their suitability for integrating heterogeneous developments, are illustrated by designing a real robotic application that enables
a user to remotely monitor and request tasks to one of our mobile robots, called RAM-2 (see fig. 2).
Fig. 2.The RAM-2 mobile robot. It is equipped with a robotic arm, a laser scanner ultrasonic sensors, and a camera, managed by two onboard computers. III.
PORTABLE ENTITIES AND THEIR RELATIONS
Portable entities of Aracne are classified into two categories. The first one, structural portable entities, is used to specify the structure of the application. Under that perspective, the application is composed of module entities, which provide services to other modules, maybe through a net. The second category is composed of codification portable entities, that are still portable but closer to implementation. They are used to specify the codification of structural portable entities in some programming language1. 1) Structural Portable Entities The structural portable entities are the following (see fig. 1): The application entity, which consists of a set of modules. The module, which is an indivisible program that can be executed on a certain machine (computer, microcontroller, etc.). Modules can be grouped into conceptual units in the design phase, for clarity. A module can be one out of three types: common module, hardware interface module, or software interface module. A common module models a normal program which is an execution piece of the application. A hardware interface module provides the functionality of some piece of hardware to the rest of the application, hiding hardware management details. Finally, a software interface module encapsulates software that has not been designed following the Aracne specification but communicates with the application. Our RAM-2 application is composed of modules of these three types. Some of them are listed in table I. A module, regardless of its type, provides services to other modules (maybe to itself) that can be collected into groups of services for clarity in the design. The services of a module express its functionality. For reusability purposes, the part of the module that implements the execution logic associated to each service is kept private to the module (through
1 Some readers may be surprised by the inclusion of codification into the design phase. Our decision is intended to enable both the use of validation techniques on codification, and the reusability of code.
codification portable entities), thus separated from the public specification of the service. Module Description Conceptual Unit Type Robot Interface with motors and Low-Level Hardware Motion odometry Control Interface Arm Interface with the robotic Low-Level Hardware Motion arm motors Control Interface Laser Interface with laser range Perception Hardware Manager sensor Interface Sonar Interface with sonars Perception Software Manager Interface Camera Interface with the camera Perception Hardware Manager Interface Position It estimates the robot Navigation Common Estimator position. algorithms Obstacle It checks for close Navigation Common Avoidance obstacles. algorithms Table I. Some modules of our robotic application. A module can request services from others. For instance, the position estimator module can reset odometry errors in two different ways: using the laser measurements and a matching algorithm ([7],[15]), or by extracting environment vertical lines using a CCD camera mounted onto the robot [14].
A service is the minimal sequential execution entity within a module. A service provides certain functionality, and can access to the internal status of its module. In addition, it can request other services and generate asynchronous communications. Services are of three types: regular, event handlers, and notification handlers. Table II shows some services provided by the Robot Motion Manager module of the RAM-2 application. A regular service is requested by others or started by its own module when the module initiates. An event handler service is executed only when an asynchronous event with the appropriate identification is received from other module. Finally, a notification handler service is executed only when an asynchronous notification is generated within the same module. All the services of a module can run concurrently. More details on the type, characteristics and utility of services can be found in [2]. Regular services can have input parameters and output data (results of its execution). In addition to the output data, the requester receives a package of information that includes communication errors, module faults, or any anomalous situation that the requested service desires to propagate to its caller. Robustness in Aracne benefits from these features. Service Description Type SetVelocity Changes the robot velocity Regular ReadVelocity Reads the robot velocity. Regular Emergency Stops the robot if a critical error occurs Event Stop (i.e. a failure in the obstacle avoidance) Handler Table II. Three services of the Robot Motion Module. Example of two regular and an event handler service. The Emergency Stop service is executed when a module sends an emergency event reporting any anomalous circumstance.
2) Relations Between Structural Portable Entities Two relations can connect structural portable entities: communication, that permits modules to transfer information, and composition, which makes up the application. Two main types of communications can be distinguished within a robotic application: signals, to notify asynchronously
some situations, or transmissions, for transferring data between services synchronously. The composition relation specifies the set of modules that make up the application. This relation is intended to be useful in other phases of the software lifecycle, for example when maintenance tools, such as module repositories, are available. 3) Codification Portable Entities Codification portable entities allow the programmer to design the code of services and modules. He/she can propose codification entities (including programming sequences, such as StateCharts [9]), and then produces source code; but Aracne is also aimed to firstly writing code in some programming language, and then interpreting it to automatically produce a set of codification entities. The most basic codification entity is the code atom, which represents a finite piece of sequential code that can be defined without using other codification portable entities. There are two types of code atoms: heterogeneous code atoms and Aracne code atoms. The former represents sequences of sentences in some programming language. The latter represents Aracne operations. The most evident Aracne code atoms concern communications: service requests, service responses, event signalling, etc. An example is the operation taken from the module Obstacle Avoidance of our RAM-2 application, which requests a service for configuring the laser managed by the Laser Manager module, in order to acquire 180 samples at 38400 bauds with a precision of 0.5 degrees: [request-synchronous&blocking,"Config", "Scanner Manager", Config", "REMOTE_PLS”, "38400, 180, 0.5","err_var","0","INF" ]
Code atoms can also include time information: a time interval with the expected duration of the execution of the atom. That information can be used for validation of the realtime requirements of the application. Codification portable entities are described in more detail in [2]. 4) Relations between Structural and Codification Portable Entities Once the structural portable entities have been designed and codification portable entities have also been produced from source code, the programmer must link codification to structure. This is done through the codification relation. A codification relation is defined between modules and codification portable entities in such a way that it indicates which codification correspond to a given module. Thus, it is possible to check the validity of aspects of the design, for example, if the time requirements of the structure are achievable by the codifications assigned to the modules. Moreover, codification relations permit to relate more than one codification entity to a given module. In that way, Aracne captures the extensibility issue and improves reusability of design. In addition, this also permits to use some fault tolerance mechanisms like implementing different replicas of a module (active replication, [8]). IV. NON-PORTABLE ENTITIES AND THEIR RELATIONS Non-portable entities in Aracne are General Platforms and
Particular Platforms. General platforms classify the nonportable support necessities of the application: hardware, execution, communications, etc. Particular platforms are real instances of general platforms (i.e., a given operating system). Aracne has been conceived in this way for covering a wide range of possible components, guaranteeing the heterogeneity of the design. 1) General Platforms Currently, Aracne admits five different general platforms: A hardware platform (HP) represents a set of hardware devices needed for the physical execution of the application including at least one processor unit and a motherboard2. The HP groups together: CPU(s), motherboard devices (hard disks, sound/graphic cards, real-time clocks, etc.), plugged-in devices (acquisition boards, network interfaces, etc.), and peripherals (monitor, external storage devices, etc.). Our RAM-2 application includes five different HPs: two onboard motherboards, the arm-controller, and two remote computers (one for user interfacing and monitoring tasks, and another for managing a symbolic model of the world and task planning). An execution platform (EP) represents the software execution environment of the application. This includes: operating systems, virtual machines, software libraries, and execution libraries (i.e. interfaces with hardware devices). The execution platforms included in our application are Microsoft Windows NT and XP [12] when no real-time is required, and LynxOS [11] to support hard real-time operations as motor control, collision avoidance, etc. (see fig. 3). A communication platform (CP) represents the software needed for communicating the modules of a distributed application. It can provide from simple protocol support (peerto-peer, TCP/IP) to object distribution (like CORBA). The application described in this paper uses two communication platforms: the ACE+TAO [16] implementation of CORBA [17], and a serial RS-232 communication software to transmit data to the arm-contoller hardware platform. A real-time platform (RTP) provides real-time facilities: real-time scheduling, time measurement, sinchronization, etc. Only the facilities included in the LynxOS real-time operating system (which provides a POSIX 1003.4 compliant interface [6]) are used in our application for controlling both the vehicle and arm movement. A fault-tolerance platform (FTP) provides software faulttolerance facilities (in the current Aracne specification, active replication), but not included in our robotic application. 2) Relations Between Non-Portable Entities Aracne defines a relation between non-portable entities, called support, to represent that hardware platforms provide support to a given execution platform, which in turn supports to a realtime platform. Support relations can be represented by an 2 In a microcontroller, the “motherboard” usually includes just the CPU, main memory, and I/O facilities.
acyclic directed graph, called Platform Configuration Graph in Aracne (PCG). Fig. 3 illustrates the PCG of our RAM-2 robotic application. Note that with the PCG, problems like using a hardware platform that does not include a real-time clock (when it is needed a real-time platform), can be detected and corrected in the design phase by using verification tools.
JAVA Monitor Remote Computer #1
RTP 3 RT-Lynx POSIX 1003.4
SP 1 Lisp Interpreter
SP 3 JAVA Compiler
SP 2 Visual C++
SP 4 gnu gcc
EP 1 MS Windows NT
EP 2 MS Windows XP + JAVA Virtual Machine
EP 4 MS Windows NT
EP 3 Lynx
HP 1 PC Pentium III
HP 2 PC AMD Athlon
HP 4 PC Pentium IV
HP 3 PC Pentium II
Obstacle Avoidance
Task Planner
Fig. 3. PCG for the robotic application designed with Aracne. Nodes of the graph represent particular platforms, while edges represent “is supported by”.
PCG allows the application to be implemented in a given set of non-portable components (computers, network, software, etc.). The key point is that portable entities are kept unchanged from one PCG to another, that is, the portable design of the application is reused as much as possible. Since, a given PCG permits the portable entities to satisfy their requirements, the resulting implementation through that PCG will also satisfy them. If a PCG does not provide enough support for all the requirements, the programmers will know at design time that the corresponding implementation will exhibit reduced capabilities, or that it will be unsuitable at all. V. RELATIONS BETWEEN PORTABLE AND NON-PORTABLE ARACNE ENTITIES Previous sections have presented most of the design of a real robotic Aracne application. However, the design phase is not complete until portable entities are associated to the implementation that supports them: non-portable entities. Relating portable to non-portable entities consists of defining relationships between modules and the processing platforms where they are going to be executed. These relationships enable validation tools to detect problems in the application before execution: impossibility of satisfying execution requirements (real-time or fault-tolerance,), no way to create the implementation (not appropriate source code platforms), possibility of creating reduced-performance implementations, etc. The representation of these relationships is nearly direct: each module is associated to one processing platform. This is called an Application Configuration Relation (ACR). Fig. 4 depicts the ACR of the RAM-2 robotic application.
Position Estimation (Laser + Sonar)
Onboard Computer #1
Fig. 4. ACR for our robotic application. The application uses four computers (and the arm-controller, not shown). Remote Computer #1 monitors the robot status and requests tasks, while the other one perform task-planning. Finally, the two robot onboard computers manage the robot sensors and actuators.
SP 5 ACL Interpreter
HP 5 Arm Controller (CPU: Motorola 68020)
Onboard Computer #2
Arm Motion
Remote Computer #2
CP 2 Serial RS-232
CP 1 CORBA
Position Estimation (CCD Camera)
Robot Motion
VI. CONCLUSIONS AND FUTURE WORK The present work has introduced the Aracne specification, which is the core of the BABEL Development System. It is aimed to solve the RSIP, that is, to facilitate the integration of heterogeneous robotic software. The work has been focused on the design and implementation phases of the development lifecycle. Aracne is flexible enough for achieving heterogeneity, as it has been demonstrated in our research during the last years and illustrated in this paper with a real application. Currently, we are extending the BABEL framework with tools for other phases of the development lifecycle: validation, debugging, maintenance, etc. REFERENCES [1] [2]
[3]
[4]
[5]
[6] [7]
[8] [9] [10] [11] [12] [13] [14] [15]
[16] [17] [18]
BABEL homepage: http://www.isa.uma.es/investig/babel/investig.htm. Fernández-Madrigal J.A. The BABEL Development System for Integrating Heterogeneous Robotic Software. Tech. Rep. System Engineering and Automation Dpt., University of Málaga, June 2003. Fernandez-Madrigal J.A., Gonzalez J. NEXUS: A Flexible, Efficient and Robust Framework for Integrating the Software Components of a Robotic System. ICRA, Leuven, Belgium, May 1998. Fernández-Madrigal J.A., González J. The NEXUS Open System for Integrating Robotic Software, Robotics and Computer-Integrated Manufacturing, Vol. 15, nº 6, 1999. Fernández-Madrigal J.A., González J., A Visual Tool for Robot Programming, 15th IFAC World Congress on Automatic Control, Barcelona, Spain, July 2002. Gallmeister B. (1995). POSIX 4. Programming for the Real World,. O'Reilly & Associates. Gonzalez J., Ollero A., and Reina A. Map Building for a Mobile Robot equipped with a Laser Range Scanner. ICRA San Diego, CA, USA, May 1994. Guerraoui R., and Schiper A. Software-Based Replication for Fault Tolerance. IEEE Computer. Vol. 30, n. 4, 1997. Harel D. StateCharts, A Visual Formalism for complex Systems. In Science of computer Programming, vol. 8, 1987. Intelitek. http://www.intelitek.com/default.asp Lynx Real-Time Systems. LynxOS Application Writer’s Guide, 1993. Microsoft Homepage. http://www.microsoft.com/homepage/ms.htm Microsoft Visual C++. http://msdn.microsoft.com/visualc/ Muñoz A.J., and Gonzalez J. 2D Landmark-based Position Estimation from a Single Image. ICRA, Leuven, Belgium, April 1998. Reina A., Gonzalez J., A Two-Stage Mobile Robot Localization Method by Overlapping Segment-based Maps. Robotics and Autonomous Systems. Elsevier Science. Vol. 31, June, 2000. Schmidt D., ACE+TAO Corba Homepage, in: http://www.cs.wustl.edu/~schmidt/TAO.html Schmidt D.C. An Overview of the Real-Time CORBA Specification. IEEE Computer, vol. 33, nº 6, 2000. Sun MicroSystems Inc. http://java.sun.com/
