Industrial scene-oriented humanoid robot co-simulation control method and related equipment

Abstract

The invention discloses an industrial scene-oriented humanoid robot co-simulation control method and related equipment. The method comprises the following steps of: determining a functional module of a humanoid robot; constructing a simulation unit corresponding to the function module; according to a container distribution algorithm, a container is distributed to the virtual module in each simulation unit, and a corresponding container resource is distributed to each container; collecting simulation performance data corresponding to each simulation unit; data transmission is carried out based on a differential transmission channel when the simulation units carry out function simulation, the differential transmission channel comprises a first network and a second network, the first network is used for realizing low-delay communication between the virtual modules in the same simulation unit, and the second network is used for realizing cooperative communication between the virtual modules crossing the simulation units; and according to the simulation performance data, performing feedback optimization operation on the function simulation of each simulation unit. The precision, the stability and the real-time performance of multi-module cooperative control of the humanoid robot can be improved, and the method can be widely applied to the technical field of computers.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a collaborative simulation control method and related equipment for humanoid robots in industrial scenarios. Background Technology

[0002] As industrial automation upgrades towards "flexibility" and "intelligence," humanoid robots, with their human-like movement capabilities and multi-task adaptability, are gradually becoming core equipment to replace manual labor in performing precision operations and high-risk tasks. Humanoid robots in industrial scenarios need to integrate four core functional modules: motion control (joint actuation, gait planning), environmental perception (visual recognition, force feedback, laser ranging), task execution (grasping, assembly, handling), and human-machine interaction (voice commands, fault alarms). These modules require high-frequency, low-latency data interaction (e.g., in assembly scenarios, the motion control module needs to receive part positioning data from the visual recognition module in real time, with latency controlled within 10 milliseconds). However, current humanoid robot simulation and control systems suffer from challenges such as high cross-module communication latency, rigid resource allocation, and low efficiency in large-scale simulations.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The embodiments of this application aim to at least partially solve one of the technical problems in the related art. Therefore, the main objective of the embodiments of this application is to propose a collaborative simulation control method and related equipment for humanoid robots in industrial scenarios, which can improve the accuracy, stability, and real-time performance of multi-module collaborative control of humanoid robots, ultimately ensuring that the control effect of the physical robot meets design expectations.

[0005] To achieve the above objectives, one aspect of this application proposes a collaborative simulation control method for humanoid robots in industrial scenarios, the method comprising the following steps: The functional modules of the humanoid robot are defined; wherein, the functional modules include a motion control module, an environmental perception module, a task execution module, and a human-computer interaction module; Construct simulation units corresponding to the functional modules; wherein each simulation unit contains at least one virtual module; According to the container allocation algorithm, a container is allocated to each virtual module in the simulation unit, and a corresponding container resource is allocated to each container; wherein, each virtual module is allocated one container, and the container is used to simulate the corresponding functional unit in the functional module; The simulation performance data corresponding to each simulation unit is collected; wherein, when the simulation unit performs functional simulation, data is transmitted based on a differentiated transmission channel, the differentiated transmission channel includes a first network and a second network, the first network is used to realize low-latency communication between virtual modules within the same simulation unit, and the second network is used to realize collaborative communication between virtual modules across simulation units; Based on the simulation performance data, feedback optimization operations are performed on the functional simulation of each simulation unit to achieve collaborative control optimization of the humanoid robot.

[0006] To achieve the above objectives, another aspect of this application proposes a humanoid robot collaborative simulation control device for industrial scenarios, the device comprising the following modules: A functional module determination module is used to determine the functional modules of the humanoid robot; wherein, the functional modules include a motion control module, an environmental perception module, a task execution module, and a human-computer interaction module; A simulation unit construction module is used to construct simulation units corresponding to the functional modules; wherein each simulation unit contains at least one virtual module; A container allocation module is used to allocate containers to each virtual module in the simulation unit according to a container allocation algorithm, and to allocate corresponding container resources to each container; wherein, each virtual module is allocated one container, and the container is used to simulate the corresponding functional unit in the functional module; The simulation performance data acquisition module is used to acquire simulation performance data corresponding to each simulation unit; wherein, when the simulation unit performs functional simulation, data transmission is carried out based on a differentiated transmission channel, the differentiated transmission channel includes a first network and a second network, the first network is used to realize low-latency communication between virtual modules within the same simulation unit, and the second network is used to realize collaborative communication between virtual modules across simulation units; The collaborative control optimization module is used to perform feedback optimization operations on the functional simulation of each simulation unit based on the simulation performance data, so as to achieve collaborative control optimization of the humanoid robot.

[0007] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0008] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0009] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0010] The embodiments of this application include at least the following beneficial effects: This application provides a humanoid robot collaborative simulation control method and related equipment for industrial scenarios. This solution achieves virtualized simulation verification of functions by constructing a simulation unit containing at least one virtual module for each functional module. Core function testing can be completed without relying on physical robot hardware, avoiding potential equipment damage or safety risks during physical testing and improving system reliability. A container allocation algorithm is used to allocate containers and corresponding resources to each virtual module individually, avoiding resource waste while ensuring that core modules such as motion control modules and task execution modules receive sufficient resource support, thus ensuring simulation stability. The first network can meet the high-frequency data interaction requirements within the module, ensuring the real-time performance and accuracy of single-module functional simulation. The second network is responsible for collaborative communication across simulation units, adapting to non-real-time but reliable data transmission between different modules. Differentiated design balances low latency and high reliability requirements, avoiding collaborative failures caused by network congestion and improving the smoothness of multi-module collaborative simulation. Based on performance data feedback optimization, a closed loop of function mapping-simulation-evaluation-optimization is formed, continuously correcting the parameters and collaborative logic of each module, gradually reducing control errors, improving the accuracy and stability of multi-module collaborative control of the humanoid robot, and ultimately ensuring that the control effect of the physical robot meets the design expectations. Attached Figure Description

[0011] Figure 1 This is a flowchart of a humanoid robot collaborative simulation control method for industrial scenarios provided in an embodiment of this application; Figure 2 This is a schematic diagram of the composition architecture of the motion control module provided in the embodiments of this application; Figure 3 This is a schematic diagram of the composition architecture of the environment perception module provided in an embodiment of this application; Figure 4 This is a schematic diagram of the composition architecture of the task execution module provided in the embodiments of this application; Figure 5 This is a schematic diagram of the composition architecture of the human-computer interaction module provided in the embodiments of this application; Figure 6 This is a schematic diagram of the process for allocating containers based on a module quantity priority algorithm provided in an embodiment of this application; Figure 7 This is a schematic diagram of the process for allocating containers based on a communication priority algorithm provided in an embodiment of this application; Figure 8 This is a schematic diagram of the process for allocating containers based on a timeliness-demand priority algorithm provided in an embodiment of this application; Figure 9 This is a schematic diagram of virtual module and container networking provided in the embodiments of this application; Figure 10 This is a schematic diagram of the process for constructing a humanoid robot collaborative simulation environment provided in this application embodiment; Figure 11 This is a schematic diagram of the structure of the humanoid robot collaborative simulation control device for industrial scenarios provided in this application embodiment; Figure 12 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0013] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0014] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0015] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0016] As industrial automation upgrades towards "flexibility" and "intelligence," humanoid robots, with their human-like movement capabilities and multi-task adaptability, are gradually becoming core equipment to replace manual labor in precision operations and high-risk tasks. Humanoid robots in industrial scenarios need to integrate four core functional modules: motion control (joint actuation, gait planning), environmental perception (visual recognition, force feedback, laser ranging), task execution (grasping, assembly, handling), and human-machine interaction (voice commands, fault alarms). These modules require high-frequency, low-latency data interaction (e.g., in assembly scenarios, the motion control module needs to receive part positioning data from the visual recognition module in real time, with latency controlled within 10 milliseconds). However, current simulation and control systems for humanoid robots suffer from the following technical challenges: (1) High cross-module communication latency: Currently, most systems adopt a single network architecture (such as full Ethernet) to carry the communication of all modules. The communication latency between the motion control module and the environmental perception module can reach 25~30 milliseconds, resulting in precision assembly errors exceeding 0.5mm; the large data transmission of the environmental perception module (such as 4K visual stream) can easily occupy the real-time bandwidth of the motion control module, causing gait instability. (2) Rigid resource allocation: Computing resources (CPU, memory, network bandwidth) are mostly allocated to each module in a "static partitioning" manner, which cannot be dynamically adjusted according to the task scenario. Under the traditional static allocation method, the memory utilization rate of the path planning module in the logistics scenario is less than 30%, while the CPU computing power of the motion control module in the assembly scenario is overloaded for a long time. (3) Low efficiency of large-scale simulation: When simulating the collaborative operation of multiple humanoid robots at the same time (such as the assembly of multiple robots on a production line), the resource consumption of traditional virtual machine deployment is large, and the synchronization error of the collaborative simulation between modules exceeds 55 milliseconds, which cannot meet the industrial-grade accuracy requirements.

