ISR / ROBOTIK 2010

BRICS – Best practice in

Rainer Bischoff 1, Tim Guhl 1, Erwin Prassler 2, Walter Nowak 2, Gerhard Kraetzschmar 3, Herman Bruyninckx 4, Peter Soetens 4, Martin Haegele 5, Andreas Pott 5, Peter Breedveld 6, Jan Broenink 6, Davide Brugali 7, Nicola Tomatis 8

1 KUKA Roboter GmbH, Augsburg, Germany 2 GPS Gesellschaft für Produktionssysteme GmbH, Stuttgart, Germany 3 Bonn-Rhein-Sieg University of Applied Sciences, Bonn, Germany 4 Katholieke Universiteit Leuven, Leuven, Belgium 5 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., Stuttgart, Germany 6 University of Twente, Twente, Netherlands 7 Università degli Studi di Bergamo, Bergamo, Italy 8 BlueBotics SA, Lausanne, Switzerland

Summary / Abstract In the past, the process of developing a new application has had more of the design of a piece of artwork or of an act of ingenious engineering than of a structured and formalized process. The prime objective of BRICS is to structure and formalize the robot development process itself and to provide tools, models, and functional libraries, which allow reducing the development time by a magnitude. BRICS is working together with academic as well as industrial providers of robotics “components” (hardware and ), to identify and document best practices in the development of com- plex robotics systems, to refactor (together) the existing components in order to achieve a much higher level of reusabil- ity and robustness, and to support the robot development process with a structured tool chain and code repository. BRICS is a joint research project funded by the European Commission ICT Challenge 2 under grant number 231940. First results include the analysis of existing robot development processes, the first steps towards harmonizing robot con- trol interfaces and component models and the set-up of robot systems for best practice analyses.

1 Introduction transformation and aggregation of models and their compilation into operational components and systems, • the large value of cross-sectional aspects, such as in- 1.1 The robot development process strumentation for benchmarking and monitoring, error In computer science the process of developing large soft- management and robustness, harmonized interfaces, ware systems is well understood. In March 2009, a search deployment support, or runtime reconfiguration of ser- in Scholar Google for the phrase “software development vices. process” resulted in approx. 49.000 hits. Some of the links point to textbooks, which have several thousand citations. 1.2 Project objectives At the same time a search for “robot development process” The prime objective of BRICS is to structure and formalize returned a total of 26 hits. This number is an indication the robot development process itself and to provide tools, that a formal robot development process has to date not models, and functional libraries, which help accelerating been well established as a structured formal process. this process significantly. More specifically the objectives Earlier attempts in supporting the “robot development are: process” did not really focus on improving the process, but • to design and implement an integrated development on the development and provision of functional libraries, environment for robotics (called “BRIDE”) and an ac- control architectures, software integration frameworks, and companying software repository of best practice robot- communication infrastructure and middleware. ics algorithms (called “BROCRE”), Important aspects were more or less neglected, such as: • to significantly promote the interoperability of hard- • formal models for the various software and hardware ware and software components by harmonizing the in- components, terfaces and as well as the communication and data ex- • reuse of designs, libraries, and architectural elements change between these components, between different robot applications, • to promote and moderate a community-wide discussion • methods and rules for the transformation of models be- on the identification, evaluation and refactoring of best tween levels of abstraction, practice in robotics algorithms and software systems • tools and tool chains which support the verification, through research camps, which will be organized and

968 hosted by BRICS and to which senior researchers and • identification of best practice in robot algorithms, soft- Ph.D. students from around the world will be invited, ware components, and architectures; • to survey and analyze completed robot application de- • design of an integrated robot development environment velopments with respect to their deficiencies in terms that supports rapid and flexible configuration of new of tool support, reuse of components, use of harmo- robot platforms and the development of sophisticated nized interfaces, and use of functional and model li- robot applications; braries, • cross-sectional activities addressing robust autonomy, • to define and implement showcases, which allow to openness and flexibility, and harmonization and study and measure the acceleration of the robot devel- benchmarking. opment process established by BRICS. 2.1 Development of two software packages

