LNAI 7628 - A Reuse-Oriented Development Process for...

14
A Reuse-Oriented Development Process for Component-Based Robotic Systems Davide Brugali 1 , Luca Gherardi 1 , A. Biziak 1 , Andrea Luzzana 1 , and Alexey Zakharov 2 1 University of Bergamo, DIIMM, Italy {brugali,luca.gherardi,andrea.luzzana}@unibg.it 2 GPS GmbH, Stuttgart, Germany [email protected] Abstract. State of the art in robot software development mostly relies on class library reuse and only to a limited extent to component-based design. In the BRICS project we have defined a software development process that is based on the two most recent and promising approaches to software reuse, i.e. Software Product Line (SPL) and Model-Driven Engineering (MDE). The aim of this paper is to illustrate the whole software development process that we have defined for developing flexible and reusable component-based robotics libraries, to exemplify it with the case study of robust navigation functionality, and to present the software tools that we have developed for supporting the proposed process. 1 Introduction The routine use of existing solutions in the development of new systems is a key attribute of every mature engineering discipline. Software reuse is a state of the practice development approach in various application domains, such as telecom- munications, factory automation, automotive, and avionics. Software Engineer- ing has produced several techniques and approaches for promoting the reuse of software in the development of complex software systems. A survey can be found in [3] (Sidebar A Historical Overview of Software Reuse). In Robotics, software reuse is typically conceived as cut and paste of code lines from program to program: this practice is called opportunistic software reuse and might work only for the development of simple systems (e.g. for educational purposes) or for unique systems (e.g. a research prototype). In contrast, the development of industrial-strength robotic systems that aim to become commodity, require a systematic approach to software reuse. Systematic software reuse is the routine use of existing software or software knowledge to construct new software, so that similarities in requirements, architectures and design between applications can be exploited to achieve substantial benefits in productivity, quality and business performance. If a company that commercializes integrated robotic systems wants to achieve customer value through large commercial diversity with a minimum of technical diversity at minimal cost, the best approach to software development is the Software Product Line (SPL)[5]. I. Noda et al. (Eds.): SIMPAR 2012, LNAI 7628, pp. 361–374, 2012. c Springer-Verlag Berlin Heidelberg 2012

Transcript of LNAI 7628 - A Reuse-Oriented Development Process for...

Page 1: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process

for Component-Based Robotic Systems

Davide Brugali1, Luca Gherardi1, A. Biziak1,Andrea Luzzana1, and Alexey Zakharov2

1 University of Bergamo, DIIMM, Italy{brugali,luca.gherardi,andrea.luzzana}@unibg.it

2 GPS GmbH, Stuttgart, [email protected]

Abstract. State of the art in robot software development mostly relieson class library reuse and only to a limited extent to component-baseddesign. In the BRICS project we have defined a software developmentprocess that is based on the two most recent and promising approachesto software reuse, i.e. Software Product Line (SPL) and Model-DrivenEngineering (MDE). The aim of this paper is to illustrate the wholesoftware development process that we have defined for developing flexibleand reusable component-based robotics libraries, to exemplify it with thecase study of robust navigation functionality, and to present the softwaretools that we have developed for supporting the proposed process.

1 Introduction

The routine use of existing solutions in the development of new systems is a keyattribute of every mature engineering discipline. Software reuse is a state of thepractice development approach in various application domains, such as telecom-munications, factory automation, automotive, and avionics. Software Engineer-ing has produced several techniques and approaches for promoting the reuse ofsoftware in the development of complex software systems. A survey can be foundin [3] (Sidebar A Historical Overview of Software Reuse).

In Robotics, software reuse is typically conceived as cut and paste of code linesfrom program to program: this practice is called opportunistic software reuseand might work only for the development of simple systems (e.g. for educationalpurposes) or for unique systems (e.g. a research prototype).

In contrast, the development of industrial-strength robotic systems that aim tobecome commodity, require a systematic approach to software reuse. Systematicsoftware reuse is the routine use of existing software or software knowledge toconstruct new software, so that similarities in requirements, architectures anddesign between applications can be exploited to achieve substantial benefits inproductivity, quality and business performance.

If a company that commercializes integrated robotic systems wants to achievecustomer value through large commercial diversity with a minimum of technicaldiversity at minimal cost, the best approach to software development is theSoftware Product Line (SPL)[5].

