Robot operating system communication method, electronic device, and storage medium

Abstract

This invention discloses a robot operating system communication method, comprising the following steps: installing a robot operating system and deploying FastDDS; when the robot operating system publishes or subscribes to messages, the hard real-time operating system obtains the QoS configuration parameters of the messages and calculates the real-time priority index; establishing a mapping strategy between the robot operating system's QoS and the hard real-time operating system's priority in the hard real-time operating system; binding corresponding priorities to message processing threads based on the real-time priority index; executing tasks based on priority scheduling and dynamic priority adjustment mechanisms; deploying a load monitoring thread, which statistically analyzes system load data, task load data, and network load data at preset intervals and adjusts thread priorities and resource allocation in real time. This robot operating system communication method allows QoS configuration to directly determine the initial priority of tasks in the hard real-time operating system, and also dynamically influences QoS resource allocation based on system load.

Description

Technical Field

[0001] This invention relates to the field of robot control technology, specifically to a robot operating system communication method, electronic device, and storage medium. Background Technology

[0002] ROS2 is a mainstream open-source framework for robot development, employing DDS as its underlying communication mechanism to provide reliable support for data interaction in distributed systems. FastDDS is a commonly used DDS implementation of ROS2, achieving relatively efficient data transmission in general scenarios. However, in applications with extremely high real-time requirements, such as robot control and industrial automation, existing communication systems based on ROS2FastDDS have significant shortcomings. Their internal QoS is completely isolated from the underlying OS scheduling priority, meaning that high QoS settings cannot effectively translate into a preemptive advantage for execution resources.

[0003] Furthermore, under high loads, high QoS control messages may compete for resources with low QoS log messages, compromising real-time performance and failing to meet the microsecond-level communication requirements of hard real-time scenarios. In hard real-time applications, data transmission latency jitter can lead to serious consequences such as robot control malfunctions and industrial equipment failures. Moreover, existing technologies have not fully optimized ROS2FastDDS to leverage the characteristics of hard real-time operating systems, failing to effectively utilize the deterministic task scheduling and low-latency interrupt handling capabilities of hard real-time operating systems. Summary of the Invention

[0004] To overcome the shortcomings of the prior art, the present invention provides a robot operating system communication method, electronic device and storage medium. The robot operating system communication method allows QoS configuration to directly determine the initial priority of hard real-time operating system tasks, and can also dynamically affect the resource allocation of QoS according to the system load.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is: a robot operating system communication method, comprising the following steps:

[0006] The hard real-time operating system establishes a priority mapping strategy table;

[0007] The hard real-time operating system obtains QoS configuration parameters, which are derived from the robot operating system.

[0008] Based on the acquired QoS configuration parameters, the QoS configuration parameters are converted into a real-time priority index through a QoS feature weighting algorithm;

[0009] Based on the real-time priority index, the priority corresponding to the priority index is determined according to the priority mapping strategy table;

[0010] Priorities are bound to the corresponding message processing threads, and the hard real-time operating system runs message processing threads based on priorities;

[0011] The hard real-time operating system collects system load data, task load data, and network load data at preset intervals.

[0012] Resource allocation is adjusted in real time based on system load data, task load data, and network load data.

[0013] Through the above technical solution, the robot operating system communication method disclosed in this application not only allows QoS configuration to directly determine the initial priority of hard real-time operating system tasks, but also dynamically affects the resource allocation of QoS according to the system load.

[0014] Furthermore, based on the acquired QoS configuration parameters, the QoS configuration parameters are converted into a real-time priority index using a QoS feature weighting algorithm:

[0015] The QoS configuration parameters include deadline, reliability, message size, and user identifier. The feature weighting algorithm includes the following calculation rules:

[0016] QoS configuration parameters are converted into a real-time priority index using a QoS feature-weighted algorithm. The QoS configuration parameters include deadline, reliability, message size, and user identifier. The feature-weighted algorithm includes the following calculation rules:

[0017] Calculate the deadline weight based on the deadline numerical value;

[0018] Reliability weights are calculated based on reliability.

[0019] Message weight is calculated based on message size;

