Real-time communication method, device, equipment, medium and program product of robot control system

Abstract

The application provides a real-time communication method, device and equipment of a robot control system, a storage medium and a program product, and can be applied to the technical field of robots. The real-time communication method of the robot control system comprises the following steps: deploying a compliant execution layer in a real-time thread of a first operating system and running at a first control period; deploying an application layer and a collaborative planning layer in a non-real-time thread of a second operating system; the application layer transmits a standardized task sequence to the collaborative planning layer through a first communication mode; the collaborative planning layer sends a desired trajectory and a force control target value through a second communication mode; the compliant execution layer executes a control algorithm to generate fine instructions at the first control period; the compliant execution layer outputs the fine instructions to a hardware execution mechanism through a third communication mode; the compliant execution layer reads actual state data through the third communication mode; and the compliant execution layer feeds back the actual state data to the collaborative planning layer through the second communication mode.

Description

Technical Field

[0001] This application relates to the field of robot control technology, and more specifically to a real-time communication method, device, equipment, medium, and program product for a robot control system. Background Technology

[0002] Existing robot control systems typically run all control tasks in a single computing environment. The application layer, collaborative planning layer, and compliant execution layer all run within the same operating system, interacting through inter-process communication or function calls. However, the application layer and collaborative planning layer require a robot operating system framework to perform complex task parsing and trajectory planning, while the compliant execution layer needs to execute control algorithms at high-frequency control cycles to ensure real-time performance. Their computing environment requirements differ: the former demands rich functionality, while the latter requires deterministic scheduling. Running within the same operating system, the high-frequency control tasks of the compliant execution layer can be preempted by non-real-time tasks, making it impossible to guarantee control cycles. This leads to uncertain delays in fine-grained instruction output, preventing timely feedback of actual state data to the collaborative planning layer and impacting the real-time performance of trajectory adjustments. Summary of the Invention

[0003] In view of the above problems, this application provides a real-time communication method, apparatus, device, medium and program product for robot control systems.

[0004] According to a first aspect of this application, a real-time communication method for a robot control system is provided. The robot control system includes an application layer, a cooperative planning layer, and a compliant execution layer. The application layer and the cooperative planning layer run within a robot operating system framework. The application layer parses a task description into a standardized task sequence. The cooperative planning layer generates a desired trajectory and a force control target value based on the standardized task sequence. The compliant execution layer executes a control algorithm based on the desired trajectory and the force control target value to generate fine-grained instructions to drive the robot's motion. The real-time communication method includes: deploying the compliant execution layer in a real-time thread of a first operating system, running with a first priority and a first control cycle, the first operating system running on a first computing core; and deploying the application layer and the cooperative planning layer in a non-real-time thread of a second operating system, running with a second priority and a second control cycle, the second operating system running on a second computing core. The first computing core differs from the second computing core, with the first priority being higher than the second priority and the first control cycle being shorter than the second control cycle. The application layer transmits the standardized task sequence to the collaborative planning layer via a first communication method. The collaborative planning layer sends the desired trajectory and the force control target value to the compliant execution layer via a second communication method. The compliant execution layer receives the desired trajectory and the force control target value, executes the control algorithm within the first control cycle, and generates the fine instructions. The compliant execution layer outputs the fine instructions to the robot's hardware actuator via a third communication method to drive the robot's movement. The compliant execution layer reads actual state data from the hardware actuator via the third communication method, the actual state data including actual pose and actual contact force. The compliant execution layer feeds back the actual state data to the collaborative planning layer via the second communication method.

[0005] According to an embodiment of this application, the first communication method is robot operating system topic communication or robot operating system service communication.

[0006] According to an embodiment of this application, the step of the collaborative planning layer sending the desired trajectory and the force control target value to the compliant execution layer via a second communication method includes: setting up a real-time bridging node between the collaborative planning layer and the compliant execution layer, wherein the real-time bridging node runs independently in the second operating system; the collaborative planning layer publishing the desired trajectory and the force control target value as a first robot operating system message; the real-time bridging node subscribing to the first robot operating system message, parsing the first robot operating system message and writing it into a first address area of ​​shared memory; and the compliant execution layer reading the desired trajectory and the force control target value from the first address area of ​​the shared memory.

[0007] According to an embodiment of this application, the step of the compliant execution layer feeding back the actual state data to the collaborative planning layer through the second communication method includes: the compliant execution layer writing the actual state data fed back from the hardware actuator into the second address area of ​​the shared memory; the real-time bridging node reading the actual state data from the second address area of ​​the shared memory, encapsulating it into a second robot operating system message and publishing it for the collaborative planning layer to subscribe to.

[0008] According to an embodiment of this application, the third communication method is shared memory communication.

[0009] According to an embodiment of this application, the first operating system is a real-time operating system, the second operating system is a non-real-time operating system, the first computing core and the second computing core are different physical cores in the same multi-core chip, and the first computing core is isolated from the second computing core through CPU isolation parameters.

[0010] A second aspect of this application provides a real-time communication device for a robot control system, comprising: a first deployment module for deploying the compliant execution layer in a real-time thread of a first operating system, running with a first priority and a first control cycle, the first operating system running on a first computing core; a second deployment module for deploying the application layer and the collaborative planning layer in a non-real-time thread of a second operating system, running with a second priority and a second control cycle, the second operating system running on a second computing core, the first computing core being different from the second computing core, the first priority being higher than the second priority, and the first control cycle being shorter than the second control cycle; and a transmission module for the application layer to transmit the standardized task sequence to the collaborative planning layer via a first communication method. The system includes: a sending module for the collaborative planning layer to send the desired trajectory and the force control target value to the compliant execution layer via a second communication method; a generation module for the compliant execution layer to receive the desired trajectory and the force control target value, execute the control algorithm in the first control cycle, and generate the fine instructions; a driving module for the compliant execution layer to output the fine instructions to the robot's hardware actuator via a third communication method to drive the robot's movement; a reading module for the compliant execution layer to read actual state data from the hardware actuator via the third communication method, the actual state data including actual pose and actual contact force; and a feedback module for the compliant execution layer to feed back the actual state data to the collaborative planning layer via the second communication method.

