Robot communication state detection system and method based on network packet analysis

Abstract

The invention discloses a robot communication state detection system and method based on network packet analysis, and belongs to the technical field of Linux system middleware. The invention aims to solve the problems of high resource consumption, coarse monitoring granularity, poor real-time performance, lack of universality and the like of an existing robot operating system (ROS2) communication monitoring tool. The system captures and deeply analyzes an RTPS network message of a bottom DDS in a non-intrusive mode, realizes accurate calculation of state indexes such as frequency and bandwidth of a communication link between a specified publisher and a subscriber, and is internally provided with logic to be compatible with various DDSs. The method has the advantages of being fine in monitoring granularity, high in real-time performance, extremely low in system resource overhead and high in universality, and the stability and maintainability of a robot system are improved by rapidly detecting communication abnormity.

Description

Technical Field

[0001] This invention relates to the field of computer middleware technology, and in particular to a system and method for real-time detection of the communication status of a robot operating system (ROS2) in a Linux system environment. Background Technology

[0002] Robot Operating System 2 (ROS2) is a widely used software development framework in the field of robotics. To meet the real-time, reliability, and distributed communication requirements of modern robot systems, ROS2 employs Data Distribution Service (DDS) as its underlying communication middleware. DDS is based on a publish-subscribe model, allowing different nodes in the system to communicate efficiently through topics, services, and other methods.

[0003] However, as robot systems become increasingly large and complex, their communication networks also become more intricate, leading to more prominent communication problems such as message loss, network connection interruptions, and Quality of Service (QoS) mismatches. These problems are often difficult to detect in real time, but they can severely impact the normal operation of robots and even cause system failure.

[0004] Currently, there are several technical solutions in the industry for monitoring the communication status of ROS2:

[0005] 1. ROS2 comes with command-line tools such as ros2topichz or ros2topicbw, which can be used to view the posting frequency and bandwidth of specific topics. However, these tools have a coarse-grained monitoring capability, only providing topic-level aggregated information and failing to delve into the link status between specific publishers and subscribers. More importantly, when monitoring a large number of topics, a separate subscription process must be started for each topic, which establishes a large number of DDS connections, consuming extremely high CPU and memory resources. In one test, using this method to monitor multiple topics resulted in a total CPU utilization of approximately 14%.

[0006] 2. Tracing and Log Analysis Tools: Tools such as ros2trace combined with LTTng (LinuxTraceToolkit next generation) can record function calls within the ROS2 system for offline analysis afterward. The drawback of this approach is its poor real-time performance, making it unsuitable for online, real-time fault detection and early warning.

[0007] 3. Vendor-specific monitoring tools for DDS: For example, eProsima's FastDDSMonitor can provide detailed communication status of its own DDS implementation. The main limitation of these tools is their vendor-locked nature, making them incompatible with other mainstream DDS implementations (such as CycloneDDS, RTIConnext, etc.) and lacking versatility.

[0008] In summary, existing technologies generally suffer from technical problems such as insufficient monitoring granularity, excessive system resource consumption, poor real-time performance, and lack of universality for cross-DDS implementation. Summary of the Invention

[0009] The present invention aims to address the aforementioned deficiencies in the prior art and provide a system and method capable of real-time, fine-grained, low-overhead, and universal monitoring of the communication status of the ROS2 system across DDS platforms.

[0010] To achieve the above objectives, this invention provides a robot communication status detection system based on network packet analysis. The system includes: a network packet capture module configured to non-intrusively monitor the network environment of the ROS2 and capture RTPS network packets in real time; a packet parsing module connected to the network packet capture module, configured to perform protocol-level parsing on the captured packets to extract key fields such as publisher entity identifier, subscriber entity identifier, and topic name, and calculate status indicators such as topic frequency or bandwidth for each communication link based on these fields. This module is also configured to adapt to packet format differences between at least two different DDS vendors; and a communication status output module connected to the packet parsing module, configured to structure the calculated communication status indicators and publish them externally.

[0011] The present invention also provides a robot communication state detection method based on network packet analysis, the method comprising the following steps: a message capture step, a message parsing step, a state calculation step, and a state output step.

[0012] Compared with the prior art, the present invention has the following beneficial effects:

[0013] 1. Real-time, fine-grained monitoring is achieved: By directly parsing the underlying DDS messages, the communication link status between a specific publisher and subscriber can be accurately monitored, greatly improving the transparency of the communication status and the accuracy of diagnosis.

[0014] 2. Extremely low system resource overhead: Employing non-intrusive passive network sniffing technology, it eliminates the need to establish a DDS connection, thus avoiding performance burden on the original system. Tests show that the CPU utilization of this invention is approximately 70% lower than that of the traditional ros2 topic hz command method.