1.3 Related projects and activities BRICS develops and supports two complementary soft- The following projects and activities are related to BRICS: ware packages: BRIDE (BRics Integrated Development • DESIRE was a cooperative research project funded by Environment) and BROCRE (BRICS Open Code Reposi- the Federal Ministry of Education and Research in tory; pronounced ”broker“) . Germany [1]. The primary objective of DESIRE was to BRIDE will be based on the widely supported Eclipse plat- maintain and build on the leading role held by German form. Eclipse has already been accepted by many other researchers and industry in the field of service robotics. domains to serve as the integrating vehicle to make the de- The project partners involved in DESIRE could learn velopment of complex systems easier and to ensure higher valuable lessons as to design robot systems in a struc- quality. The software engineering methodology behind this tured way. is Model-Driven Engineering, which provides developers • RoSta (Robot Standards and Reference Architectures) with best practice models that (i) let developers design is the main international contact point for robot stan- with higher level, abstract components, (ii) hide the details dards and reference architectures in service robotics. of implementations and middleware, and (iii) support RoSta was a Coordination Action funded within the automatic verification and code generation, when appro- FP6 of the European Commission [2, 3]. priate. BRIDE could profit from Eclipse-based develop- • ROS is a new open source robotics framework devel- ments in the domains of embedded systems and the auto- oped in the United States by Willow Garage. Its objec- motive industry, if robotics-specific extensions are added. tive is to provide the software, and tools to cre- BROCRE offers interoperable interfaces and source code ate service robotics applications. Several BRICS part- components, that implement a lot of robotics functionality, ners are evaluating and using ROS to be part of their especially for the APIs defined in the project. BRICS will robotics systems [4]. provide an initial repository which will be usable and • OPRoS (Open Platform for Robotic Service) is a Ko- credible, but which will not cover all possible robotics rean initiative aiming at establishing a component ba- components. This initial repository is expected to convince sed standard software platform for robots which sup- other stakeholders of the advantages of using the BRICS ports reusability and compatibility in a heterogeneous methodology and software tools. Their involvement will communication network [5]. then result in a gradual extension of the framework. • OpenRTM is a Japanese initiative to implement the OMG's Robotics Technology Component standard. 2.2 Targeted user groups The BRICS project has invited core OpenRTM devel- The following user groups may benefit from the integrated opers to give feedback regarding the component model robot software development environment, the interoper- and the toolchain [6]. able robotics components, and the research platforms pro- • Orocos was started in 2001 and funded under European vided by BRICS: Fifth Framework Programme to give shape to an open • Robotics researchers can make use of hardware, which source framework for robotics, looking both at service comes with a consistent set of harmonized, docu- robotics and real-time robotics. BRICS project partners mented, public APIs and an integrated software devel- are using and evaluating Orocos to be part of their ro- opment environment. This enables researchers to de- botics systems [7]. velop complex operational robotic systems with mini- mal effort, to invest their resources in research rather 2 BRICS approach than in the development of research infrastructure, and to avoid so-called “from scratch developments”. To achieve its objectives, BRICS will cooperate with all • Hardware manufacturers can use the harmonized inter- interested stakeholders, in an open and constructively criti- face descriptions to make their hardware usable in the cal atmosphere, to develop a design methodology focusing software development environment without losing ac- on four fundamental issues: cess to advanced vendor-specific functionalities. • provision of hardware components with harmonized • System integrators – companies as well as research in- interfaces and open-source application programming stitutes – can utilize the development environment to interfaces (APIs); significantly accelerate the process of integrating com-

969 ponents into robotic systems and to speed up the devel- • for showcases to study, measure, and demonstrate the opment of software for advanced robotic applications. acceleration of the robot development process; • Software developers have access to a consistent set of • to provide interfaces for external collaborators. harmonized and openly available APIs for which they This effort focuses on the promotion of the interoperability can offer (commercial or open source) implementations of hardware and software components by harmonizing the that are directly usable via the integrated development interfaces and as well as the communication and data ex- environment. change between these components.