[0020] Calculate user identifier weights based on user identifiers;

[0021] Real-time priority index = (deadline weight + reliability weight + message weight + user identifier weight) * 100.

[0022] Furthermore, the hard real-time operating system establishes a priority mapping strategy table including:

[0023] A mapping table between real-time priority index and hard real-time operating system priority is established and compiled into the kernel. The mapping table includes dividing the numerical range of real-time priority index into at least three numerical intervals according to gradient, dividing the hard real-time operating system priority into priority intervals that correspond one-to-one with the numerical intervals, and binding the numerical intervals and priority intervals in pairs.

[0024] Furthermore, the step of determining the priority corresponding to the priority index based on the real-time priority index and according to the priority mapping strategy table includes:

[0025] Determine the numerical range corresponding to the real-time priority index, and the corresponding priority range;

[0026] Calculate the priority increment corresponding to the real-time priority index, where the priority increment = priority interval length / numerical interval length;

[0027] Calculate the priority offset, where the priority offset = (real-time priority index - starting point of the numerical range) * priority increment;

[0028] Priority = Priority interval start point + Priority offset.

[0029] Furthermore, the calculation method for the real-time priority index is as follows:

[0030] The initial value of the deadline weight is set to 0: if deadline ≤ 10ms, the deadline weight is increased by 40%; if 10ms < deadline ≤ 100ms, the deadline weight is increased by 40% - (t-10) / 90*40%; if deadline > 100ms, the deadline weight is decreased by 20%, where t is the value of deadline.

[0031] The initial value of the reliability weight is set to 0. If the reliability is RELIABLE, the reliability weight is increased by 30%; if the reliability is BEST_EFFORT, the reliability weight is decreased by 10%.

[0032] The initial value of the message weight is set to 0. If the message size is less than 1KB, the message weight is increased by 10%. If 1KB ≤ message size ≤ 1MB, the message weight is increased by 0. If the message size is greater than 1MB, the message weight is decreased by 30%.

[0033] The initial value of the user identifier weight is set to 0. If the user identifier is CRITICAL, the user identifier weight is increased by 20%. If the user identifier is other, the user identifier weight is increased by 0.

[0034] Real-time priority index = (deadline weight + reliability weight + message weight + user identifier weight) * 100.

[0035] Furthermore, the binding of priorities to corresponding message processing threads, and the hard real-time operating system running message processing threads based on priorities, includes:

[0036] The hard real-time operating system binds a corresponding priority to the message processing thread and registers a dynamic adjustment flag for that thread.

[0037] Hard real-time operating systems pre-create worker threads for different priorities, and the mapping engine distributes messages to the corresponding thread queues. Hard real-time operating systems execute tasks based on priority scheduling and dynamic priority adjustment mechanisms.

[0038] Furthermore, the real-time adjustment of resource allocation based on system load data, task load data, and network load data includes:

[0039] When the load exceeds the first preset value, the scheduler lowers the priority of the message processing thread corresponding to non-critical messages, locks the priority of the message processing thread corresponding to critical messages, compresses or delays the sending of non-critical messages, prioritizes CPU allocation for critical messages, and reduces the bandwidth of non-critical messages.

[0040] Among them, the key messages must meet the following conditions: deadline is less than or equal to the second preset value, reliability is RELIABLE, real-time priority index is greater than or equal to the third preset value, and the business tag belongs to the control flow and is in the pre-configured key file;

[0041] The non-critical messages must meet the following requirements: no deadline, reliability of BEST_EFFORT, and real-time priority index less than the fourth preset value; or the business tag belongs to the data stream and is in a pre-configured non-critical file.

[0042] Furthermore, it also includes:

[0043] Embed the FastDDS microkernel into the kernel of a hard real-time operating system;

[0044] Bind the receive interrupt of the Ethernet controller to a high-priority real-time thread of the FastDDS microkernel;

[0045] A shared memory managed in kernel mode is allocated as a data exchange medium.

[0046] An electronic device includes: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described robot operating system communication method.