I. Noda et al. (Eds.): SIMPAR 2012, LNAI 7628, pp. 361–374, 2012.c© Springer-Verlag Berlin Heidelberg 2012

Page 2: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

362 D. Brugali et al.

An SPL is a set of applications (products) that share many (structural, behav-ioral, etc.) commonalities and together address a particular domain. The termdomain is used to denote or group a set of systems (e.g. mobile robots, humanoidrobots) or functional areas (motion planning, deliberative control), within sys-tems, that exhibit similar functionality. Each new application is built from theSPL repository of common software assets (e.g. architectural and design models,software components). In the BRICS project we have defined a software develop-ment process that exploits the SPL approach and accounts for two peculiaritiesof the robotics field:

– Today, a huge corpus of software applications, which implement the en-tire spectrum of robot functionality, algorithms, and control paradigms, isavailable in robotic research laboratories and potentially could be reusedin many different applications. Typically, their interoperability or their ex-tensions towards novel applications require high efforts. Any company thataims at developing professional software for complex robotic systems hasto make an initial investment in refactoring and harmonizing existing opensource robotics libraries that implement the robot functionalities offered bythe SPL. This phase is typically called software development for reuse.

– Typically, robotic systems integrators are not software engineers and donot master advanced software development techniques adequately. For thisreason, the proposed development process exploits the Model-Driven Engi-neering (MDE) [15] approach. According to the MDE approach, robotic sys-tem integrators use domain-specific languages to build models that capturethe structure, behavior, and relevant properties of their software systems.A new application is developed by reusing these models, customizing themaccording to specific application requirements, and semiautomatically trans-form models and even generate source code using transformation engines andgenerators. This phase is typically called software development with reuse.

Figure 1 illustrates the phases of the reuse-orienteddevelopment process describedin this paper. The first two phases, namely software refactoring and product linedesign, are intended to produce software for reuse. The remaining two phases,namely Variability modeling and Variability resolution, support the developmentof software with reuse. In the upper part of Figure 1, the conceptual and softwaretools that support the process are linked to the various phases, namelyRefactoringPatterns [6], the BRICS Component Model (BCM )[9], the BRICS Integrated De-velopment Environment (BRIDE)[9], and the BRICS tool for variability modelingand resolution (FODA). In the lower part of the figure the input open source li-braries and the intermediate products of the development process are represented,namely the BRICS class libraries, the Product Line models, theVariability models(features models), and the Application models.

This paper aims to illustrate the whole software development process thatwe have defined for developing flexible and reusable component-based roboticslibraries, to exemplify it with the case study of the robust navigation, and topresent the software tools that we have developed for supporting the robotic engi-neers in modeling and resolving variability in component-based robotics systems.

Page 3: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process 363

BRICS Component

model

BRIDE Tool

Code Refactoring

DocumentDocumentOpen

Source Libraries

DocumentDocumentBRICS Class

Libraries

DocumentDocumentProduct Line Model

DocumentDocumentFeature Model

DocumentDocumentApplication Model

Product Line Design

Variability Modeling

Variability Resolution

FODA Tool

Refactoring Patterns

Fig. 1. The development process

The paper is structured as follows. Section 2 illustrates state of the art opensource libraries that provide robust navigation functionality. Sections 3 to 6present the four phases of the development process and exemplify them with therobust navigation case study. Finally Section 7 draws the relevant conclusions.

2 The Robust Navigation Case Study

Robust navigation is the ability of a mobile robot to perform autonomous navi-gating, while avoiding dangerous situations such as collisions with obstacles. Itis a cross-sectional domain, which includes path planning, motion control andsensor data processing.

From an algorithmic point of view, the challenging task is to organize an effi-cient interaction between these functionalities in order to maximize performance,safety, and robustness. Mobile robot navigation algorithms have been a researchtopic for several decades (see [16] for a taxonomy). Existing algorithms could beroughly classified as one- andmulti-step methods. One-step methods directly con-vert the sensor data to a motion commands. Majority of one-step algorithms areeither based on classical planning or on the potential fields approaches [16]. To-day, they are rarely used due to their inability to cope with dynamic environmentand vehicle constraints. Multi-step methods (e.g. DynamicWindow Approach [8],Vector Field Histogram [17], Nearness Diagram [12]) overcome these limitationsby creating a local map of the environment around the robot and performing localplanning by computing possible motion directions (Nearness Diagram) and veloc-ities (VHF) taking into account distance to the goal or to a precomputed path.