2.3 Reach out In the work plan of BRICS we have foreseen so-called re- search camps to reach out to the robotics developer com- munity. These research camps will be funded by the Euro- pean Commission and will be accessible to highly quali- fied Ph.D. students and senior researchers. The character of the research camps will be somewhere between summer schools and the renowned ACM programming contests. Research camps are meetings lasting between one and two weeks, where people gather to jointly do research and de- velop software. Other than a regular workshop, where Figure 2: Overview of some of the possible Robotics RTD people meet to discuss and exchange information, research Platforms (RRPs) to be used in the project (from left to camps have tangible results, e.g., a software library (con- right): KUKA omniRob, mobile base of BlueBotics, IPA tribution to BROCRE) for a specific robotics task. Care-O-Bot, BlueBotics Gilberto.

The following scientific and technical key issues will be 3 BRICS activities addressed in this activity: BRICS is performing Research and Technology Develop- • concepts for common Robotics RTD Platforms (RRP), ment (RTD) work in the following areas: which provide open access on different levels of ab- • hardware building blocks (see section 3.1) straction; • architectures, middleware, and interfaces (section 3.2) • communication of these concepts to European robotics • best practice in robot algorithms (section 3.3) stakeholders in order to analyze the requirements and • model-driven engineering and tool chain (section 3.4) possible access models for such research platforms; • openness and flexibility (section 3.5) • specification and adaptation of existing robotics hard- • robust autonomy (section 3.6) ware according to the agreed upon concepts to enable • harmonized interfaces (section 3.7) robust and autonomous use of it and to enable integra- The results from these activities are verified in showcases tion with other robotics components; with exemplary demonstrations (see section 4). For each • models of the hardware for easy configuration, simula- activity clear resposibilities have been defined (Figure 1). tion, and deployment of this hardware in the context of the BRICS Integrated Development Environment; • a comprehensive action plan to implement common Robotics RTD Platforms in a sustainable way as an in- Hardware strument for the European robotics community to more Model Driven Architecture easily conduct and benchmark research and perform Engineering Middleware based technology transfers. Interfaces Tool chain

Algorithms 3.2 Architectures, middleware, and inter- faces

s se a The objective of this activity is to identify complete robot c w o h S control architectures or architectural subsystems and pat-

Robust Autonomy Openness Flexibility Harmonisation terns, which are attractive for re-use by researchers and application developers. This activity will review and evaluate technologies and methods used in industries deal- Figure 1: BRICS activities, partners and responsibilities. ing with systems similar to robots (automotive, aviation, embedded systems development) and identify those tech- 3.1 Hardware building blocks nologies and methods from which robotics would benefit Based on an analysis of the hardware requirements in ro- strongly. Outreach to the community is essential for this botics research and industry the BRICS partners will select activity in order to guarantee that we capture all relevant Robotics RTD Platforms (RRPs) (Fig. 2) and components: technologies and both the extent and depth of the problems