[0017] In view of this, this application provides a humanoid robot collaborative simulation control method and related equipment for industrial scenarios. This solution achieves virtualized simulation verification of functions by constructing a simulation unit containing at least one virtual module for each functional module. Core function testing can be completed without relying on physical robot hardware, avoiding potential equipment damage or safety risks during physical testing and improving system reliability. A container allocation algorithm is used to allocate containers and corresponding resources to each virtual module individually, avoiding resource waste and ensuring that core modules such as motion control modules and task execution modules receive sufficient resource support, thus ensuring simulation stability. A first network can meet the high-frequency data interaction needs within the module, ensuring the real-time performance and accuracy of single-module functional simulation. A second network is responsible for collaborative communication across simulation units, adapting to non-real-time but reliable data transmission between different modules. Differentiated design balances low latency and high reliability requirements, avoiding collaborative failures caused by network congestion and improving the smoothness of multi-module collaborative simulation. Based on performance data feedback optimization, a closed loop of function mapping-simulation-evaluation-optimization is formed, continuously correcting the parameters and collaborative logic of each module, gradually reducing control errors, improving the accuracy and stability of multi-module collaborative control of the humanoid robot, and ultimately ensuring that the control effect of the physical robot meets the design expectations.

[0018] The humanoid robot collaborative simulation control method for industrial scenarios provided in this application relates to the field of computer technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the humanoid robot collaborative simulation control method for industrial scenarios, but is not limited to the above forms.

[0019] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0020] Please see Figure 1 , Figure 1 This is an optional flowchart of a humanoid robot collaborative simulation control method for industrial scenarios provided in this application embodiment. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0021] Step S101: Determine the functional modules of the humanoid robot; wherein, the functional modules include a motion control module, an environmental perception module, a task execution module, and a human-computer interaction module; Optionally, the functional modules of the humanoid robot mainly include a motion control module, an environmental perception module, a task execution module, and a human-computer interaction module.

[0022] Please see Figure 2 , Figure 2 This is a schematic diagram of the composition architecture of the motion control module provided in the embodiments of this application, as shown below. Figure 2 As shown, the functional units in the motion control module include a joint drive unit, a gait planning unit, and a force control adjustment unit. Please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram of the composition architecture of the environment perception module provided in the embodiments of this application, as shown below. Figure 3 As shown, the functional units in the environmental perception module include a visual recognition unit, a force feedback unit, and a laser ranging unit. Please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of the composition architecture of the task execution module provided in the embodiments of this application, as shown below. Figure 4 As shown, the functional units in the task execution module include a capture control module and a path planning module. Please refer to [link / reference]. Figure 5 , Figure 5 This is a schematic diagram of the composition architecture of the human-computer interaction module provided in the embodiments of this application, such as... Figure 5 As shown, the functional units in the human-computer interaction module include a voice parsing unit and an alarm feedback unit.

[0023] Step S102: Construct simulation units corresponding to the functional modules; wherein each simulation unit contains at least one virtual module; In this embodiment of the application, the computer system includes multiple computing devices (such as industrial servers and edge computing nodes). The computing resources of each computing device are used to provide one or more Pods (container sets). The Pod (container set) is a Pod in the Kubernetes network model. Each Pod contains one or more containers and the containers in the Pod (container set) share the network namespace.

[0024] In the specific implementation, the computing resources of each computing device are containerized (using Docker 27.0.0 + Kubernetes 1.30.0) to form multiple Pods (container collections). Each Pod contains 1 to 3 containers (adjusted according to the computing power requirements of the functional unit: for example, visual recognition containers are allocated 6 CPU cores and 32GB memory, and grasping and control containers are allocated 2 CPU cores and 8GB memory). The containers within the Pod achieve internal communication of ≤2ms through shared memory to avoid cross-Pod communication overhead.

[0025] Optionally, each Pod (container set) allocates resources to containers according to the computing power requirements of functional units: for example, visual recognition containers are allocated 6 CPU cores and 32GB memory, grasping and control containers are allocated 2 CPU cores and 8GB memory, and force feedback containers are allocated 4 CPU cores and 16GB memory; and the containers within a Pod achieve internal communication of ≤2ms through shared memory.

