Communication topic monitoring and diagnosing method and system based on ros 2 system

Abstract

The application relates to the technical field of robot operating system, and provides a communication topic monitoring and diagnosing method and system based on a ROS 2 system, wherein the method comprises the following steps: configuring global parameters, topic parameters and diagnosis rules; creating an independent monitoring thread for each topic; in each monitoring thread, creating a monitor instance for the corresponding topic; each monitor instance dynamically loads the message type corresponding to the topic, establishes QoS configuration and creates a subscriber; when a message arrives at the monitoring thread, the subscriber accepts the corresponding message, triggers a preset callback function, and obtains an original statistical data stream; an independent analysis thread is created for each topic; in each analysis thread, original statistical data is subjected to real-time statistical calculation, and a structured analysis result is obtained; the structured analysis result is compared with the diagnosis rules in real time, and a specific problem description and a diagnosis result are output. The application solves the problem that topics cannot be monitored and diagnosed in batches and automatically.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of robot operating system, in particular to a communication topic monitoring and diagnosing method and system based on ROS 2 system. BACKGROUND

[0002] The ROS 2 system is a new generation of robot operating system, which adopts DDS (Data Distribution Service) as the underlying communication middleware and is widely used in the fields of robots, autonomous driving, industrial automation, etc. In the actual project development and deployment process, a typical ROS 2 system usually contains dozens or even hundreds of nodes, each of which may publish or subscribe to multiple topics, forming a complex communication topology network.

[0003] At present, the rqt toolbox provided by the ROS 2 system or the traditional manual monitoring method is usually used to monitor the topics, but each has defects.

[0004] As shown in the rqt toolbox operation interface, the topic monitor in the rqt toolbox can display the topic list, and the selected topic can display the topic name, type, bandwidth, frequency (Hz), and variable value. The rqt tool mainly faces graphical monitoring, which is difficult to run in resource-limited embedded environments or server environments, and only objectively displays the basic information of the topic, does not directly provide fault diagnosis function, and cannot batch monitor and diagnose a large number of topics, which cannot meet the requirements of modern software development for automatic monitoring. Figure 1 The traditional manual monitoring method needs to use ros2 topic list, ros2 topic info, ros2 topic hz commands one by one, which is tedious and each command can only query a single topic, and cannot realize batch monitoring and automatic integration.

[0005] SUMMARY

[0006] The technical problem to be solved by the present application is to provide a communication topic monitoring and diagnosing method and system based on the ROS 2 system to solve the problem that the prior art cannot realize batch automatic monitoring and diagnosing of topics.

[0007] In order to solve the above technical problems, the technical solutions provided by the present application are as follows:

[0008] In a first aspect, a communication topic monitoring and diagnosing method based on the ROS 2 system is provided, comprising the following steps: ​

[0009] configuring global parameters, topic parameters and diagnostic rules; the topic parameters include a topic name list, a message type, description information, an expected frequency, and a topic type; the diagnostic rules include a topic expected frequency threshold and an error rate threshold;

[0010] loading the topic parameters, creating an independent monitoring thread for each topic according to the topic name list, creating a monitor instance for the corresponding topic in each monitoring thread, dynamically loading the message type corresponding to each topic by each monitor instance, establishing a QoS configuration and creating a subscriber associated with the QoS configuration, and when a message arrives at the monitoring thread, the subscriber accepts the corresponding message, triggers a preset callback function, and obtains an original statistical data stream;

[0011] obtaining the original statistical data, creating an independent analysis thread for each topic, performing real-time statistical calculation on the original statistical data in each analysis thread, and obtaining a structured analysis result; the structured analysis result includes a total number of messages, a message frequency, and an error number;

[0012] loading the diagnostic rules, comparing the structured analysis result with the diagnostic rules in real time, performing state classification diagnosis according to the comparison result, outputting a specific problem description and a diagnostic result; the diagnostic result includes a normal state, a frequency anomaly, and an error state.

[0013] In an embodiment, before loading the topic parameters, a ROS 2 system is initialized, a shared node instance is created, and a multi-threaded executor is configured; the multi-threaded executor is started in the monitoring thread, and all subscribers are managed through the multi-threaded executor.

[0014] In an embodiment, the monitoring thread writes the original statistical data into a data cache queue, and each analysis thread reads and loads the original statistical data from the data cache queue; when the queue is full, the latest generated original statistical data is automatically discarded, and the monitoring thread is not blocked.