[0047] A storage medium, which is a computer-readable storage medium, stores a computer program that, when executed by a multi-core processor, implements the above-described robot operating system communication method.

[0048] By employing the above technical solutions, the beneficial effects of the present invention are as follows:

[0049] In this application, a priority mapping strategy table is established in the hard real-time operating system to convert the QoS of the robot operating system into the priority of the hard real-time operating system. This allows the QoS configuration to directly determine the initial priority of the hard real-time operating system tasks, thereby effectively converting the high priority set by QoS into a preemptive advantage for execution resources.

[0050] This application deploys a load monitoring thread to collect system load data, task load data, and network load data at preset intervals, and adjusts thread priority and resource allocation in real time based on the system load data, task load data, and network load data.

[0051] To make the above and other objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a flowchart of the robot operating system communication method in an embodiment of the present invention. Detailed Implementation

[0054] 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.

[0055] It should be noted that in the description of this invention, the terms "first," "second," etc., are used only for descriptive purposes and to distinguish similar objects; there is no order between them, nor should they be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0056] Example: Figure 1 As shown, this embodiment discloses a robot operating system communication method, including the following steps:

[0057] Install the robot operating system in the hard real-time operating system, and deploy FastDDS as the underlying communication middleware in the robot operating system;

[0058] The hard real-time operating system establishes a priority mapping strategy table;

[0059] The hard real-time operating system obtains QoS configuration parameters, which are derived from the robot operating system.

[0060] Calculate the real-time priority index based on the acquired QoS configuration parameters;

[0061] Based on the real-time priority index, the priority corresponding to the priority index is determined according to the priority mapping strategy table;

[0062] Priorities are bound to the corresponding message processing threads, and the hard real-time operating system runs message processing threads based on priorities;

[0063] The hard real-time operating system collects system load data, task load data, and network load data at preset intervals.

[0064] Resource allocation is adjusted in real time based on system load data, task load data, and network load data.

[0065] Through the above technical solution, the robot operating system communication method disclosed in this application not only allows QoS configuration to directly determine the initial priority of hard real-time operating system tasks, but also dynamically affects the resource allocation of QoS according to the system load.

[0066] In some feasible embodiments, the ROS2 system is installed in the NECRO industrial real-time operating system, and FastDDS is deployed in the ROS2 system as the underlying communication middleware, and the FastDDS microkernel is embedded in the kernel of the hard real-time operating system.

[0067] Among them, ROS2 (Robot Operating System 2) is a new generation of open source robot operating system. It adopts a distributed communication architecture, realizes automatic node discovery and communication through DDS middleware, and supports cross-device communication and multi-robot collaboration, real-time data transmission and QoS control, and automatic network anomaly recovery capabilities.

[0068] FastDDS is an open-source data distribution service implementation that supports zero-copy transmission, shared memory, and UDP multicast optimization.

[0069] The NECRO industrial real-time operating system employs preemptive priority scheduling, allowing high-priority tasks to immediately interrupt low-priority tasks. It supports the earliest deadline-first algorithm to dynamically allocate task execution order. A built-in deadline monitoring module triggers error callbacks or system recovery upon timeout, thus strictly ensuring that tasks are completed within a defined time window. Compared to soft real-time operating systems that allow for some delay, this system imposes strict time constraints. If a task is not completed before its deadline, the system will determine it as a critical failure, triggering an interrupt to forcibly terminate the failed task and initiating a preset recovery process, such as restarting the task or calling an emergency handling procedure.

[0070] In some feasible embodiments, a new dds_kern_module module is added based on the hard real-time kernel extension of the hard real-time operating system. This module includes three main functions: message queue management, priority resolution, and shared memory interface. It is a kernel-level extension module whose core objective is to solve the latency uncertainty problem of traditional user-space DDS (such as FastDDS) in hard real-time scenarios. By sinking the core DDS communication logic to the kernel space, it achieves low latency, high determinism, and zero-copy characteristics for message transmission. In this embodiment, the dds_kern_module module is used to implement the following functions:

[0071] Shared memory interface:

[0072] The dds_kern_module module pre-allocates 1MB of contiguous physical memory as a shared memory pool managed by the kernel during initialization.