From a software development point of view, the challenge is to implementrobust navigation functionality as a set of reusable components that can beassembled into flexible systems1. For this purpose, the BRICS project applies anovel approach to software development, which avoids to develop from scratchrobot functionalities based on yet another software architecture. Instead, bycollecting and analyzing well known open source libraries providing robotics

1 The IEEE Standard Glossary of Software Engineering Terminology defines flexibilityas the ease with which a system or component can be modified for use in applicationsor environments other than those for which it was specifically designed.

Page 4: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

364 D. Brugali et al.

functionalities, we aim at identifying those architectural aspects (i.e. entities,data structures, interfaces, relationships) that are common to all or most ofthe implementations of the same family of functionalities, and those aspectsthat distinguish one implementation from another. These common architecturalaspects represent the stable characteristics of a family of functionalities and arelikely to remain stable through future implementations of the functionalities.

By analyzing existing robust navigation libraries (see table 1) we have real-ized that typically they refer to the same functionality using different names.In some cases, the functionality is not even mentioned but is implicit in theimplementation.

– Motion planning (aka BaseGlobalPlanner, PathPlanner): is the process ofcomputing a collision-free global path in a static environment between agiven start position and a given goal position. The path is typically repre-sented as a sequence of intermediate waypoints.

– Trajectory generation (aka ParameterizedTrajectoryGenerator, DWAPlan-ner): is the process of refining a path for introducing velocity information.A trajectory defines the planned positions of the robot over the time and istypically represented as a sequence of positions with an associated velocity.

– Obstacle detection and representation (aka CostMap2D, OgMap): is the pro-cess of using sensors information (e.g. laser scans) in order to detect thepositions of the obstacles around the robot. This information is then usedfor creating and updating a map of the environment.

– Obstacle avoidance (aka Local LocalBaseNavigation, LocalNav, CAbstrac-tHolonomicReactiveMethod): is the process of adapting the precomputedtrajectory while the robot is moving in order to avoid unexpected obstaclesthat occlude the path.

– Position and velocity control (aka LocalBaseNavigation, LocalNav, Motion-Controller): is the process of generating velocity commands to the robot inorder to move it along the computed trajectory. This functionality has astrong dependency with the kinematics model, which is often implicit in thelibrary implementations.

– Localization (aka FaithLocaliser, amcl): is the process of estimating the robotposition with respect to a global reference frame. In the simplest case thisfunctionality is implemented by using only the robot odometry but othersensors can be used to improve the odometric estimation.

3 Software Refactoring

Software refactoring is the process of changing a software system in such a waythat it does not alter the external behaviour of the code yet improves its internalstructure [7]. It occurs at two complementary levels: (a) Syntactical refactoringis a behavior preserving transformation that, through the adoption of good de-sign principles (abstraction, information hiding, polymorphism, etc.) aims atmaking software artifacts modular, reusable, open. (b) Semantic refactoring is adomain-driven transformation that, through a careful analysis of the application

Page 5: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process 365

Table 1. Open source libraries for robust navigation

Type Method Library Name

Global Planners

Carrot planner, Dijkstra’s alg. ROS

ARA*, Anytime D*, ANA* SBPL/ROS

Sampling-based Planning OOMPL, BRICS MM

Trajectory Generation reactivenav::CPTG1 - CPTG7 MRPT

Local planners

VFF MRPT

VFH+ Player/Stage, ORCA

Dynamic Window ROS, Sunflower

Trajectory Rollout ROS

Nearness Diagram MRPT

Elastic Band ROS

Mappinggmapping, costmap 2d ROS

ogNode, ogMap ORCA

Localizationamcl ROS

ICP SLAM, RBPF SLAM, ... MRPT

domain (commonality/variability and stability analysis), enhances software ar-tifacts flexibility, adaptability, and portability. Software refactoring brings manyadvantages not immediately but in a long time. The initial cost in terms oftime and effort spent for rewriting the code is balanced by the time gainedin future. This gain is due to a code more readable, more reusable and moremaintainable. The result of a refactoring process is a library of classes that aremiddleware-independent, are organized in a hierarchy of abstraction levels, pro-vide harmonized interfaces (API), and implement a variety of algorithms.

