# Robot Operating System 2 (ROS2)-Based Frameworks for Increasing Robot Autonomy: A Survey
## 2 Related Work
### ROS2: Origin and Performance Analysis  
To overcome the limitations of ROS and meet the needs of both the industry and the broader ROS community by providing features such as higher efficiency, reliability, security, and real-time processing, after an initial announcement in 2014, in 2018 Open Robotics released ROS2 [11; 22], the second generation of ROS. Given the intrusive nature of the changes required to achieve these benefits, in order to keep ROS working and to be unaffected by the new developments, the ROS community decided to redesign the middleware from scratch. One of the most significant changes in ROS2 is the switch from the TCP/UDP network protocol used in ROS to DDS (Data Distribution Service) as the default middleware for communication between nodes. DDS is an industry standard published by the Object Management Group (OMG) [23] that defines a middleware for real-time and reliable data distribution according to the publish/subscribe paradigm, thus enabling ROS2 to meet the safety, security, resilience, and fault-tolerant of distributed systems. Specifically, ROS2 is compatible with multiple DDS vendors (e.g., the default eProsima [24], RTI [25], OpenDDS [26], ADLINK [27], and others). An early study exploring the performance of ROS2 was conducted by [PERSON] et al. [28] and dates back to 2016. The authors conducted proof-of-concept experiments to clarify the capabilities of ROS2 and evaluated the performance characteristics of DDS [29; 30] in ROS2 in various situations and for different aspects: latency, throughput, number of threads, and memory consumption. The performance of DDS was further analyzed in [31], showing that it can be used in some classes of industrial control systems. In more recent years, numerous research papers have been devoted to the evaluation of ROS2 performance related to various aspects: DDS, security, and distributed robotic systems. Without claiming to be exhaustive (a mapping of software engineering research on ROS can be found in [32]), several attempts to clarify DDS issues can be found in [33], which conducted analyses on ROS2 and several DDS providers. The authors of [34] evaluated the response time of processing chains in ROS2, and a latency analysis of ROS2 was provided in [35]. More recently, in [36], the authors presented an experimental evaluation of the execution of ROS2's smallest schedulable entities, namely callbacks. They identified and showed the differences in callback execution using different executor versions (i.e., the ROS2 callback scheduler) and illustrate the negative impact of the new executor on the periodic execution of timer callbacks with a real-world use-case on a multi-agent robotic system. Distributed robotic systems were addressed in [37; 38], which evaluated real-time ROS2 characteristics for multi-agent robotic systems and control performance in time-synchronized distributed networks, respectively. In the same domain, the network performance of ROS2 under varying QoS (quality of service) profiles and security settings was studied in [39]. Finally, some works related to the security issues of ROS2 can be found in [40; 41; 42]. As addressed in [43; 44], finding a trade-off between performance and security is not an easy task. Most of these evaluations conclude that an ROS2-based architecture, if properly developed, can satisfy the real-time constraints that are often required in industrial applications to meet safety and/or performance goals, unlike the previous ROS version. This is made possible, at a communication level, by employing DDS that guarantees more stable communications with lower message loss and mainly lower communication latency in both an idle network environment and with network traffic. In order to meet the constraints of real time as a whole, the communication level alone is not sufficient; however, ROS2 exhibits real-time performance even in the development environment by supporting RTOS(Real-Time Operating System) such as the Linux kernel patched with PREEMPT_RT.