[0073] The dds_kern_module module exposes system calls to user space, allowing ROS2 nodes to directly write messages to pre-allocated contiguous physical memory via the user-space write interface (rt_shm_write()). User-space applications obtain contiguous physical memory addresses through the API provided by the dds_kern_module module and write message data directly without kernel-space copying.

[0074] The kernel-mode FastDDS microkernel directly accesses data in the physical memory pool through the kernel-mode read interface (rt_shm_read()) (without copying from user mode to kernel mode), parses the message header (containing metadata such as target node and priority), and then delivers it to the corresponding message queue.

[0075] Message queue management:

[0076] The kernel maintains multiple message queues divided according to the target node, and each queue is sorted according to message priority.

[0077] After rt_shm_read() reads a message, it inserts it into the queue according to the message priority;

[0078] When a target node (such as a control node) requests a message through the kernel interface, the dds_kern_module module extracts the highest priority message from the head of the queue and directly returns the contiguous physical memory address.

[0079] In some feasible implementations, the dds_kern_module module has a built-in timeout mechanism. If a message stays in the queue for more than a threshold, a warning is triggered or the message is discarded to avoid expired messages affecting real-time performance.

[0080] Priority analysis:

[0081] Parse the QoS parameters of the ROS2 message and map them to the task priority of the hard real-time kernel;

[0082] When a low-priority node holds resources required by a high-priority message (such as a shared memory lock), the dds_kern_module module triggers a priority inheritance mechanism (to prevent priority inversion) and temporarily raises the priority of the low-priority node to the requester level.

[0083] Priority resolution includes the following steps:

[0084] When a hard real-time operating system establishes a priority mapping policy table, it establishes a mapping relationship table between the real-time priority index and the priority of the hard real-time operating system, and compiles the mapping relationship table into the kernel.

[0085] In the mapping table between the real-time priority index and the hard real-time operating system priority, the numerical range of the real-time priority index is divided into at least three numerical intervals according to the gradient, the hard real-time operating system priority is divided into priority intervals that correspond one-to-one with the numerical intervals, and the numerical intervals and priority intervals are paired and bound together.

[0086] The real-time priority index ranges from [0, 100), and the hard real-time operating system priority ranges from [1, 255). The mapping relationship between the real-time priority index and the hard real-time operating system priority is as follows:

[0087] The real-time priority index [80, 100) corresponds to the priority [200; 255);

[0088] The real-time priority index [50, 79) corresponds to the priority [100; 200);

[0089] The real-time priority index [0; 50) corresponds to the priority [1; 100), and the range of the real-time priority index corresponds to the non-real-time level.

[0090] The hard real-time operating system obtains QoS configuration parameters by: when ROS2 system nodes publish or subscribe to messages through the FastDDS middleware, the DDS entity management engine intercepts QoS configuration in real time through DataWriterListener. These QoS configuration parameters include: time constraints: deadline (message timeout) and lifespan (message validity period); reliability: RELIABLE (reliable transmission) and BEST_EFFORT (best-effort transmission); resource requirements: message size and publication frequency; and user identifier.

[0091] FastDDS passes the intercepted QoS configuration to the hard real-time operating system through the microkernel real-time scheduling layer. The hard real-time operating system then calculates the real-time priority index based on the aforementioned QoS configuration parameters.

[0092] In some feasible embodiments, QoS configuration parameters are converted into real-time priority indices using a QoS feature weighting algorithm, which includes the following calculation rules:

[0093] Deadline weight: If deadline ≤ 10ms, the weight increases by 40%; if 10ms < deadline ≤ 100ms, the weight increases by 40% - (t-10) / 90*40%; if deadline > 100ms, the weight decreases by 20%; where t is the value of deadline.

[0094] Reliability weight: if the reliability is RELIABLE, the weight is increased by 30%; if the reliability is BEST_EFFORT, the weight is decreased by 10%.

[0095] Message weighting: if the message size is less than 1KB, the weight increases by 10%; if the message size is between 1KB and 1MB, the weight increases by 0%; if the message size is greater than 1MB, the weight decreases by 30%.

