ROS2-oriented integrated robot communication control method

Abstract

The application discloses a kind of integrated robot communication control methods for ROS2, bridge layer node is deployed between ROS2 application layer and physical hardware layer, realize the bidirectional transparent conversion of ROS2 message and serial communication frame, the comprehensive priority arbitration and preemptive scheduling of multi-source control instruction, and the real-time monitoring and abnormal recovery of physical link;By applying excitation signal collection encoder feedback, extract actuator physical characteristic vector and map as initial PID parameter, online fine tuning in operation;Deployment diagnostic node resolves DDS / RTPS network communication data in non-invasive way, and generates diagnostic report by cause-effect mapping in combination with multi-source state information.The application integrally solves the problems of communication decoupling, control collaboration and intelligent diagnosis from the system architecture level, significantly improves the portability, safety and robustness of ROS2 robot system.

Description

Technical Field

[0001] This invention belongs to the field of intelligent mobile robot control system and industrial communication technology, specifically relating to an integrated robot communication control method for ROS2. Background Technology

[0002] With the increasing complexity and intelligence of robot applications, ROS2 (Robot Operating System 2) has become the mainstream platform for intelligent robot system development due to its distributed architecture, flexible communication mechanisms, and rich ecosystem support. In a typical ROS2 mobile robot system, the host computer (such as an industrial control computer or computing unit equipped with ROS2) is responsible for high-level computing tasks such as path planning and perception fusion, while the slave computer (such as microcontrollers like STM32 and ESP32) directly interacts with physical hardware such as motors (actuators) and encoders to execute low-level motion control. The two typically rely on physical links such as serial ports and CAN buses for the transmission of commands and status data. Therefore, ensuring efficient, reliable, and secure interaction of control commands between the ROS2 application layer and the physical hardware layer is one of the core issues determining the performance and stability of the robot system.

[0003] Currently, mainstream ROS2 mobile robot systems generally employ a layered and functionally fragmented architecture to achieve the aforementioned communication and control. Specifically, at the communication layer, there are format differences between the standard ROS2 control topics (such as / cmd_vel commands) issued by the host computer and the custom serial communication frames that the slave computer can parse. Existing practices typically involve hard-coding the protocol conversion logic in the slave computer firmware. This approach results in a strong binding between the communication protocol and the specific hardware platform. At the control layer, robots often need to simultaneously respond to control commands from multiple control sources, such as autonomous navigation, remote monitoring, manual remote control, and emergency braking. Existing systems often use simple "last-come-override" or fixed-priority strategies to handle command conflicts. Furthermore, regarding system operation status monitoring, commonly used ROS2 command-line tools or graphical interfaces mainly provide statistical information such as ROS2 topic publication frequency and latency, and their data source is limited to the ROS2 network layer, without involving the underlying physical link status and hardware execution.

[0004] Due to the aforementioned architectural flaws, existing ROS2 robot systems face multiple technical challenges in practical deployment: protocol conversion logic is hard-coded into the lower-level firmware, requiring rewriting and reprogramming the firmware when changing hardware platforms or adjusting communication protocols; ROS2 version upgrades also require simultaneous maintenance, resulting in high cross-platform porting costs and complex system evolution; multi-source control commands lack a unified dynamic arbitration mechanism, making it easy for emergency commands (such as emergency stops) to conflict with regular commands, posing safety risks; physical communication links (such as USB serial ports) are prone to momentary disconnections or data corruption due to vibration and electromagnetic interference, while existing systems lack low-level anomaly perception and autonomous fault-tolerant recovery capabilities, often leading to node crashes or state asynchrony; when communication anomalies or control performance degradation occur, existing diagnostic methods cannot establish a causal relationship between network layer indicators such as packet loss and latency and physical layer faults such as poor cable contact and motor aging, making problem diagnosis heavily reliant on manual experience. Therefore, there is an urgent need for a method that can comprehensively solve the aforementioned communication decoupling, control coordination, and intelligent diagnostic problems at the system architecture level. Summary of the Invention

[0005] The technical problem to be solved by this invention is that the existing ROS2 robot system suffers from poor portability, high safety risks, slow fault recovery, and difficulty in troubleshooting due to the strong coupling between the communication protocol and hardware, the lack of dynamic arbitration of multi-source control commands, the lack of autonomous fault tolerance in the physical link, and the disconnect between diagnostic indicators and physical causes.

[0006] To address the aforementioned technical problems, this invention provides an integrated robot communication and control method for ROS2, comprising:

[0007] S1: Deploy an independent bridging layer node between the ROS2 application layer and the physical hardware layer; wherein, the bridging layer node is used to realize bidirectional transparent conversion between ROS2 standard messages and serial communication frames, to perform comprehensive priority evaluation and preemptive scheduling of multi-source control commands, and to implement real-time monitoring and anomaly recovery of the physical hardware layer link.

[0008] S2: Under predetermined triggering conditions, the physical hardware layer is controlled by the bridging layer node to apply excitation signals to the actuator, and feedback data from the encoder corresponding to the physical hardware layer is continuously collected; feature vectors characterizing the physical characteristics of the actuator are extracted based on the encoder feedback data, and the feature vectors characterizing the physical characteristics of the actuator are mapped to initial PID parameters; and the PID parameters are fine-tuned online based on the control performance during operation.

[0009] S3: Deploy independent diagnostic nodes. These nodes capture and parse DDS / RTPS network communication data in a non-intrusive manner, calculate the communication quality index of each ROS2 topic, and simultaneously collect the status logs of the bridging layer nodes, resource monitoring data of the ROS2 application layer, and status information of each sensor. Based on the communication quality index of each ROS2 topic, the status logs of the bridging layer nodes, the resource monitoring data of the ROS2 application layer, and the status information of each sensor, a diagnostic report for the robot is generated through causal mapping.

[0010] The present invention has at least the following beneficial effects

[0011] This invention constructs a ROS2-serial intelligent bridging layer (bridging layer node) and introduces a multi-source instruction comprehensive priority arbitration and preemptive scheduling mechanism, achieving hardware and software decoupling of the control link and millisecond-level response to emergency instructions. This effectively eliminates multi-source instruction conflicts and improves system security. Through actuator physical feature recognition and adaptive PID online tuning, PID parameters can adapt to individual hardware differences and aging trends, significantly reducing cross-platform portability and manual parameter tuning costs. Through bidirectional heartbeat monitoring and exponential backoff reconnection mechanisms, autonomous perception and rapid recovery from physical link anomalies are achieved, avoiding node crashes and state desynchronization. Simultaneously, by leveraging DDS network packet non-intrusive deep parsing and multi-source log causal mapping, abstract communication indicators are accurately correlated with specific physical layer faults, reducing fault diagnosis time from hours to minutes. This invention provides an integrated solution to communication decoupling, control coordination, and intelligent diagnostics at the system architecture level, significantly improving the portability, security, robustness, and maintainability of the ROS2 robot system. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the overall framework of the present invention;

[0013] Figure 2 This is a schematic diagram illustrating the workflow of the bridging layer node in this invention;