[0015] 3. Versatility and high flexibility: By designing compatible logic at the parsing layer, it can support multiple mainstream DDS implementations, reducing deployment and maintenance costs and enhancing the applicability of the tool.

[0016] 4. Improved system stability and maintainability: It can quickly detect communication anomalies, ensuring the stable operation of the robot system, while providing lightweight, easy-to-integrate modules and a user-friendly visual interface, simplifying the operation and maintenance process. Attached Figure Description

[0017] To more clearly illustrate the embodiments of the present invention, a description will be given below in conjunction with the accompanying drawings, wherein:

[0018] Figure 1 This is a system architecture block diagram of one embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of the RTPS message parsing process in one embodiment of the present invention. Detailed Implementation

[0020] The technical solution of the present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be understood that the description herein is merely exemplary and is not intended to limit the scope of protection of the present invention.

[0021] Example 1: System Architecture and Working Principle. (Refer to...) Figure 1 This embodiment provides a robot communication status detection system based on network packet analysis. The system is logically implemented as two independent processes: a DDS message parsing process (107) and a DDS communication status terminal display process (108).

[0022] The DDS message parsing process (107) mainly includes the following modules:

[0023] Network packet capture module (103): This module is responsible for performing non-intrusive data collection. In this embodiment, it calls the industry-standard libpcap library (102) to capture all network packets flowing through a specified network interface (such as eth0 or any) in real time. By setting filters (e.g., filtering specific ports used by the UDP protocol and DDS / RTPS), this module can precisely capture only packets related to the RTPS protocol.

[0024] Message parsing module (101): This module receives the raw RTPS message from the network message capture module (103) and performs deep parsing to extract structured communication state information, such as identifying all active DDS entities (publishers and subscribers) in the system, as well as the topic names, transmission frequencies, and packet sizes of their communication.

[0025] After parsing is complete, the DDS message parsing process (107) will encapsulate these structured communication status information into a custom ROS2 message and publish it to the outside world through a dedicated DDS topic (e.g., / dds_network_status).

[0026] The DDS communication status terminal display process (108), acting as a client, primarily subscribes to communication status topics published by the DDS message parsing process (107). Upon receiving a new status message, the DDSDisplay module (104) within this process processes the data, which is then displayed by the TerminalScreen module (106). In this embodiment, to provide a lightweight interface, the process uses the libftxui library (105) to construct a dynamically refreshed list in text format on the terminal, clearly displaying the key indicators of each communication link to the user.

[0027] Example 2: RTPS Protocol Parsing and Cross-DDS Compatibility. (Refer to...) Figure 2 The workflow of the message parsing module (101) is as follows:

[0028] First, the RTPS data frame capture step (201) is executed, and then the preliminary parsing step (202) is executed to record basic information such as the source port, destination port and entity globally unique identifier (GUID).

[0029] Next, the sub-messages are categorized and processed according to their IDs, mainly including the processing of the INFO_TS sub-message (203), INFO_DST sub-message (204), DATA sub-message (205), and DATA_FRAG sub-message (206). Specifically, in step (207), the message timestamp provided by the INFO_TS sub-message (203) is recorded, which can be used to calculate the frequency and delay. In step (208), the target GUID provided by the INFO_DST sub-message (204) is recorded for precise matching of the receiver. The DATA sub-message (205) and DATA_FRAG sub-message (206) carry the actual user data or its fragments and are the core of the analysis.

[0030] In step (209), the parser distinguishes different DATA subtypes based on fields such as readerId and writerId within the DATA sub-message (205). For example, in step (211), the write message Data(w) representing the publisher (Writer) is processed; in step (212), the read message Data(r) representing the subscriber (Reader) is processed; and in step (213), the discovery or parameter message Data(p) related to the DDS participant (Participant) is processed. By continuously tracking this information, the parser can construct a complete picture of all DDS entities in the network and their subscription / publishing relationships.

[0031] To avoid packet loss due to time-consuming synchronous parsing under high network load, this embodiment adopts an asynchronous processing mechanism. As shown in step (219), the parser puts the key information extracted from the processing steps (215) to (218) into a queue. At the same time, an independent worker thread reads data from the queue (219) to perform state calculations, and publishes the results through the DDS topic in the final processing and publishing step (220).

[0032] In addition, the message parsing module (101) has built-in compatibility processing logic for the differences in RTPS protocols implemented by different DDS vendors. For example, it can identify the vendor ID in the message (step 61) and, based on the identified vendor, adopt the corresponding parsing strategy to correctly adapt and parse the GUID structure (step 62), while normalizing the built-in topic naming methods of different DDS (step 63).