[0096] User identifier weight: if the user identifier is CRITICAL, the weight is increased by 20%; if the user identifier is other, the weight is increased by 0.

[0097] The initial values ​​for the deadline weight, reliability weight, message weight, and user identifier weight are all 0.

[0098] Real-time priority index = (deadline weight + reliability weight + message weight + user identifier weight) * 100.

[0099] Based on the real-time priority index, the priority corresponding to the priority index is determined according to the priority mapping strategy table, and the priority is bound to the corresponding message processing thread.

[0100] In some feasible embodiments, the priority calculation steps are as follows:

[0101] Determine the numerical range corresponding to the real-time priority index, and the corresponding priority range;

[0102] Calculate the priority increment corresponding to the real-time priority index, where the priority increment = priority interval length / numerical interval length;

[0103] Calculate the priority offset, where the priority offset = (real-time priority index - starting point of the numerical range) * priority increment;

[0104] Priority = Priority interval start point + Priority offset, where if the calculation result is a decimal, it is rounded to the nearest integer.

[0105] Taking a real-time priority index of 88 as an example, 88 corresponds to the numerical range [80, 100), and the priority range is [200; 255). The length of this numerical range is 20, and the length of the priority range is 55.

[0106] Priority increment = Priority interval length / Numerical interval length = 55 / 20 = 2.75;

[0107] Priority offset = (real-time priority index - starting point of numerical range) * priority increment = (88-80) * 2.75 = 22;

[0108] Priority = Priority interval start point + Priority offset = 200 + 22 = 222.

[0109] In some feasible implementations, the Ethernet controller's receive interrupt is bound to a high-priority real-time thread of the FastDDS microkernel. Specifically, the Ethernet PHY's receive interrupt is bound to the FastDDS microkernel's `niic_dds_irq_handler()` function. With this technical solution, upon interrupt arrival, the hardware driver layer performs only minimal frame filtering, and the data frame is immediately taken over and processed by the FastDDS microkernel thread, thus reducing the delay time from interrupt to protocol processing.

[0110] In some feasible implementations, the hard real-time operating system calls the pthread_setschedparam system call to bind the corresponding priority to the message processing thread and registers a dynamic adjustment flag for the thread, allowing the adaptive scheduler to directly modify its priority later.

[0111] Specifically, if the real-time priority index is between [80, 100), the priority adjustment range set by the pthread_setschedparam system call for the message processing thread is [200; 255). If the real-time priority index is between [50, 79), the priority adjustment range set by the pthread_setschedparam system call for the message processing thread is [100; 200). If the real-time priority index is between [0; 50), the priority adjustment range set by the pthread_setschedparam system call for the message processing thread is [1; 100).

[0112] In some feasible embodiments, the hard real-time operating system performs tasks based on priority scheduling and dynamic priority adjustment mechanisms, including:

[0113] Design a static rule and dynamic parameter strategy library for a hard real-time operating system. Prioritize the hard real-time operating system according to real-time requirements and specify the elasticity coefficient for each level. For example, set priority [200; 255) to level P0, with a preemptive priority scheduling strategy (SCHED_FIFO) and an elasticity coefficient of 0 (dynamic adjustment is prohibited); set priority [100; 200) to level P1, with a time-slice round-robin scheduling strategy (SCHED_RR), a fixed time slice of 5ms, and an elasticity coefficient that can be reduced by 40% under overload and increased by 30% under low load; set priority [1; 100) to level P2, with a dynamic elastic scheduling strategy, an elasticity coefficient that can be reduced by 70% under overload and increased by 60% under low load, and level P2 must not occupy the reserved resources of P0 or P1 tasks.

[0114] Hard real-time operating systems pre-create worker threads for different priorities. The mapping engine distributes messages to the corresponding thread queues, and the hard real-time operating system executes tasks based on priority scheduling and dynamic priority adjustment mechanisms. Specifically, when the hard real-time operating system detects an anomaly, the scheduler adjusts thread priorities in real time.