[0014] Figure 3 This is a schematic diagram of the adaptive PID parameter tuning process of the present invention;

[0015] Figure 4 This is a schematic diagram of the workflow of the diagnostic node of the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] This embodiment illustrates the implementation scenario of the present invention using a specific application scenario. The present invention is applicable to the ROS2 mobile robot control system, such as... Figure 1 As shown, its overall architecture is divided from bottom to top into the physical hardware layer, the ROS2-serial intelligent bridging layer (bridging layer node), the ROS2 application layer, and the DDS non-invasive diagnostic system (diagnostic node, usually deployed on the ROS2 host computer). The physical hardware layer includes motor drivers (actuators), encoders (corresponding to the actuators; a robot has multiple joints, each driven by a motor, and each motor has a corresponding encoder), etc. The physical hardware layer interacts with the upper layer via a serial bus (such as UART, RS-232, or USB virtual serial port). In addition, each robot device is equipped with sensors such as IMU inertial measurement units and LiDAR. The data collected by these sensors is directly connected to the corresponding sensor driver nodes in the ROS application layer. The sensor driver nodes generate ROS topics containing the data collected by the corresponding sensors and publish them. The ROS2 application layer runs multiple ROS2 nodes with functions such as Nav2 navigation planning, multi-sensor fusion localization (supporting dynamic health weights), and remote monitoring (human-machine interaction UI). The ROS2 nodes interact with each other based on the DDS / RTPS network in a decentralized publish-subscribe communication mode, supporting flexible communication methods such as one-to-one, one-to-many, and many-to-many. The bridging layer node and the diagnostic node are deployed as independent ROS2 nodes in the DDS domain. The bridging layer node plays a pivotal role between the ROS2 application layer and the physical hardware layer, while the diagnostic node is responsible for bypassing and evaluating the quality of DDS network communication. Figure 2 The internal functional modules of the bridging layer node and its data interaction with the upper and lower layers are further demonstrated. This node integrates dynamic protocol parsing, multi-source command arbitration, and link health and session management, which are used to realize bidirectional transparent conversion between ROS2 standard messages and serial communication frames, caching and scheduling of multi-source control commands, and real-time monitoring and anomaly handling of physical serial port links, respectively. Figure 3 The working architecture of actuator adaptive tuning is shown. This module relies on the bridging layer node's ability to acquire encoder data from the physical hardware layer. Through excitation signal application and feedback analysis, it realizes automatic identification of actuator physical characteristics and online optimization of PID parameters. Figure 4The functional architecture of the diagnostic node is illustrated. Deployed in an independent bypass mode, this node captures DDS / RTPS communication data through a low-level network listening interface, while simultaneously collecting status logs from the bridging layer and resource monitoring information from the ROS2 application layer, achieving comprehensive awareness of communication quality. The modules interact with each other via standard ROS2 topics, forming a data loop that collectively supports the stable and reliable operation of the entire robot system in complex application scenarios. This invention can be widely applied to various ROS2-based wheeled mobile robots, unmanned delivery vehicles, service robots, and industrial AGVs, and is particularly suitable for practical deployments involving concurrent multi-source control commands, diverse hardware platforms, complex operating environments, and high system reliability requirements.

[0018] For details, please refer to Figures 1-4 This invention provides an integrated robot communication control method for ROS2, comprising:

[0019] S1: Deploy an independent bridging layer node between the ROS2 application layer and the physical hardware layer; wherein, the bridging layer node is used to realize bidirectional transparent conversion between ROS2 standard messages and serial communication frames, to perform comprehensive priority evaluation and preemptive scheduling of multi-source control commands, and to implement real-time monitoring and anomaly recovery of the physical hardware layer link.

[0020] Preferably, the ROS2 application layer includes multiple ROS2 nodes; the ROS2 nodes communicate with each other through a DDS / RTPS network, which adopts a decentralized publish-subscribe communication architecture. Each ROS2 node, as a participant in the DDS domain, automatically discovers each other and establishes communication connections through a distributed discovery protocol; the ROS2 nodes support one-to-one, one-to-many, and many-to-many communication modes; the diagnostic node and the bridging layer node are each deployed as a ROS2 node in the DDS domain.

[0021] Dynamic protocol parsing process: The bidirectional transparent conversion between ROS2 standard messages and serial communication frames includes:

[0022] S1-1-1: The bridge layer node reads the protocol mapping rule file stored externally. The protocol mapping rule file defines the correspondence between ROS2 topic names and message types, the mapping rules from message fields to communication frame byte positions, data conversion rules, and the format definition of communication frames.

[0023] S1-1-2: During downlink switching, the bridging layer node subscribes to the specified ROS2 topic, converts the received ROS2 standard messages into serial communication frames according to the protocol mapping rule file, and sends them to the physical hardware layer.

[0024] S1-1-3: During uplink conversion, the bridge layer node listens to the serial port byte stream, parses the received serial communication frames into ROS2 standard messages according to the protocol mapping rule file, and publishes them to the corresponding ROS2 topic.

[0025] S1-1-4: The bridging layer node monitors changes to the protocol mapping rule file in real time. Upon detecting a change, it automatically reloads the configuration, enabling runtime updates of the protocol mapping rule file without restarting each ROS2 node. A version identifier for the protocol mapping rule file is defined in the communication frame structure. Based on the version identifier, the corresponding protocol mapping rule file is automatically identified and selected to parse the communication frame, achieving parallel support for multiple protocol versions.

[0026] Preferably, the execution of comprehensive priority evaluation and preemptive scheduling of multi-source control commands includes:

[0027] S1-2-1: The bridging layer node establishes an instruction cache queue for each control source and presets different static priority levels for instructions from different control sources;

[0028] S1-2-2: Calculate the time priority of each instruction based on the timestamp of each instruction arriving at the bridging layer node, and determine the emergency priority of each instruction based on its content;

[0029] S1-2-3: The overall priority of an instruction is obtained by weighted summing of its time priority, static priority level, and emergency priority.

[0030] S1-2-4: Continuously evaluate the overall priority of the instructions at the head of each instruction cache queue, and select the instruction with the highest overall priority to send to the physical hardware layer;

[0031] S1-2-5: Continuously evaluate the overall priority of newly arrived instructions to the bridging layer node. When the overall priority of newly arrived instructions to the bridging layer node is higher than the first set threshold, interrupt the transmission of the current instruction, clear all instruction cache queues, cache the newly arrived instruction to the corresponding instruction cache queue, and send the newly arrived instruction with priority.

[0032] Preferably, the implementation of real-time monitoring and anomaly recovery of the physical hardware layer link includes:

[0033] S1-3-1: The bridging layer node receives the status frame actively sent by the physical hardware layer in the first predetermined period, and publishes the uplink transition of the status frame to the corresponding ROS2 topic; if no status frame is received from the physical hardware layer within the second predetermined period, the uplink is determined to be abnormal.

[0034] S1-3-2: If a bridging layer node sends a probe frame to the physical hardware layer in the third predetermined period and does not receive a response frame from the physical hardware layer within the fourth predetermined period, it determines that the downlink is abnormal.