[0011] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0012] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0013] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0014] According to some embodiments of this application, by deploying the compliant execution layer on the real-time thread of the first operating system and running it on the first computing core, while deploying the application layer and the collaborative planning layer on the non-real-time thread of the second operating system and running it on the second computing core, the processor time consumed by task parsing and trajectory planning no longer shares the same scheduling queue and time slice with the real-time control loop. Fluctuations in upper-layer computation no longer change the wake-up time of the real-time thread, thus reducing control cycle jitter and cycle errors. By setting the first priority higher than the second priority and the first control cycle shorter than the second control cycle, the scheduling order of the real-time control loop and the non-real-time planning task is clarified. The real-time thread obtains the processor first when its control cycle arrives, avoiding the long-time calculation of the planning task from delaying the control loop. The issuance time of the control instruction and the state reading time of the hardware execution mechanism are kept on the same time base. By making the first computing core and the second computing core independent of each other, the pipelines, caches, and memory bandwidth on both sides no longer compete for each other, reducing the execution caused by inter-core resource contention. With time fluctuations, the runtime of real-time threads is easier to estimate in advance. By entrusting data transmission between the application layer and the collaborative planning layer to the first communication method, the issuance of the desired trajectory and force control target value to the second communication method, and the issuance of fine instructions and the reading of actual state data to the third communication method, high-frequency closed-loop data is no longer entirely forwarded through the general topic middleware. This reduces the amount of intermediate data and dynamic memory allocation caused by serialization and deserialization, message copying, and queue scheduling. The waiting time of real-time threads on memory allocation and mutex locks is correspondingly shortened, and the growth of memory usage and the accumulation of memory fragmentation are suppressed. By executing the control algorithm to generate fine instructions in the first control cycle in the compliant execution layer, and reading the actual state data including the actual pose and actual contact force through the third communication method, and feeding the actual state data back to the collaborative planning layer through the second communication method, the state data on which the planning is based comes from the same determined feedback path. The starting point of trajectory planning is consistent with the actual state of the hardware, reducing trajectory deviation and force control error caused by state lag. Through the above processing, the embodiments of this application reduce the computational and storage resource consumption of the hierarchical robot control system in the real-time control process, improve the time determinism of the control cycle, the consistency of state data and the accuracy of trajectory execution, and also narrow the exposure range of real-time control data in the outer middleware. Attached Figure Description

[0015] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 A flowchart illustrating a real-time communication method for a robot control system according to an embodiment of this application is shown.

[0017] Figure 2 A schematic block diagram of a real-time communication device for a robot control system according to an embodiment of this application is shown.

[0018] Figure 3 A block diagram of an electronic device suitable for implementing a real-time communication method for a robot control system, according to an embodiment of this application, is shown schematically. Detailed Implementation

[0019] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0020] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0021] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0022] Figure 1 A flowchart illustrating a real-time communication method for a robot control system according to an embodiment of this application is shown schematically. Figure 1 As shown, the real-time communication method of the robot control system according to an embodiment of this application may include steps S210 to S280. The robot control system includes an application layer, a cooperative planning layer, and a compliant execution layer. The application layer and the cooperative planning layer run under the robot operating system framework. The application layer parses the task description into a standardized task sequence. The cooperative planning layer generates the desired trajectory and force control target value according to the standardized task sequence. The compliant execution layer executes the control algorithm according to the desired trajectory and force control target value to generate fine instructions to drive the robot's movement.

[0023] In step S210, the compliant execution layer is deployed in the real-time thread of the first operating system and runs with the first priority and the first control cycle. The first operating system runs on the first computing core.

[0024] In some embodiments, the compliant execution layer refers to the layer in the robot control system that directly faces the hardware actuator and undertakes the closed-loop calculation of contact force. This layer receives the desired trajectory and force control target value from the upstream, performs Jacobian transformation, impedance calculation, and force-position hybrid solution in each control cycle, and converts the results into position, velocity, or force rectangular instructions that can be directly loaded by the hardware actuator.

[0025] In some embodiments, a real-time thread refers to an execution unit that is woken up by the first operating system according to a pre-set period and immediately obtains processor execution rights after being woken up. Real-time threads do not rely on time-slice round-robin to obtain execution opportunities; their wake-up time is driven by hardware timer interrupts, and their execution duration is also constrained. A compliant execution layer is deployed entirely within this type of thread, meaning that the layer's control algorithm solution, instruction encapsulation, and status reading are all completed within the same predictable execution window, without being delayed due to queuing in the ready queue.

[0026] In some embodiments, the first priority refers to the priority value used by the real-time thread during scheduling. The first priority is higher than the priority of other threads participating in scheduling in the system, enabling the real-time thread to preempt running low-priority tasks after being woken up. In some embodiments, the first control cycle refers to the time interval between two consecutive wake-ups of the real-time thread. This interval is determined by timer parameters and remains unchanged during operation. The solution of the control algorithm, the issuance of fine instructions, and the reading of actual state data are all carried out in a cycle based on this interval.

[0027] In some embodiments, the first computing core refers to the processor core on which the first operating system runs. Constraining the first operating system to run on this core means that instruction fetching, memory access, and interrupt handling in the compliant execution layer all occur within the resource scope of the same core, and interrupt response paths no longer migrate across cores. In some embodiments, the first computing core can be a physical core or a logical core partitioned from a physical core by hardware threads; the specific form depends on the organization of computing resources provided by the processor.

[0028] In step S220, the application layer and the collaborative planning layer are deployed in the non-real-time thread of the second operating system and run with the second priority and the second control cycle. The second operating system runs on the second computing core. The first computing core is different from the second computing core. The first priority is higher than the second priority, and the first control cycle is shorter than the second control cycle.

[0029] In some examples, the application layer refers to the layer in the robot control system that directly faces the user's tasks and is responsible for task parsing and parameter management. This layer receives assembly process documents or operation instructions input by the user, decomposes them into standardized task sequences containing operation types, target poses, and force control parameters, and provides a human-machine interface for operators to monitor system status, manually intervene, or modify parameters.

[0030] In some examples, the collaborative planning layer refers to the layer in the robot control system that acts as a bridge between upstream and downstream systems, undertaking state scheduling and trajectory generation calculations. This layer receives a standardized task sequence from upstream, drives the finite state machine to perform state transitions according to the operation type, completes collaborative trajectory generation and force control target setting within each planning cycle, and converts the results into the desired trajectory and force control target values ​​that can be directly executed downstream.

[0031] In some embodiments, non-real-time threads refer to threads managed by a second operating system according to a normal scheduling policy. These threads acquire the processor through time-slice round-robin or priority negotiation, allowing them to be preempted by higher-priority tasks during execution, and also allowing them to relinquish the processor while waiting for data or input / output. Task description parsing, trajectory interpolation, and force control target value generation are all computationally intensive tasks whose execution time varies with the scenario. Executing them in non-real-time threads avoids these tasks occupying the execution window of real-time threads.

[0032] In some embodiments, the second priority refers to the priority value of the threads used by the application layer and the collaborative planning layer. The first priority is higher than the second priority, allowing the real-time thread to preempt the planning task being executed after being woken up. This relationship does not require the second priority to take a specific value, but only that it is lower than the first priority within the scheduler's value range, thereby determining the order in which the real-time threads are executed first when the execution of the two layers conflicts.