[0015] In an embodiment, in each monitoring thread, a timeout check timer and a topic existence check timer are also created, which are used to check the timeout state of the topic, the existence of the topic, and the state of the publisher, and the output diagnostic result also includes the timeout state, the non-existent state of the topic, and the no-publisher state.

[0016] In an embodiment, the topic type is automatically detected, and a differentiated diagnosis strategy is performed according to the topic type: for a periodic topic, when the message frequency deviates from the expected frequency by more than a set threshold, it is marked as abnormal; for an event-driven topic, the existence of the topic and the state of the publisher are monitored, and no frequency monitoring is performed; for a low-frequency topic, a preset timeout threshold is combined with historical data; for a burst topic, a preset special frequency calculation algorithm is used.

[0017] In an embodiment, the specific problem description and the diagnosis result are processed according to a preconfigured output rule to generate a monitoring status report; the monitoring status report is sent to a starting terminal for visual display, and the monitoring status report is also sent to a front-end monitoring platform, an automatic test framework or a log recording system downstream.

[0018] In an embodiment, a multi-thread concurrent architecture is adopted, a main thread is responsible for ROS 2 system initialization, pre-configuration loading and resource management; a topic monitoring thread creates an independent monitoring thread and a monitor for each topic, and performs timeout detection and existence checking; a statistics collection thread creates an independent analysis thread for each topic, and is responsible for queue data processing, thread safety update and state synchronization; a display output thread is responsible for real-time state display, dynamic column width calculation and formatted output; threads communicate with each other through thread-safe data queues, including a statistics data queue, a state synchronization lock and a shutdown event.

[0019] In a second aspect, a communication topic monitoring and diagnosis system based on a ROS 2 system is provided, and the system comprises:

[0020] A file configuration module is configured to configure global parameters, topic parameters and diagnosis rules; the topic parameters include a topic name list, a message type, description information, an expected frequency and a topic type; the diagnosis rules include a topic expected frequency threshold and an error rate threshold;

[0021] A topic monitoring module is configured to load the topic parameters, create an independent monitoring thread for each topic according to the topic name list; in each monitoring thread, a monitor instance is created for the corresponding topic; each monitor instance dynamically loads the message type corresponding to the topic, establishes a QoS configuration and creates a subscriber associated with the QoS configuration; when a message arrives at the monitoring thread, the subscriber accepts the corresponding message, triggers a preset callback function and obtains an original statistical data stream;

[0022] A statistics analysis module is configured to obtain the original statistical data, create an independent analysis thread for each topic; in each analysis thread, real-time statistical calculation is performed on the original statistical data to obtain a structured analysis result; the structured analysis result includes a total number of messages, a message frequency and an error number;

[0023] A real-time diagnosis module is configured to load the diagnosis rules, compare the structured analysis result with the diagnosis rules in real time, perform state classification diagnosis according to a comparison result, output a specific problem description and a diagnosis result; the diagnosis result includes a normal state, a frequency anomaly and an error state.

[0024] A result output module configured to process the specific question description and the diagnosis result according to a preconfigured output rule to generate a monitoring state report, and send the monitoring state report to the starting terminal for visual display, and send the monitoring state report to a front-end monitoring platform, an automated test framework or a log recording system downstream.

[0025] In an embodiment, the system further comprises a system monitoring module configured to create a timeout check timer and a topic existence check timer in each monitoring thread to check the timeout state, the topic existence and the publisher state, and the output diagnosis result further comprises the timeout state, the topic nonexistence state and the no-publisher state.

[0026] In an embodiment, the system and the monitored topics are deployed on different devices within the same communication domain.

[0027] The present application has the following beneficial effects:

[0028] 1. Compared with the traditional rqt toolbox graphical monitoring tool, the command line monitoring method provided by the present application occupies less system resources, is particularly suitable for resource-limited embedded environments, supports global real-time monitoring, has low monitoring delay and high accuracy, and meets the real-time monitoring requirements.

[0029] 2. The present application adopts a shared ROS 2 node design, manages multiple subscribers through a multi-threaded executor, realizes efficient monitoring of multiple topics at the same time, avoids the resource overhead of creating independent nodes for each topic, improves the concurrency performance and resource utilization of the system, and compared with the traditional serial monitoring method, the monitoring efficiency is improved by several times.

[0030] 3. The message callback function adopts a non-blocking design to ensure the real-time performance of the monitoring process.

[0031] 4. A statistical calculation algorithm compatible with the ROS 2 system is adopted to ensure the accuracy and consistency of frequency statistics and provide reliable performance indicators.