970 involved. The following scientific and technical key issues The following scientific and technical key issues will be will be addressed in this activity: addressed in this activity: • Identification of best practice in architecture, middle- • harmonization of operational context and conditions for ware, and interfaces: Past research has produced many algorithms; good ideas, concepts, and even implementations for • specification and harmonization of performance re- subsystems or particular aspects of robotics software quirements; development. The problem is that most of this work is • definition of (a language for) abstraction levels and ge- not reusable. A first challenge of this activity is to neric descriptions of robot algorithms including de- make a thorough assessment of previous work and of scription of I/O behavior, module dependencies, timing the state-of-the-art. A second challenge is to define a and hardware dependencies; coherent set of evaluation criteria, with measures and • harmonization of data structures and external (and in- procedures for assessing them. ternal) models referred to by an algorithm; • Development of a software platform for robotics: The • harmonization of interfaces, and communication first challenge is to deal with the heterogeneity of mechanisms; hardware devices. This heterogeneity can be dealt with • analysis of real-time requirements; by harmonizing the interfaces to devices. A second • definition of test conditions, procedures and bench- challenge is to manage the complexities of communica- marks for comparative evaluation. tion and distributed systems. This is the core applica- To reach the goals of this activity five major contributions tion domain of middleware systems. Middleware for are planned: the robotics domain should provide special support for • The most important contribution is an approach for handling soft and hard real-time requirements, commu- identification and re-factoring of best practice robot al- nication facilities not supported by current middleware gorithms. This approach should be applicable to any (CAN-bus etc.), and for advanced failure detection and topic in robotics for which competitive and comparable failure handling capabilities to achieve robust auton- algorithms are developed. omy. The third challenge is to handle the heterogeneity • The approach will be applied to multiple application of the algorithmic approaches used in complex robotic contexts, resulting in software libraries of interchange- applications. This requires the harmonization of inter- able algorithms. During the runtime of the project a faces of different modules which provide functionality, minimum of three libraries will be compiled, among such as mapping, SLAM, path planning, etc., as well as them ‘mobile manipulation’, ‘3D perception and mod- the harmonization of data structures exchanged be- eling’, and ‘robust obstacle avoidance’. tween modules. The fourth challenge is to provide ap- • The approach will involve a comparative evaluation of propriate support for tool chain integration, on all lev- algorithms through benchmarks. els of the software platform, and both for the develop- • A series of research camps will be organized to reach ment environment as well as the runtime environment. out to the research community and to get feedback on • Development of functional/control architecture work- the developed methodology and framework and to as- bench for robotics: Designing and implementing suit- sure acceptance. able architectures remains a largely open problem. This challenge can be met by developing a 3.4 Model driven engineering and tool control architecture workbench for robotics, which chain should provide configurable blueprints for well-known This activity will focus on: robot control architectures, which have been re- • creating the Model-Driven Engineering models for ro- factored to exploit the robust, state-of-the-art software bust autonomy in robotic systems; technologies. The workbench should support re-use of • the integration of the BRICS best practice results in architectural patterns. these domains into the Eclipse tool chain; and • the integration of existing legacy Computer Aided En- 3.3 Best practice in robot algorithms gineering (CAE) tools into a BRICS Integrated Devel- Harmonizing robotics algorithms, so that they are easily opment Environment. replaceable by another, is often not viewed as a fundamen- The following scientific and technical key issues will be tal scientific problem, but a software engineering task. addressed: However, there are also a number of fundamental issues to • The BRICS Integrated Development Environment: It is address. The BRICS consortium wants to develop a planned to create a BRICS Integrated Development framework that can be applied to a large number of robotic Environment, which will be based on Eclipse, remain tasks and algorithms, and not only to one or two. The chal- fully compatible with the ongoing evolutions within the lenge is to make such a framework sustainable, so that it broader Eclipse ecosystem, but that will provide the accommodates not only existing algorithms, but also future robotics community with an Model-Driven Engineer- developments, and it is of upmost importance to make this ing (MDE) tool chain that contains the robotics domain framework really appealing to the robotics community. specific models and tools to build the BRICS Robotics RTD Platforms, components and interfaces. This chal-

