An overview on framework design for autonomous robots <s> Separation of concerns <s> To facilitate the writing of large maintainable distributed systems we need to separate out various concerns. We view these concerns as being communication, computation, configuration and coordination. We look at the coordination requirements of long running systems, paying particular attention to enabling the dynamic addition and removal of services. We show that the key to a smooth integration of configuration and coordination into systems is a new style of communication. We show how these ideas can be incorporated into the actor model. <s> BIB001 </s> An overview on framework design for autonomous robots <s> Separation of concerns <s> Because robotic systems get more complex all the time, developers around the world have, during the last decade, created component-based software frameworks (Orocos, Open-RTM, ROS, OPRoS, SmartSoft) to support the development and reuse of "large grained" pieces of robotics software. This paper introduces the BRICS Component Model (BCM) to provide robotics developers with a set of guidelines, metamodels and tools for structuring as much as possible the development of, both, individual components and component-based architectures, using one or more of the aforementioned software frameworks at the same time, without introducing any framework- or application-specific details. The BCM is built upon two complementary paradigms: the "5Cs" (separation of concerns between the development aspects of Computation, Communication, Coordination, Configuration and Composition) and the meta-modeling approach from Model-Driven Engineering. <s> BIB002 </s> An overview on framework design for autonomous robots <s> Separation of concerns <s> Communication between software components is one of the most important functionalities a software framework for modern complex robotic systems has to provide. Here, we present the highly performant realtime communication layer of our new robotic software framework aRDx (agile robot development - next generation), with, e.g., zero-copy semantics, realtime determinism and detailed control of the QoS (quality of service). In addition, we give an in-depth performance comparison to other popular robotic frameworks, namely ROS, YARP, Orocos and aRD. <s> BIB003 </s> An overview on framework design for autonomous robots <s> Separation of concerns <s> The authors are part of a research group that had the opportunity (i) to develop a large software framework (±5 person year effort), (ii) to use that framework (“iTaSC”) on several dozen research applications in the context of the specification and execution of a wide spectrum of mobile manipulator tasks, (iii) to analyse not only the functionality and the performance of the software but also its readiness for reuse, composition and model-driven code generation, and, finally, (iv) to spend another 5 person years on re-design and refactoring. This paper presents our major lessons learned, in the form of two best practices that we identified, and are since then bringing into practice in any new software development: (i) the 5C meta model to realise separation of concerns (the concerns being Communication, Computation, Coordination, Configuration, and Composition), and (ii) the Composition Pattern as an architectural meta model supporting the methodological coupling of components developed along the lines of the 5Cs. These generic results are illustrated, grounded and motivated by what we learned from the huge efforts to refactor the iTaSC software, and are now behind all our other software development efforts, without any exception. In the concrete iTaSC case, the Composition Pattern is applied at three levels of (modelling) hierarchy: application, iTaSC, and task level, each of which consist itself of several components structured in conformance with the pattern. <s> BIB004 </s> An overview on framework design for autonomous robots <s> Separation of concerns <s> Engineering complex robot control systems typically suffers from a ma- jor break in development process between different platforms - powerful computers running an operating systems and bare metal embedded computing nodes. This work presents an approach to close this gap by running an existing state-of-the-art software framework with only minor modifications on all platforms. In this context, we discuss relevant design principles of robotic frameworks and validate their importance. <s> BIB005
As system complexity and maintainability are challenges in robotics, separation of concerns is an important design principle. In this context, the Orocos and BRICS authors propose the "5C Model" as a best practice for robotic software development BIB002 BIB004 -keeping the 5 concerns Communication, Computation, Coordination, Configuration, and Composition fully separated in design and implementation. It is a variation of the "4C Model" originally introduced by Radestock et al. BIB001 -as Schlegel et al. explain in an introduction to these topics  . Having encountered maintainability issues, Makarenko et al.  discuss this topic regarding the Orca 2 framework and propose a clear separation of concerns with respect to (1) Driver and Algorithm Implementations,  Communication Middleware, and the (3) Robotic Software Framework. This good practice of separating framework-independent code from frameworkdependent code is increasingly promoted   . Not being tied to any framework, libraries such as OpenCV or the Point Cloud Library are (re)used in research institutions around the world. Furthermore, code complexity and maintainability are correlated. Simple, independent artifacts with compact source code require less maintenance effort and are less likely to contain programming errors. Makarenko et al.  discuss the many benefits of frameworks having a slim and clearly structured code base -especially regarding development and maintainability of a framework itself. Some authors explicitly target minimalism BIB003 or a microkernel design  . A clear separation of concerns is beneficial with respect to virtually all evolution qualities of software systems -maintainability in particular. Reusability and portability of software artifacts are also increased significantly. In consequence, Finroc was implemented in a slim and highly modular way  . As illustrated in Figure 5 , it consists of many small software entities. rrlibs are framework-independent libraries. Functionality that is not needed in every application is generally implemented in optional plugins. This way, Finroc can be tailored to the requirements of an application. Notably, slim configurations can run without an operating system BIB005 . Plugins can contain almost anything, including communication port types (data_ports, rpc_ports, blackboard), component types (structure, ib2c), network transports (tcp, ros), or support for DSLs (urbiscript). With only communication plugins, Finroc could be configured as a plain middleware.