2011 20th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises
Towards the Automatic Generation of Self-Adaptive Robotics Software: an Experience Report Juan F. Inglés-Romero
Cristina Vicente-Chicote
Brice Morin
Olivier Barais
Tech. University of Cartagena ETSIT, Edificio Antigones 30202 Cartagena, Spain
Tech. University of Cartagena ETSIT, Edificio Antigones 30202 Cartagena, Spain
SINTEF ICT Forskningveien 1 NO-0314 Oslo, Norway
INRIA and IRISA Campus de Beaulieu 35042 Rennes, France
[email protected]
[email protected]
[email protected]
[email protected]
Engineering (MDE) methodology supported by an integrated framework for managing dynamic variability. In robotics, most approaches address runtime adaptation in ad-hoc manners [5], as general-purpose frameworks have not been designed to deal with robotics peculiarities. In this sense, there is a need for mechanisms to support adaptive software development in robotics [1]. In a previous work [6], we described our experience in using the design-time modeling capabilities of DiVA to define the self-adaptive behavior of autonomous robots. That work revolved around a case study based on two mobile robots playing, in turn, the roles of Victim and Rescuer. The case study illustrated different situations requiring the robots to adapt their behaviors at runtime (e.g., depending on the external lighting conditions, their internal battery level, or even the situation of each robot as perceived by the other). This experience allowed us to demonstrate the feasibility and the benefits of applying DiVA to the design of adaptive robotics software and also to identify some of its limitations. Building on our previous experience, the main goal of this research is to obtain the rules needed to automatically translate the design-time DiVA models into running selfadaptive implementations for resource-constrained robots. Taking the DiVA models developed in our previous work as our starting point, we have manually obtained a componentbased architecture that follows the design principles underlying most existing frameworks for adaptive software development, i.e., separation of concerns and reuse. To address this implementation we have selected Cecilia: the reference C implementation of the Fractal component model (http://fractal.ow2.org/), which provides developers with runtime reconfiguration capabilities, among other interesting features. This experience allows us to outline the transformation rules that need to be implemented in order to automate the code generation process. As further detailed in Section 5, in the short term, we plan to automate this process by means of a Model-to-Text (M2T) transformation that automatically translates the design-time DiVA models into the corresponding Fractal implementations. The rest of the paper is organized as follows: Section 2 surveys related work; Section 3 describes our experience in translating the DiVA models developed in [6] into a running self-adaptive implementation based on Cecilia; Section 4 reports the lessons learned and the open challenges; and, Section 5 concludes and presents some future research lines.
Abstract— This paper reports the progress on a previous work in which we described our experience in using the high-level models provided by the DiVA Framework to design the selfadaptive behavior of autonomous robots. The main objective of this work is to discuss how these models can be translated into a run-time self-adaptive architecture for resourceconstrained robots. In order to achieve this goal, the models developed for the case study presented as part of the previous work (based on a Victim-Rescuer scenario) serve as the starting point to manually obtain a self-adaptive componentbased architecture, which we have implemented using Cecilia (a C distribution of the Fractal component model) and deployed on two e-pucks (low-cost mobile robotics platform). Through this implementation, we try to identify the generic rules that will allow us to obtain (by means of an automated Model-to-Text transformation) self-adaptive robotics software from the DiVA design-time models. The lessons learned from this experience are reported at the end of the paper, leaving the way open for further improvements on self-adaptive robotics. Model-Driven Engineering; Component-Based Software Architecture; Autonomous Robotics; Runtime Self-Adaptation; DiVA; Fractal; e-puck
I.
INTRODUCTION
With increased flexibility and ease of use, robots are at the dawn of a new era, turning them into ubiquitous helpers to improve our quality of life by delivering efficient services in our homes, offices, and public places. In order to achieve the required flexibility, the management of uncertainties will be a key component of success [1]. Enabling robots to manage the different sources of uncertainty they must deal with (e.g., changes in the environment, altered requirements, software and hardware failures, etc.) requires providing them with self-awareness and self-adaptation capabilities [2]. This implies enabling robots to build and dynamically adapt models of themselves and their environments. Recently, adaptive software research has focused on creating and using frameworks for building general-purpose adaptive systems [3, 4]. These frameworks aim to simplify adaptive software development and maintenance while promoting its reuse. In this vein, the DiVA Project proposes a Model-Driven (http://www.ict-diva.eu/)
1524-4547/11 $26.00 © 2011 IEEE DOI 10.1109/WETICE.2011.54
79
II.
III.
RELATED WORK
Since the late 90s, great research efforts have been made in self-adaptive and autonomic computing [7]. As a result, some interesting high-level reference models and frameworks have been developed [8, 9]. In addition, these efforts have also resulted in modern execution platforms, such as Fractal [10], OSGi (http://www.osgi.org) or SCA (http://www.eclipse.org/stp/sca/), which provide APIs for software introspection and reconfiguration. These platforms currently exhibit some limitations as, for instance, they do not allow to preview the effects of a reconfiguration until it is actually executed, or to simulate what-if scenarios in order to evaluate different possible configurations a priori. Moreover, in the case of complex adaptive systems, a large number of low level reconfiguration scripts (calls to the reconfiguration API) need to be manually coded, making the process cumbersome and error prone. Putting the focus on the robotics domain, some interesting results have been achieved by the bio-inspired and cognitive system communities on low-level robot behavior adaptations based, e.g., on genetic algorithm mutations [5]. However, in order to deal with the increasingly growing complexity of real-word robotic systems and working environments, higher-level adaptation mechanisms need to be developed. In this vein, it becomes necessary to shift the focus from low-level self-adaptive algorithms to higher-level self-adaptive software components and component-based architectures [9]. Furthermore, the envisaged adoption of MDE by the robotics community promises not only to help raising the level of abstraction at which robotics systems are designed, but also enable their self-adaptation using models at runtime (also referred to as models@runtime). Although there exist plenty of robotics-specific software architecture styles and frameworks, commonly supported by platform-specific (and hardly inter-operable) middleware [11], most of them currently lack of support for model-driven robotics software development and selfadaptation [12]. Among the few model-driven tool-chains for robotics software development, it is worth highlighting Smartsoft [13] and V3CMM [14], both enabling component-based platform-independent design modeling and platform-specific code generation by means of automated model-to-text transformations. However, to date, neither Smartsoft nor V3CMM support runtime model adaptation (V3CMM only supports structural and behavioral variability modeling at design-time). Conversely, the work presented in [8] addresses robotics software runtime adaptation at an architectural level although, having not adopted a MDE approach, it strongly depends on the Prismspecific MW (http://csse.usc.edu/softarch/Prism/) middleware platform. Finally, it is worth highlighting the very interesting initiative started by the BRICS project (http://www.best-ofrobotics.org/), funded by the 7th EU Framework Program, where both MDE and robotic system adaptation (to achieve robust autonomy) play a key role, although these two goals do not appear explicitly related in the proposal.
IMPLEMENTATING SELF-ADAPTIVE ROBOTICS SOFTWARE
This section describes our experience in manually translating the DiVA design-time models developed in [6] into Fractal-based implementations of self-adaptive robotics software, as a first step towards the definition of an automated M2T transformation. A. Case Study Description As a starting point, we consider the case study described in [6], in which system variability and software selfadaptation requirements were described using the DiVA design-time models. Briefly, this case study takes place in a room containing a number of obstacles, where two mobile robots (equipped with a variety of sensors and actuators) are initially placed at arbitrary positions. One of these robots plays the role of a Victim and the other the role of a Rescuer. The goal of the Victim is to help the Rescuer find it as soon as possible. To achieve this, it indicates its position using an acoustic or light signal. The Victim uses its Bluetooth connection to communicate both changes in its signaling policy and in its current state, which can be: i) OK, ii) Wounded, or iii) KO. The Victim is equipped with infrared (IR) proximity sensors to detect close objects, which it can avoid adopting two different strategies, namely: i) surrounding the obstacle, or ii) changing the movement direction (the former with a greater impact on energy consumption than the later). Additionally, the Victim can adopt different strategies to improve its visibility, namely: i) running randomly, ii) walking randomly, or iii) staying still (in descending order in terms of visibility and resource consumption). The goal of the Rescuer is to find the Victim in the shortest time possible with the available resources. It is equipped with three sensors for this purpose, each one having a different precision and power consumption: i) a camera, ii) a set of microphones (allowing it to identify the direction of the sound), and iii) a set of IR proximity sensors. It can receive Bluetooth communications from the Victim, allowing it to select the most appropriate sensor and strategy to find it. The Rescuer uses the same obstacle avoidance strategies as the Victim. Both robots are equipped with sensors to measure environmental light and noise, and their battery level. Robots are expected to dynamically adapt their behavior depending on their context (i.e., their role, battery level, light conditions, etc.) in order to achieve their goals using the most appropriate sensors and strategies. In order to implement this case study we have selected to use e-puck robots (http://www.e-puck.org) as our target platform both for the Victim and the Rescuer. As shown in Figure 1, e-pucks are compact mobile robots with a large range of sensors and actuators, which make them appropriate for testing the proposed self-adaptation approach. In spite of that, the computational capabilities of the e-pucks are quite limited as they rely on a dsPIC microcontroller, which can only be programmed using a tailored version of the GCC compiler based on ANSI C
80
(C89 standard version). A low-level library is publicly available to ease the use of the e-puck hardware (e.g., to read the 40x40 pixel images obtained with the camera, or to send messages using the Bluetooth connection). In this context, the selection of the programming language to be used for implementing the self-adaptive code for the two e-pucks involved in the case study was quite limited (see Section 5 for further discussion on this issue). Finally, we selected Cecilia v2.1 (the C reference implementation of Fractal) as it is compatible with the software already available for the e-pucks, and it provides the required runtime reconfiguration mechanisms needed for self-adaptation.
(a)
B. A Runtime Self-Adaptive Architecture Before entering into the details of the self-adaptive architecture implemented to address the case study, it is worth noting the following general considerations regarding robotics software adaptation: • Differently from other domains, adaptation in robotics needs to take into account three different sources of contextual information, that is, i) the environment, ii) the robot internal state and its available resources, and iii) the perception of (and, eventually, the communication and collaboration with) other systems, either robots or not. • Adaptation aims at improving the effectiveness of robot tasks under a changeable context. However, robots should be able to work even if their adaptation mechanisms were disabled. This suggests that the robot adaptation logic should be decoupled from the robot control logic. • Adaptation should have a positive impact on the efficiency of the robot as it presumably allows a more "intelligent" use of resources. Thus, if adaptation is possible in resource-limited robots such as e-pucks, then it should be possible in any other (more powerful) robot. Taking this into account, we propose the componentbased software architecture outlined in Figure 2 to address the self-adaptation requirements of the two robots involved in the case study. It is worth noting that, for the sake of readability, some interfaces have been removed. This is why some direct connections appear between components belonging to different composition levels.
(b)
(c) Figure 2. (a) Overall component-based software architecture for selfadaptive robotic systems. Detail of the internal architecture of the CONTROl component for (b) the Rescuer, and (c) the Victim. Mandatory required interfaces in (b) and (c) are depicted using thick lines, while optional required interfaces are depicted using regurlar lines .
As shown in Figure 2a, the proposed software architecture consists of two main components: Control and Adaptation. The Control component implements the core of the robot functionality. As detailed in Figure 2b-2c, its centralized internal architecture revolves around the Main Control component, which implements the main control loop of the system. Additionally, the Control component also contains: i) OptCO components, representing optional components in the robot architecture (e.g., the Camera or the Microphone components); and ii) BaseCO components, representing mandatory components (e.g., the Battery State or the Noise Sensor components). Both OptCO and BaseCO components offer high-level interfaces. Some of them are built on top of the low-level primitives provided by the hardware (e.g., the OptCO component corresponding to the Light Sensor provides a high-level service that computes the ambient light level from the images obtained with the camera). Note that these components can define parameters subject to reconfiguration (e.g., the Main Control component, included in the Rescuer takes the Search and the Obstacle Avoidance strategies as parameters).
Figure 1. E-puck sensors and actuators.
81
The Adaptation component considers the three key elements in adaptation: monitoring, decision-making and reconfiguration [15]. This component gathers all the selfadaptation logic being, as recommended, decoupled from the robot control logic. It is worth noting that this component is the only one for which a fully automatic implementation can be obtained from the DiVA design-time models, as further discussed in the following section. The Adaptation component contains, in turn, the following components: • The Monitoring component. At runtime, robot sensors provide information about the robot internal and external context. Sensor measurements are made available to the Monitoring component by means of the “sen” interface provided by the Control component (see Figure 2a). Changes in the robot context may trigger a system reconfiguration. It is worth noting that the high-level context variables, described in the DiVA context model (see Figure 3a), are not necessarily associated to a single robot sensor. The Monitoring component defines the relations among the context variables and the actual robot sensors. In addition, this component controls the system stability (e.g., implementing a hysteresis cycle or using the average of the last values obtained from the sensors). Without this stability control, the system would constantly oscillate, entering into a spiral of reconfigurations. • The Reasoner component. This component implements the core adaptation logic. Its purpose is to calculate the best possible architecture configuration given the current context (provided by the Monitoring component). In addition, this element plays the role of coordinator in the Adaptation component. This means that, when the Main Control component makes a call to the "adapt" interface, the Reasoner is responsible for (1) getting the best possible configuration based on the information provided by the Monitoring, and (2) invoking the “wea” service provided by the Weaver to make the reconfiguration effective. • The Weaver component. Given that the proposed architecture follows the Fractal component model, the Weaver can use the reconfiguration services provided by Fractal to perform the changes prescribed by the Reasoner. To achieve this, the following Fractal interfaces have been used: i) the Content Controller (CC) that makes it possible to access the contents of composite components, enabling the addition/removal of sub-components, ii) the Attribute Controller (AC) that makes accessible the attributes of primitive components, and iii) the Binding Controller (BC) that enables to bind/unbind the client interfaces to/from the server interfaces.
C. From DiVA Models to a Self-Adaptive Implementation In order to explore an automatic code generation, in this section we discuss the implementation (manually) obtained from the DiVA design-time models, previously described in [6] for the proposed case study. 1) The Monitoring Component This component registers the changes in the robot context according to the information provided by the sensors. Given that e-pucks do not support multithreading and given their very limited computational resources, we decided to adopt a sensor polling technique to synchronously sample each robot sensor. As illustrated in Figure 4, the control loop in the Main Control component makes periodic calls to the “run” service provided by the Reasoner “adapt” interface. Then, the Reasoner delegates the detection of context changes in the Monitoring component by invoking the “getContext” service provided by its “mon” interface. As a result, the Monitoring component starts polling the status of the sensors by invoking the “getMeasure” service provided by the "sen" interface in the Main Control component. Once the Monitoring component has gathered the information from all the sensors, it compares it with the previous situation and decides whether a reconfiguration is needed or not (returning true or false to the former getContext invocation from the Reasoner). The "sen" interface declares a getMeasure method that makes sensors available even out of the Control component, thus encouraging component decoupling. This method uses an ID to select the target sensor and produces a void* output (meaning any type). This interface is independent of the DiVA context model (see Figure 3a). For instance, although there is a Boolean "Ambient Light" variable in the context model (which is true when the ambient light is “high” and false otherwise), e-pucks do not have a sensor that can directly return such a subjective boolean measurement. In order to compute this context variable, we need to (i) invoke the low-level routine provided by the camera to obtain the ambient light level as an integer (average of the current image pixel values), and (ii) apply a threshold to that value in order to obtain the Boolean value for the context variable. This link between the context model and the Cecilia implementation has been done manually. However, if the information needed to describe these links could be defined as an additional DiVA model at design-time, it would be possible to generate the associated code fully automatically. As part of this work, two monitoring modes have been implemented. The first one simply specifies that the value of a context variable is considered “low” as soon as the value returned by the corresponding sensor is below a given threshold. To improve the stability of the monitoring process, the second mode specifies that the value of a context variable is considered “high” if there is no value below a given threshold during a given timeslot. In the future we plan to implement more complex monitoring modes that enable, for instance, to define the value of a
82
context variable in terms of a user-defined combination of values and thresholds for one or more sensors at a time. 2) The Reasoner Component The Reasoner component computes the variability model in order to adapt the software architecture to the current context via its “wea” interface. The proposed implementation of this component is a specialized version of the DiVA Reasoner [16], adapted to the requirements imposed by resource-limited robots. Figure 3 shows the DiVA design-time models formerly developed in [6] for the Rescuer role as defined in the case study (for space reason, the models corresponding to the Victim role have not been included). These models specify the context to which the robot needs to adapt, the system variability and constraints, the Quality of Service (QoS) properties, the impact of selecting each variant on the QoS properties, and the adaptation rules. The information gathered in these models has been translated into the following parts of the Cecilia implementation: • Data structures to store the information gathered in the DiVA variability and constraint model (see Figure 3d) and in the impact model (see Figure 3b), namely: (1) the variability dimensions, including their name, cardinality and (a vector of) their associated variants, and (2) the variants themselves, including their names, a vector of integers to store their impact on each QoS property, and two Boolean flags to indicate whether they have required or available conditions associated or not. These data structures are application-independent and, thus, their implementation is fixed in all cases. • An initialization method that initializes the former data structures. Given that the DiVA models are application-specific, the code implementing this method needs to be obtained (automatically when possible) from them. • A method for applying ECA-like rules. The use of ECA (Event-Condition-Action) rules allows us to link the variability features with the context variables. These rules are described in the "required" and "available" columns of the variability and constraint model. For instance, as shown in Figure 3d, the Camera variant will be only available when the context variable "Ambient Light" is activated and the value of the "Signal Notification" variable is equal to LIGHT. On the other hand, the Bluetooth variant requires that the Low Battery property in the context model is set to false. This method has been implemented as a series of if...else statements that evaluate the context and set the "required" and "available" Boolean flags in the data structure for each variant. This method allows the Reasoner to filter the variants during the optimization process later discussed. Note that this method is also application-dependent and, thus, it needs to be implemented (automatically when possible) from the DiVA models.
(a)
(b)
(c)
(d)
(e) Figure 3. DiVA models formerly developed in [6] for the Rescuer role. (a) context model, (b) impact model, (c) adaptation rules, (d) variability and constraints model, and (e) QoS properties.
Figure 4. Diagram representing the component interaction involved in the monitoring process.
83
•
•
component, as their name attribute can be accessed via the AC interface. Similarly, the Weaver identifies which OptCO components need to be connected or disconnected to/from the Main Control component using the BT interface. Note that the code of these pre-defined Fractal interfaces is automatically generated by the Cecilia tool-chain.
A method for applying the adaptation rules. Adaptation rules (see Figure 3c) implicitly describe priority, i.e., they capture how relevant each system property is depending on the current context. For example, the "Battery is low" rule specifies that when the battery is low, optimizing the power consumption is of a HIGH priority. Conversely, the "Battery is ok” rule specifies that power consumption is a secondary concern (LOW priority) when the battery is OK. Similarly to the method implementing the ECA-like rules, this method also takes the context model as an input and defines several if...else statements. The method returns a vector of integers where the priority of each property is expressed using a value between 0 and 5 (5 for the highest priority). This code is also application-dependent so it can be generate from the DiVA models.
IV.
LESSONS LEARNED
In [6], we described the limitations of DiVA for designing self-adaptive robotics software. In this section, we focus on the issues raised when implementing self-adaptive robotics software from the DiVA models. A. DiVA at Runtime: Limitations in Robotics In order to support the runtime adaptation of robotics software, we initially considered the solution provided by DiVA, based on a three-layer architecture [17]. This solution enables the direct use of the DiVA design-time models for their dynamic adaptation at runtime. However, the solution provided by DiVA is far too complex to be run on a resource-limited platform such as an e-puck robot. In this vein, we found the following limitations:
A goal-based optimization method. The method implemented in this case is based on the one described in [16]. It obtains the best variant configuration by weighting the impact of the variants on each QoS property, and the priority of each property for the current context. This method implements a generic optimization engine and thus it is fully application-independent. As a consequence, similarly to the data structures, its implementation is fixed in all cases.
3) The Weaver Component The Weaver component receives an architecture configuration from the Reasoner, that is, the set of variants selected for all the features described in the variability and constraints model (see Figure 3d). In the case study, each variant is associated to a single component or component parameter (e.g., see Main Control in Figure 2b). Thus, each time the Reasoner prescribes a reconfiguration, the Weaver just needs to replace the components and, when necessary, change the parameter values related to the modified variants. However, in order to ease the automatic generation of code from the DiVA models, a proper architecture specification needs also to be defined and related to the other DiVA models (in particular to the context model) at design-time. Concerning the current implementation, its worth highlighting that all the OptCO components are created at compile-time and dynamically connected to the Main Control component when needed. As a consequence, the corresponding required interfaces in the Main Control component need to be defined as optional. To improve the efficiency of the current implementation we are planning to support the dynamic creation (and binding) of instances of OptCO components. These components will be instantiated (or released) at runtime on demand. It is also worth noting that, in the current implementation, the weaving is executed through the CC interface provided by the Control component. The Weaver gets access to the primitive components inside the Control
•
In the DiVA platform-independent model-based layer, the components produce and consume models, as DiVA relies on model@runtime. In general, this requires very demanding processes to support model manipulation (e.g., by means of or ATL Kermeta (www.kermeta.org/) (www.eclipse.org/atl/) model transformations).
•
The Monitoring component, included in the Proxy Layer, uses WildCAT [18], a generic monitoring framework that requires a Java Virtual Machine (JVM). Similarly, the current runtime of DiVA is based on OSGi, also requiring a JVM infrastructure. Although some initiatives have tried to develop a minimalistic JVM for micro-controllers [19], Java technologies are (at least to date) rarely used in robotics.
•
DiVA uses an Aspect-Oriented Modeling (AOM) approach at runtime to weave and derive different architectural configurations using complex artifacts called SmartAdapters [17]. However, most robotics software architectures are rather simple, at least from a structural point of view. In fact, even whether these architectures are formed by many components that encapsulate very complex algorithms, they usually rely on a simple centralized scheme, where a main control component is linked to and manages most other components. Thus, the weaving process proposed in DiVA may introduce an excessive complexity for dynamically adapting robotics software architectures.
In spite of its limitations for robotics software adaptation at runtime, DiVA provides valuable modeling languages for specifying robotic system variability and dynamic adaptation at design-time. In fact, the runtime
84
implementation proposed in this work is based on the DiVA design-time models, which have demonstrated to be useful for describing how and when the robots should adapt.
TABLE I.
AUTOMATIC CODE GENERATION FROM DIVA MODELS
CAN BE COMPONENT AUTOMATICALLY GENERATED?
B. Technology Limitations In our experience, providing resource-constrained robots (e.g., e-pucks) with self-adaptation capabilities can involve important difficulties. It is worth noting the lack of roboticsspecific frameworks that natively support self-adaptive software development. Furthermore, when using a generalpurpose development framework supporting some kind of software adaptation, even compiling and executing a hello world application in an e-puck-like robot may become a complex task (e.g., due to different compiler versions, supported APIs, hardware limitations, etc.). This makes these frameworks difficult to use in robotics, and commonly requires a long time to learn how to achieve effective solutions with them. For example, as already described in Section IIII.A, the e-puck microcontroller only supports ANSI C (C89 standard version). However, unfortunately, the Cecilia API contains references to headers only supported by the C99 standard version. Thus, in order to use Cecilia for developing software for e-pucks, we had to find and manually modify these references digging into the Cecilia API code. In this vein, we had a similar experience when trying to use THINK (http://think.ow2.org/), an alternative C implementation of the Fractal component model. Despite our problems to start using a Fractal implementation, we found that this component model is a valuable tool that provides a useful reference for developing self-adaptive robotics software. Putting the focus on Cecilia, we appreciate its flexibility to develop applications that can be executed on very different platforms: from very simple microcontrollers to powerful computers. However, Cecilia has some shortcomings. Probably, the main one is that it does not support the complete Fractal specification. For instance, most of the methods declared in the Fractal CC interface are not implemented in Cecilia. Furthermore, the SuperController and NameController interfaces seem to be missing.
COMMENTS
MAIN CONTROL
Partially (skeleton only)
It can be generated from the architecture model.
OptCO
Partially (skeleton only)
It can be generated from the architecture model.
BaseCO
Partially (skeleton only)
It can be generated from the architecture model.
MONITORING
Yes
It can be generated from the context model, the architecture model, and the relationships existing between them. Fixed code. Includes the declaration of the data structures and the goal-based optimization engine.
REASONER
WEAVER
V.
Yes
Yes
Application-dependent code. Includes the following methods: data structure initialization, ECA-like rule evaluation, and adaptation rule evaluation. It can be generated from the architecture model and the relations existing between components and dimension variants.
CONCLUSIONS AND FUTURE WORK
This paper reports the progress on a previous work in which we described our experience in using the high-level models provided by the DiVA Framework to design the self-adaptive behavior of autonomous robots. In this paper, the models developed as part of our previous work have served us as the starting point to manually obtain a selfadaptive component-based software implementation using Cecilia, the reference C implementation of the Fractal component model. The resulting implementation has been tested on two epuck robots, each one playing a different role (Victim and Rescuer), and thus requiring different adaptation strategies. This experience has shown us both the benefits and limitations of the DiVA design-time models to obtain adaptive robotics software implementations. We have also learned the interesting capabilities of the Fractal component model and the limitations of the Cecilia implementation when used to develop adaptive software for resourceconstrained robots. Although implementing the idea of models@runtime in e-puck-like robots is quite unfeasible, we will try to exploit MDE and the experience we gained in this work regarding the translation of DiVA models into actual implementations to automate, in as much as possible, the generation of adaptive robotics software. In this vein, we plan to implement (one or more) M2T transformations that allow us to automatically generate code for (one or more) target
C. Model–to–Text Transformation Regarding the implementation of a M2T transformation that enables the automatic generation of self-adaptive robotics software implementations from the DiVA designtime models, we found that the link between the DiVA models (e.g., high-level variables in the context model and variants in the variability model) and the components (e.g., sensors) is missing. Besides, despite the simplicity of the case study, the need for an architecture model that enables designers to specify the relations between the variants defined in the variability and constraints model and the OptCO components becomes evident. Table 1 gathers relevant information for automatic code generation, namely relating each runtime component with the required DiVA design-time models.
85
robotics platforms from the DiVA models. In order to implement these transformations we will use one of the many M2T transformation languages currently available, such as JET (www.eclipse.org/emft/projects/jet/), Xpand (www.eclipse.org/modeling/m2t/xpand), or MOFScript (www.eclipse.org/gmt/mofscript/). We also plan to implement the same (or a similar) case study on different robotic platforms (e.g., on a Pioneer robot) to evaluate frameworks other than Cecilia also supporting runtime software adaptation (e.g., THINK and OSGi). Finally, we are also interested on studying behavior adaptation in cooperative robotics applications.
[7] [8]
[9]
[10]
[11]
ACKNOWLEDGMENTS This work has been partially funded by the EXPLORE project (Spanish MICINN, TIN2009-08572) and the DiVA project (EU FP7 STREP, contract 215412). Juan F. InglésRomero thanks Fundación Séneca-CARM for a research grant (Exp. 15561/FPI/10).
[12]
[13]
REFERENCES [1]
[2]
[3]
[4]
[5]
[6]
Robotic Visions to 2020 and Beyond - the Strategic Research Agenda for Robotics in Europe. Appendix: Technology Roadmaps. Retrieved July 30, 2009, from the European Robotics Technology Platform (EUROP) website: http://www.robotics-platform.eu/sra. Brugali, D., and Shakhimardanov, A. 2010. Component-Based Robotic Engineering (Part II). IEEE Robotics and Automation Magazine, 17, 1 (March 2010), 100-112. Mukhija, A., Glinz, M.: The CASA Approach to Automatic Applications. In: 5th IEEE Workshop on Applications and Services in Wireless Networks (ASWN 2005), pp. 173--189. IEEE Press, Paris (2005). Garlan, D., Cheng, S., Huang, A., Schmerl, B., Steenkiste, P.: Rainbow: Architecture-based self-adaptation with reusable infrastructure. Computer, 37(10):46-54, 2004. Floreano, D., and Keller, L. 2010. Evolution of Adaptive Behaviour in Robots by Means of Darwinian Selection. PLoS Biol, 8, 1 (January 2010). Inglés-Romero, J. F., Vicente-Chicote, C., Morin, B., Barais, O. 2010. Using Models@Runtime for Designing Adaptive Robotics Software: an Experience Report. In Proceedings of the 1st international workshop on Model Based Engineering for Robotics (Oslo, Norway, 5 October), 1-11.
[14]
[15]
[16]
[17]
[18] [19]
86
Kephart, J. O., Chess, D. M. 2003. The Vision of Autonomic Computing. IEEE Computer, 36, 1 (January 2003), 41-50. Kramer, J., and Magee, J. 2007. Self-managed systems: an architectural challenge. In Proceedings of the 2007 Workshop on the Future of Software Engineering (Minneapolis, USA, May 23-25), 259-268. Oreizy, P., et al. 1999. An architecture-based approach to selfadaptive software. IEEE Intelligent Systems, 14, 3 (May 1999), 5462. Bruneton, E., et al. 2006. The FRACTAL Component Model and its Support in Java. Software Practice and Experience, 36, 11-12 (September 2006), 1257-1284. Mohamed, N., Al-Jaroodi, J., and Jawhar, I. 2008. Middleware for robotics: A survey. In Proceedings of the 2008 IEEE Conference on Robotics, Automation, and Mechatronics (Chengdu, China, September 21-24), 736-742. Georgas, J., and Taylor, R. 2008. Policy-based self-adaptive architectures: a feasibility study in the robotics domain. In Proceedings of the 2008 international workshop on Software engineering for adaptive and self-managing systems (Leipzig, Germany, May 12-13), 105-112. Schlegel, C. Communication patterns as key towards component interoperability. In Software Engineering for Experimental Robotics, Springer-Verlag, Heidelberg, 183-210. 2007. Alonso, D., et al. 2010. V3CMM: a 3-View Component Meta-Model for Model-Driven Robotic Software Development. Journal of Software Engineering for Robotics, 1, 1 (January 2010), 3-17. Ramirez, A.J., Cheng, B.H.C.: Design Patterns for Developing Dynamically Adaptive Systems. SEAMS, May 3–4, 2010, Cape Town, South Africa. Fleurey, F., and Solberg, A. 2009. A Domain Specific Modeling Language Supporting Specification, Simulation and Execution of Dynamic Adaptive Systems. In Proceedings of the 12th International Conference on Model Driven Engineering Languages and Systems (Denver, Colorado, USA, October 4-9), 606-621. Morin, B. 2010. Leveraging Models from Design-time to Runtime to Support Dynamic Variability. Doctoral Thesis. N°d’ordre : 4152. Université de Rennes 1, Rennes, France. WildCAT Framework, 2010. Retrieved November 01, 2010, from the OW2 Consortium website: http://wildcat.ow2.org Brouwers, N., Corke, P., and Langendoen, K. 2008. Darjeeling, a Java Compatible Virtual Machine for Microcontrollers. In Proceedings of the ACM/IFIP/USENIX Middleware '08 Conference Companion (Companion '08). ACM, New York, NY, USA, 18-23.