[0033] In some embodiments, the first control cycle being shorter than the second control cycle means that the interval between two adjacent control calculations of the compliant execution layer is less than the time interval between the application layer and the collaborative planning layer completing one task analysis or trajectory planning. By using different time scales, the real-time side maintains the contact force closed loop at a higher frequency, while the upper layer completes computationally intensive planning work at a lower frequency. The two layers are connected through data updates rather than through clock synchronization.

[0034] In some embodiments, the first computing core, unlike the second computing core, refers to a processor core carrying two operating systems that are physically independent, rather than two logical execution flows divided into time slices on the same core. Threads on both sides use their respective core's register set, L1 cache, and execution unit; intensive computation on one side does not consume the instruction fetch and decode resources of the other side. In some embodiments, the two computing cores can reside within the same multi-core chip or on different processor chips.

[0035] In step S230, the application layer transmits the standardized task sequence to the collaborative planning layer through the first communication method.

[0036] In some embodiments, a standardized task sequence refers to structured data obtained by parsing the input task description at the application layer. This data consists of several task entries, each recording the operation type, target pose, and force control parameters. The operation type identifies the type of action to be performed, the target pose identifies the desired end-effector position and posture, and the force control parameters identify the allowable contact force range and compliance of the action. The entries in the standardized task sequence are arranged in the order of operations, and the field names and units of measurement are consistent within the same control system, eliminating the need for the collaborative planning layer to parse the natural language or graphical task description again.

[0037] In some embodiments, the first communication method refers to the channel used to transmit standardized task sequences between the application layer and the collaborative planning layer. This channel carries low-frequency task data with small data volumes and allows for a certain degree of latency; therefore, it can be implemented using topic communication or service communication provided by the robot operating system. Topic communication transmits data in a publish-subscribe manner, suitable for the application layer to actively push updates when tasks are updated; service communication transmits data in a request-response manner, suitable for the application layer to initiate calls when it needs to confirm planning results. Both methods run in the second operating system where the non-real-time thread resides and do not enter the execution path of the real-time thread.

[0038] In some embodiments, the transmission of standardized task sequences occurs between the application layer and the collaborative planning layer, rather than directly between the application layer and the compliant execution layer. The application layer does not directly issue task entries to the compliant execution layer, and the collaborative planning layer does not directly obtain the execution status from the application layer. As a result, the data interface between the two levels remains clear. If the form of the upper-layer task description is subsequently adjusted, only the parsing rules of the application layer need to be modified, without affecting the control logic of the compliant execution layer.

[0039] In step S240, the collaborative planning layer sends the desired trajectory and force control target value to the compliant execution layer via a second communication method.

[0040] In some embodiments, the desired trajectory refers to the end-effector path calculated by the collaborative planning layer based on the target pose and the previous state in the standardized task sequence. This path consists of a series of discrete trajectory points, each recording the time, position, attitude, and interpolation method between adjacent points. The generation of the desired trajectory needs to consider the kinematic constraints and workspace limitations of the machine; its points are uniformly or non-uniformly distributed in time, and its overall length varies with the work amplitude.

[0041] In some embodiments, the force control target value refers to the force and compliance parameters provided by the collaborative planning layer for trajectory points on the desired trajectory, including the desired contact force in a specified direction, the allowable force deviation range, and the stiffness and damping values ​​used for impedance control. The force control target value corresponds to the trajectory points in the same order. When the compliance execution layer executes to a certain trajectory point, it reads the force control target value corresponding to that point as the input to the control algorithm.

[0042] In some embodiments, the second communication method refers to the channel used by the collaborative planning layer to send the desired trajectory and force control target value to the compliant execution layer. This channel spans both non-real-time and real-time execution environments, requiring both connection to the upper-layer message publishing mechanism and ensuring that data can be retrieved by the real-time thread within a defined timeframe. In some embodiments, the second communication method can be implemented using a real-time bridging node running on a second operating system in conjunction with shared memory. The bridging node is responsible for subscribing to upper-layer messages and writing them to an agreed-upon address region. The real-time thread reads the contents of this region at a specified offset, thereby separating the message passing process from the execution process of the real-time thread.

[0043] In some embodiments, the collaborative planning layer does not reissue the complete desired trajectory in each control cycle. Instead, it issues a new trajectory segment when the trajectory is updated. The real-time thread then automatically advances the position reading within the same trajectory segment according to the first control cycle. In this way, the planning frequency of the upper layer is independent of the control frequency on the real-time side, and the dwell time of the trajectory segment on the real-time side is determined by the density of the trajectory points.

[0044] In step S250, the compliant execution layer receives the desired trajectory and force control target value, executes the control algorithm in the first control cycle, and generates fine instructions.

[0045] In some embodiments, the control algorithm refers to the computational process employed by the compliant execution layer to solve for the desired trajectory and force control target value in each first control cycle. This includes inverse kinematics calculation at the position level, differential mapping at the velocity level, and impedance calculation and force-position hybrid allocation at the force level. The control algorithm takes the desired pose and force control target value corresponding to the current trajectory point as input, and the actual pose and actual contact force as feedback, to solve for the control quantity that each drive axis should output in the current cycle. Since the control algorithm is executed repeatedly within a fixed cycle, its single computational load and memory usage need to remain stable, and no dynamic data structures dependent on the running state are generated during the solution process.

[0046] In some embodiments, fine-grained instructions refer to control quantities obtained after the control algorithm is solved, which can be directly loaded by the hardware actuator. Fine-grained instructions are given for each drive axis and include one or more of the following: target position, target velocity, or target torque. Their values ​​have already undergone unit conversion and amplitude limiting, so the hardware actuator does not need to perform coordinate transformation or dimension conversion again. Each fine-grained instruction corresponds one-to-one with the first control cycle. Each control cycle generates a new set of fine-grained instructions, overriding the values ​​of the previous cycle.

[0047] In some embodiments, the compliant execution layer receives the desired trajectory and force control target value on demand rather than through continuous subscription. Upon entering the current control cycle, the real-time thread retrieves the current trajectory point and corresponding force control target value from shared memory at an agreed address offset, and immediately begins solving. The reading process does not involve queuing in a message queue or dynamic construction of message structures; the time required for reading is determined by the access address and the length of the data structure.

[0048] In some embodiments, the feedback quantity used by the control algorithm is taken from the actual state data read in the previous control cycle. That is, the actual pose and actual contact force are read and stored in the real-time thread-accessible storage area in step S270, and the control algorithm directly uses the data to participate in the solution in the current cycle without triggering hardware reading again in the current cycle, thereby staggering the hardware access and algorithm solution in time.

[0049] In step S260, the compliant execution layer outputs fine instructions to the robot's hardware actuators via a third communication method to drive the robot's movement.

[0050] In some embodiments, a hardware actuator refers to a component in a robot that directly receives control signals and generates motion, including servo drive units for each joint, drive units for the end effector, and associated encoders and force sensing units. The hardware actuator receives control signals and updates its output at fixed intervals, with its receiving intervals corresponding to the first control cycle of the compliant actuation layer, and a set of control signals is loaded within one receiving interval.