971 lenge contains scientific as well as technical issues and 3.6 Robust autonomy challenges. Robust Autonomy (RA) is an ability of the system to react • The Model-Driven Engineering MDE models of robot- on both explicitly-specified adverse situations and unex- ics: At the scientific level, the main challenge is the pected adverse situations in both the environment and the identification of what MDE models are appropriate ab- underlying system (hardware and software) without or stractions of the complex, autonomous and robust with a limited human guidance in order to complete its multi-agent systems that are so typical for intelligent mission in the best possible (acceptable) way. The robust- robot systems, and that are not well supported by the ness of robot autonomy should be such that interactions ongoing activities in the other mentioned domains with the environment based on reasoning remain suffi- (automotive, aerospace, aviation, mobile telephony). ciently safe, accurate, etc. The only time when an autono- Technically speaking, the major challenges are to find mous robot can be provided with resources to achieve ro- appropriate granularities for the MDE models, and to bust autonomy is at design time. It is essential to have package and document them in a way that makes them structured robot development process as well as give ro- attractive for reuse and for co-development by all botic appliance all possible resources to ensure robust stakeholders in the robotics domain. autonomy of the final design. Therefore BRICS concen- • Integration of legacy tools: Being able to integrate al- trates on steps to be taken during the robot development ready existing models from popular CAE tools (such as process and on add-ons which will increase the robustness Simulink, 20Sim, etc.) will be a key factor for accep- of the resulting autonomous system. tance in the robotics community. Robot development should be structured in a way that re- veals decisions that affect non-functional requirements 3.5 Openness and flexibility such as robust autonomy. BRICS will come up with an on- The IEEE Standard Glossary of Software Engineering tology for robust autonomy from which a user (designer) Terminology [8] defines flexibility as the “ease with which can derive which criteria should be taken into account in a a system or component can be modified for use in applica- specific context. This will help the user to make decisions tions or environments other than those for which it was about the particular demands of the context at hand and to specifically designed”. The overall objective of this activ- limit the set of possible solutions. ity is to provide the conceptual and technological means Robust autonomy solutions could be viewed as features that will allow other work packages to develop and re- included in robot – resources that ensure operation. Utiliz- engineer open and flexible robotic software artifacts, to ing or introducing some type of redundancy into the sys- define metrics to assess their degree of openness and flexi- tem could achieve this. As an example let us consider a bility, and to define design principles and implementation model of the desired behavior. In the extreme case that the guidelines to improve them. The following scientific and system is described as a “black box”, so the model merely technical issues will be addressed: consist of its specifications, it is only possible to detect po- • How to predict the class of changes that are likely to tential failure, but not to resolve it. The more relations are occur over the lifespan of the software system? For this known between the specifications and the internal func- purpose, the following issues will be addressed: tions, the more options there are to adapt these functions o to identify requirements of a robotic system are when parts are failing, such that the specifications are met more likely to remain stable over time; according to the required level of quality (quality of ser- o to identify de facto standards which are enforced in vice), which in turn, can be used as a criterion for robust- the robotic domain; ness. o to analyze the kind of evolution that a robotic sys- To reach the goals of this activity the following contribu- tem undergoes. tions are planned: • How to assess the software quality of a robotic system • design principles, implementation guidelines, evalua- design? The main issue is to define appropriate quanti- tion criteria, and use case implementations for robust tative metrics. autonomy; • Is it possible to identify recurrent design problems and • collection of methods for achieving robust autonomy. define reusable design solutions (design patterns)? De- sign patterns let some aspects of system structure vary 3.7 Harmonized interfaces independently of other aspects, thereby making a sys- This cross-sectional activity starts from the observations tem more robust to a particular kind of change. that (i) complex robot control systems are built from many These challenges are approached as follows: components, coming from many different sources, and (ii) • identifying Best Practice in system flexibility and met- it is impossible (at least in the short to medium term) to rics to evaluate implementations; impose one single standard for these components. BRICS • assessing system flexibility of robotic software arti- will develop guide-lines, document them, and provide sug- facts; gestions to the community about how to implement har- • defining design principles, implementation guidelines, monized interfaces. The following scientific and technical and evaluation criteria for enhancing openness and key issues will be addressed: flexibility of best practice robotic software artifacts.

