CoRoBa,a Multi Mobile Robot Control and Simulation Framework

Abstract

This paper describes on-going development of a multi robot control framework named CoRoBa. CoRoBa is theoretically founded by reifying Real Time Design Patterns. It uses CORBA as its communication Middleware and consequently benefits from the interoperability of this standard. A multi-robot 3D simulator written in Java3D integrates seamlessly with this framework. Several demonstration applications have been developed to validate the design and implementation options.

1. Introduction

Robotic systems are inherently multi-disciplinary and for such applications software aspects are of prime importance. Even a single robot application generally implies the use of external hardware and sensors having each their own control system and has de facto a distributed architecture.

Many searchers in robotics have been faced with the difficulty to integrate existing systems into new projects and to recycle existing code that has been produced by preceding projects. What is consequently needed in robotics is software architectures based on state-of-the-art computer engineering techniques that greatly improve software reusability like object-oriented languages, software components and software design patterns. This paper describes on-going developments which goal is to design, implement and evaluate performances of a multi-robot control framework. To validate the chosen approach, we developed and integrated several modules required to build typical robotic applications. The Framework name is CoRoBa, which stands for Controlling Robots with CORBA.

It is evident that this effort is not unique and that other laboratories have faced similar frustrations when implementing their control software and have consequently developed frameworks based on similar requirements. One of the best-known examples is certainly the module generator GenoM. It is a tool that helps building real-time software architectures and corresponds to the functional level of the architecture developed at the LAAS-CNRS (Alami, R & all, 1998). MCA2 is a software framework with real-time capabilities that is rapidly gaining in popularity (available at http://mca2.sourceforge.net). The DCA framework (Peterson, L.; Austin, D.; Christensen, H. 2001) has been developed to control a mobile manipulator. It relies on a process-algebra for specifying tasks. The main drawback in GenoM, DCA and MCA2 are their proprietary communication mechanism. Some frameworks solve the aforementioned limitation by building up on communication middleware. Miro (Enderle, S & all, 2001) is a distributed object-oriented framework developed in C++ for Linux that is based on CORBA technology. It offers synchronous and asynchronous communication and configuration capabilities through XML files. MARIE (Mobile and Autonomous Robotics Integration Environment) is a programming environment which aim is to develop an integration framework based on the mediator design pattern for distributed systems. MARIE uses ACE (Schmidt, D. C. & Huston, & S. D., 2003) as its communication library. All interactions between applications are done asynchronously. Orca (Brooks, A. & all, 2005) is an emerging open-source suite of tools for developing component-based robotic systems (available at http://orca-robotics.sourceforge.net). The Miro weak point is its behaviour engine and the lack of remote management. MARIE's approach, as mentioned in (Côté, C. & all, 2004) suffers from many drawbacks, namely, overhead, complexity and system resource management. CoRoBa tries to merge the strong points of the frameworks mentioned above while minimizing weak points. But as in all real projects, compromises have to be made and a perfect solution will never exist.

Because having a simulator is essential when developing robot control software we have developed a 3D multi-robot simulator, whose name is MoRoS3D, that integrates seamlessly in the control framework. A similar project is GSV (Graphical Simulation and Visualisation) that has been developed at the University of Auckland by the Robotics Research Group as a module of their robot programming environment. Like in MoRoS3D simulation services are exposed as CORBA interfaces. However, this simulator does not meet one of the guidelines specified in section 2 because of its commercial 3D engine.

Section 2 presents the software requirements that must be satisfied by the framework. In section 3 we discuss the selection and usability of Middleware for distributed robot control system and detail Design Patterns that guided the software development. Section 4 covers Component design and implementation and gives some examples of existing components including the simulator. Section 5 describes the current state of the work and obtained results. Section 6 concludes with comments on further research directions.

2. Requirements

Two different approaches have been considered when identifying requirements for the framework. The first approach took into account the functionality of typical applications that would be built with the framework whereas the second one considered the needs of potential users. This analysis resulted into the following requirements list:

Integration of different robotic systems,

Concurrent control of several robots,

Platform independent GUI,

Shared control between several users,

Easy integration of user's algorithms.

Flexibility (Distribution, Modularity, Configurability, Portability, Scalability, Maintainability)

Performance and efficiency

It is obvious that some requirements conflict with each other: performance and efficiency for instance have to be traded with flexibility. However, as we do not target hard real-time applications, we can accept some performance degradations due to extra-communication overheads. The following guidelines have also been considered during the development of the framework: Open source software, standard tools and technologies (UML, C++…) and Design Patterns.

3. Framework design and implementation

3.1. Low-level communication API and Middleware

The first decision when developing distributed application concerns the choice of the communication library. Some framework developers have opted for the low-level socket library. While this is a good choice with regard to performance, it is a bad one concerning portability and maintenance. One solution is to use a multi-platform wrapping communication library like ACE. It is a very powerful library that can eliminate some of the drawbacks listed above but that leaves much work to the programmer. The need for a higher-level communication library is clear. A communication Middleware lies somewhere between the low level system API and the application and automates many operations by abstracting low-level function calls. Among all existing Middlewares, CORBA has been selected because of its language and platform independence. As such a Middleware is quite complex and brings some overheads, one could ask the question if it is really usable for implementing robot control applications. The network performance can be expressed by the following relation:

$$\text{Message Transmission Time}=\text{latency}+\text{length}/\text{data transfer rate}$$

On one hand, the operations added by CORBA increases the latency (that is independent of the message length). On the other hand, the extra information contained in a CORBA frame is quite constant (a few hundreds of bytes) and has therefore a larger influence for small data packets We typically have a 20 to 30% overhead in comparison with raw socket communication. This result is confirmed by a comparative performance experiment reported by D. Gill in (Gill, C. & Smart, W., 2002). However, with increasing computing power and communication bandwidth, the overhead introduced by CORBA becomes every day less and less significant. In (Gowdy, J. 2000) J. Gowdy qualitatively compares Interprocess Communications Toolkits for Robotics and concludes that: “If the project is a long-term project …, then a more flexible and standard … communication infrastructure such as CORBA may be called for …”.

Among different CORBA implementations, we have chosen ACE|TAO because it is widely adopted and supported, it implements most of the CORBA specifications (including Notification Service, AMI, and RT-CORBA) and is free open-source software. But we are not limited to this implementation for developing components and other ORB's (Objects Request Broker) that have links to C++ or other languages like Java and Python can be used too. In (Colon, E. & Sahli, H., 2003) we showed that our Middleware selection helps fulfilling the requirements listed in section 2.

3.2. Framework design

3.2.1. Framework and control architecture

A framework is a set of cooperating classes that make up a reusable design for a specific class of software. The framework architecture defines how components are integrated into the framework and how they are interrelated. Reuse on this level leads to an inversion of control between the application and the software on which it is based: components written by the programmer are called back by the framework in response to events.

A control architecture on the other hand specifies which components are used and how they collaborate. The framework architecture must be flexible enough to allow different logical control paradigm to be build using the same components: direct control, telecontrol, assisted telecontrol, autonomous robots (deliberative and reactive), multirobot applications, etc. Framework components fall into two categories: structural components that offer basic services used by other components and application components that are the building blocks of an application.

3.2.2. Design Patterns and framework

Design Patterns (DP) bring a theoretical foundation to the software development. A DP describes a recurring programming problem and the core of the solution to that problem. It also lists the consequences of its use and gives implementation hints. We now have a look at the Architecture and Distribution DP, which are used by the CoRoBa framework. Most of the patterns are directly implemented by CORBA or its services.

Name: Component-based Architecture Pattern.

Problem: We need an architecture that is robust in the presence of maintenance and is highly reusable in a variety of circumstances.

Solution: The Component-based Architecture Pattern organises system into replaceable units with opaque interfaces.

Consequences: Systems may be constructed via assembly; we select at run-time which components we want to use. Opaque interfaces hiding implementation details can be seen as an advantage or a disadvantage. Components tend to be heavy in terms of required resources (memory, size on disk).

CoRoBa implementation: We don't use components as known in the computer engineering literature (ActiveX, Bean…) but the framework consists of replaceable execution units (processes) that are independently and remotely managed. Components can be added, (re)moved, discovered and located at run-time thanks to the Name Service.

Name: Channel Architecture Pattern.

Problem: We would like an architectural structure that improves throughput capacity with the replication of units allowing efficient processing of multiple data in different stages of processing. We also would like an architecture that improves reliability and safety through the simple addition of redundant processing.

Solution: The Channel Architecture Pattern is useful when data within a stream is sequentially transformed in a series of steps. A channel can be thought of as a pipe that sequentially transforms data from an input value to an output value. It is possible to find multiple elements of the data stream in different parts of the channel at the same time.

Consequences: The Channel Architecture Pattern improves the flexibility provided by the Component-based Architecture Pattern by lowering the coupling level between components. The event architecture greatly facilitates the implementation of Reliability Patterns.

CoRoBa implementation: Data are sent as events between the components that process and forward them to the next component(s). Components are lose coupled by the events whose data structures are declared in CORBA IDL (Interface Definition Language) structures.

Distribution, which is an essential aspect of architecture, comes in two primary forms: asymmetric and symmetric. In asymmetric distribution systems, the binding of objects to the address space is known at design time while in symmetric distribution system is not known until runtime. Symmetric distribution is more flexible and allows dynamic load balancing. The patterns presented below deal with the collaboration architecture, which focuses on how the objects find and communicate with each other.

Name: Remote Method Call Pattern.

Problem: The programming model used to invoke services locally is very well understood and what is needed is a means to do the same think even when the client and server do not reside in the same address space.

Solution: The Client does not communicate directly with the Server but via a Client Stub that contacts the Server Stub, which invokes the specified method on the Server. The low-level network operations are hidden to the Client and Server.

Consequences: this pattern simplifies the process of client-server communication over a network. There are many middleware implementations that reify this DP. Most of them propose a compiler that automatically generates the stubs.

CoRoBa implementation: CoRoBa relies on IDL (Interface Definition Language) compilers to generate stubs for clients and servers.

Name: Broker pattern.

Problem: A limitation of most of the distribution patterns is that they require a priori knowledge of the location of the servers. This limits their use to asymmetric distribution architectures. Ideally, the solution should provide a means to locate and then invoke services at the request of the client.

Solution: The Broker Pattern may be though of as a symmetric version of the Proxy Pattern. It provides a Proxy Pattern in situations where the location of the clients and servers are not known at design time. The Broker is an “object reference repository” globally visible to both clients and the servers.

Consequences: The Broker Pattern is a very effective means for hiding remoteness of clients and servers. While not completely successful in hiding all the details, it nevertheless greatly simplifies the creation of systems with symmetric distribution architectures.

Commercial ORB's do require a minimum amount of resources that may exceed those available in smaller systems. For those cases, it may be possible to use smaller, less capable ORB's or write one from scratch that includes only the desired capabilities. In the Broker Pattern, the clients may dynamically discover the relations. This makes the Broker Pattern more scalable than the Proxy Pattern but also somewhat more heavyweight.

CoRoBa implementation: This pattern is definitively implemented by CORBA, which is the middleware CoRoBa is based on. The communication model proposed by CORBA is a synchronous one. Blocking calls are not the most appropriate way to communicate in control software. The Data Bus Pattern provides a better solution.

Name: Data Bus Pattern.

Problem: Many systems need to share many different data among a mixture of servers and clients, some of whom might not be known when the client or data is designed

Solution: The Data Bus Pattern further abstracts the Observer Pattern by providing a common (logical) bus to which multiple servers post their information and where multiple clients come to get various events and data posted to the bus. The Data Bus Pattern is basically a Proxy Pattern with a centralized store into which various data objects may be plugged along with metadata that describes its contents. It serves to further decouple the client implementation from the server's. The pattern comes in both “push” and “pull” versions.

Consequences: The Data Bus pattern offers a single location for clients to go and acquire data and for servers to publish their data. The Data Bus is extensible; it does not have to understand the semantics of the data. New servers and clients can be added and, with the help of a Name Server, located at run-time.

CoRoBa implementation: Asynchronous communication in CoRoBa is based on the Event Service and its extended and improved version, the Notification Service that reify this pattern. Components are connected through Event Channels provided by the Notification Service.

4. Component design and implementation

This section presents the DP implemented by the component architecture. It also reports on integration of existing systems into the framework.

4.1. Mechanistic design

The component architecture implements the Hierarchical Control Pattern and the Message Queuing Pattern explained below.

Name: Hierarchical Control Pattern.

Problem: We desire separate the interfaces for the control and configuration of the objects and the actual functionality provided by the object.

Solution: The Hierarchical Control Pattern uses two types of interfaces: control interfaces that monitor and control how the behaviours are achieved and functional interfaces, which provide the services controlled by the other set of interfaces. This pattern is based on composition.

Consequences: The use of separate control and functional interfaces provides a simple and scalable approach when the system must be highly configurable.

CoRoBa implementation: We define at the top level of the hierarchy the Service interface that contains the declaration of generic management operations as well as types definition and exceptions. The operations defined in the Service interface are implemented in the Service class, which, once compiled, forms the Service library. A service is composed of a main thread in which run the ORB and a service thread. The service thread can be remotely managed by invoking operations defined in the Service interface (Fig. 1). Using a controller interface defined and implemented at the top level of the class hierarchy allows managing the run cycle of all components easily with unchanged CORBA invocations. A CoRoBa Service admits the following commands: start, pause, wakeup, and stop. It has 3 working modes that can be remotely selected by the set|mode(…) operation: synchronous (process data when available), periodic (whose period can be changed) and external (synchronized on an external trigger). The normal synchronous 2-way can also be used by calling additional methods declared in the IDL interfaces of derived components.

Fig.1

Events communication between components

Name: Message Queuing Pattern.

Problem: In most multithreaded systems, threads must synchronise and share information with others.

Solution: The Message Queuing Pattern provides a simple means for threads to synchronise and communicate information among one another using asynchronous communications implemented via queued messages.

Consequences: This pattern has many advantages and is supported by virtually all real-time operating systems. The primary disadvantages are that it is a relatively heavyweight approach to information passing among threads and information must be shared by value instead of by reference.

CoRoBa implementation: All CORBA objects are implemented by servants inheriting from the Service base class. This class itself inherits from the ACE class ACE|TaskBase that eases the creation of portable multithreaded applications. When the thread is started, the inherited svc() method is executed and calls the virtual method process|data() declared in the Service base class and that must be implemented in subclasses. The loop is run conditionally and flags allow pausing or stopping it. These flags are set and reset by Service methods implementing the CoRoBa Service interface operations that can be remotely invoked by administration tools.

4.2. Actuator, Processor, Sensor

We have defined three interfaces, Sensor, Processor and Actuator that inherit from the Service interface. The classes implementing these interfaces are considered as abstract and may not be instantiated and consequently real services interfaces are derived from these ones. The code is actually organised in two parallel hierarchies: the IDL interfaces and the CoRoBa classes implementing these interfaces. Sensors have connections with the physical world and they output data to one Event Channel. Processors get their inputs from one Event Channel; they transform data and send the result to another Event Channel. Actuators have output connections with the physical world and received data from one Event Channel

4.3. System integration

While new services are designed from scratch, existing applications and systems will need to be integrated in the framework. Depending on the communication and API available this integration can be a trivial or a tricky job. Integration is usually made by providing a facade, aka an object wrapper following the Wrapper Facade pattern. When wrapping libraries, we need to pay attention to serialize data access if existing libraries are not thread-safe.

4.3.1. Robot integration

In the case of our Nomad200, it comes with an API that is available for the Linux OS. We have written an actuator component that translates CORBA method invocations to motion command functions of the API and a sensor component that reads the different sensors' values and propagates them as events. The operations listed in the Nomad interface keep the same signature as the original functions of the Nomad200 API.

The integration of the second robot (Robudem) is simpler because we do not have to wrap any existing API. On the Robudem main computer runs a server that transfers data via shared memory between the Linux and the RT-Linux side of the control application. The data structure that contains the robot kinematics information but also the motion commands are exchanged via sockets. As only one client is allowed to connect to the robot, the CoRoBa wrapper component breaks with the design standard presented above that separates sensors from actuators. It is actually a processor that receives motion commands via events, propagates the commands via sockets to the Robudem server, receives the kinematics data as the reply from the socket server and finally forwards the kinematics information via the output event channel. The control of the robot is implemented by CoRoBa processor components.

4.3.2. Sensor integration

We take as example a metal detector (MD) that we use for detecting mines in humanitarian demining projects. This MD has a serial interface for configuring the system and for reading sensor signals. Two solutions are possible: the sensor component communicates directly with the serial port or the serial port is wrapped into a generic component that simply propagates messages received as events to the serial port and sends the response back. The second solution adds one unnecessary communication step. Both solutions have to be implemented as a processor because they realise duplex communication and must consequently have an in and an out Event Channel connection.

4.3.3. Simulator integration

The 3D simulator allows multiple mobile robots to be simulated at the same time (Fig. 2). It is based on Java3D that imports VRML models. Multiple virtual cameras are available (fixed, onboard, tracking) that can be selected via the GUI. The user can also (re)set the robots position, and erase the trajectory markers.

Fig 2.

MoRos3D simulator showing 8 identical robots in indoor environment

As the simulator has been designed to provide CORBA interfaces for all robots and sensors, its integration in the framework is straightforward. Two possibilities exist for a CoRoBa component to communicate with the simulator: via Event Channels or via CORBA synchronous calls. In the first case the simulator acts directly as sensors and actuators. The second solution requires developing CoRoBa sensor and actuator components that communicate with the Simulator (via asynchronous calls or events). The advantage is that we keep the same application structure as in the case where we use real robots and sensors for which we necessarily have wrapper components.

5. Status and results

The CoRoBa framework has been used to implement components of the three categories. Following components are currently available:

Simulator: 3 robots (Nomad, Robudem, Melexis), Laser distance, US distance, GPS.

Actuators: Nomad, Robudem and the 3 simulated robots,

Sensors: Joystick, components wrapping simulated distance sensors and simulated robot encoders,

Processors: Fuzzy logic Goal navigation, Goal provider, Goal scheduler, Simple Obstacles Avoidance Behaviour.

Based on these components, following typical applications have been tested (simulation and/or real systems):

Direct joystick control of robots,

Shared autonomy obtained by combining the direct control and the obstacle avoidance components,

Goal navigation with fuzzy logic control,

Sequence of Goals,

Distributed simulation.

Real applications typically require one actuator per robot, one sensor per physical (or simulated) sensor and some processors. Most of the time sensors and actuators are constrained by physical connections while the location of the processors can be freely chosen.

Thanks to the modular architecture, developing a new empty component takes less than 15 minutes. The total time required to implement the functional code depends on the type of component. Integrating a new robot or sensor is off course more complicated than just coding some processing algorithms.

Concerning the simulator performances, typical figures for 8 robots with 16 laser distance sensor is 90% processor activity (Centrino 735) and a memory usage of 40MB, image refresh period in this configuration is 80 ms.

CORBA has a steep learning curve and several months were required for understanding and mastering programming subtleties. In comparison students were able to develop new components with CoRoBa in a few weeks, what demonstrated the efficiency of the proposed framework.

6. Further research

In order to further validate the framework, we need more demonstration applications; some could be simply build up by combining existing components in different ways while others will require the development of new components. We are also working on a general distributed Behaviour engine for multi-robots applications. In the next future, we will integrate other robots (Melexis developed at the VUB, a Cartesian scanner at the RMA) and real sensors (Laser, GPS, US, MD…).