[0035] S1-3-3: When the uplink or downlink fails, the bridging layer node suspends sending instructions to the physical hardware layer, suspends receiving new instructions from each control source, and clears the instruction buffer queue of each control source; it attempts to reconnect to the physical hardware layer using the exponential backoff algorithm, and resumes receiving instructions from each control source and sending instructions after a successful reconnection.

[0036] Example 1, as a preferred implementation, shows the following specific implementation of step S1 in actual deployment:

[0037] In this embodiment, the ROS2-based mobile robot system adopts a hierarchical control architecture. The host computer runs a version of ROS2Foxy and is responsible for high-level computing tasks such as navigation planning and perception fusion. The slave computer uses an STM32F4 series microcontroller to directly drive the motor and read encoder data. The host and slave computers are physically connected and interact with each other through a USB virtual serial port.

[0038] First, an independent bridging layer node is deployed between the ROS2 application layer and the physical hardware layer, located on the host computer. Upon system startup, the bridging layer node reads the protocol_map_v2.yaml file stored externally. For example, this file defines that the linear.x field of the / cmd_vel topic (of type geometry_msgs / Twist) is mapped to bytes 3-4 of the serial frame (int16 format, scaling factor 1000), and the angular.z field is mapped to bytes 5-6. It also defines the frame format as frame header 0xAA, frame trailer 0xBB, CRC checksum, and indicates the protocol version number as 2.0. During downlink switching, the bridging layer node subscribes to the / cmd_vel topic (control commands). Upon receiving a ROS2 standard message, it extracts status values ​​such as linear velocity and angular velocity according to the mapping rules, multiplies them by the scaling factor to convert them to integers, assembles the frames according to the frame format, adds checksum bytes, and finally sends them to the physical hardware layer via the serial port. During uplink conversion, the bridging layer node listens to the serial port byte stream. Upon receiving a complete data frame, it verifies the frame header and checksum, extracts the data of each field, performs data type conversion according to the defined data conversion rules, encapsulates it into a ROS2 standard message, and publishes it to the corresponding topic. Simultaneously, the bridging layer node monitors changes to the protocol mapping rule file in real time. Upon detecting a change, it automatically reloads the configuration, enabling runtime protocol updates without restarting the node. Furthermore, a protocol version identifier is defined in the serial communication frame structure. The bridging layer node automatically identifies and selects the corresponding mapping rule for parsing based on this identifier, achieving parallel support for multiple protocol versions, including v1.0 and v2.0.

[0039] The comprehensive priority evaluation and preemptive scheduling of multi-source control commands are implemented as follows: The bridging layer node establishes an independent command cache queue for each control source, including a local autonomous navigation source command queue (Nav2 planner, generated by the corresponding ROS topic), a remote monitoring system source command queue (SCADA), a local manual control source command queue (PyQt interface), and a hardware emergency stop source command cache queue (independent emergency stop button). Each command cache queue has a length of 10 commands; when the queue exceeds this length, the oldest command at the tail is discarded. The static priority levels are preset as follows: hardware emergency stop source is Level 4 (highest), local manual control source is Level 3 (high), remote monitoring source is Level 2 (medium), and autonomous navigation source is Level 1 (low). Within each control cycle, for example, 50ms, the arbitrator polls the head command of each command cache queue and calculates the time priority based on the timestamp of the command arriving at the bridging layer node. Calculate the emergency priority based on the instruction content. The overall priority is obtained by weighted summing of time priority, static priority level, and urgency priority. Time priority includes:

[0040]

[0041] in, Indicates the time priority of the instruction; Represents an exponential function; This represents the pre-set attenuation coefficient; This represents the difference between the current time and the timestamp of the instruction arriving at the bridging layer node.

[0042] Emergency priorities include:

[0043]

[0044] in, Indicates the urgent priority of the instruction; Indicates the target linear velocity in the command; Indicates the target angular velocity in the command; This indicates the robot's current linear velocity; This indicates the robot's current angular velocity. The robot's current state can be fed back by the state frame, and the bridging layer nodes can also subscribe to topics published by the sensor-driven nodes to obtain information. This indicates the maximum allowable linear speed of the robot, which is preset by expert technicians based on the robot's performance. This indicates the robot's maximum permissible angular velocity; if the command contains a preset special flag (such as an emergency stop flag or braking flag), then the command is executed directly. ;

[0045] The arbitrator continuously evaluates the overall priority of the instructions at the head of each queue and selects the instruction with the highest score to send to the physical hardware layer. When the overall priority of a newly arriving instruction is higher than a first preset threshold, preemptive scheduling is triggered. The first preset threshold is a configurable priority score threshold preset in the arbitrator of the bridge layer node, used to determine whether the newly arriving instruction has a sufficiently high urgency level to trigger preemptive scheduling. Its specific value needs to be determined comprehensively based on the static priority level of each control source in the system, the range of urgency priority values, and the configuration of weighting coefficients. Therefore, this invention provides the following specific example: In this embodiment, the static priority levels of each control source are preset as follows: hardware emergency stop source Level 4, local manual control source Level 3, remote monitoring source Level 2, and autonomous navigation source Level 1. The weighting coefficients w1, w2, and w3 are all configured to 1.0, and the theoretical range of the overall priority value is 0~6. Based on this value range, this embodiment sets the first threshold to 3.5, which means that only when the overall priority of a newly arriving instruction exceeds 3.5 is there sufficient urgency to interrupt the currently executing instruction. This configurable threshold design allows system integrators to flexibly adjust the preemption sensitivity according to the security requirements of different application scenarios (for example, in scenarios with higher security requirements, the threshold can be lowered to 3.0 to enable more instructions to preempt; conversely, in scenarios that pursue stable operation, the threshold can be raised to 4.0 to reduce unnecessary preemption), thereby balancing system security and execution stability. Upon triggering preemptive scheduling, the current instruction transmission is immediately interrupted, all unissued low-priority instructions in the buffer queue are cleared, and new instructions are prioritized and sent to the serial port to ensure millisecond-level response to emergency instructions (total latency controlled within 5ms). After the emergency instruction response, the front bridging layer node continues to receive status frames and publish them via a topic. At this time, the robot's local control source and the user's manual control source can replan based on the latest status, generate instructions, and reissue them. It should be noted that after clearing the instruction buffer queue, if the corresponding control source is in continuous publishing mode, it will automatically receive subsequent new instructions; if it is in single-instruction mode (such as a "point-to-point movement" instruction), the bridging layer node will request the control source to reissue the latest instruction via ROS2 service or feedback topic.