[0051] In some embodiments, the third communication method refers to the channel used between the compliant execution layer and the hardware execution mechanism to transmit fine-grained instructions and actual state data. This channel is located between the real-time thread and the hardware, carrying small blocks of data that are updated periodically and have a fixed data volume. The transmission process must not introduce additional queuing or arbitration steps. In some embodiments, the third communication method can be implemented using shared memory communication. That is, the compliant execution layer and the hardware access unit read and write to the same memory block according to an agreed address area. After the writer completes the write, it updates a flag bit; the reader checks the flag bit and retrieves the data. The entire process does not involve message encapsulation or thread wake-up by middleware.

[0052] In some embodiments, the writing of fine-grained instructions and the reading of hardware actuators are organized using a double-buffered or circular-buffered approach. This means that multiple address regions are written to in turn, and the reader always accesses the region where the most recently written instruction was completed. In this way, the writer does not need to wait for confirmation from the reader to continue writing in the next cycle, and the reader will not retrieve data that has only been partially written.

[0053] In step S270, the compliant execution layer reads the actual state data from the hardware actuator through a third communication method. The actual state data includes the actual pose and the actual contact force.

[0054] In some embodiments, the actual pose refers to the current position of each drive shaft and the current attitude of the end effector, fed back by the hardware actuator. The position data is provided by the joint encoder and reflects the actual rotation angle of the drive shaft; the end effector attitude is calculated from the joint position using forward kinematics and is used to compare with the desired pose in the control algorithm in the same coordinate system. The sampling time corresponding to the actual pose is aligned with the first control cycle, and the control algorithm uses this to determine whether the end effector has reached the desired position and whether a following error has occurred.

[0055] In some embodiments, the actual contact force refers to the force and torque measured by the force sensing unit when the end effector comes into contact with the work object. The actual contact force includes components along each direction of the end effector coordinate system and torque components about each axis. In the control algorithm, it is compared with the expected contact force in the force control target value to obtain the force deviation. The sampling and reading of the actual contact force are also based on the first control cycle and share the same channel as the reading of the rigid position.

[0056] In some embodiments, the reading of actual state data and the writing of fine-grained instructions share a third communication method, but use different address regions. The reader retrieves the state data written by the hardware in the current cycle according to an agreed offset and stores it in a storage area accessible to the real-time thread for use by the control algorithm in the next cycle. Since reading and writing occur in different address regions, the accesses on both sides do not overwrite each other, and it is not necessary to allocate new memory for each cycle.

[0057] In some embodiments, the actual state data read, in addition to participating in the control calculations of this layer, also serves as feedback to the collaborative planning layer. The compliant execution layer does not compress or sample this data, but only reorganizes it according to the agreed format when feeding it back, so that the state received by the collaborative planning layer and the state used by the real-time side are taken from the same sample.

[0058] In step S280, the compliant execution layer feeds back the actual state data to the collaborative planning layer through the second communication method.

[0059] In some embodiments, the feedback of actual state data involves sending the actual pose and actual contact force read by the compliant execution layer back to the collaborative planning layer, enabling the upper-layer planning to unfold based on the latest state on the execution side. The feedback content is organized according to the needs of the collaborative planning layer, including the actual pose of the end effector, the actual position of each joint, the actual contact force and torque, and the control cycle number corresponding to this feedback. The cycle number is used by the collaborative planning layer to determine whether the received state has expired.

[0060] In some embodiments, feedback is accomplished via a second communication method, that is, through the same channel as the sending channel. The compliant execution layer writes the actual state data to a pre-defined address area in shared memory, which is then read by the real-time bridging node running in the second operating system, encapsulated into a robot operating system message, and published. The collaborative planning layer subscribes to this message according to its own planning rhythm. Throughout the entire feedback process, the real-time thread performs only one fixed-length write operation and does not participate in message construction and publication.

[0061] In some embodiments, the compliant execution layer writes actual state data at a frequency lower than the first control cycle. The real-time thread reads the actual state data in each control cycle, but only writes the most recently read state to the feedback region of shared memory when the write condition is met, for example, at fixed cycle intervals. In this way, the amount of data returned remains stable over time, and the state received by the cooperative planning layer is neither too outdated nor accumulates in a short period of time due to cycle-by-cycle writing.

[0062] In some embodiments, after receiving the actual state data, the collaborative planning layer uses this state as the starting point for the next desired trajectory segment and adjusts the force control target value for the next segment based on the deviation between the actual contact force and the force control parameters. Since the state data is transmitted back along with the control cycle number, the collaborative planning layer can determine whether the currently received state corresponds to the trajectory segment being executed, and discard the state or replan if they do not correspond.

[0063] According to the real-time communication method of the robot control system in this application embodiment, by deploying the compliant execution layer on the real-time thread of the first operating system and running it on the first computing core, and simultaneously deploying the application layer and the collaborative planning layer on the non-real-time thread of the second operating system and running it on the second computing core, the processor time consumed by task parsing and trajectory planning no longer shares the same scheduling queue and time slice with the real-time control loop. Fluctuations in the upper-layer computational load no longer change the wake-up time of the real-time thread, and the jitter and cycle errors of the control cycle are reduced accordingly. By setting the first priority higher than the second priority and the first control cycle shorter than the second control cycle, the scheduling order of the real-time control loop and the non-real-time planning task is clarified. The real-time thread obtains the processor first when its control cycle arrives, avoiding the delay of the control loop due to the long-time calculation of the planning task. The time of issuing control instructions and the time of reading the state of the hardware execution mechanism are kept on the same time base. By making the first computing core and the second computing core independent of each other, the pipelines, caches and memory bandwidth on both sides no longer compete for each other, reducing inter-core resource contention. The execution time fluctuations caused by this make the runtime of real-time threads easier to predict in advance. By entrusting data transmission between the application layer and the collaborative planning layer to the first communication method, the issuance of the desired trajectory and force control target value to the second communication method, and the issuance of fine instructions and the reading of actual state data to the third communication method, high-frequency closed-loop data is no longer all forwarded through the general topic middleware. This reduces the amount of intermediate data and dynamic memory allocation caused by serialization and deserialization, message copying, and queue scheduling. The waiting time of real-time threads on memory allocation and mutex locks is shortened accordingly, and the growth of memory usage and the accumulation of memory fragmentation are suppressed. By executing the control algorithm to generate fine instructions in the first control cycle in the compliant execution layer, and reading the actual state data including the actual pose and actual contact force through the third communication method, and feeding the actual state data back to the collaborative planning layer through the second communication method, the state data on which the planning is based comes from the same determined feedback path. The starting point of trajectory planning is consistent with the actual state of the hardware, reducing trajectory deviation and force control error caused by state lag. Through the above processing, the embodiments of this application reduce the computational and storage resource consumption of the hierarchical robot control system in the real-time control process, improve the time determinism of the control cycle, the consistency of state data and the accuracy of trajectory execution, and also narrow the exposure range of real-time control data in the outer middleware.