972 • Multiple levels of APIs: best practice for APIs will be including the developed repositories, frameworks, tools determined taking into account that this has to be done and methods) as proof of concepts, cyclic evaluations and at several levels: (i) the semantic interface of an API entry point for a wider dissemination and adoption of the has to be considered. A description of the functionality, RRPs into the robotics community beyond the project run- the objects and the results have to be in a computer- time. The scope of RRP configurations includes, but is not readable form. A clear semantic description may also limited to, a set of mobile platforms with one or two result fewer mistakes by the developers. (ii) The inter- handed arms, sensor configurations, and multi-modal inter- faces have to allow different technical approaches, for faces. Possible application domains, which are addressed example algorithms that optimize different aspects by the RRPs include robotics in manufacturing, particu- (time, complexity, quality of service, ...) and the infor- larly logistics, service or personal robotics, and rehabilita- mation about which solver is provided/needed is to be tion robotics. documented via the semantic interface. (iii) The inter- Acceptance of the RRP family depends mainly on its per- faces have to allow for various computing hardware formance, accessibility and cost. An RRP’s functionality and programming languages. has to be specified for the showcases and an RRP should • Appropriate decoupling: System developers will only meet the requirements: want to reuse each other's components if these compo- • safe operation, given everyday scenarios and distur- nents are easily understood and if the functionality they bance factors (lighting, clutteredness etc.); offer is what the developer is looking for. Tradeoffs be- • modular and scalable architecture/middleware for a tween functionality and size need to be analyzed. wide number of applications and experiments; • Integration in MDE ecosystems: Software systems in • documented interfaces, component performance (“data robotics need to be readied to be part of a large-scale sheets”) with responsive technical support; MDE system such as Eclipse. • use of state-of-the-art mechatronic components includ- The activity will approach these challenges as follows: ing validated simulation models; • Harmonization of hardware platform interfaces: The • compatibility with state-of-the-art operation systems, goal is to provide interfaces to robotics hardware that middleware(s), computer languages. are vendor independent, and that have appropriate lev- els of abstraction and granularity to serve different ap- 4.1 Showcase industry plication needs in the robotics community. The family of RRP itself forms the technological basis of • Harmonization of middleware interfaces: Here the right future robotic products for emerging markets: level of granularity and (de)coupling will be found to • mobile one or two-armed manipulators for tasks in make robotic middleware more open. manufacturing or laboratory , particularly in • Harmonization of algorithm interfaces: The functional- material flow automation and logistics; ity of software systems is mostly encoded in algo- • personal or domestic robots as helpers in everyday en- rithms. BRICS will work together with the community vironments (office, home, public spaces). to provide this functionality in a form that is harmo- The goal of the showcase industry is the implementation of nized and that is ready to be integrated in IDEs such as an RRP into a trial system development processes. Of par- Eclipse. ticular interest in this context is the application of the • Integration of harmonization guidelines in Tool chain: BRICS principles by today’s typical system integrators. BRICS hopes to contribute to the Eclipse ecosystem, For addressing specific needs and engineering cultures of via code and documentation contributions as well as both larger robotics suppliers and spin-off type small and through presentations at relevant MDE conferences to medium robotics industries two approaches are planned: ensure reusability of code is supported to an even • A prototype system of a mobile manipulation applica- grater extend. tion will be re-engineered on the basis of the BRICS results. Assessed differences regarding both develop- 4 Showcases ment processes regarding typical criteria such as reached performance, cost and time advantage, service- The activity Showcases for Industry, SME, Research, and ability etc. will be used as a measure for the BRICS Education will verify the results from the other activities RRP optimization. (as described in section 3) in showcases with exemplary • In regular assessment workshops teams of robotics en- demonstrations. These showcases shall act as vehicles for gineers apply the BRICS results in defined robotics de- assessing the suitability and performance of the BRICS velopment tasks. Systematic evaluation results of the hardware interoperability concepts, the BRICS integrated BRICS-based hardware, software, tools and engineer- robotic development environment, and methods in typical ing process will be used for directing and optimizing design processes of advanced specification, design, devel- the BRICS research and development. opment and optimization given the needs and interests of key user-groups (industry, research, education). 4.2 Showcase SME The goal of this activity is further to introduce and imple- ment a family of BRICS Robotics RTD Platforms (RRPs, The objective of this showcase is to show the efficiency gain and the reduction of development time in the context