[0046] The real-time monitoring and anomaly recovery process of the physical hardware layer link is as follows in this embodiment: The lower-level device actively sends a status frame (containing information such as speed, voltage, and error codes) to the bridge layer node at a first predetermined period of 100ms. After receiving the frame, the bridge layer node publishes it through the / motor_status topic. If the bridge layer node does not receive any status frame within the second predetermined period (600ms in this embodiment, i.e., 6 consecutive periods), it determines that the uplink is abnormal. The bridge layer node sends a probe frame (lightweight ping packet) to the lower-level device at a third predetermined period of 200ms. If it does not receive a response frame from the lower-level device within the fourth predetermined period (600ms), it determines that the downlink is abnormal. When an uplink or downlink abnormality is detected, the bridge layer node immediately suspends issuing commands to the physical hardware layer, suspends receiving new commands from each control source, clears the command buffer queues of each control source, and publishes a "link disconnected" event through the / bridge_status topic. Subsequently, the bridging layer node attempts to reconnect to the physical hardware layer using an exponential backoff algorithm, with reconnection delays of 1s, 2s, 4s, and so on, up to a maximum of 60 seconds. After a successful reconnection, the lower-level machine still actively sends status frames to the bridging layer node at a predetermined interval of 100ms. Upon receiving the status frames, the bridging layer node re-receives instructions from each control source and resumes the instruction delivery process. During this process, due to the disconnection of the uplink and downlink, the robot's real-time status data cannot be received. Therefore, subsequent cached instructions lose their timeliness after reconnection, and executing outdated instructions is potentially dangerous. Therefore, all instruction queues are cleared. After reconnection, instructions are re-issued based on the latest status from the local control source and the user's manual control source. To ensure greater safety, if the lower-level machine does not receive control instructions from the bridging layer node within a preset time, it can be set to stop and wait until reconnection before executing the corresponding action based on the latest instructions.

[0047] By deploying an independent bridging layer node between the ROS2 application layer and the physical hardware layer, configurable bidirectional transparent conversion between ROS2 standard messages and serial communication frames is achieved. The protocol parsing logic is decoupled from the lower-level firmware to an external configuration file. This allows hardware platform replacement or communication protocol adjustment to only require modifying the configuration file without rewriting and flashing the firmware, significantly reducing cross-platform porting costs and system maintenance complexity. By establishing independent cache queues for each control source and introducing a comprehensive priority weighted arbitration mechanism, coupled with a preemptive scheduling strategy, orderly scheduling of multi-source control commands and priority response to emergency commands are achieved, effectively eliminating security risks caused by command conflicts. Through bidirectional heartbeat monitoring and exponential backoff reconnection mechanisms, autonomous detection and rapid recovery of physical link anomalies are achieved, avoiding node crashes and state asynchrony problems caused by momentary serial port disconnections.

[0048] S2: Under predetermined triggering conditions, the physical hardware layer is controlled by the bridging layer node to apply excitation signals to the actuator, and feedback data from the encoder corresponding to the physical hardware layer is continuously collected; feature vectors characterizing the physical characteristics of the actuator are extracted based on the encoder feedback data, and the feature vectors characterizing the physical characteristics of the actuator are mapped to initial PID parameters; and the PID parameters are fine-tuned online based on the control performance during operation.

[0049] Preferably, step S2 includes:

[0050] S2-1: Under predetermined triggering conditions, the bridging layer node reads the robot's state data from the state frame uploaded by the physical hardware layer. At the same time, the bridging layer node obtains the data collected by each sensor of the robot by subscribing to the ROS2 topic of each sensor of the robot. Based on the robot's state data and the data collected by each sensor of the robot, the safety conditions are verified according to the preset safety conditions. If the safety condition verification fails, step S2-2 is executed. If the safety condition verification passes, step S2-3 is executed.

[0051] S2-2: The bridging layer node directly loads the default PID parameters or the locally stored optimal PID parameters as the initial PID parameters, and sends the initial PID parameters to the physical hardware layer through the serial communication frame.

[0052] S2-3: The bridging layer node sends PWM excitation commands to the physical hardware layer through serial communication frames, and the physical hardware layer operates according to the PWM excitation commands; the bridging layer node generates initial PID parameters according to the status frames sent by the physical hardware layer through preset mapping rules, and sends the initial PID parameters to the physical hardware layer through serial communication frames.

[0053] S2-4: The physical hardware layer performs PID control operation based on the received PID parameters. The bridge layer node calculates the integral absolute error and control saturation frequency in real time based on the status frame sent by the physical hardware layer, and adaptively adjusts the current PID parameters based on the integral absolute error and control saturation frequency. The adjusted PID parameters are then sent to the physical hardware layer through a serial communication frame.

[0054] S2-5: Repeat step S2-4 until the integral absolute error remains stable for a continuously preset first time and the saturation frequency of the control quantity is lower than the set threshold. When the fine-tuning converges, the PID parameters after fine-tuning convergence are used to update the locally stored optimal PID parameters.

[0055] Preferably, the bridging layer node generates initial PID parameters based on the status frame sent by the physical hardware layer according to a preset mapping rule, including: the bridging layer node extracts five-dimensional features from the status frame sent by the physical hardware layer, including: start-up delay features, rise time features, overshoot features, steady-state error features, and micro-vibration energy features, forming a five-dimensional feature vector; the five-dimensional feature vector is then predicted and mapped to the initial PID parameters through fuzzy inference or a regression model.

[0056] Example 2 is a further improvement on Example 1. As a preferred implementation, step S2 is implemented in actual deployment as follows:

[0057] In this embodiment, the robot is equipped with two DC geared motors (with incremental encoders), an IMU, a LiDAR, and an STM32F4 lower-level computer. The lower-level computer uploads status frames at 100ms intervals, including information such as the current actual speed of the left and right wheels, PWM duty cycle, encoder count value, battery voltage, and error codes.

[0058] After system startup, safety condition verification is performed first. When the robot's cumulative running time reaches the preset 100-hour threshold, or when the system detects a change in the motor's serial number, the parameter tuning process is automatically triggered. After triggering, the bridging layer node reads the current linear velocity, angular velocity, and battery voltage from the lower-level machine's status frame, and simultaneously subscribes to the ` / scan` topic to obtain LiDAR data and the ` / imu` topic to obtain attitude data. Verification conditions include: linear velocity less than 0.01 m / s (stationary), distance to the nearest obstacle greater than 1 m, tilt angle less than 10°, and battery voltage higher than a set threshold. These safety conditions are only basic; those skilled in the art can adapt and extend them based on the above description and specific application scenarios, and these are not the only conditions. If any condition is not met, the bridging layer node skips the scanning process, loads the previously converged optimal PID parameters or the factory default PID parameters from local storage, and directly sends them to the lower-level machine via serial port. For example, if the robot is on a slope (12° inclination) when a certain trigger occurs, and the safety verification fails, the bridging layer node will load the default PID parameters and send them to the lower-level machine, and the robot will run according to the default parameters.

[0059] Once all safety conditions are verified, the bridging layer node initiates the feature scanning process. First, a PWM excitation command is sent to the lower-level computer via serial port: a step signal of 20% of rated power is applied for 2 seconds, and the time difference between the command issuance and the encoder speed first exceeding 0.01 m / s is recorded as the start-up delay feature Td. Then, a sinusoidal modulated PWM signal with a frequency linearly increasing from 0.1 Hz to 5 Hz is applied for 3 seconds, and the speed response curve is recorded. The entire scanning process does not exceed 5 seconds. Throughout the scanning process, the lower-level computer continuously uploads status frames at a 100 ms period, and the bridging layer node extracts encoder speed data at a sampling rate of no less than 200 Hz.