[0064] According to some embodiments of this application, the first communication method is robot operating system topic communication or robot operating system service communication.

[0065] In some embodiments, topic communication in a robot operating system refers to a method of transmitting data between nodes using a publish-subscribe approach. Publishers and subscribers do not need to know each other's identities, nor do they need to wait for each other to be ready. The publisher writes data into the channel identified by the topic name and then returns. Subscribers, after registering the same topic name, receive data at their own pace. This transmission process does not establish an end-to-end waiting relationship, making it suitable for carrying standardized task sequences proactively pushed by the application layer when tasks change. When the workflow needs to temporarily insert a new entry or adjust the target pose of an existing entry, the application layer only needs to republish once, and the collaborative planning layer will receive the updated data on the next reception.

[0066] In some embodiments, robot operating system service communication refers to a method of transmitting data between nodes in a request-response manner. After the caller issues a request, it waits for the callee to return the result. The callee then sends the result back after processing, and the two parties maintain a correspondence within the scope of a single call. This method is suitable for carrying task data that requires confirmation of the transmitted result. For example, after the application layer issues an assembly task, it needs to confirm that the collaborative planning layer has received and completed the preliminary feasibility check before continuing with subsequent process orchestration. Because service communication involves a waiting process, its calls should not be executed in a real-time thread.

[0067] In some embodiments, the selection of the first communication method is determined based on the update characteristics of the task sequence. When task items are pre-provided by the upper-level system according to a fixed process and the update frequency is low, topic communication can be used, with the application layer publishing a complete sequence once when switching tasks. When task items need to be confirmed one by one during execution, or when the next item needs to be dynamically generated based on the execution result, service communication can be used, with the application layer initiating calls one by one and receiving confirmation results. Both methods can coexist, each carrying different types of data.

[0068] This embodiment carries standardized task sequences through topic communication or service communication that matches the update characteristics of task data, so that low-frequency task data is transmitted separately from high-frequency trajectory and status data, reducing the number of messages entering the middleware and reducing the scheduling overhead and backlog risk of message queues. At the same time, the first communication method runs in the second operating system where the non-real-time thread is located, and its publishing and waiting process does not enter the execution window of the real-time thread, thus avoiding the impact of the task data transmission rhythm on the stability of the control cycle.

[0069] According to some embodiments of this application, the step of the collaborative planning layer sending the desired trajectory and force control target value to the compliant execution layer through a second communication method includes steps S241 to S244.

[0070] In step S241, a real-time bridging node is set between the collaborative planning layer and the compliant execution layer. The real-time bridging node runs independently in the second operating system.

[0071] In some embodiments, a real-time bridging node refers to an independent execution unit that undertakes data transformation and transfer responsibilities between the collaborative planning layer and the compliant execution layer. This node possesses capabilities in two directions: downwards, it can subscribe to data published by the collaborative planning layer according to the robot operating system's message mechanism; upwards, it can write data to shared memory according to an agreed-upon data structure and encapsulate feedback data from shared memory into messages for publication. The bridging node's own computation involves fixed-length field transfers and does not include time-consuming calculations such as trajectory resolution.

[0072] In some embodiments, the real-time bridging node runs independently in a second operating system, meaning that the node's threads, memory, and message handles are all managed by the second operating system, independent of the first operating system where the real-time thread resides. This arrangement allows message reception and encapsulation to occur on the non-real-time side, and the real-time thread neither registers message callbacks nor participates in middleware thread wake-ups, thereby isolating the uncertainties introduced by the general message mechanism from the real-time execution path.

[0073] In some embodiments, the real-time bridging node and the compliant execution layer agree on the address regions and data structures for data exchange via shared memory. Both sides use the same structure definition, including field order, field length, and alignment. The writer fills in the fields according to the structure order, and the reader retrieves the values ​​in the same order. Because both sides use the same definition, data does not require serialization and deserialization during transmission, nor does it require reallocation of memory at the receiving end.

[0074] In step S242, the collaborative planning layer publishes the desired trajectory and force control target value as a first robot operating system message.

[0075] In some embodiments, the first robot operating system message refers to the message obtained by the collaborative planning layer encapsulating the desired trajectory and force control target value according to the message definition of the robot operating system. The message sequentially arranges the time, position, attitude, and corresponding force control target value of each trajectory point in order, and appends a trajectory segment identifier and a message sequence number. The trajectory segment identifier is used to distinguish trajectories from different batches, and the message sequence number allows the receiver to determine the message's age.

[0076] In some embodiments, the collaborative planning layer publishes the first robot operating system message according to the generation rhythm of trajectory segments, rather than according to the control cycle. A message carries a complete trajectory segment, the length of which is determined by the number of trajectory points. When the operation range is large, the number of points in a trajectory segment is large, and the message size increases accordingly; when the operation range is small, the message size is small. The collaborative planning layer publishes the message immediately after completing a solution, and the publishing action is completed in a non-real-time thread.

[0077] In some embodiments, the collaborative planning layer performs an executability check on the desired trajectory before publishing a message. This check includes verifying whether each trajectory point is within the workspace, whether the velocity and acceleration between adjacent points exceed limits, and whether the force control target value is within the capability range of the hardware actuator. Only messages that pass the checks are published and then proceed to the subsequent transmission process. Trajectories that fail the checks are recalculated by the collaborative planning layer without consuming real-time processing resources.

[0078] In step S243, the real-time bridging node subscribes to the first robot operating system message, parses the first robot operating system message, and writes it into the first address area of ​​the shared memory.

[0079] In some embodiments, the first address region refers to the storage range allocated in shared memory for downlink data. The starting address, length, and internal field layout of this region are jointly followed by the collaborative planning layer, the real-time bridging node, and the compliant execution layer. When writing, the bridging node fills the data sequentially according to field order, and when reading, the compliant execution layer retrieves values ​​in the same order; no additional type conversion or byte order processing is required between the two parties. The address region is allocated and fixed once during system initialization and is not reallocated during runtime.

[0080] In some embodiments, parsing refers to the process by which the bridging node retrieves data field by field according to the definition of the first robot operating system message, and rearranges the retrieved data according to the field layout of shared memory. The parsing process does not change the value of the data, only the storage format of the data. For continuously arranged data such as trajectory points, the bridging node moves the data as a whole in point order; for force control target values ​​corresponding to trajectory segments, the bridging node writes them together in the same order, so that the reader can obtain the complete information of the trajectory segment within a single address area.