In a previous paper [2] we have described how architecture refactoring patternshave been applied to refactor motion planning software libraries. Refactoringpatterns provide guidelines to redistribute the responsibilities among the classesof a software library, to harmonize the common data structures and to reducethe coupling degree.

3.1 Case Study: The ROS Navigation Stack

This section presents the architecture of an open-source library, which providesa mobile-based navigation functionality. We selected ROS framework becauseof its popularity in robotic community. Figure 2 shows a portion of the classdiagram that represents the architecture of the ROS navigation stack.

Class BaseGlobalPlanner is an interface of the global planners used in naviga-tion stack. There are two implementations: CarrotPlanner and NavfnROS. Firstone is a simplistic planner, which connects a target pose and robot actual posewith a straight line and performs collision checks along this line. The second isa grid-based A* path-planner for circular robots.

Multiple functionalities are tightly coupled in the implementation of classBaseLocalPlanner, i.e. trajectory generation, adaptation and execution. It gen-erates a number of trajectories for admissible linear and angular velocities ofthe robot. Each trajectory is scored according to an objective function, whichincludes goal heading, path heading and obstacle clearance. The trajectory with

Page 6: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

366 D. Brugali et al.

MoveBaseTransformListener Costmap2D

BaseGlobalPlannerBaseLocalPlanner

CarrotPlanner NavfnROSDWAPlannerROSTrajectoryPlannerROS

TwistPose PointCloud/LaserScan MapOdometry

Fig. 2. Mobile base navigation component in ROS

maximum objective function is selected and its associated linear and angularvelocity (twist) are sent to the robot driver. Two concrete implementations ofthis class are available, namely TrajectoryPlannerROS and DWAPlannerROS.Both assume implicitly that the robot has a differential drive kinematics model.

Class CostMap2D is an implementation of 2D occupancy grid-map. It em-beds the data structures for representing a 2D tessellated representation of theenvironment. It is used for both path planning and obstacle avoidance.

The top-level class is the MoveBase class, which instantiates all the classesthat implement specific functionality and starts several threads for their con-current execution. Concurrent access to shared resources (e.g. the map of theenvironment) is synchronized by means of infrastructure mechanisms, such asa state machine, mutexes and numerous flags and conditions across the code.There is thus no guarantee that these functionalities are executed in real-time.

The MoveBase class is instantiated by a main function that starts a ROSnode. Thus, all the functionalities for robust navigation are provided by a singlecomponent (ROS node). This component interacts with other components inthe system (e.g. the robot base driver and the laser driver) by exchanging ROSmessages. The set of exchanged messages represent the component interface.Unfortunately, the component interface is not clearly separated by the compo-nent implementation since ROS messages are produced and consumed by severalclasses that implement the component. Thus, the only way to understand howcomponents interact with each others is to carefully look at the source code.

The ROS Navigation stack classes implementations are tightly coupled withthe ROS infrastructure, thus they cannot be reused in different environments.

4 Product Line Design

In [4] we have defined a set of architectural principles for the development of flex-ible component-based systems that foster the separation of four design concernsoriginally identified in [13], namely Computation, Coordination, Communication,and Configuration.

According to these architectural principles, the robot functionalities are pro-vided by Computation components that have harmonized interfaces and im-plement specific robotic algorithms. The clear separation between component

Page 7: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process 367

interface and implementation guarantees interoperability of components thatprovide similar functionalities but implement different algorithms.

The mutual interactions of Computation components might change dynami-cally according to their current internal state. In order to improve their reusabil-ity, interaction policy should be implemented as finite state machines inspecialized Coordination components that observe state transitions in the sys-tems by listening to events notified by Computation components.

Typically, components rely on a middleware infrastructure to exchange dataand events through the network. In order to make components implementationsindependent from any specific middleware, components should be designed andimplemented according to an abstract component model (meta-model), whichdefines middleware-independent communication ports. For this purpose, simi-larly to the OMG initiative2, the BRICS project has defined a new componentmodel (BCM [9]), which provides the following architectural elements:

– Component: is a software package that encapsulates a set of related func-tionalities and has its own thread of control.

– Port: represents the component interface. It explicitly defines (in terms ofdata types and contract) how a component provides (output port) or requires(input port) a service or a data-flow.