973 of a robot application development for an end customer by in the project. This methodology has been applied to the using the BRICS integrated development environment. domain of mobile manipulation, being a mature, but still The development of robot applications for end customers highly active research area [9]. The first step consisted in is a typical activity of SME system integrators and bears exploring the state of the art in the domain itself, including significant potential for innovation. The SMEs involved in a thorough literature survey as well as the collection and BRICS will identify a typical application development ac- evaluation of existing software libraries and implementa- tivity for one of their (past, current, or future) customers, tions. Afterwards existing algorithms and libraries have which has been implemented or will be implemented. Then been analyzed concerning common structures, such as the SMEs will do a complete redesign of the identified ap- samplers, collision checkers, etc. Those sub-modules have plication development using the integrated development been identified and their interfaces harmonized in order to environments of the project and the harmonized hardware allow easy exchangeability. Based on the object-oriented and software interfaces. They will record the development library CoPP (Components for Path Planning) by Morten process, with all advantages and disadvantages and prob- Strandberg we refactored several probabilistic path plan- lems and advances, as neutral and detailed as possible. ning algorithms and integrated them into one library. This refactoring took place under a software engineering point 4.3 Showcase research of view, with the aim of providing a reusable and flexible The goal of the showcase “research” is the specification, component-based framework that is supposed to become provision and implementation of an RRP and its cyclic as- publicly available in spring 2010. sessment with expert members in robotics research: A proof of concept evaluation of the library has been al- • to provide access for the European researcher to RRPs ready undertaken by interfacing it to a newly developed in the context of different access-models, mobile , allowing the control of its base and • to implement the MDE tool chain and simulation infra- arm in a convenient way. In addition first sets of bench- structure and make it accessible as a complementary marks could be initiated, comparing mobile manipulation component to European research groups, and algorithms in varying scenarios. Ongoing work is to fur- • to set-up of a cooperative systems engineering projects ther enhance usability and the compatibility with existing between research teams and industry for developing a frameworks, thus opening up to the robotics community. specified industrially relevant robot assistant (see One major event in this respect will be the first BRICS re- showcase industry). search camp with the topic “Mobile Manipulation”. It will take place in Malaga, Spain, 24-29 October 2010. 20 ro- 4.4 Showcase education botics Ph.D. students worldwide with a solid background in mobile manipulation are invited to gather for one week Strengthening the supply of highly qualified robotics re- in a stimulating environment to explore, revise and im- searchers and engineers is essential for European robotics prove what are considered the best practice algorithms in research and industry. Thus, this showcase aims at provid- mobile manipulation today. The intended outcome of the ing access to state-of-the-art robotics research platforms research camp is an open source library of refactored and for higher education. An RRP is configured according to harmonized mobile manipulation algorithms. Travel the needs of an application scenario like mobile manipula- grants, hardware and initial set of software modules for tion. Costs will be kept low by using modular and config- mobile manipulation and 3D perception and modeling will urable robots, renting robots, or part-time accessing. A re- be provided. It is expected from the students that a com- pository of teaching material including tutorials, slide sets, petitive solution to two given tasks either using the pro- and problem sets to be used by instructors will be supplied. vided or self-developed algorithms for mobile manipula- With the tools and technology provided by the education tion is created and demonstrated in two competitions on showcase, teachers can acquaint their students in the class- the last day of the research camp. room with state-of-the-art technology. Furthermore, joint curricula can be developed between 5.2 BRICS component model programs of multiple universities in different countries. In order to harmonize algorithms and integrate them easily in robotic applications, a common software representation 5 First results of algorithms is required. The BRICS project is aiming to formalize the interface of algorithms and hardware such The BRICS project started March 1 st , 2009. Initial results that this integration can take place. The BRICS component include an in-depth analysis of existing robot development model defines this exact interface and allows algorithms processes, a first step towards harmonizing robot control defined in it, to be deployed to existing robotics software interfaces and component models and the set-up of robot frameworks. BRICS is building a tool chain that integrates system for best practice analyses. and coordinates the necessary steps to generate the code from user specifications. As such, the BRICS component 5.1 Best practice in mobile manipulation model only serves as a common language between these A first prototype of a general methodology for identifying tools. An Eclipse plug-in is under development that allows and providing best practice algorithms has been developed a graphical specification of a component or a system of

