Architecture:Motivation

Previous: Architecture index

Next: Overview

Motivation

Distributed, multi-modules robotics applications are currently built in the System and Automation Engineering department using the BABEL [1] development tools: the Module Designer (MD), the Execution Manager, and the Debugger. With the MD we can specify the attributes, services and events of modules. The interface of a module is given by its services, which can be called in a RPC (Remote Procedure Call) style if we know the service name and its input and output parameters. Traditionally, module interfaces have been developed based solely on the designer’s criterion, while not taking entirely into account their potential reusability and coherent integration into larger software structures. The ACHRIN robotic architecture [2] solves part of this problem with the introduction of common interfaces for Functional Groups, modules in charge of a specific task like navigation or manipulation. However, we rethink in this report the problem of interfaces between modules, keeping the following points in mind:

• Modules are elements of a larger structure, which we call the Control Architecture. Therefore their design must take into account not only intra-module issues, but the connections with the rest of the system.
• At some points, it is desirable to define BABEL-level interfaces acting as frontiers between low and high-level tasks. This makes easier the maintenance, reusability and substitution of existing modules, as well as the creation of new modules.
• The same architecture should run over different mobile robots with different sensors, or over a simulator, without recompiling any module. Since low-level tasks are highly related to the specific robotic platform, a normalized description of the execution platform (the robot) should be used for the software to discover the hardware details and to behave accordingly.
• The units in which parameters are given have typically been a source of confusions. Here we propose to use always units from the Systeme International (S.I), as meters, seconds, meters/second and so on.
• Modules dealing with hardware sensors must cope with a number of the same device attached to the robot (e.g. two laser scanners). It would be desirable for some modules to access to sensory data by groups for commodity and reusability, e.g. to read the laser scans from all the laser range finders on the robot.
• Reliable error propagation is another major goal. Failures in hardware or low-level software must be reported to high-level modules as sensors or actuators malfunction.
• Initialization parameters have been traditionally hard-wired in the code or set apart in ".ini" files. This specification provides a unified interface to configuration parameters stored using XML of all low-level modules. Further more, a visual application for easily editing them has been developed.
• It is desirable an event-driven data flow, as opposed to the current polling mechanism for obtaining data from sensors.

In the rest of this report we discuss these issues: in section 2 we give an overview of the proposed architecture model. The next section examines it in detail, giving developers all the needed information to maintain or create BABEL modules according to the proposed framework. Section 4 is dedicated to Robotic Platform Descriptors (RPDs) and a new graphical user interface (GUI) created to facilitate their edition. Finally we discuss issues to be specified in the future. Additional appendixes are provided with implementation details.