– Property: allows the component configuration. A property provides an in-terface for setting the value of a parameter defined in the component imple-mentation (e.g. period, algorithm parameters, . . . ).

– Connector: defines the connection between an input port and an output portand its communication mechanism.

Computation components and Coordination components can be assembled tobuild applications. A family of similar applications that are built reusing a set ofsoftware components and share the same architecture is called a Software Prod-uct Line. The product line architecture specifies the structural (data structuresand application programming interfaces) and behavioral (data and control flow)commonalities among the products and the variations reflected in each prod-uct (variation points). It prescribes how software components (variants) can beassembled to derive individual products. For example, a variation point in therobust navigation product line is the algorithm for obstacle avoidance. Differ-ent algorithms (i.e. dynamic window approach [8] or vector field histogram [17])are implemented as distinct software components. The product line architectureguarantees that these components are interchangeable.

The possible configurations of a software product line are represented in aproduct line model, which specifies (a) a set of components that can be used forbuilding all the possible applications of the family (some of them are mandatory,some others are instead optional) and (b) a set of connections among components(some of them are stable, some others are variable). By selecting the optionalcomponents, their specific implementation, the values of their configuration pa-rameters, and the variable connections, the variability of the product line isresolved and a specific application model is defined.

2 http://www.omg.org/spec/RTC/1.0/

Page 8: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

368 D. Brugali et al.

Laser Scanner Driver

laserScannerId

Trajectory Follower

robotModel

RGB Camera DriverRobot Driver

robotModel

Coordinator

Trajectory Planner

Trajectory Adapter

laserScannerIdrobotModel

Marker Locator

cameraId

Pose Tracker

Odometry

Twist

Trajectory

Laser Scan

Pose RW

Image

Robot Pose & Twist

Trajectory

Marker Id

Event

Event

Goal

MarkerPose

Event

Event

Fig. 3. The model representing the BRICS Robust Navigation Product Line

4.1 The BRICS Robust Navigation SPL

Figure 3 represents a first draft of the BRICS Robust Navigation Product Line.Continuous lines depict the default connections between input and output portswhile dashed lines represent the optional connections that may be created to con-figure a specific application. Continuous boxes represent mandatory components,while dashed boxes represent optional components. Boxes inside components in-dicate their properties. More specifically:

– Trajectory Planner implements the motion planning and trajectory gen-eration functionalities. It gets a goal position and the current robot positionas input and produces a trajectory that is a vector of poses with twist.

– Trajectory Adapter interpolates the precomputed trajectory and pro-duces an obstacle-free trajectory toward the next waypoint taking into ac-count the sensor information produced by the laser scanner.

– Trajectory Follower receives the adapted trajectory and the robot esti-mated pose and produces as output a twist for following the input trajectory.

– Robot Driver drives the physical robot. It receives twist commands andproduces the robot odometry.

– Laser Scanner Driver reads the raw data from the device and producesas output the laser scans expressed as a vector of distances and angles.

– Pose Tracker keeps track of the current pose and twist of the robot. It fusesodometry estimates with position estimates computed by other components.

– Marker Locator is an optional component, which is in charge of localizingvisual markers placed in the environment and computing their positions withrespect to a global reference frame. It receives as input an image and theodometry of the robot and produces as output the absolute marker position.

– RGB Camera Driver is an optional component, which reads data fromthe RGB camera and produces as output an RGB image.

Page 9: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process 369

– Coordinator implements the coordination logic among components. It mon-itors events generated by components that could represent abnormal situa-tions (e.g. the Trajectory Adapter cannot generate a trajectory to avoid anobstacle) and generates events that triggers state changes in other compo-nents (e.g. the Trajectory Planner should plan a new trajectory).

There are some important differences between the proposed solution and theROS navigation stack discussed in Section 3. First of all the navigation func-tionalities are mapped to finer grained components. Each component has onlyone thread of control. This allows to replace individual functionalities easier andto select the most appropriate frequency for each functionality. Accordingly, thetrajectory follower and the trajectory adapter functionalities are implementedin two different components. This separation reflects the different operating fre-quencies of the two components: the Trajectory Follower runs at a higher fre-quency, as required by the closed loop position and velocity control algorithm.On the contrary the Trajectory Adapter component computes a new output onlywhen receives a new laser scan or a new trajectory.