[0115] In some feasible embodiments, a dynamic performance monitoring module is deployed in the hard real-time operating system. This module collects system load data, task load data, and network load data every 10ms. The system load data includes the CPU utilization of threads in each priority range, the latency of high-priority threads, and the number of priority inversion events.

[0116] The task load data includes the deadline fulfillment rate of critical messages and message processing latency;

[0117] The network load data includes the actual transmission bandwidth of messages, the message queue backlog length, and the message drop rate.

[0118] The hard real-time operating system adjusts thread priorities and resource allocation in real time based on system load data, task load data, and network load data. This includes: when the load is detected to exceed a first preset value, such as when the deadline fulfillment rate of critical messages is <90%, the scheduler reduces the priority of message processing threads corresponding to non-critical messages, locks the priority of message processing threads corresponding to critical messages, compresses or delays the sending of non-critical messages, prioritizes CPU allocation for critical messages, and reduces the bandwidth of non-critical messages.

[0119] For example, when the critical message deadline satisfaction rate is detected to be less than 90%, the scheduler triggers the following operation:

[0120] For critical messages, their priority is temporarily raised to the highest value in the range (e.g., directly raised to 254 in the range [200; 255), real-time network resources are locked, 30% of the minimum bandwidth is reserved for them, and their priority is set to the top in the middleware message queue, skipping the queuing of non-critical messages.

[0121] For non-critical messages, their priority is temporarily reduced to the lowest value in the range (e.g., in the range [100; 200), it is directly reduced to 100), bandwidth compression is implemented, and high-bandwidth messages are dynamically reduced in acquisition (e.g., 1080P is changed to 720P) or the frame rate is reduced (e.g., 30fps is changed to 10fps). A delayed sending strategy is adopted (e.g., it is sent in packets every 100ms to reduce the transmission frequency, and the delay time does not exceed its lifespan).

[0122] When the dynamic performance monitoring module detects a load drop, such as when the critical message deadline satisfaction rate is ≥98%, the scheduler will restore the priority and resource configuration to their initial values.

[0123] Among them, the critical messages must meet the following requirements: deadline≤50ms, reliability is RELIABLE, real-time priority index≥80, and the business tag belongs to the control flow and is in the pre-configured critical_topics.yaml;

[0124] The non-critical messages must meet the following conditions: no deadline, reliability of BEST_EFFORT, real-time priority index < 50, or the business tag belongs to the data stream and is in non_critical_topics.yaml.

[0125] This application also discloses an electronic device, comprising: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; and at least one memory connected to the at least one bus, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described robot operating system communication method.

[0126] This application also discloses a storage medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a multi-core processor, it implements the above-described robot operating system communication method.

[0127] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A robot operating system communication method, characterized in that, Includes the following steps: The hard real-time operating system establishes a priority mapping strategy table, which includes establishing a mapping relationship table between real-time priority index and hard real-time operating system priority, and compiling the mapping relationship table into the kernel; The hard real-time operating system obtains QoS configuration parameters, which are derived from the robot operating system. Based on the acquired QoS configuration parameters, the QoS configuration parameters are converted into a real-time priority index through a QoS feature weighting algorithm; Based on the real-time priority index, the priority corresponding to the real-time priority index is determined according to the priority mapping strategy table. Priorities are bound to the corresponding message processing threads, and the hard real-time operating system runs message processing threads based on priorities; The hard real-time operating system collects system load data, task load data, and network load data at preset intervals. Resource allocation is adjusted in real time based on system load data, task load data, and network load data.

2. The robot operating system communication method as described in claim 1, characterized in that, The process of converting the acquired QoS configuration parameters into a real-time priority index using a QoS feature weighting algorithm includes: The QoS configuration parameters include deadline, reliability, message size, and user identifier. The feature weighting algorithm includes the following calculation rules: Calculate the deadline weight based on the deadline numerical value; Reliability weights are calculated based on reliability. Message weight is calculated based on message size; Calculate user identifier weights based on user identifiers; Real-time priority index = (deadline weight + reliability weight + message weight + user identifier weight) * 100.

3. The robot operating system communication method as described in claim 1, characterized in that, The hard real-time operating system establishes a priority mapping strategy table including: The mapping table between the real-time priority index and the hard real-time operating system priority includes dividing the numerical range of the real-time priority index into at least three numerical intervals according to the gradient, dividing the hard real-time operating system priority into priority intervals that correspond one-to-one with the numerical intervals, and binding the numerical intervals and priority intervals in pairs.

4. The robot operating system communication method as described in claim 3, characterized in that, The determination of the priority corresponding to the priority index based on the real-time priority index and the priority mapping strategy table includes: Determine the numerical range corresponding to the real-time priority index, and the corresponding priority range; Calculate the priority increment corresponding to the real-time priority index, where the priority increment = priority interval length / numerical interval length; Calculate the priority offset, where the priority offset = (real-time priority index - starting point of the numerical range) * priority increment; Priority = Priority interval start point + Priority offset.

5. The robot operating system communication method as described in claim 2, characterized in that, The real-time priority index is calculated as follows: The initial value of the deadline weight is set to 0: if deadline ≤ 10ms, the deadline weight is increased by 40%; if 10ms < deadline ≤ 100ms, the deadline weight is increased by 40% - (t-10) / 90*40%; if deadline > 100ms, the deadline weight is decreased by 20%, where t is the value of deadline. The initial value of the reliability weight is set to 0. If the reliability is RELIABLE, the reliability weight is increased by 30%; if the reliability is BEST_EFFORT, the reliability weight is decreased by 10%. The initial value of the message weight is set to 0. If the message size is less than 1KB, the message weight is increased by 10%. If 1KB ≤ message size ≤ 1MB, the message weight is increased by 0. If the message size is greater than 1MB, the message weight is decreased by 30%. The initial value of the user identifier weight is set to 0. If the user identifier is CRITICAL, the user identifier weight is increased by 20%. If the user identifier is other, the user identifier weight is increased by 0. Real-time priority index = (deadline weight + reliability weight + message weight + user identifier weight) * 100.

6. The robot operating system communication method as described in claim 5, characterized in that, The process of binding priorities to corresponding message processing threads, and the hard real-time operating system running message processing threads based on priorities, includes: The hard real-time operating system binds a corresponding priority to the message processing thread and registers a dynamic adjustment flag for that thread. Hard real-time operating systems pre-create worker threads for different priorities, and the mapping engine distributes messages to the corresponding thread queues. Hard real-time operating systems execute tasks based on priority scheduling and dynamic priority adjustment mechanisms.

7. The robot operating system communication method as described in claim 4, characterized in that, The real-time adjustment of resource allocation based on system load data, task load data, and network load data includes: When the load exceeds the first preset value, the scheduler lowers the priority of the message processing thread corresponding to non-critical messages, locks the priority of the message processing thread corresponding to critical messages, compresses or delays the sending of non-critical messages, prioritizes CPU allocation for critical messages, and reduces the bandwidth of non-critical messages. Among them, the key messages must meet the following conditions: deadline is less than or equal to the second preset value, reliability is RELIABLE, real-time priority index is greater than or equal to the third preset value, and the business tag belongs to the control flow and is in the pre-configured key file; The non-critical messages must meet the following requirements: no deadline, reliability of BEST_EFFORT, and real-time priority index less than the fourth preset value; or the business tag belongs to the data stream and is in a pre-configured non-critical file.

8. The robot operating system communication method as described in claim 1, characterized in that, Also includes: Embed the FastDDS microkernel into the kernel of a hard real-time operating system; Bind the receive interrupt of the Ethernet controller to a high-priority real-time thread of the FastDDS microkernel; A shared memory managed in kernel mode is allocated as a data exchange medium.

9. An electronic device, characterized in that, include: At least one communication interface; At least one bus connected to the at least one communication interface; At least one processor connected to the at least one bus; At least one memory connected to the at least one bus, wherein the memory stores a computer program, and the processor executes the computer program to implement the robot operating system communication method according to any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a multi-core processor, it implements the robot operating system communication method as described in any one of claims 1-8.

Images