# 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
### Perception  
This module is responsible for gathering from the robot and other external sensors the raw data needed to know the state of the robot and its surroundings. As for the data to be acquired directly from the robot, manufacturers usually allow access to the robot's state, but there is no standard either on the type of information accessed or the interfaces exposed; they often provide more than one way to obtain the same data. For example, in the aforementioned OMRON Technman TM-series cobot, variables such as joint angles, speeds and torques, or TCP pose, can be read either using the Modbus protocol [94], accessing dedicated registers, or by connecting to a dedicated TCP socket server (i.e., _Ethernet Slave_) that allows clients to read the variables specified by the programmer in the dedicated _Data Table_ and use them for different purposes. For example, in [95], it was used to perform cobot fault detection by applying signal-based diagnosis [96], while in [97] it was used for anomaly detection of abnormal cobot behavior. On the other hand, the same cobot does not make the data from the integrated eye-in-hand RGB camera accessible from the outside. As a result, generally, the acquisition of the robot's state cannot be entrusted to standard ROS packages, and this submodule of the perception task must be handled by a specific low-level module that serves as the cobot driver, the same module that is also responsible for sending commands to the physical robot and that will be used in the Section 4.5. Apart from this hardware-specific part, which is not necessary when working in simulation, ROS2 provides tools for managing and using the robot's state that is essentially unchanged from ROS1. While the use of this information will be addressed in later modules, for the perception task only, the only aspect to highlight is the need to have an _/joint_states_ topic, which is the standard ROS interface for publishing the current state of the robot (real or simulated) [98]. This is an ROS channel where standard _sensor_msgs/msg/JointState_ messages are sent containing the state of a set of joints (rotating or prismatic) in terms of position, velocity, and torques applied to the joint. This real-time information, combined with the prior knowledge of the physical parameters of the robot (i.e., dimensional, geometric, kinematic, and dynamic parameters) provided to ROS with the unified robot description format (URDF) [99], is all that is needed to have complete information of the robot's state in terms of pose, as will be shown in the recognition module. In summary, the only thing to be handled in this module, as far as this first part of perception is concerned, is to ensure the publication of the subject _/joint_states_. The publisher should be the robot driver of a real manipulator or the simulator (e.g., Gazebo [100]) in a simulation scenario. Regarding the perception entrusted to additional external sensors, the same concept applies, with ROS/ROS2 providing standard interfaces that must be implemented by the low-level modules handling real/simulated sensors. Again, sensors from different manufacturers, even more if of different types, require hardware-specific drivers that can be already available (sometimes provided by the same vendors) or to be developed. Despite the specific implementation, what should be standard in order to exploit existing ROS functionality are the topics where sensor data are published or rather their message types. In ROS2, this is ported from ROS1. _sensor_msgs_ is a standard ROS package containing the definition of many messages relating to sensor devices such as cameras, inertial measurement units (IMUs), and laser range-finders [101]. For example, for an RGB camera, there is _sensor_msgs/msg/Image_, a message type intended to contain an uncompressed image with a header with fields such as timestamp, _frame_id_ of the camera, image dimensions in pixels and encoding (e.g., _rgb8_), and a body that is the actual data matrix.