[0026] In this embodiment, simulation units are constructed corresponding to the four functional modules of the humanoid robot. The virtual modules and functions of each unit are clearly mapped to ensure that the simulation logic is consistent with the actual device. Specifically: (1) Motion control simulation unit ( ): Includes joint-driven virtual module ( Simulation of 6-axis joint motor control), gait planning virtual module ( Simulated arm motion path generation), force control adjustment virtual module ( (Simulation assembly pressure feedback adjustment); (2) Environmental perception simulation unit ( ): Includes a visual recognition virtual module ( A virtual module for laser ranging (based on OpenCV) achieves 0.1mm precision part positioning. Simulated lidar distance detection), force feedback virtual module ( (Simulation assembly force data acquisition). (3) Task execution simulation unit ( ): Includes a virtual module for grasping and controlling ( Simulation gripper opening and closing control), path planning virtual module ( Simulation of multi-robot collaborative paths); (4) Human-computer interaction simulation unit ( ): Includes a virtual module for speech parsing ( Simulated industrial voice command recognition), alarm feedback virtual module ( (Simulated fault audio-visual alarm triggered).

[0027] Step S103: Allocate containers to each virtual module in the simulation unit according to the container allocation algorithm, and allocate corresponding container resources to each container; wherein, each virtual module is allocated one container, and the container is used to simulate the corresponding functional unit in the functional module; Each virtual module is assigned a container, which is used to simulate the corresponding functional unit in the functional module. That is, each virtual module is assigned a container to simulate the physical logic of the corresponding functional unit, and the container resources are strongly bound to the functional requirements (e.g., the force feedback virtual module requires a high sampling rate, so it is allocated 4 CPU cores and 16GB of memory).

[0028] The core basis for classifying virtual modules is the correlation between functional characteristics and computing power requirements. Specifically: motion control modules, which focus on real-time control command processing (such as joint actuation and gait planning), require stable medium-to-high computing power support; environmental perception modules, which focus on large-scale data processing (such as visual recognition and laser ranging), require high computing power support; task execution modules, which focus on action logic and path optimization (such as grasping control and path planning), require medium computing power support and need to balance computing power and response speed; and human-computer interaction modules, which focus on signal analysis and feedback (such as voice analysis and alarm feedback), require basic computing power support and prioritize stability.

[0029] Optionally, the container allocation algorithm includes a module quantity priority algorithm, a communication priority priority algorithm, and a timeliness requirement priority algorithm. It is worth noting that in practical applications, users can choose an algorithm to execute based on the core requirements of the industrial task (such as resource utilization, interaction efficiency, and security thresholds), without needing to simultaneously meet multiple "priority" conditions. They can also combine algorithms as needed, and this application embodiment does not impose any restrictions on this.

[0030] In some embodiments, step S103 may include: allocating a corresponding container to each virtual module in the simulation unit based on a module quantity priority algorithm; or, allocating a corresponding container to each virtual module in the simulation unit based on a communication priority priority algorithm; or, allocating a corresponding container to each virtual module in the simulation unit based on a timeliness requirement priority algorithm.

[0031] In some specific embodiments, the step of allocating corresponding containers to virtual modules in each simulation unit based on a module quantity priority algorithm may include: determining simulation units currently without allocated resources from among all simulation units; determining a first target simulation unit containing the most virtual modules from among the simulation units currently without allocated resources; allocating containers of the target computing device to virtual modules in the first target simulation unit according to a maximization allocation principle; wherein, the maximization allocation principle is used to allocate containers of the same computing device to several virtual modules in the first target simulation unit; when all containers in the target computing device are allocated, if there are virtual modules in the first target simulation unit without allocated containers, then selecting idle computing devices that are physically adjacent to the target computing device and allocating them according to core function priority. The containers in the computing devices are allocated to the remaining unallocated virtual modules in the first target simulation unit. When all containers in the idle computing devices are allocated, if there are still unallocated virtual modules in the first target simulation unit, the process returns to the step of filtering idle computing devices that are physically adjacent to the target computing device and allocating the containers in the idle computing devices to the remaining unallocated virtual modules in the first target simulation unit according to the core function priority, until all virtual modules in the first target simulation unit have been allocated corresponding containers. When all virtual modules in the first target simulation unit have been allocated corresponding containers, the process returns to the step of determining the first target simulation unit with the most virtual modules from the simulation units with currently unallocated resources, until each simulation unit has been allocated corresponding containers.

[0032] Among them, the module number priority algorithm is mainly applicable to scenarios where the number of virtual functional modules varies greatly (such as the environmental perception module containing 3 virtual modules and the human-computer interaction module containing 2 virtual modules). It prioritizes the aggregation of multiple modules to the same device to reduce cross-device communication overhead, corresponding to "intelligent logistics" in industrial scenarios (where there are many path planning + grasping control modules).

[0033] For the first target simulation unit, it is the simulation unit with the most virtual modules among the simulation units currently without allocated resources. For example, if the environment perception simulation unit contains 3 virtual modules and the human-computer interaction simulation unit contains 2 virtual modules, then the simulation unit with the most virtual modules is the environment perception simulation unit.

[0034] Optionally, the principle of maximizing allocation is the core mechanism of the module quantity priority algorithm. It aims to allocate containers on the same computing device to several virtual modules within the first target simulation unit. In other words, the module quantity priority algorithm aims to allocate as many virtual modules as possible within the first target simulation unit to containers on the same computing device, maximizing the allocation of virtual modules within the first target simulation unit to containers on the same computing device. This can be understood as prioritizing the allocation of the same computing device resources to simulation units with a larger number of virtual modules.

[0035] Please see Figure 6 , Figure 6 This is a schematic diagram of the process for allocating containers based on a module quantity priority algorithm provided in an embodiment of this application, as shown below. Figure 6 As shown, the overall implementation process of container allocation based on the module quantity priority algorithm is as follows: First, determine the first target simulation unit containing the most virtual modules from the simulation units currently without allocated resources; then, allocate containers on the same computing device to as many virtual modules as possible in the first target simulation unit; when all containers in the current computing device are allocated, if there are virtual modules in the first target simulation unit without allocated containers, prioritize selecting an idle computing device that is physically adjacent to the device where the allocated modules of the first target unit are located (such as servers in the same rack, where cross-device communication latency can be controlled to ≤10ms to avoid increased latency due to excessive device distance). Next, for the remaining modules in the first target unit that have not been assigned containers, they are sorted according to "core function priority" (e.g., joint drive module of motion control unit > gait planning module), and core modules (e.g., assign joint drive module first) are assigned to the selected idle computing devices first. When all containers in the current idle computing device are assigned, if the current idle computing device resources are limited and there are still virtual modules in the first target simulation unit that have not been assigned containers, other idle computing devices are screened, and the steps of "screening idle computing devices - assigning core modules" are repeated until all virtual modules of the first target unit are assigned containers. When the first target simulation unit (e.g., All virtual modules in ) (such as of When all simulation units have been allocated corresponding containers, return to the step of determining the first target simulation unit with the most virtual modules from the simulation units with currently unallocated resources, and continue until each simulation unit ( All virtual modules (such as) Each of the four functional modules has a corresponding container; if all simulation units corresponding to the four functional modules ( All virtual modules within ) (such as If all virtual modules in all simulation units have been allocated containers, the module quantity priority algorithm ends. Otherwise, it returns to the step of determining the first target simulation unit with the most virtual modules from the simulation units that are currently not allocated resources, until all virtual modules in all simulation units have been allocated containers, then the algorithm ends.

[0036] For example, the overall algorithm flow of the module number priority algorithm is as follows: (1) Initialization: All simulation units ( Both the virtual module and its corresponding virtual module are marked as "unassigned". (2) Step A: From the simulation units currently marked as "unassigned", select the unit with the "most virtual modules" as the target simulation unit (e.g., the first selection). (Contains 3 modules) (3) Step B: Assign containers to the virtual modules of the target simulation unit (prioritize assigning them to the same computing device, with priority given to core modules). (4) Step C (single loop judgment): Determine whether all virtual modules of the target simulation unit have been allocated: If "No" (example: of If not assigned, return to step B and continue. The remaining modules search for idle computing devices (such as nearby servers). ), through idle computing devices for The remaining modules are allocated to containers; if the current available device resources are still insufficient (e.g., can only accommodate 1 remaining module), return to step B to filter other available computing devices until... All virtual modules are allocated containers; if"( If all modules are allocated, proceed to step D; (5) Step D (Global Judgment): Judgment of all simulation units ( Have all virtual modules been allocated? If "No" (example: , , If the module is not assigned, return to step A and select the next "unassigned" unit with the largest number of modules (e.g., ...). As the new objective, repeat steps B through D; If "yes", the algorithm terminates.

[0037] In this embodiment, priority is given to ensuring "aggregation of individual unit modules": In industrial scenarios, virtual modules of the same simulation unit (such as the joint drive module and force feedback module of the motion control unit) need to interact at high frequency (more than 300 times / second). If they are scattered across different devices, the cross-device latency will increase from ≤5ms to 15~20ms, resulting in a decrease in robot motion accuracy (such as the assembly error increasing from ±0.02mm to ±0.1mm). Therefore, the algorithm prioritizes ensuring that "all modules of the target unit are aggregated as much as possible" before processing other units. Ultimately, "global coverage of all units" is achieved: Robot simulation requires the collaborative work of four major functional modules (motion control, environmental perception, task execution, and human-machine interaction), none of which can be missing. Therefore, the algorithm ensures that all modules of all units are allocated through "global judgment" to avoid functional deficiencies (such as the inability to receive operator instructions due to the lack of a human-machine interaction module).

[0038] The virtual module resource allocation for the motion control module is as follows: the motion control simulation unit includes joint drives ( ), gait planning ( Force control adjustment () Virtual modules such as joint drive virtual modules are strongly tied to the real-time and precision requirements of robot motion control in industrial scenarios. Specifically: The system is equipped with a 4-core CPU and 16GB of memory, requiring high-frequency processing of joint torque control commands (such as 1kHz angle refresh requirements), ensuring a control latency of ≤5ms, and meeting the ±0.02mm accuracy requirement for "screw tightening" actions in precision assembly scenarios; gait planning virtual module ( The system is equipped with a 2-core CPU and 8GB of memory. It primarily generates walking gait based on ground information from the environmental perception module (e.g., obstacle avoidance gait in logistics scenarios). Its computing power requirement is slightly lower than that of joint drives, but it must ensure real-time path planning (≤10ms gait adjustment response). A force control adjustment virtual module ( It is equipped with a 3-core CPU and 12GB of memory, mainly used for real-time acquisition of pressure data at the end of the robotic arm (such as force control adjustment with a precision of 10N), ensuring a feedback delay of ≤3ms, and adapting to the force control assembly scenario of "grabbing fragile parts" in high-risk operations.

[0039] The virtual module resource allocation for the environmental perception module is as follows: the environmental perception simulation unit includes visual recognition (…). Force feedback ), laser ranging ( Virtual modules such as visual recognition are strongly tied to resource allocation and "large-scale data processing and real-time perception accuracy." Specifically: the visual recognition virtual module... The system is equipped with a 6-core CPU and 32GB of memory. It needs to process image feature extraction from industrial cameras at 200fps (such as "bolt hole center coordinates" recognition, with an error of ±0.01mm), ensuring an image processing latency of ≤10ms to support the core perception requirements of precision assembly scenarios; force feedback virtual module ( The system is equipped with a 4-core CPU and 16GB of memory, primarily used for real-time transmission of pressure data at the robotic arm's end effector (such as 10N pressure threshold control for "gripping parts"), for force control adjustment in the motion control module, and ensuring cross-module communication latency of ≤5ms; a laser ranging virtual module ( It is equipped with 2 CPU cores and 8GB of memory, mainly used to process laser point cloud data to generate obstacle contours. Its computing power requirement is lower than that of visual recognition, which meets the communication timeliness requirements of robot obstacle avoidance in logistics scenarios (≤20ms path adjustment response).

[0040] The virtual module resource allocation for the task execution module is as follows: the task execution simulation unit includes grasping control (… ), path planning Virtual modules, such as the grasping control module, have computational requirements between those of motion control and environmental perception modules. Specifically: the grasping control virtual module is allocated 2-4 CPU cores and 8-16GB of memory (comparable to the joint drive module in motion control, as it needs to respond to grasping commands in real time); the path planning virtual module is allocated 4 CPU cores and 16GB of memory (it needs to handle multi-robot collaborative path calculations, so its computational requirements are slightly higher than those of the grasping control module). In the module quantity priority algorithm, if the number of virtual modules in the task execution simulation unit (e.g., 2) is greater than that of other unallocated units (e.g., the human-computer interaction module contains 2, and the motion control module contains 3), then they participate in the allocation according to the "quantity sorting" and have priority in obtaining container resources of the same computing device.

[0041] Optionally, the virtual module allocation resources for the human-computer interaction module are as follows: the human-computer interaction simulation unit includes speech parsing (… ), alarm feedback ( Virtual modules, such as voice parsing virtual modules, have lower computing power requirements. Specifically: the voice parsing virtual module is allocated 2 CPU cores and 8GB of memory (requiring basic voice signal processing computing power); the alarm feedback virtual module is allocated 1 CPU core and 4GB of memory (only needing to handle simple alarm signal triggering logic). In the module quantity priority algorithm, if the number of virtual modules in the human-computer interaction simulation unit (e.g., 2) is the largest among currently unallocated units (e.g., all other units have 1), then it will be prioritized for allocation of container resources on the same computing device; if the number is less than other units (e.g., the motion control module has 3), then allocation will be carried out after units with a larger number of modules are allocated.

[0042] It is worth mentioning that the motion control module focuses on "motion accuracy and real-time performance," with resource allocation tilted towards high-frequency control command processing; the environmental perception module focuses on "data processing and perception accuracy," with resource allocation tilted towards large-scale data computation; and the task execution and human-computer interaction modules focus on "task logic and interaction response," respectively, with resource allocation balancing computing power and scenario requirements. This differentiated allocation not only ensures the core functional requirements of each module but also achieves global resource optimization through a "module quantity priority algorithm," perfectly aligning with the technical goals of collaborative simulation and control of industrial humanoid robots.

[0043] In some specific embodiments, the step of allocating corresponding containers to virtual modules in each simulation unit based on a communication priority algorithm may include: determining the communication priorities of several virtual module pairs based on the communication load, communication quality requirements, and communication timeliness requirements between each virtual module pair; allocating containers of the target computing device to virtual module pairs with communication priorities higher than preset priority requirements according to the communication priority principle; wherein, the communication priority principle is used to allocate containers of the same computing device to virtual module pairs with communication priorities higher than preset priority requirements; when all containers in the target computing device are allocated, if there are virtual module pairs without allocated containers, then an idle computing device is selected as the target computing device, and the process returns to the step of allocating containers of the target computing device to virtual module pairs with communication priorities higher than preset priority requirements according to the communication priority principle, until each virtual module pair has been allocated a corresponding container.

[0044] In some specific embodiments, the step of determining the communication priority of several virtual module pairs based on the communication load, communication quality requirements, and communication timeliness requirements between each virtual module pair may include: obtaining the communication latency requirement threshold of each virtual module; calculating the communication timeliness requirement of each virtual module according to the communication timeliness requirement calculation formula and in combination with the communication latency requirement threshold of each virtual module; determining the individual priority of each virtual module in the first network by combining the communication timeliness requirement corresponding to each virtual module with the importance of the virtual module; and calculating the communication priority of each virtual module pair by combining the communication load, communication quality requirements, and the individual priority corresponding to each virtual module pair.

[0045] Here, "virtual module pair" refers to the combination of all virtual modules in all simulation units, including module pairs across simulation units. Optionally, the simulation and control of industrial humanoid robots relies on multi-module cross-unit collaboration; for example, the "visual recognition module (…)" of the environmental perception unit… The "joint drive module" of the motion control unit needs to be integrated with it. High-frequency interaction (such as 200fps image feature-joint angle correction and 500 communication times / second) is required to achieve a visually guided assembly accuracy of ±0.02mm. If only "module pairs within the same simulation unit" are considered, the core interaction links between such units cannot be covered, causing the communication latency to increase from ≤5ms to 15~20ms, directly affecting the robot's motion accuracy.

[0046] Among them, the communication priority algorithm is mainly applicable to scenarios of "high-frequency interaction between modules" (such as visual recognition and joint drive unit needing 500 times / second communication). It prioritizes the aggregation of core interaction links through priority calculation, corresponding to "precision assembly" in industrial scenarios.

[0047] The communication priority principle is the core mechanism of the priority priority algorithm. It aims to allocate containers on the same computing device to virtual module pairs with communication priorities higher than the preset priority requirements. In other words, virtual module pairs with higher communication priorities are given priority in being allocated containers on the same computing device.

[0048] Optionally, the communication quality requirement is based on the maximum permissible bit error rate (BER) of the virtual module for transmitted data packets. ,unit: The communication timeliness requirement is described in terms of the maximum allowable delay for communication by the virtual module. The description is in milliseconds, and the maximum allowable latency is ( ). (Not greater than the communication latency requirement threshold of the corresponding virtual module) ( The communication latency requirement threshold for a single virtual module is determined by the module's functional characteristics.

[0049] The linear function expression for communication priority (P) is as follows: ; Where α, β, and γ are weighting coefficients greater than 0 and α + β + γ = 1; α takes values ​​of 0.4~0.6 in industrial assembly scenarios and 0.2~0.3 in logistics scenarios; β takes values ​​of 0.3~0.5 in hazardous environment operation scenarios; γ takes values ​​of 0.5~0.7 in precision assembly scenarios; f is the communication frequency per unit time of the virtual module pair; q is the maximum permissible bit error rate; d is the maximum permissible delay and ( The communication latency requirement threshold for a single virtual module, such as ≤5ms for the joint driving module and ≤10ms for the image processing module.

[0050] Please see Figure 7 , Figure 7 This is a schematic diagram of the process for allocating containers based on a communication priority algorithm provided in an embodiment of this application, as shown below. Figure 7As shown, the overall implementation process of allocating containers based on the communication priority algorithm provided in this application embodiment includes: First, determining the communication load between all virtual module pairs ( ), communication quality requirements ( ) and the need for timely communication ( Then, based on the communication load between virtual module pairs ( ), communication quality requirements ( ) and the need for timely communication ( The process involves calculating the communication priority of each virtual module pair, sorting the communication priorities from highest to lowest, and finally allocating containers on the same computing device to virtual module pairs with higher communication priorities, until all module pairs (including cross-cell pairs) have been allocated.

[0051] In this embodiment of the application, when calculating and determining the communication priority of each virtual module within each simulation unit, the method further includes a step of determining the communication priority of the virtual module in the first network (for ease of distinction, the communication priority of a single virtual module is represented by an individual priority), specifically: First, obtain the communication latency requirement threshold for the j-th virtual module ( The characteristics of the virtual module and industrial scene standards are determined by factors such as the image processing module of an industrial camera. ≤10ms, joint drive module Force feedback module ; Next, according to the communication timeliness requirements ( The calculation formula calculates the communication timeliness requirement of the j-th virtual module. ): ; in, The weighting coefficient of the simulation unit to which this virtual module belongs (motion control module) Values ​​range from 0.6 to 0.8; environmental perception module. (Values ​​range from 0.3 to 0.5) The expected maximum data throughput of this virtual module (unit: times / second, e.g., for a 200fps camera). ), The communication latency requirement threshold for a single virtual module (e.g., force feedback module ≤ 3ms). The actual communication latency that the first network can provide (measured using the iPerf3 tool at the core node of the first network for more than 5 minutes, and taken as the 99th percentile value, in milliseconds). In combination with the aforementioned communication timeliness requirements ( The importance of virtual modules (e.g., force feedback modules are more important than speech parsing modules) is used to determine the individual priority of virtual modules in the first network.

[0052] Specifically, the overall implementation process for determining the communication priority of virtual module pairs in the communication priority algorithm is as follows: First, determine the individual priority of each virtual module in the first network (e.g., the visual recognition module). It has a higher priority than the speech parsing module. When combining two virtual modules into a module pair, the communication load between them (e.g.) and Communication frequency 500 times / second), communication quality requirements (such as bit error rate ≤) ), and the individual priorities corresponding to the two virtual modules, to finally calculate the communication priority of the virtual module pair (e.g. The priority is higher than ).

[0053] For example, priority handling for cross-unit module pairs: cross-unit module pairs (such as environment sensing units) of With motion control unit of This falls within the scope of the first network (core control interaction), and its communication priority calculation fully follows the first network's architecture: first, the communication timeliness requirements of each of the two modules are calculated. Based on individual priorities and combined with the communication load and quality requirements of the module pair, the priority of the module pair is finally determined and it is preferentially allocated to the same device to ensure low latency (≤5ms) for cross-unit interaction.

[0054] It should be noted that the first network (STT protocol, core control link) needs to guarantee a low latency of ≤5ms. Therefore, it is necessary to calculate the communication priority carefully and prioritize the allocation of high-priority modules to the same device to ensure the control accuracy in industrial scenarios (such as precision assembly). The second network (Geneve protocol, auxiliary coordination link) has a latency requirement of ≤10ms and is less sensitive to priority. It is usually allocated according to "remaining resources" or "default low priority allocation". Therefore, it does not need to perform the same complex communication priority calculation as the first network.

[0055] In the "communication priority first" strategy, timeliness requirements are considered. ")" and "Single virtual module latency threshold" The association between "function" and "delay" makes priority calculation more aligned with the strong "function-delay" binding characteristics of industrial robots (such as joint drive modules). ≤5ms, speech parsing module ≤50ms). For example, in a precision assembly scenario, the calculation of "visual recognition ( - Joint drive ( When prioritizing modules, it is necessary to first go through... Formula Confirmation The timeliness requirement (due to V) 21 of , The value is higher than that of low-time-efficiency modules), and then the communication load (f=500 times / second) and bit error rate are added. Calculate the final priority to ensure that the priority result reflects both the "interaction intensity" and the "real-time rigidity constraint".

[0056] In this embodiment, the difference between the communication priority algorithm and the module quantity priority algorithm is as follows: the module quantity priority algorithm focuses on "module aggregation within the same simulation unit," reducing cross-device communication within the unit; the communication priority algorithm focuses on "communication strength and real-time performance of all module pairs," prioritizing low latency for high-interaction links regardless of whether they are in the same unit. This differentiated design enables this application to simultaneously cover two scenarios: "resource aggregation within the unit" and "cross-unit collaborative communication." For example: if in a certain scenario "visual recognition ( - Joint drive ( The communication priority of "" is the highest (due to assembly precision requirements). The algorithm will prioritize assigning these two cross-unit module pairs to the same device to ensure core link latency. If the priority of "multi-module interaction within the same unit" is higher in a certain scenario (such as "grabbing control-path planning" in the task execution unit), the algorithm can also adapt.

[0057] In some specific embodiments, the step of allocating a corresponding container to a virtual module in each simulation unit based on a timeliness requirement priority algorithm may include: obtaining a communication latency requirement threshold for the virtual module in each simulation unit; calculating the communication timeliness requirement for each simulation unit according to the communication timeliness requirement calculation formula and the communication latency requirement threshold for the virtual module in each simulation unit; and allocating the container of the target computing device to a second target simulation unit whose communication timeliness requirement is higher than a preset timeliness requirement according to the communication timeliness principle; wherein, the communication timeliness principle is used to allocate the container of the target computing device to the second target simulation unit whose communication timeliness requirement is higher than the preset timeliness requirement. Containers on the same computing device; if not all virtual modules in the second target simulation unit are assigned to the same computing device, then based on the communication latency requirement threshold and data throughput of a single virtual module in the second target simulation unit, containers on the same computing device are assigned to target virtual modules in the second target simulation unit whose communication timeliness requirements are higher than the preset timeliness requirements; when all virtual modules in the second target simulation unit have been assigned corresponding containers, the process returns to the step of assigning containers on the target computing device to the second target simulation unit whose communication timeliness requirements are higher than the preset timeliness requirements according to the communication timeliness principle, until each simulation unit is assigned a corresponding container.

[0058] Among them, the timeliness requirement priority algorithm is mainly applicable to scenarios where the "delay threshold cannot be broken" (such as the force feedback unit needing a delay of ≤3ms to avoid damage to the parts), prioritizing the rigid constraints of real-time performance, corresponding to "high-risk operations" in industrial scenarios (chemical / mining environments).

[0059] Please see Figure 8 , Figure 8 This is a schematic diagram of the process for allocating containers based on a timeliness-demand priority algorithm provided in an embodiment of this application, as shown below. Figure 8 As shown, the overall implementation process of allocating containers based on the timeliness demand priority algorithm provided in this application embodiment includes: First, obtaining the communication delay demand threshold of each virtual module ( ), and calculate the communication timeliness requirements of each simulation unit ( Then, priority is given to communication timeliness requirements (); Higher-level simulation units are allocated containers on the same computing device; if the virtual modules of a simulation unit cannot all be allocated to the same computing device, then a single virtual module is used. and data throughput ( Select the simulation unit to be assigned, and prioritize assigning containers on the same computing device to virtual modules with higher timeliness requirements within the simulation unit.

[0060] In the "timeliness priority" strategy, when the core objective of an industrial scenario is "the delay threshold cannot be breached" (such as "force feedback" in high-risk operations), - Emergency Braking The "Timeliness Priority" module can be used for independent allocation: it does not require calculation of parameters such as communication load and bit error rate, but only through the "Simulation Unit". Value Sort - Module "Sorting" prioritizes assigning high-efficiency modules to the same device. For example, in high-risk operation scenarios, the force feedback module... ≤3ms ), alarm feedback module ≤50ms At this point, the force feedback module is directly assigned to the same device first, without the need for associated communication priority calculation, making the demand quantification more accurate.

[0061] Step S104: Collect simulation performance data corresponding to each simulation unit; wherein, when the simulation unit performs functional simulation, data transmission is performed based on a differentiated transmission channel, the differentiated transmission channel includes a first network and a second network, the first network is used to realize low-latency communication between virtual modules within the same simulation unit, and the second network is used to realize collaborative communication between virtual modules across simulation units; During functional simulation within the simulation unit, data transmission is conducted using differentiated transmission channels. These channels include a first network and a second network. The first network enables low-latency communication between virtual modules within the same simulation unit, while the second network enables collaborative communication between virtual modules across simulation units. Specifically, virtual module containers within the same simulation unit are networked into a first network based on a first communication protocol, achieving low-latency communication of ≤5ms between virtual modules within the same simulation unit. All Pods are networked into a second network based on a second communication protocol, enabling collaborative communication between virtual modules across simulation units. Specifically, the first network is a physical network or a routing overlay network, preferentially using the STT protocol, with a communication latency of ≤5ms. The second network is a virtual network, preferentially using the Geneve protocol, with a communication latency of ≤10ms. Additionally, the first and second communication protocols can also be VXLAN or NVGRE protocols.

[0062] Please see Figure 9 , Figure 9 This is a schematic diagram of virtual module and container networking provided in the embodiments of this application, such as... Figure 9 As shown in the diagram, the "feedback container" and "control container" are containerized carriers of the virtual module, corresponding to the core virtual module defined above. The feedback container is used to house the environmental sensing unit (…). Force feedback module ( Its core function is to collect pressure data at the end of the robotic arm; and to control the motion control unit of the container ( The joint drive module () Its core function is to output joint angle control commands. Figure 9 In the example, both the feedback container and the control container are deployed on server 1 (256GB memory, enterprise-grade server), utilizing the high computing power of server 1 to support the high-frequency calculations of the core modules (such as the joint-driven virtual module). 1kHz joint command refresh, force feedback virtual module ( The first network uses 300 data acquisitions per second; the second network uses server 2 as the core node (with a configuration slightly lower than server 1, such as 128GB memory + 32-core CPU) to undertake the communication tasks of non-core modules.

[0063] by Figure 9 Taking a container and server deployment framework as an example, the communication logic between containers and networks (the functional application of layered networks) is as follows: (1) Feedback container ( ) and control container ( Communication between the two networks achieves low-latency collaboration through the first network: Feedback container ( ) and control container ( Interacting via the first network (STT protocol): First, the feedback container ( The pressure data collected at the end of the robotic arm (such as a force signal with a precision of 10N) is transmitted to the control container via the first network with a delay of ≤3ms. Then, control the container ( The joint drive commands are adjusted in real time based on force data (such as correcting joint torque) to meet the ±0.02mm accuracy requirement for "force-controlled screw tightening" in precision assembly scenarios.

[0064] (2) Communication positioning of the second network to realize the resource scheduling strategy of "core control priority and auxiliary function adaptation": The second network (Geneve protocol) is supported by server 2 and is used to carry communication for non-core auxiliary modules (such as the instruction feedback module of the human-computer interaction unit, i.e., the alarm feedback virtual module). For example, alarm feedback virtual modules Abnormal alarm data (such as excessive joint torque) is transmitted to the terminal via the second network to avoid occupying the bandwidth resources of the first network and ensure low latency of the core control link.

[0065] Step S105: Based on the simulation performance data, perform feedback optimization operations on the functional simulation of each simulation unit to achieve collaborative control optimization of the humanoid robot.

[0066] Steps S101 to S105 as illustrated in this embodiment of the application achieve virtualized simulation verification of functions by constructing a simulation unit containing at least one virtual module for each functional module. This allows core function testing to be completed without relying on physical robot hardware, avoiding potential equipment damage or safety risks during physical testing and improving system reliability. A container allocation algorithm is used to allocate containers and corresponding resources to each virtual module individually, avoiding resource waste while ensuring that core modules such as motion control and task execution modules receive sufficient resource support, thus guaranteeing simulation stability. The first network meets the high-frequency data interaction requirements within the module, ensuring the real-time performance and accuracy of single-module functional simulation. The second network is responsible for collaborative communication across simulation units, adapting to non-real-time but reliable data transmission between different modules. Differentiated design balances low latency and high reliability requirements, avoiding collaborative failures caused by network congestion and improving the smoothness of multi-module collaborative simulation. Feedback optimization based on performance data forms a closed loop of function mapping-simulation-evaluation-optimization, continuously correcting the parameters and collaborative logic of each module, gradually reducing control errors, improving the accuracy and stability of multi-module collaborative control of the humanoid robot, and ultimately ensuring that the control effect of the physical robot meets design expectations.

[0067] To explain in detail the principle of the technical solution of the present invention, the overall process of the present invention will be described below with reference to some specific embodiments. It is easy to understand that the following is an explanation of the technical principle of the present invention and should not be regarded as a limitation of the present invention.

[0068] This application aims to specifically address the problems of high communication latency, rigid resource allocation, and low simulation efficiency in current related systems. Therefore, it provides a simulation and control system capable of achieving "low-latency communication within modules (≤5ms), flexible cross-module collaboration, and dynamic resource adaptation" to solve the core technical bottleneck of multi-module collaboration of humanoid robots in industrial scenarios. The specific implementation of the humanoid robot collaborative simulation control method for industrial scenarios provided in this application includes the following four parts: Part One: System Architecture Design; The computer system includes multiple computing devices (such as industrial servers and edge computing nodes). The computing resources of each computing device are containerized (using Docker 27.0.0 + Kubernetes 1.30.0) to form multiple Pods (container collections). Each Pod contains 1 to 3 containers (adjusted according to the computing power requirements of the functional unit: for example, visual recognition containers are allocated 6 CPU cores and 32GB of memory, and grasping and control containers are allocated 2 CPU cores and 8GB of memory). The containers within a Pod achieve internal communication of ≤2ms through shared memory to avoid cross-Pod communication overhead.

[0069] Part Two: Division of Simulation Units and Virtual Modules; Simulation units were built to correspond to the robot's four functional modules. The virtual modules and functions of each unit were clearly mapped to ensure that the simulation logic was consistent with the actual equipment. (1) Motion control simulation unit ( ): Includes joint-driven virtual module ( Simulation of 6-axis joint motor control), gait planning virtual module ( Simulated arm motion path generation), force control adjustment virtual module ( (Simulation assembly pressure feedback adjustment); (2) Environmental perception simulation unit ( ): Includes a visual recognition virtual module ( A virtual module for laser ranging (based on OpenCV) achieves 0.1mm precision part positioning. Simulated lidar distance detection), force feedback virtual module ( (Simulation assembly force data acquisition). (3) Task execution simulation unit ( ): Includes a virtual module for grasping and controlling ( Simulation gripper opening and closing control), path planning virtual module ( Simulation of multi-robot collaborative paths); (4) Human-computer interaction simulation unit ( ): Includes a virtual module for speech parsing ( Simulated industrial voice command recognition), alarm feedback virtual module ( (Simulated fault audio-visual alarm triggered).

[0070] Each virtual module is assigned a container to simulate the physical logic of the corresponding functional unit, and the container resources are strongly bound to the functional requirements (e.g., the force feedback virtual module requires a high sampling rate and is allocated 4 CPU cores and 16GB of memory).

[0071] Part Three: Layered Network Communication Architecture; The system adopts a "dual-network layered design" to adapt to both intra-module low-latency and cross-module collaboration requirements, with clear protocol selection and latency targets. (1) First Network (Intra-module Communication): Containers within the same simulation unit are networked using a physical network or a VXLAN-based routing overlay network, prioritizing the use of the STT protocol (transmission delay ≤ 5ms) to ensure communication within the core module. For example... Inside (Gait planning) towards (Joint drive) transmission command, the measured delay is 2.3~3.5ms, which meets the 0.1mm assembly accuracy requirement; (2) Second network (cross-module collaboration): All Pods are networked together using a virtual network based on the Geneve protocol, which supports traffic slicing and QoS scheduling (such as prioritizing the bandwidth of fault alarm signals). The measured cross-unit communication latency is 8.7~10ms, which meets the requirements of multi-module collaboration.

[0072] Part Four: Dynamic Container Allocation Strategy.

[0073] It provides three scenario-specific container allocation algorithms to cover different industrial needs, and the parameters are quantifiable and repeatable: (1) Module Quantity Priority Algorithm: Prioritize simulation units with a large number of virtual modules (such as...) Pods (containing 3 virtual modules) are allocated to the same computing device, reducing cross-device communication overhead and increasing resource utilization to over 60%; (2) Communication Priority Algorithm: The communication priority of virtual module pairs is calculated using a linear formula. Prioritize high-priority module pairs (such as in assembly scenarios). , When allocated to the same computing device, the core link latency is reduced to ≤5ms; (3) Timeliness requirement priority algorithm: based on the timeliness requirement of simulation unit ( Prioritize modules with high demand (such as those used in high-risk operations). , To avoid overloading critical modules by allocating the same equipment requirements, the system can avoid delays and other issues.

[0074] The humanoid robot collaborative simulation control method for industrial scenarios provided in this application embodiment can achieve the following: communication latency of humanoid robot multi-module collaborative simulation in industrial scenarios ≤10ms (core link ≤5ms), resource utilization rate increased to over 60%, and synchronization error of multi-robot collaborative simulation ≤20ms, fully meeting the industrial-grade requirements of precision assembly, high-risk operations, etc.

[0075] Please see Figure 10 , Figure 10 This is a schematic diagram of the process for constructing a humanoid robot collaborative simulation environment provided in an embodiment of this application, such as... Figure 10 As shown, the specific implementation process of the humanoid robot collaborative simulation environment construction method provided in this application embodiment includes the following steps 1001 to 1005: Step 1001: Deploy computing devices and containerization tools—the “computing power foundation” for simulation control; In the specific implementation, three servers and a Kubernetes cluster are configured. The hardware configuration of the three servers is specifically tailored to the robot simulation control requirements, for example: server (256GB RAM + 64-core CPU): A container for deploying core control modules such as motion control and force feedback, supporting high-frequency calculations (such as 1kHz joint angle refresh) for "joint drive simulation" and "force control adjustment". server (128GB RAM + 32-core CPU): A container for deploying environmental perception modules such as visual recognition and laser ranging, supporting large-scale data processing for "image feature extraction" and "obstacle localization"; server (64GB RAM + 16-core CPU): A container for deploying auxiliary modules such as human-computer interaction and alarm feedback, supporting lightweight computing for "voice command parsing" and "abnormal status alarms".

[0076] In this embodiment of the application, the "dynamic resource scheduling" function of the Kubernetes cluster can be used to adjust container resources in real time according to the fluctuation of computing power in the simulation control (such as the peak CPU usage in the assembly scenario reaching 80%), so as to avoid the control command lag.

[0077] The three servers and Kubernetes cluster deployed in step 1001 provide scalable and highly reliable computing power support for the subsequent "simulation unit operation" and "control command transmission" - for example, K8s' "Pod self-healing" function can restart within 3 seconds when the motion control container fails, ensuring the continuity of simulation control.

[0078] Step 1002: Construct the "functional mapping" between simulation units and virtual modules—simulation control; The output in step 1002 is " Simulation unit and The "virtual module" directly maps to the core control functions of the humanoid robot, among which, For motion control unit, For environmental sensing units, As a task execution unit, This refers to the human-computer interaction unit. The specific correspondence is shown in Table 1 below: Table 1

[0079] In step 1002, the "abstract robot control function" is transformed into a "computable virtual module," clarifying the objectives for subsequent "container allocation" and "network communication"—for example... (Joint drive) and Force feedback requires high-frequency interaction (300 times / second). Therefore, subsequent steps must prioritize ensuring the communication delay between the two, which is a prerequisite for simulation control to achieve "force-controlled assembly".

[0080] Step 1003: Execute the container allocation algorithm – “real-time guarantee” for simulation control; The "Container-Pod-Server Mapping Table" output in step 1003 directly determines the real-time performance of the simulation control. Taking the allocation result of the "Precision Assembly Scenario" as an example, the container allocation example is shown in Table 2 below: Table 2

[0081] The allocation result in this application embodiment is directly bound to the "robot motion control accuracy". For example, if... (Joint drive) and (Force feedback) is distributed to different servers, and the cross-device communication latency will rise to 15ms, causing joint torque overshoot (from 10N to 15N) and damage to assembly parts. This is the risk that this application avoids by using the "communication priority algorithm".

[0082] Step 1004: Establish a hierarchical communication network (first network and second network) – the “data channel” for simulation control; The "First Network (STT) + Second Network (Geneve)" output in step 1004 provides a "differentiated transmission channel" for simulation control data. The specific division of labor of the "differentiated transmission channel" is as follows: (1) For the first network (STT protocol, latency ≤ 5ms), it is mainly used to transmit core control data, including: (Joint-driven) (Force Feedback): Force control adjustment command (300 times / second); (Visual recognition) (Grab Control): Part feature coordinates (200 times / second); The first network ensures that control data is not lost and has low latency through a "priority queue," which is the key to achieving "±0.02mm assembly accuracy" in simulation control. (2) For the second network (Geneve protocol, latency ≤10ms), it is mainly used to transmit non-core auxiliary data, including: (Speech Analysis) → ~ Human-computer interaction commands (10 times / second); → Motion status alarm data (5 times / second); The second network protection auxiliary function does not occupy the bandwidth of the core control channel.

[0083] The hierarchical network established in step 1004 solves the problem of "core control data and auxiliary data competing for bandwidth". For example, if the image data of visual recognition (100Mbps) occupies the core channel, it will cause the joint control command delay to rise to 20ms, and the robot's movement will be lagging. However, the "STT protocol" of the first network can prioritize the transmission of control commands and avoid such problems.

[0084] Step 1005: Start collaborative simulation and real-time monitoring – “closed-loop optimization” of simulation control.

[0085] The "Simulation Log + Delay / Accuracy Data" output in step 1005 serves as a quantitative evaluation basis for the simulation control effect. Its specific content and function are shown in Table 3 below: Table 3

[0086] In this embodiment, the output data in step 1005 directly serves the "iterative optimization of humanoid robot simulation control", forming a closed loop of "deployment-simulation-monitoring-optimization".

[0087] Through steps 1001 to 1005, a deep integration of resource allocation and simulation control can be achieved, and Figure 10 Through the link of "computing power support (1001) - function mapping (1002) - real-time guarantee (1003) - data channel (1004) - closed-loop optimization (1005)," technologies such as "container allocation and two-layer network" are deeply integrated with "humanoid robot collaborative simulation and precise control." The ultimate goal is not only "efficient use of resources," but also the core objective of "±0.02mm accuracy and ≤5ms latency for robot simulation control in industrial scenarios."

[0088] For ease of understanding, combined with Figures 2 to 10 Taking the "precision assembly scenario of automotive parts" as an example, this application describes the specific implementation process of the humanoid robot collaborative simulation control method for industrial scenarios provided in this embodiment. All parameters and steps are based on industry standards and measured data to ensure repeatability. Specifically, it includes the following steps one through five: Step 1: System deployment environment; (1) Computing equipment: 3 industrial servers ( Each industrial server is equipped with an Intel Xeon Gold 6348 CPU (32 cores), 256GB DDR4 memory, and a 100Gbps dual-port network card (model: Mellanox ConnectX-6). (2) Containerization tools: Docker 27.0.0, Kubernetes 1.30.0, Pod scheduling policy set to "functional module affinity" (Pods in the same simulation unit are preferentially scheduled to the same server); (3) Communication protocol: The first network uses the STT protocol (implemented through the Kubernetes CNI plugin, with MTU set to 9000), and the measured latency is 2.3~3.5ms; the second network uses the Geneve protocol (with traffic slicing enabled, allocating 50% bandwidth to motion control data), and the measured latency is 8.7~9.8ms.

[0089] Step 2: Configure simulation units and virtual modules; For automotive parts assembly scenarios (meeting the requirements of 0.1mm accuracy and ≤5ms delay in GB / T1800.3-1998 "Standard Tolerance Values"), four simulation units were constructed. The virtual modules and parameters of each unit are shown in Table 4 below: Table 4

[0090] Step 3, Container allocation process (this example uses a communication priority-first algorithm for illustration); (1) Determine communication priority calculation parameters: Based on GB / T1800.3-1998 "Standard Tolerance Values" and equipment performance (e.g., a 200fps industrial camera corresponds to f=500 times / second), set the weighting coefficients: , , , The communication parameters for each virtual module pair are shown in Table 5 below: Table 5

[0091] (2) Calculate communication priority: According to the linear function expression of communication priority (P) Calculate the communication priority of each virtual module pair: (Visual Recognition) - (Joint drive): ; (Force Feedback) - (Force control adjustment): ; (Crawling control) - (Gait planning): ; (Speech Analysis) - (Path planning): .

[0092] (3) Perform container allocation: highest priority (Force Feedback) - (Force control adjustment): Distribute to of (Configured with 4-core CPU / 16GB RAM×2, shared memory communication), meeting the ≤3ms latency requirement; Second highest priority (Visual Recognition) - (Joint drive): Assigned to of (Configured with 6-core CPU / 32GB RAM + 4-core CPU / 16GB RAM, shared memory communication), and same Cross-Pod latency ≤5ms; Third priority (Crawling control) - (Gait planning): Assigned to of Configuration: 2-core CPU / 8GB RAM + 2-core CPU / 8GB RAM) Lowest priority (Speech Analysis) - (Route planning): Assign to of (Configuration: 2-core CPU / 8GB RAM + 4-core CPU / 16GB RAM).

[0093] Step 4: Network communication verification; First network verification: of ( ), ( , , Networking via STT protocol, using the iPerf3 tool A 5-minute measurement of the switch port showed a 99th percentile latency, which meets operational requirements. The bit error rate... (lower than) ); Second network verification: of Towards of Transmitting part location data (4K resolution, 30fps), using Geneve protocol QoS scheduling, the measured latency was 8.7ms (meeting the ≤10ms requirement), and the bandwidth usage was stable at 200Mbps (not exceeding 50% of the bandwidth quota). Multi-robot collaborative verification: Simultaneously simulate two robots assembling the same automotive bearing component. Through the second network synchronization command, the actual measured motion synchronization error of the two robots is 15ms (meeting the ≤20ms requirement), and the assembly accuracy is ±0.08mm (better than the 0.1mm standard).

[0094] Step 5, Scenario Adaptation Adjustment (Switch to Smart Logistics Scenario): If the task is switched to "Intelligent Logistics Scenario for Automotive Parts" (core requirements: real-time route planning and data retrieval efficiency), the adjustments are as follows: Weighting coefficients: , , , Priority calculation: (Path planning) - (Catching Control) Module , , Priority is raised to the highest level and allocated to of (Same server). Bandwidth expansion: The second network bandwidth expansion is achieved in two ways: (1) to (1) The 100Gbps dual-port network card is configured as LACP binding, and the physical link bandwidth is increased to 200Gbps; (2) In the Kubernetes network configuration, the virtual tunnel bandwidth threshold of the Geneve protocol is adjusted to 50Gbps, and the bandwidth allocation of path planning data is guaranteed by the token bucket algorithm. The actual path update delay is ≤5ms.

[0095] It should be noted that this embodiment is only a brief illustrative description of the overall process of the humanoid robot collaborative simulation control method for industrial scenarios. Detailed descriptions of each step can be found in the relevant content of the foregoing embodiments, and will not be repeated here. It is understood that the present invention does not impose any limitations on this.

[0096] In summary, this application specifically relates to humanoid robot technology and computer simulation control technology, particularly to a humanoid robot collaborative simulation and control computer system for industrial scenarios (such as precision assembly, intelligent logistics, and hazardous environment operations). This system includes multiple computing devices, and its containerized computing resource deployment method is as follows: corresponding simulation units are constructed for the robot's motion control, environmental perception, task execution, and human-machine interaction functional modules. Each simulation unit contains one or more virtual modules, and each virtual module is assigned a container to simulate the corresponding functional unit. The containers within the same simulation unit are networked as a first network based on a first communication protocol (ensuring low-latency communication within the module ≤5ms), and all Pods (container collections, implemented using the Kubernetes network model) are networked as a second network based on a second communication protocol (achieving cross-module collaboration). Simultaneously, through three allocation algorithms—"module quantity priority," "communication priority priority," and "timeliness requirement priority"—virtual modules with high real-time performance and high communication load are preferentially allocated to the same computing device container, significantly improving the real-time performance and resource utilization of multi-module collaborative simulation of humanoid robots in industrial scenarios. This solves the problems of high cross-module communication latency, rigid resource allocation, and large synchronization errors in multi-robot collaboration in current related systems with an all-Ethernet architecture.

[0097] This application involves the intersection of humanoid robot technology, computer simulation technology and industrial control technology, and is specifically applied to the development and deployment of humanoid robots in industrial scenarios, including but not limited to precision parts assembly, intelligent warehousing and logistics, and high-risk environment (such as chemical and mining) operations. It aims to achieve efficient collaborative simulation and real-time control of humanoid robot multifunctional modules (core link latency ≤5ms) through containerized resource scheduling and hierarchical network communication architecture.

[0098] Please see Figure 11 This application also provides a humanoid robot collaborative simulation control device 1100 for industrial scenarios, which can implement the above-mentioned method. The device includes the following modules: The functional module determination module 1101 is used to determine the functional modules of the humanoid robot; wherein, the functional modules include a motion control module, an environment perception module, a task execution module, and a human-computer interaction module; The simulation unit construction module 1102 is used to construct simulation units corresponding to the functional modules; wherein each simulation unit contains at least one virtual module; The container allocation module 1103 is used to allocate containers to each virtual module in the simulation unit according to the container allocation algorithm, and to allocate corresponding container resources to each container; wherein, each virtual module is allocated one container, and the container is used to simulate the corresponding functional unit in the functional module; The simulation performance data acquisition module 1104 is used to acquire simulation performance data corresponding to each simulation unit; wherein, when the simulation unit performs functional simulation, data is transmitted based on a differentiated transmission channel, the differentiated transmission channel includes a first network and a second network, the first network is used to realize low-latency communication between virtual modules within the same simulation unit, and the second network is used to realize collaborative communication between virtual modules across simulation units; The collaborative control optimization module 1105 is used to perform feedback optimization operations on the functional simulation of each simulation unit based on the simulation performance data, so as to realize the collaborative control optimization of the humanoid robot.

[0099] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0100] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0101] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0102] Please see Figure 12 , Figure 12 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 1201 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 1202 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1202 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1202 and is called and executed by the processor 1201 using the methods described in the embodiments of this application. The input / output interface 1203 is used to implement information input and output; The communication interface 1204 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 1205 transmits information between various components of the device (e.g., processor 1201, memory 1202, input / output interface 1203, and communication interface 1204); The processor 1201, memory 1202, input / output interface 1203 and communication interface 1204 are connected to each other within the device via bus 1205.

[0103] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0104] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0105] It is understood that the content of the above method embodiments is applicable to the storage medium embodiments and the program product embodiments. The specific functions implemented by the storage medium embodiments and the program product embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0106] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0107] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A humanoid robot collaborative simulation control method for industrial scenarios, characterized in that, The method includes the following steps: The functional modules of the humanoid robot are defined; wherein, the functional modules include a motion control module, an environmental perception module, a task execution module, and a human-computer interaction module; Construct simulation units corresponding to the functional modules; wherein each simulation unit contains at least one virtual module; According to the container allocation algorithm, a container is allocated to each virtual module in the simulation unit, and a corresponding container resource is allocated to each container; wherein, each virtual module is allocated one container, and the container is used to simulate the corresponding functional unit in the functional module; The simulation performance data corresponding to each simulation unit is collected; wherein, when the simulation unit performs functional simulation, data is transmitted based on a differentiated transmission channel, the differentiated transmission channel includes a first network and a second network, the first network is used to realize low-latency communication between virtual modules within the same simulation unit, and the second network is used to realize collaborative communication between virtual modules across simulation units; Based on the simulation performance data, feedback optimization operations are performed on the functional simulation of each simulation unit to achieve collaborative control optimization of the humanoid robot.

2. The method according to claim 1, characterized in that, The container allocation algorithm includes a module quantity priority algorithm, a communication priority priority algorithm, and a timeliness requirement priority algorithm. Allocating containers to each virtual module in the simulation unit according to the container allocation algorithm includes: Based on the module quantity priority algorithm, a corresponding container is allocated to each virtual module in the simulation unit; or, Based on the communication priority algorithm, a corresponding container is assigned to each virtual module in the simulation unit; or, Based on the timeliness priority algorithm, a corresponding container is assigned to each virtual module in the simulation unit.

3. The method according to claim 2, characterized in that, The method of allocating a corresponding container to each virtual module in the simulation unit based on the module quantity priority algorithm includes: From each of the simulation units, identify the simulation unit that currently has no allocated resources; From the simulation units currently without allocated resources, determine the first target simulation unit that contains the largest number of virtual modules; According to the principle of maximizing allocation, the containers of the target computing device are allocated to the virtual modules in the first target simulation unit; wherein, the principle of maximizing allocation is used to allocate containers of the same computing device to several virtual modules in the first target simulation unit. When all containers in the target computing device are allocated, if there are virtual modules in the first target simulation unit that have not been allocated containers, then idle computing devices that are adjacent to the physical topology of the target computing device are selected, and the containers in the idle computing devices are allocated to the remaining virtual modules in the first target simulation unit that have not been allocated containers according to the core function priority. When all containers in the idle computing devices are allocated, if there are still virtual modules in the first target simulation unit that have not been allocated containers, then the process of filtering idle computing devices that are adjacent to the physical topology of the target computing device and allocating the containers in the idle computing devices to the remaining virtual modules in the first target simulation unit that have not been allocated containers is returned to the previous step, until all virtual modules in the first target simulation unit have been allocated corresponding containers. When all virtual modules in the first target simulation unit have been allocated corresponding containers, return to the step of determining the first target simulation unit with the most virtual modules from the simulation units that are currently not allocated resources, until each simulation unit is allocated a corresponding container.

4. The method according to claim 2, characterized in that, The step of allocating a corresponding container to each virtual module in the simulation unit based on the communication priority algorithm includes: Based on the communication load, communication quality requirements, and communication timeliness requirements between each virtual module pair, the communication priority of several virtual module pairs is determined. According to the communication priority principle, the containers of the target computing device are allocated to virtual module pairs with a communication priority higher than the preset priority requirement; wherein, the communication priority principle is used to allocate containers of the same computing device to the virtual module pairs with a communication priority higher than the preset priority requirement; When all containers in the target computing device have been allocated, if there are virtual module pairs that have not been allocated containers, then an idle computing device is selected as the target computing device, and the process returns to the step of allocating the containers of the target computing device to virtual module pairs with communication priorities higher than the preset priority requirement according to the communication priority principle, until each virtual module pair has been allocated a corresponding container.

5. The method according to claim 4, characterized in that, The communication priorities of several virtual module pairs are determined based on the communication load, communication quality requirements, and communication timeliness requirements between each virtual module pair, including: Obtain the communication latency requirement threshold for each virtual module; Based on the formula for calculating communication timeliness requirements, and combined with the communication delay requirement threshold of each virtual module, the communication timeliness requirements of each virtual module are calculated. Based on the communication timeliness requirements and importance of each virtual module, the individual priority of each virtual module in the first network is determined; The communication priority of each virtual module pair is calculated by combining the communication load between each virtual module pair, the communication quality requirements, and the individual priority corresponding to each virtual module pair.

6. The method according to claim 2, characterized in that, The method of allocating a corresponding container to each virtual module in the simulation unit based on the timeliness priority algorithm includes: Obtain the communication delay requirement threshold for each virtual module in the simulation unit; Based on the formula for calculating communication timeliness requirements, and combined with the communication delay requirement threshold of the virtual module in each simulation unit, the communication timeliness requirement of each simulation unit is calculated. Based on the principle of communication timeliness, the container of the target computing device is allocated to the second target simulation unit whose communication timeliness requirement is higher than the preset timeliness requirement; wherein, the principle of communication timeliness is used to allocate the container of the same computing device to the second target simulation unit whose communication timeliness requirement is higher than the preset timeliness requirement; If not all virtual modules in the second target simulation unit are allocated to the same computing device, then based on the communication latency requirement threshold and data throughput of a single virtual module in the second target simulation unit, containers of the same computing device are allocated to target virtual modules in the second target simulation unit whose communication timeliness requirements are higher than the preset timeliness requirements. When all virtual modules in the second target simulation unit have been assigned corresponding containers, return to the step of assigning containers of the target computing device to the second target simulation unit with communication timeliness requirements higher than the preset timeliness requirements according to the communication timeliness principle, until each simulation unit is assigned a corresponding container.

7. A humanoid robot collaborative simulation control device for industrial scenarios, characterized in that, The device includes the following modules: A functional module determination module is used to determine the functional modules of the humanoid robot; wherein, the functional modules include a motion control module, an environmental perception module, a task execution module, and a human-computer interaction module; A simulation unit construction module is used to construct simulation units corresponding to the functional modules; wherein each simulation unit contains at least one virtual module; A container allocation module is used to allocate containers to each virtual module in the simulation unit according to a container allocation algorithm, and to allocate corresponding container resources to each container; wherein, each virtual module is allocated one container, and the container is used to simulate the corresponding functional unit in the functional module; The simulation performance data acquisition module is used to acquire simulation performance data corresponding to each simulation unit; wherein, when the simulation unit performs functional simulation, data transmission is carried out based on a differentiated transmission channel, the differentiated transmission channel includes a first network and a second network, the first network is used to realize low-latency communication between virtual modules within the same simulation unit, and the second network is used to realize collaborative communication between virtual modules across simulation units; The collaborative control optimization module is used to perform feedback optimization operations on the functional simulation of each simulation unit based on the simulation performance data, so as to achieve collaborative control optimization of the humanoid robot.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images