Σχόλια 0

Το κείμενο του εγγράφου

A Reuse-Oriented Development Process forComponent-based Robotic SystemsD.Brugali1L.Gherardi1A.Luzzana1A.Zakharov21University of Bergamo,DIIMM,Italyfbrugali,luca.gherardi,andrea.luzzanag@unibg.it2GPS GmbH,Stuttgart,Germanyzakharov@gps-stuttgart.deAbstract.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 dened 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 dened for developing exibleand 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 IntroductionThe 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 codelines from program to program:this practice is called opportunistic softwarereuse and might work only for the development of simple systems (e.g.for edu-cational purposes) or for unique systems (e.g.a research prototype).In contrast,the development of industrial-strength robotic systems that aimto become commodity,require a systematic approach to software reuse.System-atic software reuse is the routine use of existing software or software knowledgeto construct new software,so that similarities in requirements,architectures anddesign between applications can be exploited to achieve substantial benets 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].An SPL is a set of applications (products) that share many (structural,be-havioral,etc.) commonalities and together address a particular domain.Theterm domain is used to denote or group a set of systems (e.g.mobile robots,humanoid robots) or functional areas (motion planning,deliberative control),within systems,that exhibit similar functionality.Each new application is builtfrom the SPL repository of common software assets (e.g.architectural and de-sign models,software components).In the BRICS project we have dened asoftware development process that exploits the SPL approach and accounts fortwo peculiarities of the robotics eld:{ 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 dierent applications.Typically,their interoperability or their ex-tensions towards novel applications require high eorts.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 oered bythe SPL.This phase is typically called software development for reuse.{ Typically,robotic systems integrators are not software engineers and do notmaster advanced software development techniques adequately.For this rea-son,the proposed development process exploits the Model-Driven Engineer-ing (MDE) [15] approach.According to the MDE approach,robotic sys-tem integrators use domain-specic 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 specic application requirements,and semiautomatically trans-formmodels 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-oriented development processdescribed in this paper.The rst two phases,namely software refactoring andproduct line design,are intended to produce software for reuse.The remainingtwo phases,namely Variability modeling and Variability resolution,support thedevelopment of software with reuse.In the upper part of Figure 1,the conceptualand software tools that support the process are linked to the various phases,namely Refactoring Patterns [6],the BRICS Component Model (BCM)[9],theBRICS Integrated Development Environment (BRIDE)[9],and the BRICS toolfor variability modeling and resolution (FODA).In the lower part of the gurethe input open source libraries and the intermediate products of the developmentprocess are represented,namely the BRICS class libraries,the Product Linemodels,the Variability models (features models),and the Application models.This paper aims to illustrate the whole software development process thatwe have dened for developing exible 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.BRICSComponentmodelBRIDEToolCodeRefactoringDocumentDocumentOpenSourceLibrariesDocumentDocumentBRICSClassLibrariesDocumentDocumentProductLine ModelDocumentDocumentFeatureModelDocumentDocumentApplicationModelProductLine DesignVariabilityModelingVariabilityResolutionFODAToolRefactoringPatternsFig.1.The development processThe 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 StudyRobust 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 e-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 couldbe roughly classied as one- and multi-step methods.One-step methods directlyconvert the sensor data to a motion commands.Majority of one-step algorithmsare either based on classical planning or on the potential elds approaches [16].Today,they are rarely used due to their inability to cope with dynamic en-vironment and vehicle constraints.Multi-step methods (e.g.Dynamic WindowApproach [8],Vector Field Histogram [17],Nearness Diagram [12]) overcomethese limitations by creating a local map of the environment around the robotand performing local planning by computing possible motion directions (Near-ness Diagram) and velocities (VHF) taking into account distance to the goal orto 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 exible systems3.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 robotics3The IEEE Standard Glossary of Software Engineering Terminology denes exibilityas the ease with which a systemor component can be modied for use in applicationsor environments other than those for which it was specically designed.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 re-alized that typically they refer to the same functionality using dierent 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 rening a path for introducing velocity information.A trajectory denes 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 RefactoringSoftware 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 aTypeMethodLibrary NameGlobal PlannersCarrot planner,Dijkstra's alg.ROSARA*,Anytime D*,ANA*SBPL/ROSSampling-based PlanningOOMPL,BRICSMMTrajectory Generationreactivenav::CPTG1 - CPTG7MRPTLocal plannersVFFMRPTVFH+Player/Stage,ORCADynamic WindowROS,Sun owerTrajectory RolloutROSNearness DiagramMRPTElastic BandROSMappinggmapping,costmap2dROSogNode,ogMapORCALocalizationamclROSICP SLAM,RBPF SLAM,...MRPTTable 1.Open source libraries for robust navigationdomain-driven transformation that,through a careful analysis of the applicationdomain (commonality/variability and stability analysis),enhances software ar-tifacts exibility,adaptability,and portability.Software refactoring brings manyadvantages not immediately but in a long time.The initial cost in terms oftime and eort 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 pat-terns have been applied to refactor motion planning software libraries.Refac-toring patterns provide guidelines to redistribute the responsibilities among theclasses of a software library,to harmonize the common data structures and toreduce the coupling degree.3.1 Case study:the ROS Navigation StackThis 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,whichMoveBaseTransformListenerCostmap2DBaseGlobalPlannerBaseLocalPlannerCarrotPlannerNavfnROSDWAPlannerROSTrajectoryPlannerROSTwistPosePointCloud/LaserScanMapOdometryFig.2.Mobile base navigation component in ROSincludes goal heading,path heading and obstacle clearance.The trajectory withmaximum 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 dierential 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 specic 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 ags 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 dierent environments.4 Product Line DesignIn [4] we have dened a set of architectural principles for the development of ex-ible component-based systems that foster the separation of four design concernsoriginally identied in [13],namely Computation,Coordination,Communication,and Conguration.According to these architectural principles,the robot functionalities are pro-vided by Computation components that have harmonized interfaces and imple-ment specic robotic algorithms.The clear separation between component inter-face and implementation guarantees interoperability of components that providesimilar functionalities but implement dierent 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 nite state machines in special-ized Coordination components that observe state transitions in the systems bylistening to events notied 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 specic middleware,components should be designed andimplemented according to an abstract component model (meta-model),whichdenes middleware-independent communication ports.For this purpose,simi-larly to the OMG initiative4,the BRICS project has dened 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 denes (in terms ofdata types and contract) howa component provides (output port) or requires(input port) a service or a data- ow.{ Property:allows the component conguration.A property provides an in-terface for setting the value of a parameter dened in the component imple-mentation (e.g.period,algorithm parameters,...).{ Connector:denes 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 species the structural (data structuresand application programming interfaces) and behavioral (data and control ow)commonalities among the products and the variations re ected 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.Dier-ent algorithms (i.e.dynamic window approach [8] or vector eld histogram [17])are implemented as distinct software components.The product line architectureguarantees that these components are interchangeable.The possible congurations of a software product line are represented in aproduct line model,which species (a) a set of components that can be used forbuilding all the possible applications of the family (some of themare 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 specic implementation,the values of their conguration pa-rameters,and the variable connections,the variability of the product line isresolved and a specic application model is dened.4http://www.omg.org/spec/RTC/1.0/Laser Scanner DriverlaserScannerIdTrajectory FollowerrobotModelRGB Camera DriverRobot DriverrobotModelCoordinatorTrajectory PlannerTrajectory AdapterlaserScannerIdrobotModelMarker LocatorcameraIdPose TrackerOdometryTwistTrajectoryLaser ScanPose RWImageRobot Pose & TwistTrajectoryMarker IdEventEventGoalMarkerPoseEventEventFig.3.The model representing the BRICS Robust Navigation Product Line4.1 The BRICS Robust Navigation SPLFigure 3 represents a rst 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-gure a specic application.Continuous boxes represent mandatory components,while dashed boxes represent optional components.Boxes inside components in-dicate their properties.More specically:{ 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.{ 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 dierences between the proposed solution and theROS navigation stack discussed in Section 3.First of all the navigation func-tionalities are mapped to ner 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 dierent components.This separation re ects the dierent 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 independentfromthe components implementations by introducing a Coordinator component.5 Variability ModelingBuilding software systems according to the product line approach is economicand ecient [5].Most work is about integration,customization,and congura-tion instead of creation.Asystemconguration is an arrangement of componentsand associated options and settings that completely implements a software prod-uct.Variants may exclude each others (e.g.,the selection of a component imple-menting an indoor navigation algorithm excludes the choice of components pro-viding GPS-based localization services) or one option may make the integrationof a second one a necessity (e.g.,a component implementing a visual odometryalgorithm depends on a component that supplies images of the environment).Hence,only a subset of all combinations is the admissible conguration.In order to model and symbolically represent the product line variationpoints,their variants and the constraints between them,a formalism called Fea-ture Models was introduced in 1990 in the context of the Feature Oriented Do-main Analysis (FODA) approach [11].These models make explicit the variabilitythat is implicitly dened during the product line design.A feature model is a hierarchical composition of features.A feature denesa 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 specic 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,denes the application family.Parent features are connected to childrenfeatures by means of edges,which represent containment relationships.Featurescan 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 dene 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 dene two kinds of constraints between the features:requires and excludes.These constraints allow the denition of a subset ofvalid congurations.The requires constraint means that if a feature Ais 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 denes the rules forcreating feature models conform to the standard specication introduced above.5.1 Variability in the BRICS Robust Navigation SPLFigure 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 rst 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 specic 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 specic support.The feature model also denes 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 requirementsFig.4.The model representing the variability in the BRICS RN Product Line.It wasdesigned with our Feature Model pluginare 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 ResolutionThe 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-cic application.Thanks to our tool this can be done by selecting the set ofvariants (features),which re ect 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 dened in thefeature model.The tool automatically checks the constraints satisfaction andonly successively generates the application model,which can be transformedin the deployment le of a specic middleware by means of the model-to-texttransformation provided by BRIDE.In order to dene how the Product Line model has to be modied for produc-ing the model of a specic application,we introduced the concept of transforma-tion.A transformation is an action that modies the architectural elements of aProduct Line model in order to replace a variation point with a specic variant.Dierent kinds of transformations are available,according to the elements thathave to be modied (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 thefeatures.Currently it has been done only for the generation of Orocos RTTapplication.For this reason the meta-model has three links to three elementsdened in the RTT-BCM meta-model:Task Context,Connection Policy,andProperty [1].However the approach can be easily extended to other middle-wares such ROS and SCA [14].The following list describes the dierent kindsof transformations.{ TransfImplementation:denes which implementation will be used for acertain component,i.e.which algorithm (Computation and Coordination).The developer species a link to the desired component (dened in the Prod-Fig.5.The extension of the feature model meta-model that species how transforma-tions are mapped to RTT elements (classes with the arrow on the top right corner)uct Line model) and the class that implements its interface (by means of thenamespace and the class name).{ TransfConnection:denes how the components will be connected (Com-position).The developer species 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 specic lock policies and the buer sizes).Asa result of these transformations unconnected components will be removedfrom the model.{ TransfProperty:denes the value of a certain property (Conguration).The developer species a link to the desired property (dened in the ProductLine model) and the value he wants to assign to it.6.1 Variability resolution in the BRICS Robust Navigation SPLThe product line presented in the previous sections allows the deployment ofdierent applications that can be classied according to two navigation strate-gies:map-based and marker-based.The dierent strategies can be derived byresolving the Navigation variation point.If a map-based navigation is chosen,then the Marker Locator,the RGBCamera Driver components and all the connections between these componentsand the others are not necessary.So these components can be removed fromthe model.In case of marker-based navigation instead,the Trajectory Plannercomponent receives the goal from the Marker Locator.Hence the optional con-nections of Marker Locator and RGB Camera Driver have to be created.In addition to these connections,the Coordinator implementation and itsconnections have to be dened 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 fromthe 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 conguration needsa connection between the Event interfaces of Marker Locator and Coordinator.From this point several applications belonging to the two groups can bederived by resolving the other variation points.The Localization based on markercan be deployed by connecting the Pose RWinterface of the Marker Locator tothe Pose Tracker.The obstacle avoidance variation point can be resolved bysetting the implementation of the Trajectory Adapter in order to use one ofthe two algorithms (DWA or VHF).Finally the Sensors variation point can beresolved by setting the implementation of the sensors drivers and conguring 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 gure 4 denes 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 dened,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 ConclusionsIn this paper we have presented the BRICS software development process forrobotic component-based systems that builds on the concept of software exi-bility.The key to achieving software exibility is the possibility to identify theclass of changes that are likely to occur in the environment over the lifespan ofrobotic software components and that aect components and systems portabil-ity,interoperability,and reusability.The BRICS approach to robotic software development consists in refactoringexisting open source robotic libraries according to exible architectures,whichclearly separate stable and variables characteristics.By explicitly modeling software variability,it is possible to build new appli-cations by selecting and integrating components that provide concrete imple-mentations (variants) of robotic functionalities (variation points).8 ACKNOWLEDGMENTSThe research leading to these results has received funding from the EuropeanCommunity's Seventh Framework Programme (FP7/2007-2013) under grant agree-ment no.FP7-ICT-231940-BRICS (Best Practice in Robotics).The authorswould like to thank all the partners of the project for their valuable comments.References1.The RTT meta model.http://www.best-of-robotics.org/bride/rtt.html.2.D.Brugali,W.Nowak,L.Gherardi,A.Zakharov,and E.Prassler.Component-based refactoring of motion planning libraries.In IEEE/RSJ Int.Conference onIntelligent Robots and Systems (IROS),pages 4042{4049,2010.3.D.Brugali and P.Scandurra.Component-based robotic engineering (parti)[tutorial].Robotics & Automation Magazine,IEEE,16(4):84{96,2009.4.D.Brugali and A.Shakhimardanov.Component-based robotic engineering (partii)[tutorial].Robotics & Automation Magazine,IEEE,17(1):100{112,2010.5.P.Clements and L.Northrop.Software Product Lines:Practices and Patterns.Addison-Wesley,2002.6.S.Demeyer,S.Ducasse,and O.Nierstrasz.Object-oriented reengineering patterns.Morgan Kaufmann,2008.7.M.Fowler and K.Beck.Refactoring:improving the design of existing code.Addison-Wesley Professional,1999.8.D.Fox,W.Burgard,and S.Thrun.The dynamic window approach to collisionavoidance.Robotics & Automation Magazine,IEEE,4(1):23{33,1997.9.H.Garcia and H.Bruyninckx.Tool chain (bride) delivered as brics software dis-tribution.BRICS Deliverable 4.4,2011.10.L.Gherardi and D.Brugali.An eclipse-based feature models toolchain.In 6thItalian Workshop on Eclipse Technologies (EclipseIT 2011),2011.11.K.Kang.Feature-oriented domain analysis (FODA) feasibility study.Technicalreport,DTIC Document,1990.12.J.Minguez and L.Montano.Nearness diagram(nd) navigation:collision avoidancein troublesome scenarios.IEEE Transactions on Robotics and Automation,2004.13.M.Radestock and S.Eisenbach.Coordination in evolving systems.In Proceedingsof the Int,Workshop on Trends in Distributed Systems CORBA and Beyond,pages162{176.Springer LNCS vol.1161,1996.14.Service Component Architecture (SCA).http://www.osoa.org.15.D.Schmidt.Guest editor's introduction:Model-driven engineering.Computer,39(2):25{31,2006.16.B.Siciliano and O.Khatib.Springer handbook of robotics.Springer-Verlag NewYork Inc,2008.17.I.Ulrich and J.Borenstein.Vfh+:Reliable obstacle avoidance for fast mobilerobots.In IEEE Int.Conference on Robotics and Automation,1998.