[0032] 5. The system supports differentiated diagnosis strategies for multiple topic types, can provide accurate health status judgments according to the characteristics of different topics, and includes monitoring and display of non-existent topics.

[0033] 6. The system monitoring module adopts a non-blocking timer mechanism, the check frequency is independent of the message monitoring frequency, which avoids the influence of state checking on message monitoring performance, and provides a fault-tolerant mechanism that does not affect the normal operation of other monitoring functions when API calls fail.

[0034] 7. The monitoring architecture based on the DDS communication domain, the monitoring system and the monitored topics can be deployed on different devices, supporting large-scale deployment. BRIEF DESCRIPTION OF DRAWINGS

[0035] The application will be further described below with reference to the drawings.

[0036] Figure 1 is the operation interface of the rqt toolbox in the technical background.

[0037] Figure 2 is a real-time drawing statistical chart of the communication topic monitoring and diagnosis method and system based on the ROS 2 system provided by the embodiment of the application.

[0038] Figure 3 is a communication topic monitoring and diagnosis system framework based on the ROS 2 system provided by the embodiment of the application.

[0039] Figure 4 is a real-time drawing statistical chart of the communication topic monitoring and diagnosis method and system based on the ROS 2 system provided by the embodiment of the application. DETAILED DESCRIPTION

[0040] The embodiment of the application provides a communication topic monitoring and diagnosis method based on a ROS 2 system, comprising the following steps:

[0041] S1, global parameters, topic parameters and diagnosis rules are configured; the topic parameters comprise a topic name list, a message type, description information, an expected frequency and a topic type; the diagnosis rules comprise a topic expected frequency threshold;

[0042] Specifically, a user pre-configures global parameters and rules for topics (Topic) to be monitored in a YAML configuration file, reads the configuration file in the YAML format, and parses global configuration parameters and a Topic configuration list. The global configuration (global) is responsible for providing parameters including a monitoring update frequency, a log level, display detailed statistics, a frequency statistical window size (a message quantity) and the like; the topic configuration (Topics) is responsible for providing configurations for each topic (Topic), including a monitored topic (Topic) name, topic (Topic) description, topic (Topic) diagnosis type, topic (Topic) diagnosis expected frequency, whether the topic (Topic) is started real-time echo, whether the topic (Topic) is started real-time frequency calculation, a topic (Topic) reception diagnosis timeout threshold and topic (Topic) attribution node and the like information. After the configuration is completed, the system is initialized. Through the YAML configuration file and the command line parameter, a highly flexible configuration management mechanism is provided, and functions such as Topic filtering, automatic discovery, command line parameter coverage and the like are supported.

[0043] In this embodiment, the system automatically detects and sets the environment variables required for ROS 2 system operation, including ROS_DISTRO, RMW_IMPLEMENTATION, ROS_DOMAIN_ID, etc. If the environment variables are not set, the system automatically sets the default values: ROS_DISTRO='galactic', RMW_IMPLEMENTATION='rmw_cyclonedx_cpp', ROS_DOMAIN_ID='0'. At the same time, the system tries multiple possible ROS 2 Python paths to ensure that the ROS 2 related libraries can be correctly imported.

[0044] The monitor_config_enhanced_v2.yaml configuration file is read, which adopts a hierarchical structure and contains three main parts:

[0045] The global section defines global configuration parameters such as update_interval (monitoring update frequency, default 1.0 seconds), log_level (log level, default INFO), show_detailed_stats (whether to display detailed statistics, default true), hz_window_size (frequency statistics window size, default 100 samples), etc.

[0046] The topics section defines a list of Topic configuration to be monitored, each Topic contains name (Topic name), message_type (message type), description (description information), topic_type (Topic type, supports periodic, event, low_frequency, burst four types), expected_hz (expected frequency), enable_echo (whether to enable message echo), enable_hz_monitor (whether to enable frequency monitoring), timeout_threshold (timeout threshold), node (associated node information), etc.

[0047] The nodes section defines node configuration information, which can be automatically generated from the topic configuration or explicitly configured.

[0048] Taking the " / turtle1 / cmd_vel" Topic as an example, the configuration is as follows:

[0049] ```yaml

[0050] - name: " / turtle1 / cmd_vel"

[0051] description: "turtle speed control"

[0052] topic_type: "periodic"

[0053] expected_hz: 10.0

[0054] enable_echo: false

[0055] enable_hz_monitor: true

[0056] timeout_threshold: 2.0

[0057] node:

[0058] name: "turtle_controller"

[0059] description: "turtle control node"

[0060] ```

