YARA: A Software Framework Enhancing Service ... - Semantic Scholar

YARA: A Software Framework Enhancing Service Robot Dependability Stefano Caselli, Francesco Monica, and Monica Reggiani Dipartimento di Ingegneria dell’Informazione Universit`a degli Studi di Parma Parco Area delle Scienze, 181/A – 43100 Parma, Italy {caselli, fmonica, reggiani}@ce.unipr.it

Abstract— This paper focuses on the role of real-time operation support in mobile robot control architectures for service applications. We show that a control architecture with integrated real-time features ensures better performance in terms of accuracy in navigation and reactivity to external events, compared with an architecture where no provision for real-time has been made. We argue that proper consideration to real-time operation should be given in order to ensure safe, dependable robot operation in human-inhabited environments. Along the paper, we describe features of YARA, a software framework improving dependability of mobile robot architectures by virtue of its support for real-time operation. Index Terms— Service robots, software frameworks, realtime systems, control architectures, mobile robots.

I. I NTRODUCTION The development of mobile robots for service applications must cope with new requirements along with old but tighter ones. First and foremost, service robotics requires that dependable robot systems be deployed to operate in human-inhabited environments [11]. Second, service robots must fulfill their tasks with adequate performance and robustness in dynamic and unpredictable environments. Third, they should be easily programmed and configured for the specific task and operational environment. Fourth, they should be cost-effective and suitable for economy of scale in order to emerge as viable products. Dependability integrates many system properties relevant to robotics, such as reliability, availability, safety, security, survivability, and maintainability [3]. For mobile robots, the safety requirement is particularly relevant, since the robot actively engages the environment and hence bears full responsibility in case of hard contact with people or objects [12]. Current mobile robot service applications show the potential of mobile robotics and the effectiveness of existing approaches [12], [30]. However, considerable improvement in all areas is required to attain the full market potential of service robotics. As far as the safety aspect is concerned, in some cases safety is intrinsically guaranteed by the electromechanical characteristics (speed, mass, geometry) of the robot. An example in case is the highly successful Roomba (tm) robotized vacuum cleaner manufactured by ∗ Work on this paper has been supported by CNR and MURST, Italy (Project RoboCare “Sistema multiagente con componenti fisse e robotiche mobili”), under the program funded by L. 449/97.

iRobot. In other cases, increased safety must be built by proper design of control, sensing, and intelligence subsystems. In this paper, we focus on the control architecture of mobile robots. We pay special attention to real-time operation, since this is one of the levers available within the control architecture to improve system dependability. For a mobile robot, real-time operation implies better control about when a specific reaction to an external event will be taken, and whether or not the execution of a specific computational job is guaranteed in face of unforeseen overloads. Only a handful of mobile robot control architectures explicitly integrate some support for real-time operation. CIRCA was one of the earlier architectures pursuing this concept [17]. Other architectures with explicit real-time support are ORCCAD [4], CLARAty [18], XO/2 [5], and Ethnos [22]. Of course, other architectures might take advantage of a real-time engine even though the authors did not overtly discuss the issue in their documentation. Indeed, the usefulness of real time support in mobile robot control architectures is debated. According to a view sometime voiced in verbal discussions, manipulators do require strict real-time control, whereas mobile robots require at most soft real-time computations, and could as well go along without any real-time guarantee. It should be remarked that ensuring real-time operations is rather more difficult for mobile robots, owing to their large scale and dynamic operating environments, the larger number of sensors, and the AI techniques required for their control. For these very reasons, simple but brittle real-time techniques, such as cyclic executives [15], are not applicable to mobile robots. One of our goals in this paper is to assess, to some extent quantitatively [7], the impact of a real-time support on the observed navigation performance and safety properties of a mobile robot. To this purpose, we exert specific functionalities of logically similar but implementation-wise different control architectures running the same mobile robot. These architectures are built specializing software frameworks with or without integral support for real-time features. Along the paper, we describe features of YARA, a software framework for mobile robot architectures developed at the Robotics and Intelligent Machines Laboratory of the University of Parma. YARA is actually a misnomer: it stands for Yet Another Robot Architecture, whereas YARA

is rather a framework. Among the original motivations behind the development of YARA were the need to develop common control abstractions for different robots in the lab, and some dissatisfaction with alternative open architectures. The paper continues as follows. Section 2 reports the outcome of a navigation experiment to further motivate this work. Section 3 describes some relevant architectural features of YARA. Section 4 highlights the real-time features and their implications on performance. Section 5 addresses the communication issues, and Section 6 concludes the paper. II. A NAVIGATION E XPERIMENT We describe an experiment involving the execution of an edge following behavior by a mobile robot under different control architectures and computational loads. The mobile robot is a Nomad200, by Nomadics Technologies Inc., whose original computing platform has been replaced with a motherboard including a PentiumIII 1GHz processor and 256MB RAM. To ensure the required soft real-time capabilities, the system runs a flavor of GNU/Linux OS with Linux preemptible kernel version 2.6. Edge following is a basic behavior for a service mobile robot in an indoor environment. The behavior architecture implements an algorithm requiring the robot to navigate forward at a speed of 30 cm/s while keeping at 20 cm from the side wall and with a front clearance of at least 35 cm. A two-phase feedback control tracks the distance between the robot and the wall and the angle between robot orientation and wall surface. The feedback control loop, based on infrared sensors, runs with a period of 30 ms. The edge following behavior has been implemented in YARA, with its underlying real-time and communication features described later in the paper, and in SmartSoft, a CORBA-based framework partially developed in the context of the OROCOS project [27]. SmartSoft (also labeled OROCOS@FAW) is a mature and feature-rich framework, built on top of the TAO CORBA implementation [8], and has served as a major source of inspiration for YARA as well. SmartSoft tasking is based on the standard Linux scheduler. Therefore, it does not take advantage from the soft real-time capabilities of Linux 2.6, whereas YARA strives to fully exploit such capabilities. Since SmartSoft did not include support for the Nomad platform, we implemented a new low-level SmartSoft baseserver dealing with the Nomad hardware. Neither SmartSoft nor YARA rely on the robotd server originally provided by Nomadic Technologies. The limited internal concurrency of robotd proved in the past a bottleneck to reactivity, since its 100 ms synchronous operation increases the end-to-end latency, i.e. the maximum time it takes for a sensor reading to impact on actuator commands. Getting rid of robotd was also one of the original objectives of YARA. Figure 1 shows multiple navigation traces resulting from the execution of the edge following behavior by the Nomad200 with different underlying support architectures and computational load. The same control algorithm was

executed by the Nomad200 on both architecture. Observed differences in behavior, thus, are solely due to the different support architecture and computational load. The Nomad was started approximately in the same position and orientation in all runs, to the extent allowed by a manual positioning. Trajectories were recorded by means of a six degree of freedom Polhemus FASTRAK electromagnetic tracker [23], whose receiver was placed on the mobile robot during the edge following task. Recorded traces are affected by some measurement error (in the order of few centimeters in the most distant positions), since the task moves the robot somehow beyond the standard range of operation of the tracker. Nontheless, recorded trajectories closely reflect the differences in observed behaviors. The range of operation of the tracker restricted data recording to the fragment of environment shown in Figure 1, whose sizes are approximately 150 cm by 300 cm.

noRT_2 noRT_1 noRT_0 RT

Start Fig. 1. Edge following behavior with and without real-time support under variable computational load.

To evaluate dependability in critical situations, the presence of a few competing tasks on the system is simulated by means of an artificial computational load. In Figure 1 the trace labeled RT refers to the execution by YARA including additional computational load, whereas traces labeled noRT * refer to executions with SmartSoft and increasing additional computational load. Each load level is obtained by adding a dummy thread alternating busy waiting and sleeping phases. Behavior execution with YARA under additional computational loads generates very similar trajectories, within the variability induced by measurement noise and sensor readings (for readability, only

one trajectory with real-time support is shown in Figure 1). When real-time support is not in place, the behavior of the robot is significantly affected by the concurrent computational load. With no competing computations (Figure 1, line noRT 0) the robot trajectory is close the one executed with YARA. When the load of competing tasks increases, the robot shows increasingly incorrect behavior (Figure 1, traces noRT 1, noRT 2). In the noRT 1 case, the robot appears to err in the initial part of the trajectory (possibly due to delays in sensor data processing) before resuming correct operation. In the noRT 2 case (high computational load), the behavior of the robot is entirely wrong, as at some point it seems to wander off toward some random direction. There is no question that the execution trace labeled as noRT 2 in Figure 1 does not qualify as a dependable behavior. Therefore, we contend that real-time support in the control architecture affects overall robot dependability. The following sections highlight YARA features and provide additional experimental evidence. III. T HE YARA F RAMEWORK The majority of control systems for autonomous mobile robots are characterized by a three-layer architecture [10]. Moving up along the intelligence dimension, a Functional Layer, or Controller, with the basic computational threads for robot action and perception, is controlled by an Executive Layer, or Sequencer, that sends requests and receives the outcomes of the Functional Layer. The Executive Layer, in turn, operates according to a Planner Layer, or Deliberator, providing the time-consuming deliberative capabilities [10], [24], [31]. Whereas the responsibilities, capabilities, and names of each layer are still matter of discussion [32], [24], the Functional Layer has a uniform view in all architectures: a set of components, communicating with each other and with the upper layers, run concurrently tightly coupling sensors to actuators (Figure 2). Components encapsulate either an interface toward the robot hardware or basic built-in robot functionalities and are de-/activated by external inputs. Upper layers receive information about successful termination or failure together with computation results. YARA is a framework supporting the implementation of functional layers. Frameworks are a form of design reuse providing the skeleton of an application that can be customized by an application developer [13]. This form of reuse has been already successfully exploited in robotics [19], [9], [25], [27]. YARA is written in C++ in order to take advantage from the benefits of objectoriented software in the design of robotic architectures [32]. Using inheritance and generic programming, it is possible to build a library with immutable parts (frozen spots) and yet open to the users that can implement code tuned to the application. This code must be inserted in a few parts of the framework which are left intentionally incomplete by the framework designers (hot spots). YARA aims at improving dependability in robot architectures and simplifying implementation of new com-

Fig. 2.

A set of components running in the Functional Layer.

ponents. Therefore, the development of the framework has paid attention to real-time issues, such as support of time constraints, dynamic scheduling, and deadline miss detection. Moreover, infrastructure for the implementation of components and efficient communication among them is provided. A. Framework Design 1 2 3 4 5

, class ConcreteModule : public Module { private : void act1Body ( i n t param ) ; void act2Body ( ) ;

6

public : A c t i v i t y a c t 1 ; A c t i v i t y a c t 2 ;

7 8 9 10

ConcreteModule ( ) : Module ( ‘ ‘ MyName ’ ’ ) , a c t 1 (∗ t h i s , & ConcreteModule : : act1Body , 0 . 1 ) ; a c t 2 (∗ t h i s , & ConcreteModule : : act2Body , 0 . 0 2 ) {}

11 12 13 14 15

};

To support the implementation of components, the framework provides the abstract class Module, which is its basic hot-spot and core element. The development of a concrete component starts with the inheritance from the Module class (Listing 1 above, line 1). A set of function methods, inherited from the Module class, is available in the framework. The developer can focus his/her attention on component functionality, avoiding to get entangled with details about management of module execution and data communication. The implementation of the concrete module must be integrated with the definition of a set of data members, storing the state of the component, and a set of methods for their management. Everything is defined as private members of the class (lines 3-5) and cannot be directly invoked by other modules. This requirement, which could seem unusual at first, stems from the fact that the module is not a passive object exporting functionalities; i.e., it is not

executed in the control thread of the invoking object which stops synchronously waiting the end of the execution of the invoked method. Components, instead, export “activities” with their own execution threads, working asynchronously with respect to the other architectural components and layers. This concept is implemented in the framework by the Activity template class, which provides methods to support the correct use of the activities exported by the module. The main purpose of the Activity class is to hide from developers the complexity inherent in the execution of concurrent activities with time constraints. Each activity exported by the component must be declared as an object of the Activity class (lines 8-9) and constructed specifying a pointer to the actual private member method that it must execute when invoked (lines 1213). The constructor can also specify deadline and period for activity execution. The Activity template class already implements a set of methods that can be invoked to control the execution of periodic activities, such as startPeriodicRun() and stopPeriodicRun(). Some of the ideas behind the design of the Module and Activity classes come from research in software engineering for concurrent and distributed architectures. Main contributions are the Active Object pattern [28] and the synchronization requirements in [16]. IV. F RAMEWORK S UPPORT FOR R EAL -T IME Control architectures are composed of both reactive components, with safety and predictability constraints, and time-consuming deliberative components, adapting robot behavior to the dynamic world. To improve the dependability of the system and to ensure a fast response to environment changes, reactive components must have a priority in the use of CPU computational power. A simple approach takes advantage of soft real-time schedulers available on most general-purpose operating systems, such as Linux and the POSIX standard, manually tuning the priority of each thread of control. Exploiting the POSIX real-time priority class results in a better coexistence of reactive and deliberative components in the same platform, with improved efficiency and scalability of the system. Moreover, the use of real-time priorities decreases the sources of jitter in the execution of periodic processes, such as those managing sensors, thereby reducing errors in control loops and the need for data oversampling. Despite the benefits provided by real-time priorities, this simple approach suffers from several drawbacks, mostly related to the complexity of hand coding real-time guarantees. To ensure system dependability, the control architecture of a mobile robot must satisfy a number of requirements, which cannot be easily guaranteed without the use of advanced scheduling techniques [15]. In YARA, dynamic scheduling of Activity objects is implemented by TODS (Timed Object for Distributed Systems), a POSIX-compliant framework providing an objectoriented interface for C++ programming of real-time systems [21]. TODS is based on a deadline-driven scheduling policy (Earliest Deadline First-EDF) [14] dynamically

Fig. 3.

The TODS real-time scheduling framework.

changing thread priorities of periodic and one-shot tasks belonging to a thread pool which is FIFO scheduled by Linux OS kernel (Figure 3). When a new critical task is submitted using methods of the Activity class, the system performs a schedulability analysis to check whether the whole set of tasks will still meet their timing constraints. If a task cannot be guaranteed, the system does not accept the incoming task and raises an exception. This exception allows an alternative action to be taken by the control architecture, possibly leading to a graceful degradation. As shown in Figure 3, TODS exploits a thread pool to avoid the overhead of dynamic thread creation. Integration of an EDF dynamic scheduler, while ensuring a more rigorous and safe approach to real-time guarantees, simplifies implementation of the application and relieves the developer from details concerning timing problems. The framework also provides procedures to detect overload situations, which result in deadline misses. Quoting Gat [10], “rather than attempt to design algorithms that never fail (which is impossible on real robots) one can instead design algorithms that never fail to detect a failure. This allows other components of the system (the sequencer and deliberator) to take corrective action to recover from the failure.” Finally, to guarantee correct EDF scheduling when resources are shared among tasks and to overcome priority inversion problem, synchronization mechanisms with integrated priority inheritance protocols [29] are provided. A. Experimental Evaluation A fundamental problem with robotic architectures is the lack of quantitative analysis on their performance [7]. The limited number of comparisons available in literature [20] is partially motivated by the complexity of control systems for autonomous mobile robots. As these systems do not share a common architecture, it is often difficult to extract common dimensions of variability for their evaluation. The ensuing analysis is focused on the lowest level of the architecture. The similarity exposed at this level by most architectures allowed the design of a few experiments

evaluating the impact of real-time support on overall system dependability. The robot, software architectures, and measurement instruments involved in these experiments are those described in section II. In all experiments, identical control algorithms are implemented by YARA and SmartSoft. Navigation Accuracy Experiment In this experiment, the robot was required to travel in 60 s a sinusoidal path with a horizontal length of 4 m, a period of 1.3 m, and a peak-to-peak vertical amplitude of 1 m (the dashed line in both diagrams of Figure 4). The robot controlling behavior exploited two parametric functions to compute linear and rotational velocities. These functions were re-evaluated every 50 ms and new set points were then sent to the actuators. The path was executed by the robot open loop, without evaluating its odometry. The Polhemus transmitter, for path recording, was located approximately in the origin of the diagrams in Figure 4. Since the nominal trajectory departed more than 2 m from the Polhemus transmitter, measurements are affected by a systematic error component. This systematic error increases with distance and clearly shows as distortion in the various traces of Figure 4. We have not corrected this distortion, but we have manually aligned the curves in the central part (less affected by error) to enable a comparison. The sinusodal path was executed multiple times under control of the YARA-based and OROCOS@FAW-based architectures considering increasing additional computational load, from no additional load (level 0) to high load (level 6). The purpose of the experiment was to simulate a critical situation requiring arbitration among multiple computations in favor of motion behaviors, while factoring out the effect of sensors. The diagram labeled RT in Figure 4 shows, in multiple traces, the trajectories actually executed by the robot under additional computational load with the YARA-based architecture. Even when the CPU was required to execute other competing processes (traces 3 and 6 refer to medium and high additional computational load conditions), navigation accuracy was not affected. The period of the executed spline was correct and the robot followed with good accuracy the prescribed sinusoidal path regardless of the additional load. Discrepancy in the initial and final parts of the trajectories displayed in Figure 4 (top) are essentially due to Polhemus error and manual alignment of recorded traces. In contrast, without real-time support actual robot trajectories are affected in a critical way by the additional computational load (diagram noRT in Figure 4), since timely dispatch of the spline evaluation task is not guaranteed. Up to load level 4, trajectories deviate somewhat but remain close to the nominal path, and the control error is hidden by the measurement one. With load level 5, the resulting trajectory is completely different from the prescribed path, even though it preserves a sinusoidal-like shape. With load level 6, the mobile robot is totally out of control. Trajectories with load levels 5 and 6 would be

Fig. 4. Execution of a sinusoidal trajectory with a mobile robot under increasing computational load. Top diagram: YARA. Bottom diagram: OROCOS@FAW.

clearly unacceptable in any service robot application. A major problem exposed by this experiment is also that the execution failures went undetected because of the openloop task. The non–real-time control architecture had no internal monitoring mechanism to detect such failures. Reactivity Experiment This experiment focused on the end-to-end latency of the architecture, i.e. the time required to issue a command to the hardware actuators once that sensors have detected an anomalous situation. Reduced architecture latency determines improved robot reactivity, and hence enhances safety. In a sort of crash test, the robot was programmed to move toward a wall at a speed of 25 cm/s. When at least one of the three frontal sonars detected a distance equal to or below 35 cm, the control behavior issued an emergency stop setting the speed to zero. Table I shows the stopping distance (the distance between the robot and the wall) obtained by YARA and OROCOS@FAW with or without additional computational load. A high additional load, at the level 6 of the previous experiment, was applied. Each line in the table refers to an average of 12 trials. Average, standard deviation, minimum, and maximum values are provided. Without additional load, the two control architectures behave similarly, stopping the robot on the average at 27 cm from the wall (8 cm breaking space at 25 cm/s) and at 20 cm in the worst case (15 cm breaking space). With additional computational load, the YARA-based architecture is affected only to a limited extent, since the

TABLE I S TOPPING Framework YARA YARA OROCOS@FAW OROCOS@FAW OROCOS@FAW (+robotd)

DISTANCE ( IN

Load N Y N Y N

avg 27.0 25.1 26.9 12.0 23.8

cm) std dev 3.39 2.84 2.13 8.36 3.24

min 20.3 20 24.4 0 18.3

max 30.2 29 30.4 21.8 28.5

average distance from the wall becomes 25 cm, and the worst case distance is unchanged. Lacking full real-time support, OROCOS@FAW cannot deal properly with the relative priority of computations, and in case of additional computational load the average distance to the wall decreases to 12 cm. Moreover, standard deviation is high and minimum stopping distance is 0 cm, since two hits against the wall (hopefully, not at full speed) have been observed. The last line in Table I refers to the OROCOS@FAW architecture with the lowest level of its baseserver based on the robotd server provided by Nomadic. Adding an external synchronous loop is a standard way of providing an abstract interface to the higher-levels of the architecture, including to the motion control behaviors. This approach is often adopted, for example, in vendor-supplied control software such as Saphira [20], because it simplifies user development and represents a valuable tool for teaching purposes. However, the synchronous loop should be carefully questioned in most service robot applications, since it introduces additional latency, as shown by robotd in Table I, where an average loss of safety margin of more than 3 cm is reported, along with a loss in the worst case of 6 cm. V. F RAMEWORK S UPPORT FOR C OMMUNICATION Communication support is an essential service in any modular control architecture. The communication subsystem in YARA has been strongly influenced by the patterns for communication in autonomous systems proposed in OROCOS@FAW/SmartSoft [26]. We devised four patterns to support communication in YARA: Information, Query, Command, and Event. The first three patterns have been implemented, whereas the fourth is still under development. When a module produces data required by several other modules, such as sensor readings, the Information pattern provides a broadcast-like mechanism. When a new data is available, it is distributed to a list of modules that previously registered as interested in this specific data. Client modules can attach Activity tasks to the delivery of new data. When a module needs one-shot information from another module, it can explicitly request the data using a Query pattern. The behavior of the Query pattern is quite similar to a remote procedure call: a remote Activity is awaken when a query is received to reply with the enquired information. The Command pattern supports the delivery of commands, such as motion commands, towards a module that

performs the required Activity. It is quite easy, however, to depict a scenario with multiple modules requiring concurrent conflicting actions that need to be mediated. The framework implementation thus provides an arbitration mechanism that currently supports two policies. The first policy is priority-based and selects only one action for execution based on its importance for the whole system. The second policy, instead, combines commands according to a user-defined merging policy depending on command types. While the first policy allows a command to subsume others in a Subsumption architecture fashion [6], the second one is geared toward the implementation of potential field approaches for merging commands [2]. The concept of arbitration mechanism was not included in the patterns presented in [26]. The adoption of standard mechanisms for arbitration hides to the user unnecessary implementation details. We are currently designing an additional communication pattern, Event, aimed at publishing state-like information in the architecture. Although the Event and Information patterns serve similar needs, the Event pattern is better suited for sporadic communication acts involving multiple information producers and consumers. A. Experimental Results Communication in autonomous systems can involve modules which either execute on a single computational platform or are distributed on a set of robots and/or computational nodes. Distributed communication is known to be more time-demanding than shared memory communication. The latter, however, is only suitable for modules sharing the same address space. Hence, the communication subsystem should be aware of module location to exploit the most efficient communication technique. In YARA a single interface manages both communication infrastructures, thereby masking their differences. The user is completely unaware of module locations when he specifies a communication. When modules execute inside the same address space, the communication is translated into an information exchange using shared memory and appropriate synchronization mechanisms. For modules located on remote machines, a communication layer based on a distributed object middleware (CORBA) is instead exploited. A few architectures [1], including OROCOS@FAW [27], follow a different approach and base their whole communication system on a CORBA implementation supporting collocation techniques, i.e. techniques that transparently minimize communication overhead when clients and server are configured into the same address space. Table II reports the time required (in µs) for the communication of an integer value between two modules running on the same computational platform using YARA and OROCOS@FAW–based applications. Table entries refer to 200 measured time values per line. In YARA (first line), communication between modules is both efficient and predictable. In OROCOS@FAW, a significant overhead arises when information is exchanged between two components (second line). Only when communication occurs

TABLE II C OMMUNICATION

TIME BETWEEN MODULES , TIME IN

Framework YARA OROCOS@FAW (between components) OROCOS@FAW (same component)

Average 175 786 175

µs

Std dev 5 30 33

inside the same component (third line) OROCOS@FAW is as efficient as YARA. The latter type of communication, however, is quite unusual, because in OROCOS@FAW different architectural entities are usually implemented as distinct components. The third line in Table II shows that collocation support is indeed provided in TAO, but the common way of application development with OROCOS@FAW, i.e. running components in separate address spaces, is not able to fully exploit it. Moreover, the use of the Synchronous Message Interface (SMI) for message passing communication is an additional source of inefficiency. Whether to implement a single interface in two different ways, as in YARA, or to use a middleware aware of module location, as in OROCOS@FAW [27] and ORCA [1], is up to the designer of the system. While the use of an external middleware requires deeper knowledge of the exploited software to avoid subtle errors, the development of the framework from the bottom up requires more effort for system implementation and tuning. VI. C ONCLUSION A common misconception in robotics is that guaranteed real-time operation is required for robot manipulators, whereas for mobile robots real-time operation is optional. We have shown that the increased navigation accuracy, reactivity, and robustness achieved by means of a realtime support are clearly observable in a mobile robot task execution and can be quantified. The extent to which this increased navigational performance translates into improved safety depends upon the speed of operation, intended application, and degree of close interaction with humans required. An open question is the impact of a hard real-time operating system support (e.g., QNX) on task-level mobile robot performance. A difficulty hindering such an investigation is the lack of suitable device drivers for the sensors and actuators of our mobile robots. R EFERENCES [1] ORCA Web Site. http://orca-robotics.sourceforge.net/. [2] R. C. Arkin. Behavior Based Robotics. MIT Press, Cambridge, MA, 1998. [3] A. Aviˇzienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1):11–33, 2004. [4] J.J. Borrelly, E. Coste-Maniere, B. Espiau, K. Kapellos, R. PissardGibollet, D. Simon, and N. Turro. The ORCCAD architecture. International Journal of Robotics Research, 17(4):338–359, 1998. [5] R. Brega, N. Tomatis, and K. O. Arras. The need for autonomy and real-time in mobile robotics: a case study of XO/2 and Pygmalion. In IEEE/RSJ Intern. Conf. on Intelligent Robots and Systems (IROS 2000), pages 1422 – 1427, Takamatsu, Japan, 2000.

[6] R. A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation, 2(1):14–23, 1986. ` Coste-Mani`ere and R. Simmons. Architecture, the backbone of [7] E. robotic systems. In IEEE Intern. Conf. on Robotics and Automation (ICRA 2000), pages 67–72, San Francisco, CA, 2000. [8] Distributed Object Computing (DOC) Group. Real-time CORBA with TAO (The ACE ORB). http://www.ece.uci.edu/ ˜schmidt/TAO.html. [9] A.C. Dominguez-Brito, D. Hernandez-Sosa, J. Isern-Gonzalez, and J. Cabrera-Gamez. Integrating robotics software. In IEEE International Conference on Robotics and Automation (ICRA 2004), pages 3423 – 3428, New Orleans, LA, 2004. [10] E. Gat. On three-layer architecture. In D. Kortenkamp, R. P. Bonnasso, and R. Murphy, editors, Artificial Intelligence and Mobile Robots, pages 195–210. AAAI Press, Boston, MA, 1998. [11] G. Giralt and F. Ingrand. Dependability in human-centered robotics. IEEE Robotics & Automation Magazine, 11(2):4, 2004. [12] B. Graf, M. Hans, and Schraft R. D. Mobile robot assistants. IEEE Robotics & Automation Magazine, 11(2):67–77, 2004. [13] R. E. Johnson. Frameworks = (Components + Patterns). Communications of the ACM, 40(10):39–42, 1997. [14] C. L. Liu and J. W. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment. Journal of the ACM, 20(1):46–61, 1973. [15] J. W. S. Liu. Real-Time Systems. Prentice-Hall, 2000. [16] B. Meyer. Object-oriented software construction. Prentice–Hall, 1997. [17] D. J. Musliner, E. H. Durfee, and K. G. Shin. CIRCA: a cooperative intelligent real-time control architecture. IEEE Transaction on Systems, Man, and Cybernetics, 23(6):1561–1574, 1993. [18] I. A. Nesnas, A. Wright, M. Bajracharya, R. Simmons, and T. Estlin. CLARAty and challenges of developing interoperable robotic software. In IEEE/RSJ Intern. Conf. on Intelligent Robots and Systems (IROS 2003), pages 2428 – 2435, Las Vegas, Nevada, 2003. [19] I. A. D. Nesnas. Toward developing reusable software components for robotic applications. Technical report, Jet Propulsion Laboratory (JPL), 2001. [20] A. Oreb¨ack and H. I. Christensen. Evaluation of architectures for mobile robotics. Autonomous Robots, 14(1):33–49, 2003. [21] D. Pallastrelli. Studio e realizzazione di un framework orientato agli oggetti per applicazioni real-time. Computer Engineering master’s thesis, Universit`a degli Studi di Parma, 2002. [22] M. Piaggio, A. Sgorbissa, and R. Zaccaria. A programming environment for real time control of distributed multiple robotic systems. Advanced Robotics, 14(1), 2000. [23] Polhemus. FASTRAK web page. http://www.polhemus.com/ fastrak.htm. [24] F. Py and F. Ingrand. Real-time execution control for autonomous systems. In 2nd European Congress Embedded Real Time Software (ERTS 2004), 2004. [25] D. M. Rivero, R. Barber, F. Rodriguez, and M. A. Salichs. A framework for complex skill generation. In 5th IFAC/EURON Symposium on Intelligent Autonomous Vehicles, Lisboa, Portugal, 2004. [26] C. Schlegel. Communications patterns for OROCOS. Hints, remarks, specifications. Technical report, Research Institute for Applied Knowledge Processing (FAW), 2002. [27] C. Schlegel and R. W¨orz. The software framework SmartSoft for implementing sensorimotor systems. In IEEE/RSJ Intern. Conf. on Intelligent Robots and Systems (IROS ’99), pages 1610–1616, Kyongju, Korea, 1999. [28] D.C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann. PatternOriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects. J. Wiley and Sons, 2000. [29] L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority inheritance protocols: an approach to real-time synchronization. IEEE Transactions on Computers, 39(9):1175–1185, 1990. [30] R. Siegwart, K. O. Arras, S. Bouabdallah, and et al. Robox at expo.02: A large-scale installation of personal robots. Robotics and Autonomous Systems, 42(3–4):203–222, 2003. [31] R. Simmons and D. Apfelbaum. A task description language for robot control. In IEEE/RSJ Intern. Conf. on Intelligent Robots and Systems (IROS 1998), Vancouver, Canada, 1998. [32] R. Volpe, I. Nesnas, T. Estlin, D. Mutz, R. Petras, and H. Das. The CLARAty architecture for robotic autonomy. In IEEE Aerospace Conference 2001, Big Sky, MT, 2001.