[0081] In some embodiments, the bridging node updates the status flag of the first address region after the write operation is complete. The flag value indicates that the region is currently in one of three states: readable, in progress, or read. The compliant execution layer checks the flag before reading. If the flag indicates that the write operation is not yet complete, it continues using the previous trajectory segment and does not use data that is not fully written. The status flag occupies only one field, and its read and write operations are atomic and do not require locking.

[0082] As one feasible approach, the first address region can be organized using a double-buffered structure, that is, preparing two equally sized sub-regions for a trajectory segment, which are used alternately. The bridging node writes to the currently free sub-region, and after the write is complete, it switches the flag to point to that sub-region. The compliant execution layer always reads the sub-region pointed to by the flag. In this way, the writing of new trajectory segments and the reading of old trajectory segments can be performed simultaneously, and the writing process of the bridging node will not be interrupted by the reading of the real-time thread.

[0083] In step S244, the compliant execution layer reads the desired trajectory and force control target value from the first address region of the shared memory.

[0084] In some embodiments, the compliant execution layer reads the first address region when a new trajectory segment needs to be acquired. The reading is triggered either by the completion of the trajectory points of the current trajectory segment or by a flag indicating that a new trajectory segment has been written into the first address region. The reading operation is completed within a real-time thread, and its time is determined by the access address and the length of the data structure, without including the process of waiting for a middleware response.

[0085] In some embodiments, the desired trajectory and force control target value read by the compliant execution layer are stored in the real-time thread's own storage area for subsequent control cycles to access sequentially. That is, a single read can support the progression of multiple control cycles, with a read frequency lower than the control frequency. This arrangement reduces the number of times the real-time thread accesses shared memory and avoids repeatedly parsing the same batch of trajectory data in each control cycle.

[0086] In some embodiments, after the compliant execution layer completes a read, it sets the status flag of the first address region to "read," allowing the bridging node to determine whether it can write to the next trajectory segment. If the compliant execution layer is executing the current trajectory segment and the flag is still "read," the bridging node postpones writing until the flag becomes "read" before writing new data. Through this alternating relationship formed by the flags, the two sides can cooperate under lock-free conditions.

[0087] This embodiment sets up a real-time bridging node running independently in a second operating system between the collaborative planning layer and the compliant execution layer. This node handles message subscription, field parsing, and the relocation of data to shared memory. This keeps the thread wake-up and queue scheduling caused by the message mechanism on the non-real-time side, and the real-time thread only performs a memory read of a fixed length once, shortening the execution time for the real-time thread to acquire trajectory data. At the same time, the trajectory data is stored in the first address area of ​​shared memory with a fixed structure, and both sides read and write according to the same field definition, eliminating the intermediate data of serialization and deserialization, reducing the number of data copies and dynamic memory allocations in a single transmission, and the memory usage tends to level off as the running time increases.

[0088] According to some embodiments of this application, the step of the compliant execution layer feeding back actual state data to the collaborative planning layer through a second communication method includes steps S281 to S282.

[0089] In step S281, the compliant execution layer writes the actual state data fed back from the hardware actuator into the second address region of the shared memory.

[0090] In some embodiments, the second address region refers to a storage area in shared memory designated for uplink state data. This region is independent of the first address region, which carries the desired trajectory and force control target value. Its starting address and length are determined during system initialization and remain unchanged during operation. The uplink and downlink regions are stored separately to prevent data from overlapping, ensuring that the compliant execution layer's writing of state data does not affect the trajectory data it is reading.

[0091] In some embodiments, the actual state data written to the second address region is organized with a fixed length and includes the actual pose of the end effector, the actual position of each joint, the actual contact force and torque, and the control cycle number corresponding to the current state. The length and order of the fields are determined by a structure definition jointly followed by both parties. The compliant execution layer fills the fields sequentially, and the bridging nodes take values ​​in the same order. Because the structure length is fixed, the writing process does not involve memory allocation and deallocation, nor does it generate intermediate data of variable length.

[0092] In some embodiments, the compliant execution layer determines whether to perform a write operation based on write conditions. Write conditions can be either the control cycle count reaching a predetermined interval or the change in actual state data exceeding a predetermined threshold. If the write conditions are not met, the compliant execution layer only updates its own storage area without accessing shared memory. This arrangement ensures that the amount of upstream data does not increase linearly with the control frequency, and the number of shared memory accesses remains controllable.

[0093] In some embodiments, the compliant execution layer updates the status flag of the second address region after the write operation is complete. The flag value indicates that the region is currently in one of three states: written, read, or idle. The bridging node checks the flag before reading and only retrieves the value if the flag indicates that the data has been completely written, thereby avoiding retrieving state data that is in the process of being written.

[0094] In step S282, the real-time bridging node reads the actual state data from the second address area of ​​the shared memory, encapsulates it into a second robot operating system message and publishes it for the collaborative planning layer to subscribe to.

[0095] In some embodiments, the real-time bridging node checks the status flags of the second address region according to its own polling rhythm. When the flag indicates that the data has been completely written, it retrieves the current batch of status data and sets the flag to idle, indicating that the region can receive the next write. The polling interval is determined by the scheduling cycle of the thread to which the bridging node resides, and is independent of the first control cycle of the real-time thread; there is no waiting relationship between the two.

[0096] In some embodiments, the second robot operating system message refers to the message obtained by the bridging node reorganizing the retrieved actual state data according to the message definition of the robot operating system. The message includes the actual pose of the end effector, the actual contact force and torque, and the control cycle number, which are used by the collaborative planning layer to determine the age of the state during planning. The construction and publication of the message are completed in the second operating system; the real-time thread does not participate in this process and is not awakened by the message publication.

[0097] In some embodiments, the collaborative planning layer subscribes to messages from the second robot operating system according to its own planning rhythm. When the planning task is idle, the collaborative planning layer still receives messages and updates the latest locally stored state, but does not trigger new trajectory calculations; when the next trajectory segment needs to be generated, the collaborative planning layer directly uses the latest locally stored state as the trajectory starting point. This on-demand triggering method ensures that the computational load of the upper layer corresponds to the actual planning needs, rather than to the frequency of state reporting.

[0098] As one feasible approach, the bridging node can perform consistency labeling on state data when encapsulating the second robot operating system message. This involves labeling position, attitude, and force data obtained from the same sampling as the same group and retaining the control cycle number of that group in the message. When the collaborative planning layer receives multiple sets of data, it selects the latest set based on the cycle number, discarding data with backdated or duplicate numbers.

[0099] This embodiment writes the actual state data into the second address region of shared memory, and then the bridge node running in the second operating system reads, encapsulates, and publishes it. This allows the real-time thread to perform only one fixed-length write in the feedback phase, without participating in message construction and middleware publishing. This shortens the execution time of the real-time thread in the feedback phase and reduces the dynamic memory allocation that may occur in this phase. At the same time, the uplink and downlink regions are independent of each other, and the state writing and trajectory reading are performed in the same memory partition, avoiding data overlap between the two directions and reducing retransmissions and state misalignments caused by data contention.