Unlike in ROS, the coordination mechanisms have been made independentfrom the components implementations by introducing a Coordinator component.

5 Variability Modeling

Building software systems according to the product line approach is economicand efficient [5]. Most work is about integration, customization, and configu-ration instead of creation. A system configuration is an arrangement of compo-nents and associated options and settings that completely implements a softwareproduct. Variants may exclude each others (e.g., the selection of a componentimplementing an indoor navigation algorithm excludes the choice of componentsproviding GPS-based localization services) or one option may make the integra-tion of a second one a necessity (e.g., a component implementing a visual odome-try algorithm depends on a component that supplies images of the environment).Hence, only a subset of all combinations is the admissible configuration.

In order to model and symbolically represent the product line variation points,their variants and the constraints between them, a formalism called FeatureModels was introduced in 1990 in the context of the Feature Oriented DomainAnalysis (FODA) approach [11]. These models make explicit the variability thatis implicitly defined during the product line design.

A feature model is a hierarchical composition of features. A feature definesa software property and represents an increment in program functionality. Com-posing features, i.e. selecting a subset of all the features contained in a featuremodel, corresponds to select a specific product (application) that belongs to theproduct line described by the model. This selection is usually called instance.

Feature models are organized as a tree and the root feature, also called con-cept, defines the application family. Parent features are connected to childrenfeatures by means of edges, which represent containment relationships. Features

Page 10: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

370 D. Brugali et al.

can be discerned in two main categories: mandatory and optional. Mandatoryfeatures have to be present in all the application of the product line (common-alities). They are graphically depicted by means of a black circle on the top.Optional features instead can be present but they are not mandatory (variationpoints). They are depicted by means of a white circle on the top.

Three types of containment relationships define containment constraints be-tween the parent and the children features: one-to-one, or and alternative.The one-to-one containment means that the parent feature can (or has to) con-tain the child feature. The other two kinds of containments are containmentsbetween the parent feature and its children features. Here the parent featureis the variation point, while the subfeatures the variants. The or containmentmeans that from the children features at least one has to be present in theapplication. The alternative containment (X-Or) instead means that from thechildren features only one can be present in the application.

Feature models also define two kinds of constraints between the features:requires and excludes. These constraints allow the definition of a subset ofvalid configurations. The requires constraint means that if a feature A is selected,then also a feature B has to be selected. The excludes constraint instead meansthat if a feature A is selected, then a feature B cannot be selected.

[10] presents an Eclipse plugin that allows the design of feature models. Thisplugin provides a formal meta-model (Ecore based), which defines the rules forcreating feature models conform to the standard specification introduced above.

5.1 Variability in the BRICS Robust Navigation SPL

Figure 4 depicts the feature model describing the variability of the BRICS Ro-bust Navigation Product Line. Gray boxes represent the or and alternativecontainments relationship and show the cardinality (1. . . n represents or and1. . . 1 represents alternative). It contains four main variation points:

– Localization: this variation point regards the information used for localizingthe robot. Using the odometry is mandatory but a marker locator can beused in order to improve the pose estimation.

– Navigation: this variation point regards the navigation strategy. Two vari-ants are available: map-based and marker-based. In the first case a TrajectoryPlanner computes a collision-free path according to the goal received as in-put from its client. In the second case instead the goal is provided by theMarker Locator and represents the position of a specific marker.

– Obstacle Avoidance: this variation point regards the algorithm used foravoiding obstacles. Two variants are available: Dynamic Windows Approachand Vector Field Histogram.

– Sensors: this variation point regards the sensors used in the application.Using the laser scanner is mandatory for obstacle avoidance. However, inorder to recognize visual markers, the robot equipment can be extended byusing a front camera and a camera held on a specific support.

Page 11: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process 371

Fig. 4. The model representing the variability in the BRICS RN Product Line. It wasdesigned with our Feature Model plugin.

The feature model also defines the following three constraints that limit theallowable combinations of features. (a) The use of the marker-based navigationstrategies requires at least one of the two cameras. (b) The same requirementsare valid when we want to use the markers for localization. (c) The selection ofa marked based navigation excludes the use of the markers for the localization.

6 Variability Resolution