[0061] In an embodiment, a multi-threaded concurrent architecture is adopted, the main thread is responsible for ROS 2 system initialization, loading pre-configuration and resource management; the topic monitoring thread creates an independent monitoring thread and monitor for each topic, and performs timeout detection and existence check; the statistics collection thread creates an independent analysis thread for each topic, responsible for queue data processing, thread-safe update and state synchronization; the display output thread is responsible for real-time state display, dynamic column width calculation and formatted output; the threads communicate through thread-safe data queues, including statistics data queues, state synchronization locks and shutdown events.

[0062] In an embodiment, before loading the topic parameters, the ROS 2 system is initialized, a shared node instance is created, and a multi-threaded executor is configured; the multi-threaded executor is started in the monitoring thread, and all subscribers are managed through the multi-threaded executor.

[0063] Specifically, rclpy.init() is called to initialize the ROS 2 system running environment, a shared node instance (Node) is created, a multi-threaded executor (MultiThreadedExecutor) is configured, and the spin() method of the executor is started in an independent thread to provide a basic running environment for subsequent concurrent monitoring.

[0064] In this embodiment, the rclpy.init() is called in the main thread to initialize the ROS 2 system runtime environment, a shared node instance (Node) named'multi_topic_monitor' is created, a multi-threaded executor (MultiThreadedExecutor) is configured, the number of threads is set to 4, the shared node is added to the multi-threaded executor, and then the spin() method of the multi-threaded executor is started in a separate monitoring thread (daemon).

[0065] S2, load topic parameters, create an independent monitoring thread for each topic according to the topic name list; in each monitoring thread, create a monitor instance for the corresponding topic; each monitor instance dynamically loads the message type corresponding to the topic, establishes a QoS configuration conforming to the requirements of the topic, and creates a subscriber associated with the QoS configuration; when the message arrives in the monitoring thread, the subscriber accepts the corresponding message, triggers the preset callback function, and obtains the original statistical data stream.

[0066] Specifically, the system initializes and loads the global configuration configured in the YAML configuration file for the overall service of the system, and then loads the topic configuration (Topics) in the YAML configuration file.

[0067] Get all topic (Topic) names, and the system creates an independent topic monitor instance (TopicMonitor instance) for each configured topic (Topic). The constructor of the topic monitor class (TopicMonitor class), which encapsulates the core class of the topic (Topic) monitoring logic, receives the topic_config configuration dictionary, shared_node shared node reference, and stats_queue statistical queue reference as parameters.

[0068] The ROS 2 system topic (Topic) message type and quality of service (QoS configuration) are loaded dynamically. The QoS configuration adopts the BEST_EFFORT reliability strategy and the KEEP_LAST history strategy. The topic monitor instance (TopicMonitor instance) dynamically imports the message type corresponding to the topic (Topic) through the_import_message_type() method. This method supports multiple message type formats:

[0069] "package / msg / MessageType" format: such as "geometry_msgs / msg / Twist"

[0070] "package.msg.MessageType" format: such as "geometry_msgs.msg.Twist"

[0071] "package.MessageType" format: e.g. "geometry_msgs.Twist"

[0072] A subscriber to the corresponding Topic is then automatically created, which automatically subscribes to the Topic publisher using the Data Distribution Service (DDS) protocol stack through the middleware abstraction layer (RMW) to the DDS communication domain of the entire ROS 2 system.

[0073] After successful subscription, the data stream is sent in real time to the monitoring thread of the corresponding Topic through DDS, and the original data stream is obtained after real-time processing. When a new message arrives at the Topic, the message callback is triggered, the callback function records the message arrival timestamp, updates the message counter, calculates the time interval and adds it to the sliding window, outputs the message content if the message echo function is enabled, and finally sends the statistical data to the main thread through the thread-safe queue. The message callback function is designed with thread safety, and RLock is used to protect the statistical data update.

[0074] Taking the " / turtle1 / cmd_vel" Topic as an example, a special monitoring thread is created for the Topic, and a TopicMonitor instance is created in the monitoring thread to monitor the Topic. The system automatically detects that the message type is "geometry_msgs / msg / Twist", and then dynamically loads the geometry_msgs.msg module using importlib.import_module(), and gets the Twist message class through getattr().

[0075] A Topic subscriber is created using the create_subscription() method of the shared node, and the QoS configuration uses the BEST_EFFORT reliability policy and the KEEP_LAST history policy, with a depth of 10. The callback function of the subscriber points to the _message_callback() method. For the " / turtle1 / cmd_vel" Topic, a subscriber is created to receive messages of the geometry_msgs / msg / Twist type.

