A Top-Down Approach to Managing Variability in Robotics Algorithms  Selma Kchir, Tewfik Ziadi, Mikal Ziane  UMR CNRS 7606 LIP6-MoVe Universit ́ e Pierre et Marie Curie, France Email: firstname.lastname@lip6.fr  Serge Stinckwich  UMI UMMISCO 209 IRD/UPMC Universit ́ e de Caen-Basse Normandie, France Email: serge.stinckwich@ird.fr  Abstract — One of the defining features of the field of robotics is its breadth and heterogeneity. Unfortunately, despite the availability of several robotics middleware services, robotics software still fails to smoothly handle at least two kinds of variability: algorithmic variability and lower-level variability. The consequence is that implementations of algorithms are hard to understand and impacted by changes to lower-level details such as the choice or configuration of sensors or actuators. Moreover, when several algorithms or algorithmic variants are available it is difficult to compare and combine them. In order to alleviate these problems we propose a top-down approach to express and implement robotics algorithms and families of algorithms so that they are both less dependent on lower-level details and easier to understand and combine. This approach goes top-down from the algorithms and shields them from lower-level details by introducing very high level abstractions   atop   the   intermediate   abstractions   of   robotics middleware. This approach is illustrated on 7 variants of the Bug family that were implemented using both laser and infra- red sensors.  I. I NTRODUCTION  The development of robotics software must deal with a large amount of variability from at least two sources. First, robots are very different from each other: ”They have differ- ent locomotion mechanisms, different onboard computational hardware, different sensor systems, and different sizes and shapes.” [1]. Second, robots are used for very different tasks with varying constraints which leads to a large variety of algorithms. Robotics   middleware,   among   other   improvements,   has been a significant attempt at addressing the first kind of variability by decoupling robotics application from lower levels details. ”It is designed to manage the heterogeneity of the hardware, [...] simplify software design [...]. A developer needs only to build the logic or algorithm as a component” [2]. The task is huge however, as well explained by W.D. Smart who considers the hypothetical case of middleware providing an obstacle-avoidance routine for a mobile robot [1]. According to him ”writing a generic obstacle avoider that will work for all locomotion mechanisms, using input from all possible sensors is a daunting task”. It is not surprising then that, a few years later, middleware services are still far from solving this decoupling problem. Consequently, robotics algorithms are still  •   difficult to understand,  •   difficult to adapt or combine,  •   impacted by changes in lower-level details. Even with the very simplified assumptions such as those of the Bug family of navigation algorithms [3] it is far from obvious in which case such or such variant is best suited to go from one point to another while avoiding obstacles [4]. In this paper we propose a top-down approach to complement the bottom-up middleware approach. The input of this approach is a robotic task and either a family of algorithms or at least enough knowledge to produce algorithms to solve it. Its output is twofold:  •   a set of algorithmic, sensory or action abstractions,  •   a configurable generic algorithm. The produced algorithm can be configured by providing the values of a series of parameters to be adapted to different hypotheses, say on the environment. Furthermore it is generic in two other ways. First, it is decoupled from low-level details on sensors and actuators and second, the algorithmic variability which cannot be resolved statically by specifying configuration parameters is managed by dynamically linking the actions abstractions to executable routines. This rest of this paper is organized as follows. Section II describes our approach and illustrates it on Bug algorithms. Section III deals with the problem of organizing reusable implementations of the abstractions. Section IV discusses the approach. Section V presents preliminary validation results while section VI compares our approach to related work. II. R ATIONAL  In this section, we propose our approach to provide a generic algorithm for a family of algorithms for mobile robots. All the algorithms of the family are assumed to achieve the same task. It is further assumed that there is a significant plan aspect in the algorithms: they are not merely reactive. The generic algorithm can then be seen as a planner specialized to the considered task. Our approach is to be performed by a human robotics ex- pert with a strong background in programming. The input to the approach is a description of the task to be accomplished and a series of algorithmic descriptions in whatever format the expert understands (code, pseudo-code ...). The approach consists in defining a generic algorithm while extracting two   kinds   of   abstractions   to   shield   it   from   respectively  arXiv:1312.7572v1 [cs.RO] 29 Dec 2013
low-level and algorithmic sources of variability. These two steps are performed concurrently. In a third subsequent step, the generic algorithm is implemented using the Template Method design pattern which delegates (similarly to the Bridge design pattern) sensing and actuation to so-called virtual sensors and actuators whose implementations can then vary independently from the algorithmic variants. Figure 1 depicts the main steps of our approach (the first two steps are preformed concurrently): 1)   Abstractions Identification  •   Definition:   Abstractions   are   a   set   of   methods which allows to encapsulate specific data or to abstract specific methods by extracting a general signature from specific ones.  •   Description: If we consider a family of algorithms where variants propose different strategies to per- form the same task, we should handle this variabil- ity. Therefore, abstractions must gather hardware and what we call algorithmic variability. One of the possible approaches to define abstractions is a goal directed approach. In our point of view, defining hardware abstractions does not require specific knowledge of specific robots sensors or actuators but a global description of the needed data types of the handled task. Regarding algo- rithmic abstractions they relie on a comprehensive study of algorithms variants whence the needed intervention of a robotic expert. Invariant parts among algorithms of the same family can then be written in terms of these abstractions. 2)   Generic Algorithm Definition  •   Definition:   A   generic   algorithm   is   a   sequence of instructions written in terms of hardware and algorithmic abstractions.  •   Decription: At this level, the robotic expert com- bine the abstractions identified previsouly in order to write the algorithm or to design a state machine corresponding to a specific robotic task. In this way, there is no specific detail related to a partic- ular algorithms variant and the defined algorithm is completely independent from low level details and from specific algorithms variants. 3)   Organising Implementation  •   Definition: Organising implementation means im- plementing   variants   of   a   family   of   algorithms starting from the generic algorithm.  •   Description: In this step, we implement the in- variant parts of the algorithm in terms of ab- stractions. To do so, the Template Method (TM) design pattern [5] allows the definition of an al- gorithm skeleton in an abstract class as a template method.   This   method   is   the   generic   algorithm identified   previsouly.   It   defines   the   basic   step of the algorithm as ”placeholders” methods (or hook methods), that are different in each subclass. Invariants parts of the algorithm are represented once in the abstract class as concrete methods. Abstract methods will be used to represent needed operations that are different in each subclass. The main idea is to represent the variants of the al- gorithm as subclasses that implement these ab- stract methods. Thus, algorithmic abstractions will be implemented in these subclasses. Concerning hardware abstractions, they are not implemented in subclasses like algorithmic abstractions but del- egated to adaptors which implement them. We define one adapter per physical sensor. Adaptors implement these operations to extract physical data and convert them to the needed abstractions. Then, the specification of the physical sensor used in the algorithm is done at the deployment level.  Fig. 1.   Generic algorithm: from identification to implementation  In the next section, we illustrate our approach on the Bug family of navigation algorithms. III. C ASE STUDY : B UG ALGORITHMS  It   is   symptomatic   that   even   with   the   very   simplified assumptions underlying these algorithms it is still difficult:  •   to understand the differences among the algorithmic variants,  •   to choose one variant over another,  •   to share development efforts among variants.  A. Bug algorithms overview  The Bug algorithms attempt to solve the navigation prob- lem in an unknown two-dimensional environment with fixed obstacles and a known goal position. Over 19 versions of Bug algorithms have been defined in the literature. Among them, 7 variants are considered in this paper. Bug algorithms share the following assumptions [3] : 1) The environment is unknown and a finite number of fixed obstacles are placed arbitrarily. 2) The robot is considered as a point (i.e. without body). It has perfect sensors (for obstacle detection) and a perfect localization ability (e.g. to compute its distance to its goal). In Bug family, the robot has a local knowledge and a global goal. In other words, the inputs of Bug algorithms are the robot’s start position and the target position. At the end of the algorithm’s execution, the robot must indicate if its goal is reached or if the goal is unreachable. Most of the Bug algorithms can be programmed on any mobile robot
using tactile or distance sensing and a localization method while some require distance sensing.  B. Abstractions identification  In the litterature, as far as we know, Bug algorithms are only published with an informal description. Bug algorithms are very similar fundamentally but differ in some points of interest. Their principle is the following: (1) The robot  motion to its goal   until an   obstacle is detected   on its way. (2) From the point where the obstacle were encountered (called hit point), the robot   looks for a point   (called leave point)   around the encountered obstacle   to be able to move to its goal again. (3) When a   leave point is identified , the robot   moves to it   and leaves the obstacle. Steps (1), (2) and (3) are repeated until   the goal is reached   or until the robot indicates that the   goal is unreachable . This description of Bug hides hardware and algorithmic variability. Hardware variability impacts on obstacle detection and localisation tasks because of their dependency of the robot actual sensors. Algorithmic variability is related to the leave point identifi- cation task. Following a goal directed approach and based on a comprehensive study of Bug algorithms, we have identified the following abstractions (described here as methods):  •   Motion to goal: the robot needs to face its goal and to be able to go ahead it:   FACE G OAL (P OINT GOAL P OSI -  TION ),   GO A HEAD ().  •   Obstacle   on   the   robot’s   way:   BOOL   OBSTACLE I N - F RONT O F T HE R OBOT ()  •   Current position: P OINT GET P OSITION ()  •   Get around the encountered obstacle consists in per- forming clockwise or anticlockwise circumnavigation while maintaining a safety distance from the obstacle:  WALL F OLLOWING ( DIRECTION )  –   DOUBLE GET S AFE D ISTANCE ()  –   BOOL OBSTACLE O N T HE R IGHT (),   BOOL OBSTA -  CLE O N T HE L EFT (): Depending if we follow the wall on the right or the left.  –   DOUBLE   GET R IGHT D ISTANCE (),   DOUBLE GET L EFT D ISTANCE (): To keep a safety distance from a wall, we need to know the distance to the wall from the right and the distance from the left.  •   Look for a leave point:   IDENTIFY L EAVE P OINT ( BOOL DIRECTION , P OINT   ROBOT P OSITION , P OINT   GOAL - P OSITION )   which   consists   in   wall   following   while looking for a leave point. This could be a local de- cision (choose the first leave point which satisfies the algorithm condition) or a global decision (choose the best leave point after visiting all the points around the obstacle). The following conditions are examples of decisions that the algorithm defines to find a leave point:  – The   closest   point   around   obstacle   boundary condition.   It consists on recording the closest point to the goal among all the points ever visited by the robot while performing boundary following[3][6].  – The m-line detection condition.   It is a straight line between the starting point and the target which aims at providing a set of prededefined leave points. The robot must leave only on these points[6][7].  – The local minimum condition.   Using its distance sensors, the robot can detect discontinuity points[8] on obstacles on its way with respect to the target.  – The   disabling   segment   condition.   A disabling segment occurs when the robot cannot move to its goal from all points in a segment while perfoming boundary following.  – The   step   method.   The robot uses its distance sensors to detect a point which is   STEP [9] closer to the target than any point already visited. Thus,   we   have   identified   the   method   FIND L EAVE - P OINT (P OINT   ROBOT P OSITION ,   P OINT   HIT P OINT , P OINT GOAL P OSITION ) which will be applied to each point around the obstacle and which is specific to each algorithm variant to hide all low level details. The code of   IDENTIFY L EAVE P OINT   is given by the algorithm 1.  •   Leave point identified:   BOOL IS L EAVE P OINT F OUND ()  •   RESEARCH C OMPLETE :   In   case   of   a   local   decision of   leave   point   identification,   the   research   complete is equivalent to the condition leave point identified. In case of a global decision, the research complete decision   is   equivalent   to   a   complete   cycle   around the obstacle:   RESEARCH C OMPLETE (P OINT ROBOT P O -  SITION , P OINT HIT P OINT , P OINT GOAL P OSITION ).  •   Move to the leave point: Once the leave point identified, the robot goes to it. This is a variability point because the robot can go to the leave point following the shorter distance or other strategies:   GO T O L EAVE P OINT (P OINT LEAVE P OINT ).  •   GOAL   UNREACHABLE : This condition is checked if there   is   no   leave   point   identified   after   perform- ing   an   entire   cycle   around   the   obstacle:   BOOL COMPLETE C YCLE A ROUND O BSTACLE (P OINT ROBOT - P OSITION ,P OINT   HIT P OINT )   AND   NOT   IS L EAVE - P OINT F OUND ()  •   goal reached: Depending on the algorithm objective, we define an error margin which indicates if the robot must reach its goal or stops before arriving to it:   BOOL GOAL - R EACHED (P OINT ROBOT P OSITION , P OINT GOAL P O -  SITION ,   DOUBLE ERR )  Algorithm 1:   Identify leave method algorithm  function   IDENTIFY L EAVE - P OINT ( Bool direction, P oint robotP os, P oint goalP os ) computeData(robotPos); wallFollowing(direction); findLeavePoint(robotPos, hitPoint); After identifying these abstractions, we classify them into hardware abstractions and algorithmic abstractions. 1) Hardware abstractions:
GET P OSITION (),   GET S AFE D ISTANCE (),   OBSTA -  CLE O N T HE L EFT (),   OBSTACLE O N T HE R IGHT (),  GET R IGHT D ISTANCE (),   GET L EFT D ISTANCE (),  OBSTACLE I N F RONT O F T HE R OBOT (), 2) Algorithmic abstractions:  FIND L EAVE P OINT (P OINT   ROBOT P OSITION , P OINT   HIT P OINT ,   P OINT   GOAL P OSITION ),  IDENTIFY L EAVE P OINT ( BOOL   DIRECTION ,   P OINT ROBOT P OSITION ,   P OINT   GOAL P OSITION ),  BOOL   GOAL R EACHED (P OINT   ROBOT P OSITION , P OINT   GOAL P OSITION ,   DOUBLE   ERR ),  COMPLETE C YCLE A ROUND O BSTACLE (P OINT ROBOT P OSITION ,P OINT   HIT P OINT ),   BOOL IS L EAVE P OINT F OUND (),   GO T O L EAVE P OINT (P OINT LEAVE P OINT ).  C. Generic Bug algorithm definition  The generic algorithm is a combination of the previ- ously defined abstractions as a sequence of instructions. Our generic algorithm is given in 2.  Algorithm 2:   Bug generic algorithm  Sensors   : A perfect localization method. An obstacle detection sensor  input   : Position of Start ( q start ), Position of Target ( q goal )  Initialisation : robotPos   ←   getPosition() ; direction   ←   getDirection() ;  if   goalReached( robotPos )   then  EXIT SUCCESS ;  end else if   obstacleInFrontOfTheRobot()   == true  then  identifyLeavePoint   (direction, robotPos, goalPos);  if   leavePointFound()   &&  researchComplete( robotPos, getHitPoint(), goalPosition )   then  goToLeavePoint( getLeavePoint() ) ;  faceGoal()() ;  end else if  completeCycleAroundObstacle( robotPos, getHitPoint() )   &&   ! leavePointFound()   then  EXIT FAILURE ;  end end else  motionToGoal() ;  end  D. Implementation: Template Method design pattern  As we said previously, the Template Method deals with variability problem by proposing to define the basic step of the algorithm as a template method written in terms of abstractions which will be implemented in subclasses. Define a subclass for each algorithm without handling sensors and actuators variability cause a combinatorial explosion. Conse- quently, we dealed with this problem by delegating hardware variability to what we call virtual sensors or adaptors. Virtual sensors convert specific data from the physical sensors to the needed data in the algorithm. They implement a set of interface abstract operations. For instance, the method   OB -  STACLE I NFRONT O F T HE R OBOT () is different in each sensor adaptor. We have defined an adaptor per sensor. In case of multiple physical sensors use, their adaptors are combined together to provide the needed data for the algorithm. The architecture of our implementation is presented in Figure 2. To   perform   wall   following,   right   hand   and   left   hand algorithms are written in terms of sensors abstractions (i.e.  OBSTACLE O N T HE L EFT () and   OBSTACLE O N T HE R IGHT ())  E. Discussion  The hierarchy of classes defined by our approach can lead to a combinatorial explosion if we add additional variants of Bug family. It is then much cheaper to build operations of the algorithm as components and to assemble desired family members from them. This is our main motivation for using an alternate solution based on Software Product Lines (SPL). SPL are easy to use, compact and generate only a configuration which interests the user. This constitutes an immediate topic for a future work. IV. R ESULTS AND   V ALIDATION  Several performance comparison studies[4] were realized on the Bug family. In this section, we do not intend to perform a comparison between Bug family but to prove that each algorithm of the Bug family fits with our generic algorithm. We demonstrate the capabilities of our generic algorithm in   the   OROCOS-RTT   framework   through   7   variants   of Bug:   Bug1   [3],   Bug2   [6],   Alg1   [7],   Alg2   [10],   Dist- Bug [9],TangentBug [8] and Rev1 [11]. Simulation   was   performed   using   Stage-ROS   with   2 configurations. The first tested configuration was done with a laser scanner with 180 degrees scanning angle and a detection range which varies from 0.02 meters to approximately 4 meters and a GPS for localization. The robot does not have any knowledge about its environment except its start position and the goal position. The second configuration was done using 3 infrared range sensors placed on the front, on the left and on the right compared to the central axis of the robot with a field of view equals to 26 degrees and a range which detects until 2 meters. To   demonstrate   that   any   algorithm   of   the   ones   studied here fits with our generic algorithm, we have tested both configurations in 3 different environments for all algorithms. We defined the first environment (see figure 3) to validate the target reachability condition. In all implemented algorithms,
Fig. 2.   Bug algorithms class diagram (extract)  the   robot   returns   failure   because   it   can   not   achieve   its goal.   The   second   environment   shown   in   figure   4   is   a simple   simulation   environment   with   one   obstacle.   Some algorithms   behave   similarly   in   this   environment   despite their different obstacle avoidance strategies. For instance, Alg1   and   Bug2   rely   on   the   M-line   detection   condition but   behave   differently   when   they   encounter   an   already traversed point. In other words, Alg1 was defined above Bug2 to overcome situations where the robot can find itself in an overlasting loop around obstacle. For this reason, we defined the third environment, presented in figure 5, to validate the encountered points condition (i.e. when the robot encounters an already traversed point), particularly used in the algorithms Alg1 and Alg2.  Fig. 3.   Environment with un- reachable target   Fig. 4.   Basic Simulation Environ- ment  Fig. 5.   Environment to validate the encountered points condition  The trajectory of the robot could depend on the com- putation time of sensors information. Since most of the algorithms treatments are reactive, we had to define the period of execution time which allow us to get as much real- time information as possible and to optimize the execution time and the robot’s path. Consequently, we set the execution period of the algorithm to 0.5 seconds. Alll the code of Bugs algorithm variants 1   and simulations results 2   are available on GitHub. V. R ELATED WORK  Several software engineering technologies and methods aim at improving software design and reusability. In robotics, reusability is obtained after handling variability which could be related to the robot hardware or to the robot’s capabil- ities (e.g. different strategies for obstacle avoidance, etc). Robotics software like Robot Operating System (ROS)[12], RISCWare framework [13], Player [14] propose a hardware abstraction layer to encapsulate the sensors that gather infor- mation about the environment and provide a set of predefined intefaces. These middlewares rely on a bottom up approach which consists on classifying the most used physical sensors (or actuators), analysing the potential data they are able to provide and then define interfaces. Unlike these middlewares, we use a top-down approach which consists in analysing the needed data in a particular application, defining abstractions and then writing the appli- cation in terms of these abstractions (possibly provided by middlewares). In our approach, we have applied the Template Method design pattern to implement variants of a generic algorithm. They are several proposals that try to apply design patterns in robotics to handle variabilities. CLARATy authors [15] say they used many well-know techniques developed by the software community including design patterns but without being   much   more   explicit   about   them.   MARIE   [16],   a  1   https://github.com/SelmaKchir/BugAlgorithms  2   https://github.com/SelmaKchir/BugAlgorithms/wiki/Implementing-Bug- Algorithms-variants
middleware framework for robotics, applied the Mediator Design Pattern [5] to create a mediator interoperability layer for distributed robotics applications. VI. C ONCLUSION AND   P ERSPECTIVES  In this paper we have proposed an approach to organize families of algorithms so that the algorithmic decisions to make are clearly expressed and decoupled from implemen- tation details. Our approach relies on the Template Method design pattern to define a generic algorithm for Bug algo- rithms family. Our approach consists of three steps. The first step takes as input a set of algorithmic variants; as described in the litterature, and manually extract hardware abstractions and what we have called algorithmic abstractions. The generic algorithm is then defined as a sequence of instructions in terms of these abstractions. The implementation of these variants relies then on the Template Method design pattern. This approach has been illustrated on the Bug family of robot navigation algorithms. Seven implemented variants of Bug algorithms have been implemented using the OROCOS- RTT robotic framework. Simulation was performed in dif- ferent unknown environments with a random positioning of obstacles. Bug variants are about 20 versions of algorithms. Imple- menting all   BugAlgorithm   subclasses is very complicated to understand and too expensive to build all Bug family mem- bers. In addition, it is error prone to not define constraints on subclasses and the data they must specify and use. It is then much cheaper to build operations of the algorithm as components and to assemble desired family members from them. This is our main motivation for using Software Product Lines (SPL) [17] as an immediate topic of future work. R EFERENCES [1]   W. D. Smart, “Is a Common Middleware for Robotics Possible?” in   IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS’07) Workshop   on   Measures   and   Procedures   for   the   Evaluation   of Robot Architectures and Middleware , Nov. 2007. [Online]. Available: http://www.cse.wustl.edu/ ∼ wds/library/papers/2007/iros-ws2007.pdf [2]   A.   Elkady   and   T.   Sobh,   “Robotics   Middleware:   A   Comprehen- sive Literature Survey and Attribute-Based Bibliography,”   Journal of Robotics , vol. 2012, 2012. [3]   V.   J.   Lumelsky   and   A.   A.   Stepanov,   “Effect   of   Uncertainty   on Continuous Path Planning for an Autonomous Vehicle,” in   Decision and Control, 1984. The 23rd IEEE Conference on , vol. 23, dec. 1984, pp. 1616–1621. [4]   J.   Ng   and   T.   Br ̈ aunl,   “Performance   Comparison   of   Bug Navigation   Algorithms,”   J.   Intell.   Robotics   Syst. ,   vol.   50, no.   1,   pp.   73–84,   Sep.   2007.   [Online].   Available:   http: //dx.doi.org/10.1007/s10846-007-9157-6 [5]   E. Gamma, R. Helm, R. Johnson, and J. Vlissides,   Design Patterns: Elements of reusable object-oriented software .   Addison-Wesley Publishing, 1995. [6]   V. Lumelsky and A. Stepanov, “Dynamic Path Planning for a Mobile Automaton with Limited Information on the Environment,”   Automatic Control, IEEE Transactions on , vol. 31, no. 11, pp. 1058 – 1063, nov 1986. [7]   H. Noborio, K. Fujimura, and Y. Horiuchi, “A Comparative Study of Sensor-based Path-planning Algorithms in an Unknown Maze,” in  Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) , vol. 2, 2000, pp. 909–916. [8]   I. Kamon, E. Rimon, and E. Rivlin, “TangentBug: A Range-Sensor- Based Navigation Algorithm,”   The International Journal of Robotics Research , vol. 17, no. 9, pp. 934–953, September 1998. [9]   I. Kamon, “Sensory Based Motion Planning with Global Proofs,” in  Proceedings of the IROS95 , 1995, pp. 435–440. [10]   A. Sankaranarayanar and M. Vidyasagar, “Path Planning for Moving a Point Object amidst Unknown Obstacles in a Plane: a New Algorithm and a General Theory for Algorithm Development,” in   Proceedings of the 29th IEEE Conference on Decision and Control , 1990, pp. 1111– 1119 vol.2. [11]   Y.   Horiuchi   and   H.   Noborio,   “Evaluation   of   Path   Length   Made in Sensor-Based Path-Planning with the Alternative Following,” in  Proceedings of the IEEE International Conference on Robotics and Automation (ICRA 2001) , vol. 2.   IEEE Xplore, 2001, pp. 1728–1735. [12]   M. Quigley, K. Conley, B. P. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng, “ROS: an Open-source Robot Operating System,” in   ICRA Workshop on Open Source Software , 2009. [13]   A. Elkady, J. Joy, T. Sobh, and K. Valavanis, “A Structured Approach for   Modular   Design   in   Robotics   and   Automation   Environments,”  Journal of Intelligent & Robotic Systems , pp. 1–15, 2013. [Online]. Available: http://dx.doi.org/10.1007/s10846-012-9798-y [14]   T. H. Collett, B. A. MacDonald, and B. P. Gerkey, “Player 2.0: Toward a Practical Robot Programming Framework,” in   Proc. of the Australasian Conf. on Robotics and Automation (ACRA) , Sydney, Australia, 2005. [15]   I. A. Nesnas, R. Simmons, D. Gaines, C. Kunz, A. Diaz-Calderon, T. Estlin, R. Madison, J. Guineau, M. McHenry, and I.-H. Shu, “CLARAty: Challenges and Steps Toward Reusable Robotic Soft- ware,”   International Journal of Advanced Robotic Systems , vol. 3, no. 1, pp. 23–30, 2003. [16]   C. Cˆ ot ́ e, Y. Brosseau, D. L ́ etourneau, C. Ra ̈ ıevsky, and F. Michaud, “Robotic   Software   Integration   Using   MARIE,”   International Journal   of   Advanced   Robotic   Systems ,   vol.   3,   no.   1,   pp. 055–060,   Mar.   2006.   [Online].   Available:   http://www.ars-journal. com/International-Journal-of-Advanced-Robotic-Systems/Volume-3/ 055-060.pdf [17]   P. Clements and L. Northrop,   Software Product Lines: Practices and Patterns .   Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001.