The last phase of development process regards the resolution of the variabilityin the Product Line model and has the goal of producing the model of a spe-cific application. Thanks to our tool this can be done by selecting the set ofvariants (features), which reflect the application requirements, directly on thefeature model. This selection should satisfy the explicit constraints, the contain-ments cardinalities and the selection of the mandatory features defined in thefeature model. The tool automatically checks the constraints satisfaction andonly successively generates the application model, which can be transformedin the deployment file of a specific middleware by means of the model-to-texttransformation provided by BRIDE.

In order to define how the Product Line model has to be modified for produc-ing the model of a specific application, we introduced the concept of transforma-tion. A transformation is an action that modifies the architectural elements of aProduct Line model in order to replace a variation point with a specific variant.Different kinds of transformations are available, according to the elements thathave to be modified (components implementations, connections, properties). Thedeveloper can associate to each feature one or more transformations. A selectionof a set of features will hence result in the execution of a set of transformations.

Figure 5 illustrates how the meta-model of the feature models described in [10]has been extended for representing the transformation associated to the features.Currently it has been done only for the generation of Orocos RTT application.For this reason the meta-model has three links to three elements defined inthe RTT-BCM meta-model: Task Context, Connection Policy, and Property [1].However the approach can be easily extended to other middlewares such ROSand SCA [14]. The following list describes the different kinds of transformations.

Page 12: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

372 D. Brugali et al.

Fig. 5. The extension of the feature model meta-model that specifies how transforma-tions are mapped to RTT elements (classes with the arrow on the top right corner)

– TransfImplementation : defines which implementation will be used for acertain component, i.e. which algorithm (Computation and Coordination).The developer specifies a link to the desired component (defined in the Prod-uct Line model) and the class that implements its interface (by means of thenamespace and the class name).

– TransfConnection : defines how the components will be connected (Com-position). The developer specifies a link to a connection that has to be re-moved from the Product Line model (if needed) and a set of connectionsthat have to be created (with specific lock policies and the buffer sizes). Asa result of these transformations unconnected components will be removedfrom the model.

– TransfProperty : defines the value of a certain property (Configuration).The developer specifies a link to the desired property (defined in the ProductLine model) and the value he wants to assign to it.

6.1 Variability Resolution in the BRICS Robust Navigation SPL

The product line presented in the previous sections allows the deployment ofdifferent applications that can be classified according to two navigation strate-gies: map-based and marker-based. The different strategies can be derived byresolving the Navigation variation point.

If a map-based navigation is chosen, then the Marker Locator, the RGB Cam-era Driver components and all the connections between these components andthe others are not necessary. So these components can be removed from themodel. In case of marker-based navigation instead, the Trajectory Planner com-ponent receives the goal from the Marker Locator. Hence the optional connec-tions of Marker Locator and RGB Camera Driver have to be created.

Page 13: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

A Reuse-Oriented Development Process 373

In addition to these connections, the Coordinator implementation and itsconnections have to be defined according to the navigation strategy. The Co-ordinator always recovers from situation in which the Trajectory Adapter isunable to adapt the trajectory. This can happen due to the presence of obstaclesall around the front part of the robot. In these cases, the Coordinator receivesan event from the Trajectory Adapter and returns an event to the TrajectoryPlanner asking it to recompute a path. When a marker-based strategy is choseninstead, the Coordinator resolves also situations in which no markers can be de-tected. In these cases the Coordinator receives an event from the Marker Locatoran returns an event to the Trajectory Planner asking it to create a trajectory formoving the robot in such a way to seek new markers. This configuration needsa connection between the Event interfaces of Marker Locator and Coordinator.

From this point several applications belonging to the two groups can be de-rived by resolving the other variation points. The Localization based on markercan be deployed by connecting the Pose RW interface of the Marker Locatorto the Pose Tracker. The obstacle avoidance variation point can be resolved bysetting the implementation of the Trajectory Adapter in order to use one of thetwo algorithms (DWA or VHF). Finally the Sensors variation point can be re-solved by setting the implementation of the sensors drivers and configuring theproperty of the MarkerLocator in order to specify the camera Id. This value isneeded in order to retrieve the camera position from the robot kinematic model.

The feature model depicted in figure 4 defines for each feature the transfor-mations that allow the resolution of the variation points. Some examples of thetransformations associated to the features are reported below.