[0076] In an embodiment, in each monitoring thread, a timeout check timer and a topic existence check timer are also created to check the topic timeout state, topic existence and publisher state.

[0077] Specifically, the ROS 2 API interfaces such as get_topic_names_and_types(), get_publishers_info_by_topic(), get_subscriptions_info_by_topic(), etc. are periodically called through a non-blocking timer mechanism to check the existence of topics, the number of publishers, the number of subscribers, and other topology information in real time. The checking frequency is independent of the message monitoring frequency, avoiding the impact of state checking on message monitoring performance, while providing a fault tolerance mechanism that does not affect the normal operation of other monitoring functions when API calls fail.

[0078] In this embodiment, two timers are created:

[0079] - timeout_timer: triggered every 1 second to check the timeout state of the Topic.

[0080] - topic_info_timer: triggered every 5 seconds to check the existence of the Topic and the state of the publisher, and to obtain the topology information of the Topic by calling get_topic_names_and_types() and get_publishers_info_by_topic() ROS 2 API.

[0081] For the " / turtle1 / cmd_vel" Topic, if no message is received for more than 2.0 seconds, it is marked as a timeout state.

[0082] In one embodiment, the monitoring thread writes raw statistical data to the data cache queue, and each analysis thread reads and loads raw statistical data from the data cache queue; when the queue is full, the latest generated raw statistical data is automatically discarded without blocking the monitoring thread.

[0083] Specifically, the message callback function uses a non-blocking design, using the queue.put_nowait() method to send data to the main thread, and when the data cache queue is full, the data is automatically discarded without blocking the monitoring thread, ensuring the real-time performance of the monitoring process.

[0084] The core implementation logic of the message callback function is as follows:

[0085] ```python

[0086] def _message_callback(self, msg):

[0087] current_time = time.time()

[0088] # Get last message time (thread-safe)

[0089] last_time = None

[0090] if self.stats.enable_hz_monitor:

[0091] with self.stats._lock:

[0092] last_time = self.stats.last_message_time

[0093] # Update message statistics

[0094] self.stats.update_message_stats(current_time)

[0095] # Calculate and update frequency statistics

[0096] if self.stats.enable_hz_monitor and last_time is not None:

[0097] interval = current_time - last_time

[0098] if interval>0:

[0099] self.stats.update_hz_stats(interval)

[0100] # Echo message content (if enabled)

[0101] if self.stats.enable_echo:

[0102] self._echo_message(msg)

[0103] # Send statistics to main thread

[0104] try:

[0105] self.stats_queue.put_nowait((self.topic_name, self.stats.get_safe_copy()))

[0106] except queue.Full:

[0107] pass # queue full, ignore, do not block monitoring thread

[0108] ```

[0109] S3, obtaining original statistical data, creating an independent analysis thread for each topic; in each analysis thread, real-time statistical calculation is performed on the original statistical data to obtain structured analysis results; the structured analysis results include the total number of messages, message frequency, and error count;

[0110] Specifically, the statistical calculation includes message frequency (the calculation uses the ROS 2 official compatible frequency algorithm, based on the inverse of the time interval mean), message interval statistical analysis, message loss rate statistics, error count statistics, and message size statistics. The TopicStats class is defined using the dataclass decorator, including message statistics, frequency statistics, configuration parameters, error statistics, topic (Topic) existence, and other fields. Key fields include:

[0111] - message_count: total number of messages

[0112] - last_message_time: last message timestamp

[0113] - current_hz: current frequency

[0114] - average_hz: average frequency

[0115] - interval_samples: double-ended queue of time interval samples, maximum length 100

[0116] - _lock: thread-safe lock

[0117] Using an algorithm compatible with the ROS 2 system official topic hz command, time interval samples are maintained through a sliding window, and the window size can be set through a configuration file, with a default of 100 samples. When a new time interval arrives, if the window is not full, it is directly added, and if the window is full, the oldest sample is removed using the FIFO strategy. The current frequency is calculated by the inverse of the latest time interval, and the average frequency is calculated by the statistical mean of all samples in the window. At the same time, the total number of messages, error count, and other indicators are also calculated.

[0118] Inter-thread communication is implemented using queue.Queue, which supports non-blocking processing when the queue is full, ensuring the real-time performance of the monitoring process. Thread-safe locks are used to protect concurrent access, and all read and write operations on raw statistics are protected using threading.RLock recursive locks, which support nested locking. The get_safe_copy() method returns a safe copy of the statistics, avoiding cross-thread data races.

