An overview on framework design for autonomous robots <s> Implementation <s> Developing reusable robotic software is particularly difficult because there is no universally agreed upon definition of what a robot is. Over the past half-century, robots took many forms. Some were inspired by their biological counterparts such as humanoids, dogs, snakes, and spiders. Others were designed for particular domains such as manufacturing, medical, service, military, or space applications. They took the form of arms, wheeled robots, legged robots, hoppers, blimps, underwater vehicles, sub-surface diggers, and even reconfigurable robots. <s> BIB001 </s> An overview on framework design for autonomous robots <s> Implementation <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> BIB002
In the mobile robotics domain, software performance is a critical factor -as this determines required computing resources and battery power. Regarding frameworks, a key issue is sharing data among connected software components and threads. As Nesnas BIB001 points out, "an application framework must pay particular attention to avoiding unnecessary copying of data [...]". Components can be located in the same process (intra-process), on the same computing node (inter-process), or on different computing nodes (inter-host). Efficiency also influences latency and scalability -imposing limits on the maximum number of components that are feasible (see Section 2.1.3). Locking can be an even bigger issue with respect to latency and scalability. Lock-ing buffers exclusively from different components quickly causes significant, varying delays. Support for meeting hard real-time requirements in component interaction is another important feature -especially for low-level control loops and safety-critical systems. Not being limited to a single component for real-time tasks increases reusability -e. g. with separate components for accessing sensors and actuators in control loops. Several frameworks support this, including OpenRTMaist, Orocos, OPRoS, SmartSoft, GenoM3, aRDx and mca2. For real-time implementations, unboundedly varying delays must be avoided. Lock-free implementations are advantageous in this respect. Zero-copy transport mechanisms, typically use either ring buffers or pools of buffers with reference counters. The former is simpler to implement, while the latter is more flexible. Hammer et al. BIB002 present an efficient implementation based on ring-buffers that is zerocopying even for inter-process communication. In  , we explain Finroc's efficient, lock-free, zero-copy intraprocess transport based on buffer pools. Due to the modular application style, using a framework induces computational overhead compared to a perfectly engineered monolithic solution. However, modern frameworks show that computational overhead can be low, despite a relatively loose coupling. In practice, as soon as it comes to buffer management or multithreading, we often observe that framework-based solutions actually outperform custom standalone code -sometimes drastically. This is due the fact that efficient, lock-free buffer management is complex to implement. High bandwidth, low latency, low computational overhead, robustness, and support for quality of service (QoS) are desirable attributes of a network transport used for distributed robotic systems. Interoperability and security can be further requirements. As discussed in Section 2.1, several frameworks are independent from a specific networktransport. This is beneficial with respect to varying requirements of applications. Regarding the primary transport mechanism, some frameworks rely on custom TCPbased implementations tailored to their requirements. This includes ROS, Player and mca2. Others rely on professional middleware packets based on standards such as CORBA or DDS¹¹. ICE is a popular middleware product not based on these standards. OpenRTM-aist, Orocos, OPRoS and SmartSoft are frameworks with a CORBA implementation, for instance. Several frameworks are interoperable 11 http://portals.omg.org/dds with ROS -including Finroc. Notably, some transportindependent frameworks such as Orocos and GenoM3 can use the ROS transport for all components.