– Feature Marker-based. (a) Connection transformation. New connections be-tween: Goal interface of Trajectory Planner and Marker Pose interface ofMarker Locator, Event interfaces of Coordinator and Marker Locator, Eventinterfaces of Trajectory Adapter and Coordinator. (b) Implementation trans-formation: set the implementation of the coordinator for resolving situationsin which no markers are visible.

– Feature DWA. In this case a single Implementation transformation is defined,which sets the implementation of the Trajectory Generator for using theDynamic Window Approach.

– Feature Front Camera. (a) Property transformation: set the value of thecameraId property of the marker locator to the Id of the front camera. (b)Implementation transformation: set the implementation of the RGB CameraDriver for using the driver of the appropriated camera.

7 Conclusions

In this paper we have presented the BRICS software development process forrobotic component-based systems that builds on the concept of software flexi-bility. The key to achieving software flexibility is the possibility to identify theclass of changes that are likely to occur in the environment over the lifespan ofrobotic software components and that affect components and systems portabil-ity, interoperability, and reusability.

Page 14: LNAI 7628 - A Reuse-Oriented Development Process for ...lucagherardi.it/wp-content/papercite-data/pdf/... · A Reuse-Oriented Development Process for Component-Based Robotic Systems

374 D. Brugali et al.

The BRICS approach to robotic software development consists in refactoringexisting open source robotic libraries according to flexible architectures, whichclearly separate stable and variables characteristics.

By explicitly modeling software variability, it is possible to build new applica-tions by selecting and integrating components that provide concrete implemen-tations (variants) of robotic functionalities (variation points).

Acknowledgments. The research leading to these results has received fundingfrom the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement no. FP7-ICT-231940-BRICS (Best Practice inRobotics). The authors would like to thank all the partners of the project fortheir valuable comments.

References

1. The RTT meta model, http://www.best-of-robotics.org/bride/rtt.html2. Brugali, D., Nowak, W., Gherardi, L., Zakharov, A., Prassler, E.: Component-

based refactoring of motion planning libraries. In: IEEE/RSJ Int. Conference onIntelligent Robots and Systems (IROS), pp. 4042–4049 (2010)

3. Brugali, D., Scandurra, P.: Component-based robotic engineering (part i)[tutorial].IEEE Robotics & Automation Magazine 16(4), 84–96 (2009)

4. Brugali, D., Shakhimardanov, A.: Component-based robotic engineering (partii)[tutorial]. IEEE Robotics & Automation Magazine 17(1), 100–112 (2010)

5. Clements, P., Northrop, L.: Software Product Lines: Practices and Patterns.Addison-Wesley (2002)

6. Demeyer, S., Ducasse, S., Nierstrasz, O.: Object-oriented reengineering patterns.Morgan Kaufmann (2008)

7. Fowler, M., Beck, K.: Refactoring: improving the design of existing code. Addison-Wesley Professional (1999)

8. Fox, D., Burgard, W., Thrun, S.: The dynamic window approach to collision avoid-ance. IEEE Robotics & Automation Magazine 4(1), 23–33 (1997)

9. Garcia, H., Bruyninckx, H.: Tool chain (bride) delivered as brics software distribu-tion. BRICS Deliverable 4.4 (2011)

10. Gherardi, L., Brugali, D.: An eclipse-based feature models toolchain. In: 6th ItalianWorkshop on Eclipse Technologies, EclipseIT 2011 (2011)

11. Kang, K.: Feature-oriented domain analysis (FODA) feasibility study. Technicalreport, DTIC Document (1990)

12. Minguez, J., Montano, L.: Nearness diagram (nd) navigation: collision avoidancein troublesome scenarios. IEEE Transactions on Robotics and Automation (2004)

13. Radestock, M., Eisenbach, S.: Coordination in Evolving Systems. In: Spaniol, O.,Meyer, B., Linnhoff-Popien, C. (eds.) TreDS 1996. LNCS, vol. 1161, pp. 162–176.Springer, Heidelberg (1996)

14. Service Component Architecture (SCA), http://www.osoa.org15. Schmidt, D.: Guest editor’s introduction: Model-driven engineering. Com-

puter 39(2), 25–31 (2006)16. Siciliano, B., Khatib, O.: Springer handbook of robotics. Springer-Verlag New York

Inc. (2008)17. Ulrich, I., Borenstein, J.: Vfh+: Reliable obstacle avoidance for fast mobile robots.

In: IEEE Int. Conference on Robotics and Automation (1998)