[0119] For the " / turtle1 / cmd_vel" Topic, the system maintains the last 100 message interval samples, and the current frequency is calculated by averaging the last 10 interval samples, and the average frequency is calculated by averaging all interval samples.

[0120] In one embodiment, when a timeout check timer and a topic existence check timer are also created in the monitoring thread, real-time statistical calculation also includes Topic timeout detection, etc.

[0121] S4, load diagnostic rules, compare structured analysis results with diagnostic rules in real time, classify and diagnose states according to comparison results, output specific problem descriptions and diagnostic results; the diagnostic results include normal state, frequency anomaly, error state.

[0122] Specifically, diagnostic rule configurations are pre-loaded, including Topic expected frequency threshold, error rate threshold, and other diagnostic parameters. After receiving the structured analysis results, a rule matching algorithm is used to compare and judge the analysis results with the pre-configured diagnostic rules in real time, and state classification diagnosis is performed according to the comparison results, including: normal state, frequency anomaly state, error state, etc. In one embodiment, when a timeout check timer and a topic existence check timer are also created in each monitoring thread, the diagnostic results also include timeout state, topic nonexistence state, and no publisher state. The health degree of the computing node is evaluated by calculating the ratio of the number of active Topics to the total number of Topics as a health degree indicator. Diagnostic results containing specific problem descriptions and diagnostic suggestions are generated.

[0123] In one embodiment, the topic type is automatically detected, and differential diagnosis strategies are performed according to the topic type: for periodic topics, when the message frequency deviates from the expected frequency by more than a set threshold, it is marked as abnormal; for event-driven topics, the topic existence and publisher state are monitored, and no frequency monitoring is performed; for low-frequency topics, a preset timeout threshold is combined with historical data; for burst topics, a preset special frequency algorithm is used.

[0124] Specifically, different diagnostic strategies are used for different types of Topics:

[0125] Periodic Topic (periodic type): Marked as abnormal when the message frequency deviates from the expected frequency by more than a set threshold. For example, the " / turtle1 / cmd_vel" Topic is a periodic topic, and the frequency stability should be monitored. When the actual frequency deviates from the expected frequency by more than 10.0 Hz, it is marked as abnormal.

[0126] Event-driven Topic (event type): No frequency monitoring is performed, and the main check is whether the topic (Topic) exists and whether there is a publisher

[0127] Low-frequency Topic (low_frequency type): Combine historical data and use a longer timeout threshold to avoid false positives

[0128] Burst Topic (burst type): Use a special frequency calculation algorithm to handle non-periodic message patterns. For example, instead of actively calculating at a fixed period, the calculation is triggered by a message burst event: when the number of messages in a unit of time exceeds a preset threshold (such as ≥5 in 1 second), automatically switch to a high-frequency statistical mode (such as calculate every 0.5 seconds); when the message frequency is lower than the preset threshold, switch back to a low-frequency statistical mode (such as calculate every 10 seconds).

[0129] In one embodiment, the specific problem description and diagnosis result are processed according to a preconfigured output rule to generate a monitoring state report; the monitoring state report is sent to a starting terminal for visual display, and the monitoring state report is also sent to a downstream front-end monitoring platform, an automated test framework, or a log recording system.

[0130] Specifically, data is arranged and formatted according to a preconfigured output rule, including real-time state display formatting, monitoring report generation, node health summary, and diagnosis result classification and arrangement, and then the formatted monitoring state report is output to the starting terminal for visual display in real time according to the system configured update period.

[0131] The system will traverse all topic (Topic) statistics data, collect all monitor statistics data, calculate dynamic column width to adapt to different length topic (Topic) names and state information, and set reasonable minimum width and maximum width limits to ensure the beauty and readability of the table display; according to the configured update_interval (default 1.0 seconds) periodically refresh the display content, use status icons and color coding to distinguish different topic (Topic) states, display the monitoring results in a formatted table form in real time, support clear screen refresh and historical data recording. The monitoring report is sent to the downstream front-end monitoring platform, the automated test framework, or the log recording system to realize multi-channel output of the monitoring results and system integration.

[0132] As shown in Figure 2 For the "turtle_controller" node, the system will count the health status of all topics associated with it, and calculate the ratio of active topics to the total number of topics as the health indicator. For the " / turtle1 / cmd_vel" Topic, the system will display its status as "active", the current frequency as 10.2Hz, the average frequency as 10.1Hz, the total number of messages as 962, the last message time as N / A, and the diagnostic information as "Publisher: 1, Subscriber: 2". The overall state is healthy, and the associated "Turtle Control Node" shows a healthy state.