[0060] After the scan is complete, the bridging layer nodes extract a five-dimensional feature vector from the collected response data. Among them, if measured (Start-up delay characteristic, defined as the time difference from the issuance of the PWM excitation command from the bridge layer node to the first time the actuator speed exceeds 0.01m / s). Rise time characteristic is defined as the time required for the actuator speed to rise from 10% to 90% of the target steady-state speed. (Peak overshoot ratio, defined as the percentage difference between the actuator's peak speed and the target steady-state speed divided by the target steady-state speed). (Steady-state velocity deviation is defined as the absolute deviation between the average velocity value after entering steady state (usually within the last second of the response curve) and the target steady-state velocity.) The steady-state velocity standard deviation (defined as the standard deviation of the velocity signal during the steady-state phase) is then used to construct the feature vector. Based on this feature vector, the bridging layer nodes generate initial PID parameters through a pre-defined fuzzy inference engine. The inference rules are, for example: Larger values ​​(exceeding the 0.1s threshold) result in fuzzy inference output. Incremental Factor ;because If the value is too large (exceeding the 15% threshold), the output Kd increment factor is +0.4; because... Normal, output Ki increment factor +0.1; because Normal (below the 0.02 threshold), output Kd reduction factor -0.1. The initial PID parameters after synthesis are: The parameter is then sent to the lower-level machine via a serial communication frame; where the baseline value of Kp (proportional coefficient) is 1.5; the baseline value of Ki (integral coefficient) is 0.1; the baseline value of Kd (differential coefficient) is 0.05; the inference rules in the fuzzy inference engine are calibrated in advance by experts in this field.

[0061] Preferably, in addition to generating initial PID parameters using a fuzzy inference engine, a data-driven regression model can also be used to predict PID parameters. The implementation process can be illustrated in the following example:

[0062] In a laboratory environment, actuator response data under different vehicle models and load conditions were collected in advance. The specific operation was as follows: Ten mobile robot chassis with different wheel diameters (several units each of 6-inch, 8-inch, and 10-inch wheels) and different reduction ratios (1:20, 1:30, and 1:50) were selected. Under three working conditions—no load, half load, and full load—a complete feature scanning process (step excitation + frequency sweep excitation) was executed to extract five-dimensional feature vectors. Meanwhile, senior engineers manually tuned the optimal PID parameters for each set of features based on their experience. This resulted in 120 sets of "feature-optimal parameter" paired datasets. The datasets were then divided into 80% training and 20% test sets to train a lightweight random forest regression model (containing 100 decision trees, maximum depth 10). The input was a five-dimensional feature vector, and the output was three PID parameter values. After training, the model was deployed to the bridging layer nodes in ONNX format or as a pickle serialized file.

[0063] In actual deployment, after a newly assembled robot is powered on for the first time and completes feature scanning, a five-dimensional feature vector is extracted. The bridging layer nodes input this vector into the loaded random forest regression model for inference, and the model directly outputs the predicted PID parameters. For example, the model inference output... The bridging layer node then sends the set of parameters to the lower-level machine via serial communication frames. The advantage of this scheme is that it eliminates the need for a pre-established expert rule base; the model can automatically learn the complex mapping relationship between features and optimal parameters from the data, and can be periodically retrained to improve prediction accuracy as more data accumulates. The data-driven regression model can include all existing deep learning or machine learning models applicable to this patent; this embodiment uses only the random forest regression model as an example.

[0064] In addition to the fuzzy inference engine and data-driven regression model mentioned above, a combination of the fuzzy inference engine and data-driven regression model can also be used. The bridging layer node first inputs the five-dimensional feature vector into the rule base for fuzzy inference to generate initial PID parameters. The initial parameters and the five-dimensional feature vector are then used as input to a lightweight linear regression fine-tuning model, which outputs the correction values ​​for each parameter. Final output This hybrid strategy combines the interpretability of the rule base with the accuracy advantages of the regression model, further improving parameter matching accuracy through a data-driven approach while ensuring basic security. The final output PID parameters are sent to the lower-level machine via serial communication frames, subsequently entering the online fine-tuning phase during runtime.

[0065] After receiving the initial PID parameters, the lower-level machine begins closed-loop control operation. During operation, the bridging layer node calculates the integral absolute error (IAE) and control saturation frequency in real time based on the status frames uploaded by the lower-level machine every 100ms. If the current IAE exceeds the set threshold of 0.5 for 10 consecutive cycles, or the control saturation frequency exceeds 10% in the last 50 cycles, online fine-tuning is triggered. Fine-tuning adopts a step-by-step adjustment, with each step not exceeding 5% of the current value, and is subject to restrictions. , , For example, the current IAE level remains high, and the bridging layer nodes increase in increments of 0.05. Simultaneously, the system monitors changes in IAE after adjustment. If the IAE increases after adjustment, it immediately reverts to the parameters before adjustment. During continuous fine-tuning, when the IAE remains stable for 10 consecutive seconds and the control saturation frequency remains below 10%, the fine-tuning is considered to have converged. The current PID parameters are then stored in the local YAML configuration file and updated to the "optimal PID parameters." These parameters are loaded as the initial values ​​on the next startup to shorten the tuning time.

[0066] In this embodiment, a startup safety verification and feature scanning mechanism automatically applies a step and sweep frequency composite excitation signal to the actuator while ensuring the vehicle is in a safe, stationary state. Five-dimensional feature vectors—startup delay, rise time, overshoot, steady-state error, and micro-vibration energy—are extracted from encoder feedback data. These feature vectors are then mapped to initial PID parameters adapted to the current actuator's physical characteristics based on fuzzy inference or regression models. This replaces the traditional trial-and-error tuning method that relies on human experience, allowing the PID parameters to adapt to individual hardware differences (such as different wheel diameters and reduction ratios) without human intervention. Simultaneously, an online fine-tuning strategy based on integral absolute error and control quantity saturation frequency triggering during operation, combined with a step-by-step adjustment and stability monitoring backoff mechanism, enables dynamic tracking of PID parameters to operational changes such as motor wear, tire aging, and load variations. After fine-tuning convergence, the optimal parameters are persistently stored for subsequent startup loading, avoiding repeated tuning. This mechanism effectively reduces the reliance on engineer experience in PID parameter tuning, improves the control system's adaptability to individual hardware differences and environmental changes, and ensures the stability of control quality during long-term robot operation.

[0067] S3: Deploy independent diagnostic nodes. These nodes capture and parse DDS / RTPS network communication data in a non-intrusive manner, calculate the communication quality index of each ROS2 topic, and simultaneously collect the status logs of the bridging layer nodes, resource monitoring data of the ROS2 application layer, and status information of each sensor. Based on the communication quality index of each ROS2 topic, the status logs of the bridging layer nodes, the resource monitoring data of the ROS2 application layer, and the status information of each sensor, a diagnostic report for the robot is generated through causal mapping.

[0068] Preferably, step S3 includes:

[0069] S3-1: The diagnostic node uses the underlying library to listen to the network card in promiscuous mode, capture DDS / RTPS network packets, and perform transport layer parsing, RTPS protocol layer parsing, and ROS2 semantic layer parsing on the captured network packets; and simultaneously collects the status logs of the bridging layer node, resource monitoring data of the ROS2 application layer, and status data of each sensor.

[0070] S3-2: Based on the information obtained from parsing, calculate the communication quality index of each ROS2 topic in real time;

[0071] S3-3: Perform time-series correlation of communication quality indicators of each ROS2 topic, status logs of bridging layer nodes, resource monitoring data of ROS2 application layer, and status data of each sensor. Diagnose the cause of failure through causal mapping and generate a diagnostic report for the robot, and publish it through ROS2 topics.

[0072] Preferably, the diagnostic node scores the health of each sensor based on the communication quality index of the ROS2 topic for each sensor, and publishes the health scores of each sensor through the ROS2 topic for the sensor fusion node to subscribe to; the sensor fusion node dynamically adjusts the weight of each sensor in the fusion localization based on the health scores; the sensor fusion node is used to perform fusion localization on multi-sensor data.

[0073] Example 3 is a further improvement based on Examples 1 and 2. As a preferred implementation method, step S3 is specifically implemented in actual deployment as follows:

[0074] In this embodiment, the host computer runs multiple ROS2 nodes, including navigation planning, sensor fusion, LiDAR driving, and IMU driving. All nodes interact with each other via a DDS / RTPS network. The diagnostic node is deployed as an independent ROS2 node in the same DDS domain and runs along with the system when the host computer starts up.

[0075] First, the diagnostic node uses the libpcap library on the Linux platform to listen to the host computer's local loopback network interface (lo) in promiscuous mode, capturing DDS / RTPS network packets. In actual deployment, the listening interface (such as lo, eth0, or wlan0) can be configured to adapt to different network environments. The diagnostic node performs multi-level parsing on each captured packet: transport layer parsing extracts the UDP port number, identifies the DDS domain ID, etc.; counts the traffic of each port; RTPS protocol layer parsing RTPS headers, extracts sub-message types (DATA, HEARTBEAT, ACK_NACK, GAP, etc.) as well as sequence numbers and timestamps; ROS2 semantic layer parsing identifies topic names through the DDS discovery protocol, associates sequence numbers with specific message content, and identifies the QoS policy configuration for each topic; traffic filtering policies are also deployed in the diagnostic node (such as only listening to critical control topics / cmd_vel, / imu, / diagnostics, ignoring high-throughput / scan or / image_raw), or a sampling and parsing period is set (such as capturing packets within 1 second every 1 second).

[0076] Based on the information obtained from deep analysis, the diagnostic node calculates communication quality indicators for each ROS2 topic in real time, including the accurate packet loss rate based on RTPS sequence number gap statistics, the delay jitter based on timestamp variance statistics, the retransmission rate based on the number of ACK_NACK sub-messages, and the back pressure indication determined by the delay of the associated topic sender and the water level of the bridging layer serial port buffer.

[0077] The diagnostic node synchronously collects multi-source underlying information: it obtains status logs such as serial port buffer level, serial port read / write blocking count, and link disconnection and reconnection events by subscribing to the / bridge_status topic published by the bridging layer node; it reads system resource monitoring data such as CPU utilization and memory utilization through Linux system interfaces (such as / proc / stat and / proc / meminfo); it obtains sensor status information such as IMU data quality flag, LiDAR point cloud density, and camera frame rate by subscribing to various sensor topics; at the same time, the diagnostic node also collects environmental event information such as acceleration peak detection (used to determine whether a speed bump has been passed) and GPS signal strength (used to determine whether a tunnel or elevator has been entered).

[0078] The diagnostic node correlates the communication quality indicators of the aforementioned topics with the bridging layer status logs, system resource monitoring data, sensor status information, and environmental events in a time-series manner, diagnosing the causes of faults through causal mapping. Causal mapping can be achieved using one or a combination of three methods: rule-based heuristic mapping (predefining a set of causal rules to map specific symptom combinations to corresponding diagnostic conclusions, confidence levels, and treatment suggestions), Granger causality testing based on time-series dependency graphs (constructing a time-series relationship graph between event nodes and identifying causal relationships between events through statistical tests), or pattern recognition based on machine learning (using a pre-trained classification model to map feature vectors to fault types and probability distributions). Finally, the diagnostic node generates a structured diagnostic report for the robot at the topic level and publishes it via ROS2 topics for the upper-level monitoring system to subscribe for display or log to local log files for offline analysis.

[0079] For example, if the IMU topic packet loss rate is greater than 5%, jitter is greater than 10ms, the time window is less than 1 second, and an acceleration impact is detected at the same time, the diagnosis is "suspected excessive mechanical vibration," and the recommended actions include checking the vehicle suspension damping and checking whether the IMU mounting screws are loose, with a confidence level of 0.85. If the back pressure lasts for more than 5 seconds and the serial port write buffer level is greater than 90%, the diagnosis is "insufficient serial communication rate," and the recommended actions include increasing the serial port baud rate, reducing the topic posting frequency, and enabling data compression, with a confidence level of 0.90. If all topics periodically disconnect for 30 seconds and the dmesg log shows that the USB device is re-identified, the diagnosis is "unstable USB power supply or poor contact," and the recommended actions include replacing the USB cable, using an active USB hub, and checking the USB interface power supply capability, with a confidence level of 0.95. Method two is causal inference based on time-series dependency graphs. A time-series dependency graph is constructed where nodes represent various events (network packet loss, serial port congestion, CPU spikes, vibration detection, etc.), and edges represent temporal sequence and correlation. Granger causality tests are used to identify causal relationships between events, i.e., determining whether the historical value of event A helps predict the future value of event B. Method three is pattern recognition based on machine learning. A lightweight classification model (such as decision trees or random forests) is trained using manually labeled historical fault case data. During real-time inference, newly collected feature vectors are input into the model, outputting the most likely fault type and its probability distribution.

[0080] The diagnostic module generates diagnostic reports at the topic level, including the topic name and status identifier (normal / warning / error), key indicator values ​​(packet loss rate, jitter, retransmission rate, etc.), diagnostic conclusion, confidence level, evidence chain supporting the conclusion, and easy-to-understand handling suggestions. Report output supports multiple methods, including publishing via ROS2 topics (e.g., the / diagnostics_agg topic, compatible with the standard ROS diagnostic framework), displaying in a visualization interface (e.g., RViz2 or a custom monitoring panel), logging to a local log file (supporting offline analysis), and proactively pushing email or SMS alerts when a high-confidence critical fault is detected.

[0081] Furthermore, the diagnostic node scores the health of each sensor based on the communication quality indicators of the corresponding topic, and publishes these scores through the sensor health topic for the sensor fusion node to subscribe to. The sensor fusion node dynamically adjusts the weight of each sensor in the fusion localization process based on the received health scores. When a sensor's health score falls below a set threshold, its fusion weight is reduced or completely removed to prevent faulty sensors from contaminating the fusion results and improve the overall robustness of the system.

[0082] By deploying independent diagnostic nodes and using non-intrusive network interface cards (NICs) with low-level libraries such as libpcap to capture DDS / RTPS network packets, zero-interference data acquisition of communication is achieved without modifying any business node source code, avoiding the impact of traditional intrusive diagnostic methods on system real-time performance. Through multi-layered deep analysis of network packets at the transport layer, RTPS protocol layer, and ROS2 semantic layer, combined with synchronous acquisition of multi-source data including bridging layer status logs, ROS2 resource monitoring data, and sensor status information, communication quality indicators (packet loss rate, jitter, retransmission rate, backpressure, etc.) are time-series correlated with underlying physical events. Causal mapping precisely pinpoints abstract phenomena like "high packet loss rate" in traditional diagnostics to specific physical layer faults such as "serial communication congestion leading to IMU data loss" or "unstable USB power supply causing periodic power outages." It generates structured diagnostic reports containing diagnostic conclusions, confidence levels, evidence chains, and handling suggestions, effectively reducing reliance on engineers' personal experience. Meanwhile, the health scores of each sensor published by the diagnostic node allow the sensor fusion node to dynamically adjust the fusion weights, preventing faulty sensor data from contaminating the fusion results. This significantly improves the diagnostics, maintainability, and overall robustness of the ROS2 robot system at the system architecture level.

[0083] Preferably, the bridging layer node fits a trend curve to the state of the physical hardware layer based on the state frames sent by the physical hardware layer. When the state change rate of the physical hardware layer exceeds a predetermined threshold, the bridging layer node publishes an actuator performance degradation warning through the ROS2 topic.

[0084] In Example 4, the bridging layer node continuously receives status frames actively sent by the lower-level machine at a first predetermined period (e.g., 100ms). These status frames contain information such as the actual speeds of the left and right wheels, PWM duty cycle, encoder count values, battery voltage, and error codes. Each time the bridging layer node receives a status frame, it extracts the key actuator status data (such as speed tracking error, rise time characteristic Tr, etc.) from the frame and stores it in a local circular buffer or log file in time-series format for subsequent trend analysis.

[0085] After each complete feature scan, the bridging layer node records the rise time feature Tr obtained from the current scan and stores it in chronological order in the local / var / robot / tr_history.log file. Each record is formatted as "timestamp, Tr value". The bridging layer node performs a trend analysis once every fixed maintenance cycle (every 10 seconds in this embodiment). Specifically, the node extracts the most recent 200 sets of state data from the circular buffer, and uses the encoder speed tracking error as the vertical axis and time as the horizontal axis to fit a linear trend curve using the least squares method. Where the slope 'a' represents the rate of error change. Taking a certain analysis result as an example: the slope obtained from the fitting... (That is, the speed tracking error continues to increase at a rate of 0.005 m / s per hour). This means that the error increases by 10% every 100 hours. Since this rate of change exceeds a predetermined threshold (in this embodiment, the predetermined threshold is set to 5% / 100h), the bridging layer node determines that the actuator performance has degraded, and then publishes an actuator performance degradation warning message through the / diagnostics topic;

[0086] Simultaneously, the bridging layer node records the trend fitting curve data and early warning information in JSON format to the local log file / var / log / performance_trend.log for offline analysis and maintenance decisions by operations and maintenance personnel. After receiving the early warning notification, the operator performs preventative maintenance on the left motor (such as replacing the tire or adding lubricating oil). After the maintenance is completed, if the bridging layer node detects in subsequent trend analysis that the error change rate has returned to below the threshold (e.g., recovered to 2% / 100h), the early warning status is automatically lifted.

[0087] Furthermore, if the degradation trend continues to worsen, the rise time characteristic Tr recorded by the bridging layer node in subsequent periodic scans shows a gradual increasing trend (e.g., gradually increasing from the initial value of 0.3s to 0.5s). This characteristic change also serves as an auxiliary judgment basis to further confirm the judgment of actuator physical performance degradation. Updated warning information and corresponding maintenance suggestions are published through the / diagnostics topic, realizing the transformation from passive maintenance to proactive warning and effectively reducing the risk of sudden failures.

[0088] By introducing an actuator performance trend tracking and degradation early warning mechanism into the bridging layer node, the system continuously fits the trend curves of key actuator status indicators (such as speed tracking error and rise time characteristics) using the periodically transmitted status frame data from the lower-level machine. When the rate of change of status exceeds a preset threshold, a performance degradation early warning message is automatically triggered and published through the ROS2 topic. This allows maintenance personnel to receive early warnings before the actuator performance deteriorates significantly, thus transforming traditional reactive maintenance into proactive preventive maintenance and effectively reducing the risk of downtime due to sudden hardware failures. At the same time, this mechanism fully reuses the existing status frame data stream of the bridging layer node without the need for additional vibration sensors or monitoring equipment. It achieves continuous tracking and trend prediction of the actuator's health status without increasing hardware costs, further improving the maintainability and operational reliability of the ROS2 robot system.

[0089] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. An integrated robot communication control method for ROS2, characterized in that, include: S1: Deploy an independent bridging layer node between the ROS2 application layer and the physical hardware layer; wherein, the bridging layer node is used to realize bidirectional transparent conversion between ROS2 standard messages and serial communication frames, to perform comprehensive priority evaluation and preemptive scheduling of multi-source control commands, and to implement real-time monitoring and anomaly recovery of the physical hardware layer link. S2: Under predetermined triggering conditions, the physical hardware layer is controlled by the bridging layer node to apply excitation signals to the actuator, and feedback data from the encoder corresponding to the physical hardware layer is continuously collected; feature vectors characterizing the physical characteristics of the actuator are extracted based on the encoder feedback data, and the feature vectors characterizing the physical characteristics of the actuator are mapped to initial PID parameters; and the PID parameters are fine-tuned online based on the control performance during operation. S3: Deploy independent diagnostic nodes. These nodes capture and parse DDS / RTPS network communication data in a non-intrusive manner, calculate the communication quality index of each ROS2 topic, and simultaneously collect the status logs of the bridging layer nodes, resource monitoring data of the ROS2 application layer, and status information of each sensor. Based on the communication quality index of each ROS2 topic, the status logs of the bridging layer nodes, the resource monitoring data of the ROS2 application layer, and the status information of each sensor, a diagnostic report for the robot is generated through causal mapping.

2. The integrated robot communication control method for ROS2 according to claim 1, characterized in that, The ROS2 application layer includes multiple ROS2 nodes; the ROS2 nodes communicate with each other through a DDS / RTPS network, which adopts a decentralized publish-subscribe communication architecture. Each ROS2 node, as a participant in the DDS domain, automatically discovers each other and establishes communication connections through a distributed discovery protocol; the ROS2 nodes support one-to-one, one-to-many, and many-to-many communication modes; the diagnostic node and the bridging layer node are each deployed as a ROS2 node in the DDS domain.

3. The integrated robot communication control method for ROS2 according to claim 1, characterized in that, The bidirectional transparent conversion between ROS2 standard messages and serial communication frames includes: S1-1-1: The bridge layer node reads the protocol mapping rule file stored externally. The protocol mapping rule file defines the correspondence between ROS2 topic names and message types, the mapping rules from message fields to communication frame byte positions, data conversion rules, and the format definition of communication frames. S1-1-2: During downlink switching, the bridging layer node subscribes to the specified ROS2 topic, converts the received ROS2 standard messages into serial communication frames according to the protocol mapping rule file, and sends them to the physical hardware layer. S1-1-3: During uplink conversion, the bridge layer node listens to the serial port byte stream, parses the received serial communication frames into ROS2 standard messages according to the protocol mapping rule file, and publishes them to the corresponding ROS2 topic. S1-1-4: The bridging layer node monitors changes to the protocol mapping rule file in real time. Upon detecting a change, it automatically reloads the configuration, enabling runtime updates of the protocol mapping rule file without restarting each ROS2 node. A version identifier for the protocol mapping rule file is defined in the communication frame structure. Based on the version identifier, the corresponding protocol mapping rule file is automatically identified and selected to parse the communication frame, achieving parallel support for multiple protocol versions.

4. The integrated robot communication control method for ROS2 according to claim 1, characterized in that, The execution of comprehensive priority evaluation and preemptive scheduling of multi-source control commands includes: S1-2-1: The bridging layer node establishes an instruction cache queue for each control source and presets different static priority levels for instructions from different control sources; S1-2-2: Calculate the time priority of each instruction based on the timestamp of each instruction arriving at the bridging layer node, and determine the emergency priority of each instruction based on its content; S1-2-3: The overall priority of an instruction is obtained by weighted summing of its time priority, static priority level, and emergency priority. S1-2-4: Continuously evaluate the overall priority of the instructions at the head of each instruction cache queue, and select the instruction with the highest overall priority to send to the physical hardware layer; S1-2-5: Continuously evaluate the overall priority of newly arrived instructions to the bridging layer node. When the overall priority of newly arrived instructions to the bridging layer node is higher than the first set threshold, interrupt the transmission of the current instruction, clear all instruction cache queues, cache the newly arrived instruction to the corresponding instruction cache queue, and send the newly arrived instruction with priority.

5. The integrated robot communication control method for ROS2 according to claim 1, characterized in that, The implementation of real-time monitoring and anomaly recovery of the physical hardware layer link includes: S1-3-1: The bridging layer node receives the status frame actively sent by the physical hardware layer in the first predetermined period, and publishes the uplink transition of the status frame to the corresponding ROS2 topic; if no status frame is received from the physical hardware layer within the second predetermined period, the uplink is determined to be abnormal. S1-3-2: If a bridging layer node sends a probe frame to the physical hardware layer in the third predetermined period and does not receive a response frame from the physical hardware layer within the fourth predetermined period, it determines that the downlink is abnormal. S1-3-3: When the uplink or downlink fails, the bridging layer node suspends sending instructions to the physical hardware layer, suspends receiving new instructions from each control source, and clears the instruction buffer queue of each control source; it attempts to reconnect to the physical hardware layer using the exponential backoff algorithm, and resumes receiving instructions from each control source and sending instructions after a successful reconnection.

6. The integrated robot communication control method for ROS2 according to claim 5, characterized in that, Step S2 includes: S2-1: Under predetermined triggering conditions, the bridging layer node reads the robot's state data from the state frame uploaded by the physical hardware layer. At the same time, the bridging layer node obtains the data collected by each sensor of the robot by subscribing to the ROS2 topic of each sensor of the robot. Based on the robot's state data and the data collected by each sensor of the robot, the safety conditions are verified according to the preset safety conditions. If the safety condition verification fails, step S2-2 is executed. If the safety condition verification passes, step S2-3 is executed. S2-2: The bridging layer node directly loads the default PID parameters or the locally stored optimal PID parameters as the initial PID parameters, and sends the initial PID parameters to the physical hardware layer through the serial communication frame. S2-3: The bridging layer node sends PWM excitation commands to the physical hardware layer through serial communication frames, and the physical hardware layer operates according to the PWM excitation commands; the bridging layer node generates initial PID parameters according to the status frames sent by the physical hardware layer through preset mapping rules, and sends the initial PID parameters to the physical hardware layer through serial communication frames. S2-4: The physical hardware layer performs PID control operation based on the received PID parameters. The bridge layer node calculates the integral absolute error and control saturation frequency in real time based on the status frame sent by the physical hardware layer, and adaptively adjusts the current PID parameters based on the integral absolute error and control saturation frequency. The adjusted PID parameters are then sent to the physical hardware layer through a serial communication frame. S2-5: Repeat step S2-4 until the integral absolute error remains stable for a continuously preset first time and the saturation frequency of the control quantity is lower than the set threshold. When the fine-tuning converges, the PID parameters after fine-tuning convergence are used to update the locally stored optimal PID parameters.

7. The integrated robot communication control method for ROS2 according to claim 6, characterized in that, The bridging layer node generates initial PID parameters based on the status frames sent by the physical hardware layer according to preset mapping rules. This includes: the bridging layer node extracts five-dimensional features from the status frames sent by the physical hardware layer, including: start-up delay features, rise time features, overshoot features, steady-state error features, and micro-vibration energy features, forming a five-dimensional feature vector; and the five-dimensional feature vector is predicted and mapped to the initial PID parameters through fuzzy inference or regression models.

8. The integrated robot communication control method for ROS2 according to claim 1, characterized in that, Step S3 includes: S3-1: The diagnostic node uses the underlying library to listen to the network card in promiscuous mode, capture DDS / RTPS network packets, and perform transport layer parsing, RTPS protocol layer parsing, and ROS2 semantic layer parsing on the captured network packets; and simultaneously collects the status logs of the bridging layer node, resource monitoring data of the ROS2 application layer, and status data of each sensor. S3-2: Based on the information obtained from parsing, calculate the communication quality index of each ROS2 topic in real time; S3-3: Perform time-series correlation of communication quality indicators of each ROS2 topic, status logs of bridging layer nodes, resource monitoring data of ROS2 application layer, and status data of each sensor. Diagnose the cause of failure through causal mapping and generate a diagnostic report for the robot, and publish it through ROS2 topics.

9. The integrated robot communication control method for ROS2 according to claim 6, characterized in that, The bridging layer node fits a trend curve to the physical hardware layer's state based on the state frames sent by the physical hardware layer. When the rate of change of the physical hardware layer's state exceeds a predetermined threshold, the bridging layer node publishes an actuator performance degradation warning through the ROS2 topic.

10. The integrated robot communication control method for ROS2 according to claim 8, characterized in that, The diagnostic node scores the health of each sensor based on the communication quality metrics of the ROS2 topic for each sensor, and publishes the health scores of each sensor through the ROS2 topic for the sensor fusion node to subscribe to. The sensor fusion node dynamically adjusts the weight of each sensor in the fusion positioning based on the health score.

Images