An overview on framework design for autonomous robots <s> Component interfaces <s> We seek to make robot programming more efficient by developing a standard abstract interface for robot hardware, based on familiar techniques from operating systems and network engineering. This paper describes the application of three well known abstractions, the character device model, the interface/driver model, and the client/server model to this purpose. These abstractions underlie Player/Stage, our open source project for rapid development of robot control systems. One product of this project is the Player Abstract Device Interface (PADI) specification, which defines a set of interfaces that capture the functionality of logically similar sensors and actuators. This specification is the central abstraction that enables Player-based controllers to run unchanged on a variety of real and simulated devices. We propose that PADI could be a starting point for development of a standard platform for robot interfacing, independent of Player, to enable code portability and re-use, while still providing access to the unique capabilities of individual devices. <s> BIB001 </s> An overview on framework design for autonomous robots <s> Component interfaces <s> A component is a reusable and replaceable software module accessed through its interface. Component-based development is expected to shorten the development period, reduce maintenance costs, and improve program reusability and the interoperability of components. This paper proposes a new robot software component platform in order to support the entire process of robot software development. It consists of specifications of a component model, component authoring tool, component composer, and component execution engine. To show its feasibility, this paper presents the analysis results of the component’s communication overhead, a comparison with other robotic software platforms, and applications in commercial robots. <s> BIB002 </s> An overview on framework design for autonomous robots <s> Component interfaces <s> The idea of component-based software engineering was proposed more that 40 years ago, yet only few robotics software frameworks follow these ideas. The main problem with robotics software usually is that it runs on a particular platform and transferring source code to another platform is crucial. In this paper, we present our software framework Fawkes which follows the component-based software design paradigm by featuring a clear component concept with well-defined communication interfaces. We deployed Fawkes on several different robot platforms ranging from service robots to biped soccer robots. Following the component concept with clearly defined communication interfaces shows great benefit when porting robot software from one robot to the other. Fawkes comes with a number of useful plugins for tasks like timing, logging, data visualization, software configuration, and even high-level decision making. These make it particularly easy to create and to debug productive code, shortening the typical development cycle for robot software. <s> BIB003 </s> An overview on framework design for autonomous robots <s> Component interfaces <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
Component interfaces typically consist of a set of communication endpoints called ports. There are two major types of such ports: data flow and service ports. Most frameworks support both. Data flow ports publish and consume data -either directly connected forming data flow graphs (point-to-point), or indirectly communicating via topics. ROS  is well-known for the latter. Joyeux et al. discuss advantages of the former  . Service ports provide and use interfaces with remote procedure calls or synchronous transactions -as known from web services or CORBA. Some authors propose to explicitly separate data flow from events BIB004 . OPRoS BIB002 , for instance, has additional port types for events. Other frameworks including mca2 and FAWKES BIB003 provide native support for blackboards -network-transparent shared memory. Data flow graphs are simple and a natural fit especially for lower-level control loops. Designing interfaces based on data ports is typically straightforward. However, for complex interaction patterns, data flow is not appropriate. Supporting only services, on the other hand, can lead to many marginally different, incompatible interfaces, which hinders reuse. The developers of the Player Project discuss this difficulty BIB001 and the necessity of introducing standard interfaces. The numerous data types used in ROS show that this problem can also occur with data ports. Depending on the framework, data ports differ in supported communication patterns. Common patterns are what Schlegel et al.  call "push newest" and "push timed" in SmartSoft. The former corresponds to subscrip-tion types "New" and "Flush" in OpenRTM-aist, the latter to "Periodic". Many frameworks support (only) one of these patterns. -"Push timed" pushes data at a fixed rate. This behavior is typically expected from e. g. ROS nodes. -"Push newest" pushes new data to subscribers as soon as it is available. As different components might access ports at different rates, most frameworks provide optional FIFO buffers for this pattern. SmartSoft furthermore supports "send" (one-way communication), "query" (two-way request) and "event" (asynchronous notification)  . Instead of providing separate port types for services, these patterns are used. Design decisions on component interfaces influence the flexibility of a framework and its ease of use. A lack of suitable interface patterns for certain use cases leads to workarounds that are detrimental to maintainability and possibly also to performance of systems. In Finroc, port types are provided by optional plugins. Currently, there are plugins for data ports, service ports and blackboards. Data ports support switching between push (newest) and pull strategy at runtime. The latter corresponds to "query" in SmartSoft.