[0033] Example 3: Performance and Anomaly Detection. The non-intrusive architecture of this invention brings significant performance advantages. In a test environment running the navigation2 mapping routine, after starting the message analysis tool of this invention, its CPU utilization stabilized at around 4.0%. In contrast, if the ROS2 built-in ros2 topic hz command is used to monitor all major topics, the total CPU utilization reaches approximately 14%.

[0034] In addition, this system may include a communication status assessment and anomaly detection module, configured to perform real-time assessment of the calculated communication status indicators according to preset rules. This module can implement the following anomaly detection logic:

[0035] When the real-time frequency of a topic fluctuates more than the nominal frequency by a preset first threshold (e.g., 10%), the system can highlight it or issue an alarm.

[0036] When the calculated packet loss rate (which can be estimated by comparing sequence numbers) exceeds a preset second threshold (e.g., 1%), it is determined to be a communication anomaly.

[0037] In summary, this invention provides a powerful, high-performance, and easy-to-use ROS2 communication status detection tool, effectively solving many pain points of existing technologies.

Claims

1. A robot communication state detection system based on network packet analysis, characterized in that, The system includes: a network packet capture module configured to non-intrusively monitor one or more network interfaces in the network environment where the Robot Operating System (ROS2) is located, and capture network packets of the Real-Time Publish-Subscribe Protocol (RTPS) used by the Data Distribution Service (DDS) in real time; A message parsing module, connected to the network message capture module, is configured as follows: The captured RTPS network packets are parsed at the protocol layer to extract multiple key fields that characterize the communication link state. These key fields include at least the publisher entity identifier, the subscriber entity identifier, and the topic name. Based on the key fields, for each communication link consisting of a specific publisher entity and a specific subscriber entity, at least one communication status indicator is calculated, including topic frequency or bandwidth. The message parsing module is also configured to adapt to the differences in RTPS message formats implemented by at least two different DDS vendors; A communication status output module, connected to the message parsing module, is configured to perform structured processing on the communication status indicators and publish them externally for monitoring.

2. The robot communication state detection system based on network packet analysis according to claim 1, characterized in that, The network packet capture module uses the libpcap library to capture and filter RTPS network packets.

3. The robot communication state detection system based on network packet analysis according to claim 1, characterized in that, The message parsing module extracts the key fields by parsing RTPS sub-messages. The sub-messages include at least one of the following types: INFO_TS timestamp sub-message, INFO_DST destination address sub-message, DATA data sub-message, or DATA_FRAG fragmented data sub-message.

4. A robot communication state detection system based on network packet analysis according to claim 1 or 3, characterized in that, The message parsing module adapts to the differences in the RTPS message format by identifying and distinguishing at least one of the generation structures of different DDS vendors' vendor IDs (VendorID), globally unique identifiers (GUIDs), or built-in topic naming rules.

5. The robot communication state detection system based on network packet analysis according to claim 1, characterized in that, The system is implemented as two independent processes: a DDS message parsing process, which includes the network message capture module and the message parsing module; A DDS communication status display process; wherein the DDS message parsing process publishes the communication status indicators through a DDS topic, and the DDS communication status display process subscribes to the DDS topic to receive and display the communication status indicators.

6. The robot communication state detection system based on network packet analysis according to claim 5, characterized in that, The DDS communication status display process calls the libftxui library to visualize the communication status indicators in a terminal user interface (TUI).

7. The robot communication state detection system based on network packet analysis according to claim 1, characterized in that, The system is also configured to detect communication anomalies. When the frequency of a topic fluctuates beyond a preset first threshold, or the packet loss rate of a communication link exceeds a preset second threshold, it is determined to be a communication anomaly.

8. A robot communication state detection method based on network packet analysis, characterized in that, The method includes the following steps: Message capture step: non-intrusively listening to one or more network interfaces in the network environment where the robot operating system (ROS2) is located, and capturing network messages of the Real-time Publish-Subscribe Protocol (RTPS) used by the Data Distribution Service (DDS) in real time; Message parsing steps: Perform protocol layer parsing on the captured RTPS network messages to extract multiple key fields that characterize the communication link status. The key fields include at least the publisher entity identifier, subscriber entity identifier, and topic name, and adapt to the differences in RTPS message formats implemented by at least two different DDS vendors. State calculation steps: Based on the key fields, calculate at least one communication state indicator for each communication link consisting of a specific publisher entity and a specific subscriber entity. The communication state indicator includes topic frequency or bandwidth. Status output steps: The communication status indicators are structured and published externally for monitoring.

9. A robot communication state detection method based on network packet analysis according to claim 8, characterized in that, The message parsing step further includes: adapting to the differences in the RTPS message format by identifying and distinguishing at least one of the generation structures of different DDS vendors' vendor IDs (VendorID), globally unique identifiers (GUID), or built-in topic naming rules.

Images