[0100] According to some embodiments of this application, the third communication method is shared memory communication.

[0101] In some embodiments, shared memory communication refers to a communication method between the compliant execution layer and the hardware execution unit that exchanges data through the same physical memory. During the initialization phase, both parties agree on the address region and field layout. The compliant execution layer writes detailed instructions into the agreed-upon region, and the hardware access unit retrieves the instructions from the agreed-upon region. The hardware access unit writes actual state data into another agreed-upon region, and the compliant execution layer retrieves the state data from that region. The entire exchange process does not involve message encapsulation or middleware forwarding.

[0102] In some embodiments, the difference between shared memory communication and message-based communication lies in how data ownership is transferred. Message-based communication requires copying data from the sender's address space to a middleware buffer, and then the receiver copies it from the buffer to its own address space; shared memory communication, on the other hand, allows both parties to directly access the same data, with data written only once and retrieved directly at an agreed offset, without creating copies in between. For small blocks of data that are updated periodically with a fixed amount of data per cycle, this method has lower transmission overhead.

[0103] In some embodiments, fine-grained instructions and actual state data are separated into write and read regions in shared memory, and each region is organized using a double-buffered or circular buffer to allow writes and reads to be performed alternately. Fields within the regions are arranged in a fixed order, and the compliant execution layer and hardware access unit use the same structure definition. The meaning of field values ​​is consistent with the unit of measurement, eliminating the need for unit conversions or data reorganization during transmission.

[0104] As one feasible approach, shared memory communication can also be used in conjunction with a sequence number field. The compliant execution layer synchronously increments the sequence number when writing fine instructions in each control cycle. The hardware access unit compares the sequence number during reading; if the sequence number is the same as the previous one, it means the instruction has not been updated, and the hardware retains the output from the previous cycle. If the sequence number increments continuously, the output is updated according to the new value. Through sequence number comparison, both parties confirm the age of the data without locking, avoiding duplicate loading of the same set of instructions.

[0105] This embodiment employs shared memory communication to carry out the issuance of fine-grained instructions and the reading of actual state data. This ensures that the control data updated periodically is written and read only once during transmission, reducing the amount of intermediate data and processor overhead caused by message encapsulation, buffer copying, and thread wake-up. At the same time, the instruction area and the state area are separated and organized in an alternating manner, so the writer does not need to wait for the reader's confirmation to continue the work of the next cycle, reducing the blocking time of real-time threads waiting for confirmation. The execution time of the control cycle is closer to the computation time of the algorithm itself.

[0106] According to some embodiments of this application, the first operating system is a real-time operating system, the second operating system is a non-real-time operating system, the first computing core and the second computing core are different physical cores in the same multi-core chip, and the first computing core is isolated from the second computing core through CPU isolation parameters.

[0107] In some embodiments, a real-time operating system refers to a system that aims to determine response time in task scheduling. Such systems provide threads with preemptive priority scheduling, priority inheritance mechanisms, and deterministic interrupt response paths, and the latency from task readiness to execution start has an estimable upper bound. A compliant execution layer runs on top of the real-time operating system, allowing the wake-up latency and execution duration of its control loop to be estimated in advance, thus limiting control cycle jitter to an acceptable range.

[0108] In some embodiments, a non-real-time operating system refers to a system designed for average throughput and versatility. Such systems provide time-slice rotation and dynamic priority adjustment for threads, and allow background tasks such as memory reclamation, log writing, and file synchronization to be performed during runtime. These tasks may cause uncertain delays on the order of hundreds of microseconds or even longer. Since the application layer and the cooperative planning layer are not sensitive to the latency of a single execution, running them in a non-real-time operating system satisfies functional requirements while preventing the background behavior of general-purpose systems from affecting real-time threads.

[0109] In some embodiments, the first computing core and the second computing core are different physical cores within the same multi-core chip, meaning that two operating systems run on independent processor cores within the same chip. Compared to two logical execution flows running on the same core, threads located on different physical cores each have independent register sets and L1 caches, do not need to yield execution units to each other, and do not need to save and restore execution context during switching. Meanwhile, the two operating systems share the final-level cache and memory controller within the same chip; to avoid contention at this level, further isolation parameters need to be configured.

[0110] In some embodiments, CPU isolation parameters refer to configuration parameters used to exclude processor cores from the jurisdiction of the general-purpose scheduler and limit their executable tasks. These parameters take effect during system startup, specifying which cores do not participate in the distribution of ordinary tasks, and also constraining the scope of interrupt delivery, preventing peripheral interrupts unrelated to real-time control from being delivered to the first computing core. After configuration, only the real-time threads of the compliant execution layer and minimal interrupt handling related to hardware access run on the first computing core, while the application layer, cooperative planning layer, and real-time bridging node run on the second computing core.

[0111] This embodiment uses a real-time operating system to carry the compliant execution layer and a non-real-time operating system to carry the application layer and the collaborative planning layer, and constrains the two types of systems to different physical cores of the same multi-core chip. This gives the wake-up latency and execution time of the real-time control loop an estimable upper bound, reducing the uncertain latency caused by background tasks in general systems. At the same time, by excluding the first computing core from the general scheduling scope and constraining the interrupt delivery scope through CPU isolation parameters, the execution time fluctuations caused by inter-core scheduling migration and interrupt contention are reduced. The runtime of real-time threads is easier to estimate in advance, and the time determinism of the control cycle is correspondingly improved.

[0112] Based on the real-time communication method of the robot control system described above, this application also provides a real-time communication device for the robot control system. The following will be combined with... Figure 2 The device is described in detail.

[0113] Figure 2 A schematic block diagram of a real-time communication device for a robot control system according to an embodiment of this application is shown.

[0114] like Figure 2 As shown, the real-time communication device 10 of the robot control system according to an embodiment of this application includes a first deployment module 1, a second deployment module 2, a transmission module 3, a sending module 4, a generation module 5, a driving module 6, a reading module 7, and a feedback module 8.

[0115] The first deployment module 1 is used to deploy the compliant execution layer in the real-time thread of the first operating system, and run it with the first priority and the first control cycle. The first operating system runs on the first computing core.

[0116] The second deployment module 2 is used to deploy the application layer and the collaborative planning layer in the non-real-time thread of the second operating system, and run them with the second priority and the second control cycle. The second operating system runs on the second computing core. The first computing core is different from the second computing core. The first priority is higher than the second priority, and the first control cycle is shorter than the second control cycle.

[0117] The transmission module 3 is used by the application layer to transmit the standardized task sequence to the collaborative planning layer through the first communication method.

[0118] The sending module 4 is used by the collaborative planning layer to send the desired trajectory and force control target value to the compliant execution layer through a second communication method.

[0119] The generation module 5 is used by the compliant execution layer to receive the desired trajectory and force control target value, execute the control algorithm in the first control cycle, and generate fine instructions.