[0133] As shown in Figure 3 The ROS 2 system-based communication topic monitoring and diagnostic system provided by the embodiment of the present application comprises:

[0134] A file configuration module is configured to configure global parameters, topic parameters, and diagnostic rules. The topic parameters include a topic name list, a message type, description information, an expected frequency, and a topic type. The diagnostic rules include a topic expected frequency threshold and an error rate threshold.

[0135] A topic monitoring module is configured to load the topic parameters, create an independent monitoring thread for each topic according to the topic name list, create a monitor instance for the corresponding topic in each monitoring thread, dynamically load the message type corresponding to the topic for each monitor instance, establish a QoS configuration and create a subscriber associated with the QoS configuration, and accept the corresponding message when the message arrives at the monitoring thread, trigger a preset callback function, and obtain an original statistical data stream.

[0136] A statistical analysis module is configured to obtain the original statistical data, create an independent analysis thread for each topic, perform real-time statistical calculation on the original statistical data in each analysis thread, and obtain a structured analysis result. The structured analysis result includes a total number of messages, a message frequency, and an error number.

[0137] A real-time diagnostic module is configured to load the diagnostic rules, compare the structured analysis result with the diagnostic rules in real time, perform state classification diagnosis according to the comparison result, output a specific problem description and a diagnostic result, and the diagnostic result includes a normal state, a frequency anomaly, and an error state.

[0138] A result output module is configured to process the specific problem description and the diagnostic result according to a preconfigured output rule, generate a monitoring state report, send the monitoring state report to a starting terminal for visual display, and send the monitoring state report to a downstream front-end monitoring platform, an automated test framework, or a log recording system.

[0139] In an embodiment, the system further comprises a system monitoring module, which is configured to create a timeout check timer and a topic existence check timer in each monitoring thread, and check the timeout state, the topic existence and the publisher state, and the output diagnostic result further comprises a timeout state, a topic nonexistence state and a no-publisher state.

[0140] In an embodiment, the system and the monitored topics are deployed on different devices in the same communication domain.

[0141] As shown in Figure 4 , the embodiments of the present application have also been tested and verified in an actual autonomous driving system. The test environment includes 35 ROS 2 nodes, and the monitored topics cover two modules of sensing and perception, and the topic types include laser radar point cloud fusion, camera image, target detection, millimeter wave radar fusion and vehicle state.

[0142] The test results show that:

[0143] 1. The system can simultaneously monitor 50 default topics, and the theoretical value is unlimited. The actual number of monitored topics is determined by the size of the thread pool.

[0144] 2. The memory occupation is much lower than the resource consumption of the graphical monitoring tool.

[0145] 3. The monitoring delay is less than 100 ms, meeting the real-time monitoring requirements.

[0146] 4. The frequency statistics accuracy is consistent with the official ROS 2 tool.

[0147] 5. The abnormal topic detection accuracy rate is above 99%.

[0148] The embodiments of the present application also support various extensions and integration methods:

[0149] 1. Automated test integration: provides a Python programming interface to support direct invocation of monitoring functions in test scripts.

[0150] 2. CI / CD integration: supports command line parameter configuration and can be integrated into continuous integration platforms such as Jenkins and GitLab CI.

[0151] 3. Monitoring system integration: provides JSON format data export and can be integrated with monitoring systems such as Prometheus and Grafana.

[0152] 4. Distributed deployment: supports cross-device monitoring and can deploy monitoring instances on edge computing nodes.

Claims

1. A communication topic monitoring and diagnosing method based on a ROS 2 system, characterized by, The method comprises the following steps: configuring global parameters, topic parameters and diagnostic rules; the topic parameters comprise a topic name list, a message type, description information, an expected frequency and a topic type; the diagnostic rules comprise a topic expected frequency threshold and an error rate threshold; loading the topic parameters, creating an independent monitoring thread for each topic according to the topic name list, creating a monitor instance for the corresponding topic in each monitoring thread, dynamically loading the message type corresponding to the topic for each monitor instance, establishing a QoS configuration and creating a subscriber associated with the QoS configuration; when a message arrives at the monitoring thread, the subscriber accepts the corresponding message, triggers a preset callback function and obtains an original statistical data stream; obtaining the original statistical data, creating an independent analysis thread for each topic, performing real-time statistical calculation on the original statistical data in each analysis thread and obtaining a structured analysis result; the structured analysis result comprises a total number of messages, a message frequency and an error number; loading the diagnostic rules, comparing the structured analysis result with the diagnostic rules in real time, automatically detecting the topic type, executing a differentiated diagnostic strategy according to the topic type, marking an abnormality when the message frequency deviates from the expected frequency by more than a set threshold for a periodic topic, not performing frequency monitoring for an event-driven topic, combining historical data to preset a timeout threshold for a low-frequency topic, adopting a preset special frequency calculation algorithm for a burst topic, performing state classification diagnosis according to the comparison result, outputting a specific problem description and a diagnostic result; the diagnostic result comprises a normal state, a frequency abnormality and an error state. Before loading the topic parameters, initializing a ROS 2 system, creating a shared node instance and configuring a multi-threaded executor; starting the multi-threaded executor in the monitoring thread and managing all subscribers through the multi-threaded executor.