974 components. This Eclipse extension is tailored specifically external PC. When establishing a connection, the sampling towards robotics and aims to support robot application de- rate of the interface can be freely selected between 1 and velopers with the integration of their algorithms or hard- 100 ms. Motion commands which are issued more slowly ware into a real robotics system. than at millisecond intervals are preprocessed and interpo- The advantages of specifying applications as BRICS com- lated by the KUKA controller. As Ethernet UDP is used as ponents are: allowing to make a late decision on the target the connection technology, the interface can be ported to a platform or robotics framework; having a formal interface wide variety of operating systems and computers. description of a component which allows model validation; providing an always up-to-date graphical representation of a component or system of components. 6 Conclusions The BRICS component model is defined and defended by Harmonisation of academic research and technology de- a series of use cases that express a commonly experienced velopment is badly needed to create new products, to boost action when building a robotic system, e.g., processing new applications, and to accelerate innovation cycles. The sensor data, online parameter tuning or distributed com- EC funded project BRICS will enable robot manufacturers municating processes. Most modern robotic frameworks to collaborate more closely and effectively with academia support such features, making code generation towards and to benefit from top European research. Furthermore, such frameworks straightforward. The present version of system integrators will be able to utilize the developments the tool chain allows to embed algorithms in components to significantly accelerate the process of integrating com- and to specify data flows between these components in a ponents into robotic systems and to speed up the applica- single model, which is used to generate code for Orocos, tion development. The EC funded parts of the develop- ROS, and OpenRTM. ments through FP7 – BRICS (ICT-231940). 5.3 KUKA Fast Research Interface 7 Literature One goal of the project is to establish the KUKA Light- weight Robot (LWR) as a reference platform for research, [1] DESIRE Consortium: URL: www.service-robotik- in order to make results more comparable and to transfer initiative.de [last accessed on 22.03.2010]. them to industry. A further goal is the creation of a small- [2] RoSta Consortium: URL: www.robot-standards.eu scale controller to make it easier for users and system inte- [last accessed on 22.03.2010] grators to integrate the LWR as a component in their own [3] E. Prassler, H. Bruyninckx, K. Nilsson, A. Shakhi- system, e.g., as manipulator for a mobile platform. mardanov (2010): The Use of Reuse for Designing As a first step toward reaching this goal, a software inter- and Manufacturing Robots. White Paper, Version face was created (building on work from the PHRIENDS 0.9, 19 June 2009. URL: www.robot-standards.eu project [10]) to enable the robot behavior to be very pre- [last accessed on 22.03.2010] cisely monitored (e.g., position and torque measurement [4] ROS – Robot operating system, URL: www.ros.org data). Additionally, the robot can be remote-controlled at [last accessed 22.03.2010] different levels of autonomy (ranging from discrete events [5] B. Song, S. Jung, C. Jang, S. Kim (2008): An Intro- in KRL to quasi-continuous motion at millisecond inter- duction to Robot Component Model for OPRoS vals). The existing control processes of the robot can be (Open Platform for Robotic Services). Proceedings utilized for this purpose; the parameters (e.g., stiffness and of the Intern. Conf. on Simulation, Modeling and damping) can be set via the interface (Figure 3). Programming for Autonomous Robots (SIMPAR In a second step, this interface was completely integrated 2008), Venice, Italy, 3-4 Nov. 2008, pp. 592-603. into the KUKA LWR controller, and is now available to [6] OpenRTM-aist Official Web Site. URL: research partners as the “Fast Research Interface” (FRI) www.openrtm.org [last accessed on 23.03.2010] [11]. Based on a simple UDP protocol, the interface allows [7] The Orocos Project – Smarter control in R&A. URL: the user to control the robot and monitor its status from an www.orocos.org [last accessed on 22.03.2010]. [8] IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990 [9] E. Milke, S. Christen, W. Nowak, and E. Prassler. Towards harmonization and refactoring of mobile manipulation algorithms. Proc. Intern. Conf. on Ad- vanced Robotics (ICAR 2009), Munich, Germany. [10] PHRIENDS Consortium: URL: http://www. phriends.eu [last accessed on 23.11.2009]. [11] Schreiber, G.; Stemmer, A.; Bischoff, R. (2010): The Fast Research Interface for the KUKA Light- Figure 3: Overview of the Fast Research Interface (FRI) weight Robot. IEEE ICRA 2010 Workshop on Inno- control system architecture (for details see [11]). vative Robot Control Architectures for Demanding (Research) Applications. Anchorage, May 2010.

975