[0120] The drive module 6 is used by the compliant execution layer to output fine instructions to the robot's hardware actuators through a third communication method to drive the robot's movement.

[0121] The reading module 7 is used by the compliant execution layer to read actual state data from the hardware actuator through a third communication method. The actual state data includes actual pose and actual contact force.

[0122] Feedback module 8 is used by the compliant execution layer to feed back the actual state data to the collaborative planning layer through a second communication method.

[0123] The beneficial effects of the real-time communication device 10 of the robot control system according to the embodiments of this application are the same as those of the real-time communication method of the robot control system according to the embodiments of this application, and will not be repeated here.

[0124] According to embodiments of this application, any multiple modules among the first deployment module 1, second deployment module 2, transmission module 3, sending module 4, generation module 5, driving module 6, reading module 7, and feedback module 8 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the first deployment module 1, second deployment module 2, transmission module 3, sending module 4, generation module 5, driving module 6, reading module 7, and feedback module 8 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, and firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the first deployment module 1, the second deployment module 2, the transmission module 3, the sending module 4, the generation module 5, the driving module 6, the reading module 7, and the feedback module 8 can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0125] Figure 3 A block diagram schematically illustrates an electronic device suitable for implementing the above-described method according to an embodiment of this application.

[0126] like Figure 3As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory 902 or a program loaded from a storage portion 908 into a random access memory 903. The processor 901 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0127] Random access memory 903 stores various programs and data required for the operation of electronic device 900. Processor 901, read-only memory 902, and random access memory 903 are interconnected via bus 904. Processor 901 executes various steps of the method flow according to embodiments of this application by executing programs stored in read-only memory 902 and / or random access memory 903. It should be noted that the programs may also be stored in one or more memories other than read-only memory 902 and random access memory 903. Processor 901 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0128] According to embodiments of this application, the electronic device 900 may further include an input / output interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card, such as a local area network card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0129] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0130] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 902 described above, and / or random access memory 903, and / or one or more memories other than read-only memory 902 and random access memory 903.

[0131] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0132] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0133] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by processor 901, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0134] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0135] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0136] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A real-time communication method for a robot control system, the robot control system comprising an application layer, a cooperative planning layer, and a compliant execution layer, wherein the application layer and the cooperative planning layer run within a robot operating system framework, the application layer parses a task description into a standardized task sequence, the cooperative planning layer generates a desired trajectory and a force control target value based on the standardized task sequence, and the compliant execution layer executes a control algorithm based on the desired trajectory and the force control target value to generate fine instructions to drive the robot's motion, characterized in that... The real-time communication method includes: The compliant execution layer is deployed in the real-time thread of the first operating system and runs with a first priority and a first control cycle. The first operating system runs on the first computing core. The application layer and the collaborative planning layer are deployed in the non-real-time thread of the second operating system and run with the second priority and the second control cycle. The second operating system runs on the second computing core. The first computing core is different from the second computing core. The first priority is higher than the second priority and the first control cycle is shorter than the second control cycle. The application layer transmits the standardized task sequence to the collaborative planning layer via a first communication method; The collaborative planning layer sends the desired trajectory and the force control target value to the compliant execution layer via a second communication method. The compliant execution layer receives the desired trajectory and the force control target value, executes the control algorithm in the first control cycle, and generates the fine instructions; The compliant execution layer outputs the fine instructions to the robot's hardware execution mechanism via a third communication method to drive the robot's movement; The compliant execution layer reads actual state data from the hardware actuator through the third communication method. The actual state data includes actual pose and actual contact force. The compliant execution layer feeds back the actual state data to the collaborative planning layer through the second communication method.

2. The real-time communication method according to claim 1, characterized in that, The first communication method is either robot operating system topic communication or robot operating system service communication.

3. The real-time communication method according to claim 1, characterized in that, The step of the collaborative planning layer sending the desired trajectory and the force control target value to the compliant execution layer via a second communication method includes: A real-time bridging node is set between the collaborative planning layer and the compliant execution layer, and the real-time bridging node runs independently in the second operating system; The collaborative planning layer publishes the desired trajectory and the force control target value as a first robot operating system message; The real-time bridging node subscribes to the first robot operating system message, parses the first robot operating system message, and writes it into the first address area of ​​shared memory. The compliant execution layer reads the desired trajectory and the force control target value from the first address region of the shared memory.

4. The real-time communication method according to claim 3, characterized in that, The step of the compliant execution layer feeding back the actual state data to the collaborative planning layer through the second communication method includes: The compliant execution layer writes the actual state data fed back from the hardware actuator into the second address region of the shared memory; The real-time bridging node reads the actual state data from the second address region of the shared memory, encapsulates it into a second robot operating system message, and publishes it for the collaborative planning layer to subscribe to.

5. The real-time communication method according to claim 1, characterized in that, The third communication method is shared memory communication.

6. The real-time communication method according to claim 1, characterized in that, The first operating system is a real-time operating system, the second operating system is a non-real-time operating system, the first computing core and the second computing core are different physical cores in the same multi-core chip, and the first computing core is isolated from the second computing core through CPU isolation parameters.

7. A real-time communication device for a robot control system, the robot control system comprising an application layer, a cooperative planning layer, and a compliant execution layer, wherein the application layer and the cooperative planning layer run within a robot operating system framework, the application layer parses a task description into a standardized task sequence, the cooperative planning layer generates a desired trajectory and a force control target value based on the standardized task sequence, and the compliant execution layer executes a control algorithm based on the desired trajectory and the force control target value to generate fine instructions to drive the robot's motion, characterized in that... The real-time communication device includes: The first deployment module is used to deploy the compliant execution layer in the real-time thread of the first operating system, and run it with a first priority and a first control cycle. The first operating system runs on the first computing core. The second deployment module is used to deploy the application layer and the collaborative planning layer in the non-real-time thread of the second operating system, and run them with a second priority and a second control cycle. The second operating system runs on a second computing core. The first computing core is different from the second computing core. The first priority is higher than the second priority and the first control cycle is shorter than the second control cycle. The transmission module is used by the application layer to transmit the standardized task sequence to the collaborative planning layer via a first communication method; The sending module is used by the collaborative planning layer to send the desired trajectory and the force control target value to the compliant execution layer via a second communication method; The generation module is used by the compliant execution layer to receive the desired trajectory and the force control target value, execute the control algorithm in the first control cycle, and generate the fine instructions; The drive module is used by the compliant execution layer to output the fine instructions to the robot's hardware execution mechanism through a third communication method, so as to drive the robot to move; The reading module is used by the compliant execution layer to read actual state data from the hardware actuator through the third communication method. The actual state data includes actual pose and actual contact force. The feedback module is used by the compliant execution layer to feed back the actual state data to the collaborative planning layer through the second communication method.

8. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 6.

Images