2. The communication topic monitoring and diagnosing method based on a ROS 2 system according to claim 1, characterized in that: The monitoring thread writes the original statistical data into a data cache queue, and each analysis thread reads and loads the original statistical data from the data cache queue; when the queue is full, the latest generated original statistical data is automatically discarded, and the monitoring thread is not blocked.

3. The communication topic monitoring and diagnosing method based on a ROS 2 system according to claim 1, characterized in that: In each monitoring thread, a timeout check timer and a topic existence check timer are also created, which are used to check the timeout state of the topic, the existence of the topic and the state of the publisher, and the output diagnostic result further comprises a timeout state, a topic nonexistence state and a no-publisher state.

4. The communication topic monitoring and diagnostic method based on a ROS 2 system of claim 1, wherein: The specific problem description and the diagnostic result are processed according to a preconfigured output rule, a monitoring state report is generated, the monitoring state report is sent to a starting terminal for visual display, and the monitoring state report is also sent to a front-end monitoring platform, an automated test framework or a log recording system downstream.

5. The communication topic monitoring and diagnostic method based on a ROS 2 system of claim 1, wherein: A multi-threaded concurrent architecture is adopted, a main thread is responsible for ROS 2 system initialization, preconfiguration loading and resource management; a topic monitoring thread creates an independent monitoring thread and a monitor for each topic and performs timeout detection and existence checking; a statistical collection thread creates an independent analysis thread for each topic and is responsible for queue data processing, thread safety updating and state synchronization.

6. The method of claim 1-5, wherein the method is based on a ROS 2 system. ​ The display output thread is responsible for real-time status display, dynamic column width calculation and formatted output; the threads communicate through thread-safe data queues, including statistical data queues, status synchronization locks and shutdown events.

7. A communication topic monitoring and diagnostic system based on a ROS 2 system, characterized by The system comprises: a file configuration module for configuring global parameters, topic parameters and diagnostic rules; the topic parameters include topic name lists, message types, description information, expected frequencies and topic types; the diagnostic rules include topic expected frequency thresholds and error rate thresholds; a topic monitoring module for loading topic parameters, creating an independent monitoring thread for each topic according to the topic name list, creating a monitor instance for the corresponding topic in each monitoring thread, dynamically loading the message types corresponding to each topic for each monitor instance, establishing QoS configurations and creating a subscriber associated with the QoS configurations, and triggering a preset callback function to obtain an original statistical data stream when a message arrives in the monitoring thread; a statistical analysis module for obtaining original statistical data, creating an independent analysis thread for each topic, performing real-time statistical calculation on the original statistical data in each analysis thread to obtain structured analysis results, and the structured analysis results including message totals, message frequencies and error counts; a real-time diagnostic module for loading diagnostic rules, comparing the structured analysis results with the diagnostic rules in real time, classifying the states according to the comparison results, outputting specific problem descriptions and diagnostic results, and the diagnostic results including normal states, frequency abnormalities and error states; a result output module for processing the specific problem descriptions and diagnostic results according to preconfigured output rules, generating a monitoring status report, sending the monitoring status report to a starting terminal for visual display, and simultaneously sending the monitoring status report to a downstream front-end monitoring platform, an automated test framework or a log recording system.

8. A ROS 2 system-based communication topic monitoring diagnostic system as claimed in claim 7, wherein: The system further comprises a system monitoring module for creating a timeout check timer and a topic existence check timer in each monitoring thread to check topic timeout states, topic existences and publisher states, and the output diagnostic results further including timeout states, topic nonexistence states and no-publisher states.

9. A ROS 2 system based communication topic monitoring diagnostic system as claimed in claim 7, wherein: The system and the monitored topics are deployed on different devices within the same communication domain.

Images