# Robot Operating System 2 (ROS2)-Based Frameworks for Increasing Robot Autonomy: A Survey
## 4 ROS2-Based Architecture for Enhancing Cobot Autonomy: Current Capabilities and Limitations  
Implementation of the modular architecture described above requires the use of middleware to easily integrate heterogeneous hardware (e.g., different sensors, robots, and end-effectors), as well as heterogeneous software components (e.g., those needed to accomplish individual tasks). For this purpose, several open-source robotic frameworks are available as alternatives to ROS, such as YARP (Yet Another Robot Platform) [87] for humanoid robots, OROCOS (Open Robot Control Software) [88] originally applied to both robots and drones [89,90], and MOOS (Mission Oriented Operating Suite) [91], applied to the domains of mobile robotics and marine vehicles; an overview of the frameworks can be found in [92]. Each of them has its own characteristics that make it more or less suitable for specific types of applications. For example, MOOS was originally developed to support operations with autonomous marine vehicles and continues to be primarily utilized in the field of marine robotics. OROCOS was created before ROS as a general-purpose framework for advanced machine and robot control, and it was the go-to framework when real-time requirements were in place until the development of ROS2. YARP is another framework older than ROS that has been mainly used in the domain of humanoid robots where skills such as visual, auditory, and tactile perception and legged locomotion are central, whereas ROS has a higher focus on mobile robots and provides more tools on navigation and planning. Moreover, even if both of them are under active development and provide features for general-purpose robots, ROS supports more robots and remains the most widely used framework among all of them. As a result, ROS, and in particular ROS2, is proposed as the most suitable middleware to implement the framework described in Section 3 not only because of its spread, but also because it provides the features previously described in Section 2, such as the structured communication layer and hardware abstraction, along with libraries, tools, and utilities that implement state-of-the-art algorithms and facilitate functionality (e.g., visualization and debugging) useful to rapidly build robotic applications. This choice is also motivated by the large and active ROS community that contributes to its development and maintenance, as well as to the creation and distribution of packages and resources solving classical problems encountered in robotics applications, including some of those that the proposed architecture aims to address. The disadvantage of this choice lies in the fact that ROS2 is relatively recent (the first Ardent distribution was released in 2017). It has not yet fully replaced its previous version (to which henceforth we will refer as ROS1 for clarity, using instead ROS to indicate the middleware in general and regardless of the specific version), and new applications are still being developed in ROS1 because the migration of all the components implemented in ROS1 to ROS2 is ongoing and documentation about it is still lacking. This section is devoted to analyzing how ROS2 can be used to develop the proposed general high-level architecture, showing what is currently implemented and available in ROS2 for the development of each layer and task and what their potential limitations are, with an emphasis on similarities and differences from ROS1. The general idea is to have a single ROS2 application, in which each module in Figure 3 is implemented by one or more nodes grouped in one or more packages and communicates with others using the standard communication mechanisms provided by ROS. Specifically, each module exposes as an interface a set of ROS topics, services, and/or actions to offer information and/or functionality to other modules and to gather the necessary data and/or request services from other modules. In the following, each module is analyzed independently while also dealing with its interfaces exposed to the rest of the ROS application.