A method and system for cooperative communication and safety control of a robot heterogeneous controller

Abstract

This invention discloses a collaborative communication and safety control method and system for a heterogeneous robot controller. The method includes the following steps: deploying a communication middleware based on Micro XRCE-DDS on an MCU module, configuring Quality of Service (QoS) policies for heartbeat, power status, and emergency stop messages respectively; during system power-on, establishing a dual-channel closed-loop start-up control mechanism combining hardware start-up gating and software readiness confirmation; during system operation, the MCU module collects the bus voltage, motor phase current, and motor speed parameters of the joint modules in real time, and when an emergency stop trigger signal is received, selects different deceleration strategies to execute braking control based on the parameters; and achieves physical-level safety isolation in the event of a main control module failure. This invention solves the technical problems of high communication latency, unreliable state synchronization, chaotic start-up timing, and delayed fault response in traditional communication methods.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of robotics technology, specifically to a collaborative communication and safety control method and system for heterogeneous robot controllers, electronic devices, and storage media. Background Technology

[0002] With the rapid development of service robots, industrial mobile platforms, and special-purpose equipment, higher requirements are being placed on control systems in terms of real-time performance, reliability, and functional safety. Currently, mainstream robot controllers generally adopt a heterogeneous dual-chip architecture of a high-performance application processor and a low-power coprocessor. The application processor (such as Allwinner T527, Rockchip RK3568, or NVIDIA Jetson series) runs the Linux system and handles high-computing tasks such as human-machine interaction, visual perception, and path planning. The coprocessor (usually an ARM Cortex-M series MCU) is used for critical real-time and safety functions such as power management, sensor acquisition, and emergency shutdown. In this architecture, the communication mechanism between the application processor and the coprocessor directly determines the overall responsiveness and robustness of the system.

[0003] However, in traditional technologies, the application processor and coprocessor often use a traditional serial communication protocol based on the UART interface. Typical solutions include: a custom binary frame protocol, where the main controller periodically polls the MCU to obtain information such as power supply voltage, temperature, and emergency stop status. This type of solution is simple to implement, but it has the following obvious drawbacks: 1) The communication is a master-slave polling mode, which requires continuous sending of requests even if the state has not changed, resulting in wasted bandwidth; the event response latency is limited by the polling period of 10-100ms, which cannot meet the robot safety control requirements for "millisecond-level" response; there is no built-in retransmission or acknowledgment mechanism, which makes it easy to lose packets in electromagnetic interference environments and difficult to detect.

[0004] 2) While the Modbus RTU protocol has the advantage of standardization, it still inherits the polling nature and has significant protocol overhead (including address, function code, CRC, and other fields), further exacerbating latency at low baud rates (such as 115200bps). More importantly, Modbus is a unidirectional master control model; the MCU cannot proactively report abnormal events (such as battery overvoltage or watchdog timeout) and must wait for the next polling, thus losing the initiative to prevent failures. Figure 1 and Figure 2 As shown, Figure 1 This is a schematic diagram of traditional Modbus RTU client-server communication. Figure 2This diagram illustrates the Modbus RTU protocol's MODBUS transaction processing on the server side. Initially, the system is in a "waiting for MB indication" state. Upon receiving a Modbus request, it sequentially performs a triple validation check on the acknowledgment opcode, acknowledgment data address, and acknowledgment data value. If any check fails, it immediately jumps to the corresponding exception handling branch, ultimately sending a Modbus exception response and returning to the initial waiting state. If all checks pass, it enters the MB operation phase. After the operation, it checks the validity of the result—if invalid, it triggers "exception code 456" and sends an exception response; if valid, it sends a Modbus response and then returns to the "waiting for MB indication" state, completing a full request-response or error handling loop. Modbus uses a unidirectional master control model and cannot proactively report exception events; it must wait for the next polling, thus losing the initiative in case of failure. Furthermore, the Modbus protocol itself does not provide automatic retransmission requests or forward error correction. If a frame error occurs due to signal quality issues (such as CRC errors or incorrect frame formats), the master station can only determine failure through a timeout mechanism and re-initiate the request. This not only reduces the effective communication rate but also leads to repeated failures when noise persists, affecting system real-time performance. Furthermore, during system startup, the application processor (such as the T527) needs to load a complete Linux system, taking several seconds to boot. The MCU module must complete PMIC configuration, battery detection, and peripheral power enable before power-on. Without a coordination mechanism, the following issues can easily arise: the application processor forcibly starts before the power supply is stable, causing SoC reset or damage; the MCU waits indefinitely without receiving the master control ready signal, causing the system to "freeze"; more seriously, when the application processor loses responsiveness due to software crashes or hardware failures, existing solutions often lack effective fault detection and physical isolation methods. Most designs rely solely on software heartbeats; if the operating system freezes, the heartbeat stops but power supply continues, potentially leading to motor malfunctions, actuator misoperations, and other safety hazards. Although some solutions introduce hardware watchdogs, their triggering typically only resets the master control, failing to save the fault scene or notify the remote monitoring end, and lacks linkage with the communication layer, making the recovery process uncontrollable.

[0005] 3) Existing robot controllers generally use high-performance application processors (such as T527 chips) paired with low-power MCUs to achieve power management. However, the two often use point-to-point serial communication without QoS guarantees, which cannot achieve millisecond-level status awareness and safety linkage in critical scenarios such as emergency stop, power failure or system crash. At the same time, the lack of a dual-channel collaborative startup mechanism can easily cause power supply timing conflicts, and a single communication channel is also difficult to support fault diagnosis and automatic recovery.

[0006] 4) Although ROS 2 and its embedded-oriented micro-ROS framework have been gradually applied to robot development in recent years, supporting distributed node communication through DDS (Data Distribution Service), current practices are mostly focused on communication between multiple Linux nodes, or micro-ROS is only used for sensor data uploading, and cannot simultaneously solve system-level problems such as highly reliable state synchronization, controlled startup, rapid fault response and safety isolation. Summary of the Invention

[0007] To overcome the shortcomings of existing technologies, the present invention aims to provide a collaborative communication and safety control method, system, and electronic device for heterogeneous robot controllers. It solves the technical problems of high communication latency, unreliable state synchronization, chaotic startup timing, and delayed fault response in traditional communication. Without significantly increasing hardware costs, it utilizes heterogeneous collaborative communication and software-hardware co-design to break through the performance bottleneck of traditional polling mechanisms and overcome the limitations of simple SOC / MCU module control, achieving high real-time, high reliability, and high safety control.

[0008] To address the aforementioned problems, the first aspect of this invention discloses a method for collaborative communication and safety control of heterogeneous robot controllers, comprising the following steps: Deploy a communication middleware based on Micro XRCE-DDS on the MCU module, establish a publish-subscribe communication mechanism with QoS policy control capability between the main control module and the MCU module, and configure QoS policies for heartbeat topic messages, power status topic messages and emergency stop topic messages respectively. During the system power-on phase, after the MCU module completes the initialization of the power management unit and confirms that the power supply is stable, it outputs a start enable signal to the main control module through the hardware signal line, and at the same time listens for the ready topic message issued by the main control module, so as to form a dual-channel closed-loop start control mechanism that combines hardware start gating and software ready confirmation. If the ready topic message is not received within a preset time, the power management unit is controlled to cut off the power supply to the main control module and then power it on again after a delay to perform a controlled restart. During system operation, the MCU module collects the bus voltage, motor phase current and motor speed parameters of the joint module in real time. When an emergency stop trigger signal is received, different deceleration strategies are selected according to the parameters to perform braking control. If the heartbeat topic messages are continuously lost or the watchdog signal timeout is detected during system operation, the power supply to the main control module will be cut off within a preset time to achieve physical-level security isolation in the case of main control module failure.

[0009] Optionally, configuring Quality of Service (QoS) policies for heartbeat topic messages, power status topic messages, and emergency stop topic messages respectively includes: A reliable transmission mode is enabled for the emergency stop topic message, and an acknowledgment and automatic retransmission mechanism is configured. Deadline monitoring and activity monitoring parameters are configured for the heartbeat topic message as the basis for determining the failure of the main control module. Corresponding timeliness parameters are configured for the power status topic message to achieve differentiated transmission control under different safety levels.

[0010] Optionally, the startup enable signal is a GPIO high-level signal output by the security coprocessor module after the power management chip initialization is completed, and the ready topic message is a startup completion indication message issued by the main control module after the operating system and the communication middleware are loaded.

[0011] Optionally, if the ready topic message is not received within a preset time, the power management unit is controlled to cut off the power supply to the main control module and then power it back on after a delay to perform a controlled restart, including: If the ready topic message is not received within a preset time, the power supply to the main control module is cut off, and a preset time is delayed to complete the capacitor discharge, and the power output is re-enabled, with the number of retries not exceeding 2.

[0012] Optionally, when an emergency stop trigger signal is received, the step of selecting different deceleration strategies to perform braking control according to the parameters includes: executing a high-energy discharge braking mode when any parameter of the joint module's bus voltage, motor phase current, or motor speed exceeds a preset threshold; and executing a smooth deceleration stop mode when none of the parameters of the joint module's bus voltage, motor phase current, or motor speed exceeds the preset threshold.

[0013] Optionally, when an emergency stop trigger signal is received, selecting different deceleration strategies to perform braking control according to the parameters includes: Upon receiving an emergency stop trigger signal, the MCU module estimates the mechanical kinetic energy based on the current motor speed parameters of the joint module, and calculates the absorbable energy capacity based on the bus voltage of the joint module and the rated absorption capacity of the energy discharge module. When the expected reinjection energy corresponding to the mechanical kinetic energy is greater than the absorbable energy capacity, a high-energy discharge braking mode is executed; otherwise, a smooth deceleration mode is executed.

[0014] Optionally, the execution of the high-energy discharge braking mode includes: putting the energy discharge module into a conducting state, generating a deceleration control curve with a preset deceleration upper limit as a constraint, and controlling the motor speed to decrease according to the deceleration control curve; while controlling the motor speed to decrease, turning off the pulse width modulation output channel of the driver.

[0015] A second aspect of this invention discloses a collaborative communication and safety control system for heterogeneous robot controllers, comprising: The system comprises a main control module, an MCU module, and a power management unit. The MCU module is equipped with a communication middleware based on Micro XRCE-DDS. This middleware establishes a publish-subscribe communication mechanism with QoS policy control capabilities between the main control module and the MCU module, and configures QoS policies for heartbeat, power status, and emergency stop messages. The MCU module, after initializing the power management unit and confirming power stability during system power-up, outputs a start-up enable signal to the main control module via a hardware signal line, while simultaneously listening for ready messages published by the main control module. This constitutes a dual-channel closed-loop start-up control mechanism combining hardware start-up gating and software ready confirmation. It is also used to control the power management unit to cut off the power supply to the main control module and delay power-on to perform controlled restart when the ready topic message is not received within a preset time; the MCU module is also used to collect the bus voltage, motor phase current and motor speed parameters of the joint module in real time during system operation, and select different deceleration strategies to perform braking control according to whether the parameters exceed a preset threshold when an emergency stop trigger signal is received; the MCU module is also used to cut off the power supply to the main control module within a preset time when the heartbeat topic message is continuously lost or the watchdog signal timeout is detected during system operation, so as to achieve physical-level safety isolation in the failure state of the main control module.

[0016] A third aspect of the present invention discloses an electronic device, comprising: a memory storing executable program code; a processor coupled to the memory; the processor calling the executable program code stored in the memory to execute the collaborative communication and safety control method for a heterogeneous robot controller disclosed in the first aspect of the present invention.

[0017] A fourth aspect of the present invention discloses a computer-readable storage medium storing a computer program, wherein the computer program causes a computer to execute the collaborative communication and safety control method for a heterogeneous robot controller disclosed in the first aspect of the present invention.

[0018] Compared with the prior art, the beneficial effects of the embodiments of the present invention are as follows: 1) This invention can achieve millisecond-level high-reliability state synchronization. By introducing a DDS-based publish-subscribe model and QoS strategy, this invention breaks the limitations of traditional Modbus polling, enabling the coprocessor (MCU module) to actively and immediately report when critical events such as emergency stop and power failure occur, with response latency controlled at the millisecond level.

[0019] 2) This invention solves the problems of unidirectional master-slave communication and event lag. It addresses the issue that the traditional Modbus protocol is a unidirectional master control model, where the MCU module cannot actively notify of anomalies. This invention supports bidirectional, event-driven communication, ensuring "zero-wait" reporting of safety events and avoiding missing the golden window for fault handling due to polling intervals. It adopts a publish-subscribe communication model based on Micro XRCE-DDS to replace the traditional polling mechanism, enabling the safety coprocessor to actively push data instantly upon state changes. The end-to-end delay from triggering critical events such as emergency stop signals and power abnormalities to receiving and processing by the master control module is ≤50ms, which is significantly better than conventional serial polling schemes (usually ≥100ms), meeting the stringent requirements of high real-time performance for robot safety control.

[0020] 3) This invention establishes a controlled and fault-tolerant dual-chip dual-channel collaborative startup mechanism. Through the DDS collaborative handshake protocol, it ensures that the main control module only starts after the power supply is stable and the MCU module is ready, preventing power supply timing conflicts, SoC module reset or startup failure, and improving the system power-on reliability.

[0021] 4.) This invention establishes a hierarchical response security event handling mechanism. For the highest priority event (such as an external emergency stop), the security coprocessor immediately issues an / emergency / stop power emergency stop message with high priority QoS. The main control module sets an emergency stop flag within 10ms and cuts off the actuator enable, achieving physical-level safe shutdown. For the next highest priority event (such as power overvoltage, undervoltage, or overcurrent), an / power / warning power alarm message is issued. The main control module logs and alerts the user, but does not interrupt the current task, balancing security and continuity.

[0022] 4) This invention achieves fault detection and physical-level safety shutdown within <100ms. Combined with DDS liveness monitoring, even if the main control module completely crashes, the MCU module can still detect the fault and trigger physical-level power-off protection (such as cutting off the motor power supply) within 100 milliseconds to prevent the actuator from going out of control and meet the basic requirements of functional safety.

[0023] 5) This invention supports fault scene preservation and automatic recovery. MCU Mika can record fault codes and save status during the main control failure, and realize traceable diagnosis and controlled recovery by synchronizing logs through DDS after the main control module recovers, avoiding "black box" downtime.

[0024] 6) This invention is compatible with existing hardware, allows for low-cost upgrades, and does not require replacement of physical interfaces such as UART / SPI. It only requires software architecture upgrades and deployment of micro-ROS + QoS configuration to achieve highly reliable communication on resource-constrained MCU modules, balancing performance improvement and deployment cost. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of traditional Modbus RTU client-server communication in the background technology; Figure 2 This is a schematic diagram illustrating the processing of MODBUS transactions on the server side using the Modbus RTU protocol in the background technology. Figure 3 This is a flowchart illustrating a collaborative communication and safety control method for a heterogeneous robot controller according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the architecture of a collaborative communication and safety control system for a heterogeneous robot controller according to an embodiment of the present invention. Figure 5 This is a schematic diagram of the software layer of a collaborative communication and safety control system for a heterogeneous robot controller according to the present invention. Figure 6 This is a flowchart illustrating a dual-channel closed-loop start-up control mechanism disclosed in an embodiment of the present invention; Figure 7 This is a schematic diagram of the process of activating a safety signal in a collaborative communication and safety control method for a heterogeneous robot controller disclosed in an embodiment of the present invention; Figure 8 This is a schematic diagram of the communication data flow between the main control module, the MCU module, and the joint module in a collaborative communication and safety control method for a heterogeneous robot controller disclosed in an embodiment of the present invention. Figure 9 This is a schematic diagram of the communication architecture of a collaborative communication and safety control system for a heterogeneous robot controller disclosed in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention. Detailed Implementation

[0026] This specific embodiment is merely an explanation of the embodiments of the present invention and is not intended to limit the embodiments of the present invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but as long as they are within the scope of the claims of the embodiments of the present invention, they are protected by patent law.

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

[0028] The term "comprising" and any variations thereof in the specification and claims of this application are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0029] In embodiments of the present invention, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in embodiments of the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0030] The application scenarios of this invention are as follows: This invention can be applied to industrial mobile robots (AGV / AMR, warehouse logistics vehicles): factories experience strong electromagnetic interference, and traditional serial communication is prone to packet loss. This invention can also be applied to service robots (such as hotel delivery, hospital guidance, and home care), which require long-term unattended operation and high automatic recovery capabilities; human-machine coexistence environments require emergency stop response times ≤100ms, ensuring reliable transmission of critical messages through DDS + QoS, and physically cutting off power when the main control unit malfunctions to prevent collisions or production line shutdowns; special operation robots (power inspection, explosion-proof, firefighting). This invention can also be applied to harsh operating environments where the system must have fault log storage and safety isolation capabilities; even if the SoC module completely fails, the MCU module can still independently record fault information and enter a safe standby state. This invention can also be applied to domestically produced intelligent control terminals, based on a full-stack domestic platform, achieving a collaborative control architecture that conforms to functional safety principles without relying on foreign safety chips or dedicated buses.

[0031] Example 1 This invention discloses a collaborative communication and safety control system for heterogeneous robot controllers, comprising: The system comprises a main control module, an MCU module, and a power management unit. The MCU module is equipped with a communication middleware based on Micro XRCE-DDS. This middleware establishes a publish-subscribe communication mechanism with QoS policy control capabilities between the main control module and the MCU module, and configures QoS policies for heartbeat, power status, and emergency stop messages. The MCU module, after initializing the power management unit and confirming power stability during system power-up, outputs a start-up enable signal to the main control module via a hardware signal line, while simultaneously listening for ready messages published by the main control module. This constitutes a dual-channel closed-loop start-up control mechanism combining hardware start-up gating and software ready confirmation. It is also used to control the power management unit to cut off the power supply to the main control module and delay power-on to perform controlled restart when the ready topic message is not received within a preset time; the MCU module is also used to collect the bus voltage, motor phase current and motor speed parameters of the joint module in real time during system operation, and select different deceleration strategies to perform braking control according to whether the parameters exceed a preset threshold when an emergency stop trigger signal is received; the MCU module is also used to cut off the power supply to the main control module within a preset time when the heartbeat topic message is continuously lost or the watchdog signal timeout is detected during system operation, so as to achieve physical-level safety isolation in the failure state of the main control module.

[0032] Specifically, such as Figure 4 As shown, the collaborative communication and safety control system architecture of a robot heterogeneous controller of the present invention is as follows: a dual-chip collaborative control architecture consisting of a main control module (such as a T527 chip), a safety co-processing module (such as a smart chip MCU module), a serial communication link and a power control unit, wherein the safety co-processing module is independently responsible for power management, safety monitoring and physical shutdown, and the main control module is responsible for task scheduling and human-machine interaction.

[0033] like Figure 5 As shown, Figure 5 This is a software-level schematic diagram of a collaborative communication and safety control system for a heterogeneous robot controller according to the present invention. Specifically, at the communication mechanism level: a publish-subscribe communication model based on MicroXRCE-DDS is deployed between the main control module and the safety coprocessing module. By configuring RELIABLE for reliable transmission, and QoS strategies such as DEADLINE monitoring and LIVELINESS activity monitoring parameters, highly reliable and low-latency proactive push of critical states (heartbeat, power, emergency stop) is achieved.

[0034] The startup control layer is as follows: a dual-channel collaborative mechanism of GPIO hardware signals and DDS software messages is adopted to achieve controlled power-on, readiness confirmation and automatic retry of startup failure (power off → delay → restart) to ensure power supply sequence safety.

[0035] The safety response is as follows: When the safety co-processing module detects an external emergency stop or internal power abnormality, it responds according to priority: an emergency stop event issues a DDS message with the highest priority, triggering the main controller to stop immediately; a power alarm event issues a non-interrupted warning, supporting degraded operation.

[0036] The fault recovery mechanism is as follows: The main control status is monitored by a combination of DDS heartbeat and hardware watchdog. If any abnormality occurs, the main control power supply will be cut off within 100ms, the fault log will be saved, and the system will enter a safe standby mode, supporting remote or local wake-up recovery.

[0037] As a specific embodiment, the system includes a main control module, a security coprocessing module, a serial communication link, and a power control unit. By deploying a lightweight ROS 2 client on the security coprocessing module and building a publish-subscribe communication model based on DDS (Data Distribution Service) with the main control module, combined with hardware-level security mechanisms, highly reliable state synchronization, controlled startup process, and rapid fault recovery are achieved.

[0038] In specific implementation, the main control module can use a high-performance application processor (such as Allwinner T527) (e.g., SOC module), run the Linux operating system and ROS 2 node, and be responsible for human-computer interaction interface, environment awareness, path planning and task scheduling; The security coprocessor module uses a low-power microcontroller (such as a domestically produced Zhixin MCU) (such as an MCU module), runs a real-time operating system (RTOS) and a micro-ROS client, and is dedicated to performing power management, battery monitoring, emergency shutdown and safety status reporting. The power control unit (PMIC) is driven by the safety coprocessor module and includes a MOSFET switching circuit for cutting off or restoring power to the main control module as needed.

[0039] The serial communication link connects the main control module and the security coprocessing module. The physical layer can be a UART interface, an SPI interface (with an independent interrupt line), or a USB CDC interface. Specifically, the communication between the SoC module and the MCU module is as follows: they are connected via an SPI interface (speed ≥ 10 MHz), and an additional interrupt GPIO general-purpose input / output pin is set up as an external interrupt source for event wake-up; The MCU module and the joint module are connected via a CAN FD bus (speed 2–5Mbps), supporting multi-node cascading; all communication protocol stacks are open source or independently controllable, without relying on dedicated chips.

[0040] This invention deploys a micro-ROS client on a resource-constrained smart chip MCU and constructs a publish-subscribe communication model based on the DDS protocol with the T527 main control module. Combined with security isolation and DDS collaboration mechanism, it can achieve: highly reliable state synchronization at the sub-millisecond level; a controlled and fault-tolerant dual-chip startup process; fault detection and physical-level safe shutdown at <100ms; and significantly improve communication efficiency and system security without changing the underlying physical interface (such as UART). It has high robustness, high real-time performance, and meets functional safety requirements.

[0041] Example 2 A method for collaborative communication and safety control of heterogeneous robot controllers, such as Figure 3 As shown, it includes the following steps: Step S110: Deploy a communication middleware based on Micro XRCE-DDS on the MCU module, establish a publish-subscribe communication mechanism with QoS policy control capability between the main control module and the MCU module, and configure QoS policies for heartbeat topic messages, power status topic messages and emergency stop topic messages respectively. Among them, Micro XRCE-DDS (Micro eXtremely Resource Constrained Environments – Data Distribution Service) is a lightweight communication middleware protocol and implementation framework for resource-constrained embedded devices.

[0042] Specifically, a reliable transmission mode is enabled for the emergency stop topic message and an acknowledgment and automatic retransmission mechanism is configured. Deadline monitoring and activity monitoring parameters are configured for the heartbeat topic message as the basis for determining the failure of the main control module. Corresponding timeliness parameters are configured for the power status topic message to achieve differentiated transmission control under different safety levels.

[0043] The power status topic message includes at least one of the following: normal status message, power alarm message, and fault status message.

[0044] Specifically, on the physical medium serial communication link, the MCU module acts as a secure coprocessor module, deploying communication middleware based on Micro XRCE-DDS to build a publish-subscribe model. The secure coprocessor module acts as a DDS publisher, periodically or event-triggeredly publishing the following key topics: / system / heartbeat: Live heartbeat signal of the main control module (SOC module) (cycle 20ms); / power / status: Power supply voltage, current, and battery status; / emergency / stop: Emergency stop button triggered or safety threshold exceeded event; / power / warning: Power alarm message; The main control module acts as a DDS subscriber, receiving the above messages in real time and adjusting system behavior (such as frequency reduction, hibernation, shutdown, or alarm) based on the content. The DDS communication is configured with the following QoS policies: RELIABLE: Enables ACK and automatic retransmission to ensure that critical messages are not lost; DEADLINE(50ms): If the message is not delivered within 50ms, a timeout will be triggered. LIVELINESS(AUTOMATIC, 100ms): Monitors the publisher's activity status and automatically notifies subscribers when abnormalities occur.

[0045] The configuration of Quality of Service (QoS) policies for heartbeat topic messages, power status topic messages, and emergency stop topic messages includes: Specifically, a reliable transmission mode is enabled for the emergency stop topic message, and an acknowledgment and automatic retransmission mechanism is configured. Deadline monitoring and activity monitoring parameters are configured for the heartbeat topic message as the basis for determining the failure of the main control module. Corresponding timeliness parameters are configured for the power status topic message to achieve differentiated transmission control under different safety levels.

[0046] As an optional embodiment, the QoS policy includes a deadline monitoring parameter. When a deadline default event is detected in the heartbeat topic message, the MCU module directly triggers the main control module to cut off power supply without going through the application layer status judgment.

[0047] The deadline monitoring parameter is used to limit the maximum allowed interval for receiving the heartbeat topic message. The deadline default event is generated by the communication middleware as a default notification signal, which is directly used as the power-off trigger condition for the power management unit.

[0048] In specific implementation, when the communication middleware detects that the heartbeat topic message has not arrived within the maximum allowed reception interval and a deadline default event is generated, a default notification signal is generated.

[0049] Step S120: During the system power-on phase, after the MCU module completes the initialization of the power management unit and confirms that the power supply is stable, it outputs a start enable signal to the main control module through the hardware signal line, and at the same time listens to the ready topic message issued by the main control module, so as to form a dual-channel closed-loop start control mechanism that combines hardware start gating and software ready confirmation. Specifically, the startup enable signal is a GPIO high-level signal output by the security coprocessor module after the power management chip initialization is completed, and the ready topic message is a startup completion indication message issued by the main control module after the operating system and the communication middleware are loaded.

[0050] like Figure 6 As shown, Figure 6 This is a flowchart illustrating a dual-channel closed-loop startup control mechanism disclosed in an embodiment of the present invention; specifically, after the system is powered on, the following startup process is executed: 1) The security coprocessing module, i.e. the MCU module initialization phase, first completes its own initialization and configures the PMIC power management unit output power enable pin to be low to ensure that the SOC module (such as the T527 chip) is in a power-off state.

[0051] 2) Power Ready: The MCU module and PMIC power management unit communicate via I2C to perform self-checks on battery voltage, temperature, and the status of the PMIC power management unit. If there are no abnormalities, the MCU module first sends a custom "Power Ready" high-level signal to the SOC module through the GPIO interface, and then enables the power output pin through the PMIC power management unit to power on the SOC module.

[0052] 3) SOC module startup monitoring: The MCU module simultaneously starts a startup timeout timer (e.g., 3 seconds) and listens to whether the SOC module publishes the / system / ready message through DDS.

[0053] 4) Startup successful: If the / system / ready message is received on time, the SOC is considered to have started successfully and entered normal operating mode.

[0054] 5) Startup Failure and Automatic Restart: If no ready message is received within the timeout period, the MCU module determines that the SOC module has failed to start and performs the following operations: The power supply to the SOC module is cut off via the PMIC power management unit control pin (by pulling the enable signal low); a 500ms delay is performed (to ensure capacitor discharge); the PMIC power management unit enable signal is pulled high again to power on the SOC module, triggering a new startup cycle. This process is repeated a maximum of two times. If it still fails, the system enters a safe standby state and reports a fault.

[0055] Since the SOC module requires a complete operating system and middleware to establish DDS communication, it cannot receive any software messages before that. To ensure that the power supply is stable before allowing the SOC module to start, a dedicated hardware signal line, such as a GPIO signal line, is added. This line is pulled high by the security coprocessor after the PMIC power management unit is initialized, serving as the hardware enable condition for the main control module (SOC module) to start.

[0056] This GPIO signal, together with the subsequent DDS ready message, constitutes a two-stage confirmation mechanism, ensuring both boot safety and closed-loop verification of the boot result. This collaborative DDS boot control mechanism ensures strict control over power timing, preventing damage or reset of the SoC module due to premature power-on by the main controller.

[0057] Step S130: When the ready topic message is not received within a preset time, control the power management unit to cut off the power supply to the main control module and delay before powering it back on to perform a controlled restart; Specifically, if the ready topic message is not received within a preset time, the power supply to the main control module is cut off, and a preset time is delayed to complete capacitor discharge, and the power output is re-enabled, with the number of retries not exceeding 2.

[0058] Step S140: During system operation, the MCU module collects the bus voltage, motor phase current and motor speed parameters of the joint module in real time. When an emergency stop trigger signal is received, different deceleration strategies are selected according to the parameters to perform braking control. Among them, the joint module can be the joint module of a humanoid robot or collaborative robot that does not have a dedicated emergency stop signal line reserved.

[0059] In this embodiment, the MCU module communicates with the joint module through the MCU driver module CAN FD, such as... Figure 8 and Figure 9 As shown, Figure 8 This is a schematic diagram of the communication data flow between the main control module, the MCU module, and the joint module. Figure 9 The diagram shows the communication architecture of the system. CAN FD (Flexible Data Rate) supports up to 5 Mbps and a maximum of 64 bytes per frame. It is used to transmit target position / speed / torque, read encoder values, current, temperature, and fault codes. The MCU module acts as the CAN FD master station, periodically (e.g., 1 kHz) polling each joint module, or using a hybrid scheduling of event triggering and time triggering.

[0060] In the above implementation process, an event-driven, bidirectional asynchronous communication paradigm is adopted, abandoning the traditional master-slave polling mode, which significantly improves real-time performance and bandwidth utilization.

[0061] likeFigure 7 As shown, Figure 7 This is a schematic diagram of a process for activating a security signal according to an embodiment of the present invention. In specific implementation, during the normal operation of the SOC module, the MCU module monitors external security inputs in real time and responds according to the following priority levels.

[0062] (1) Emergency stop safety operation, highest priority This hierarchical emergency stop control based on real-time electrical and motion status is particularly suitable for humanoid or collaborative robot joint modules where dedicated emergency stop signal lines are not provided due to structural space constraints. The MCU module monitors parameters such as voltage, current, and rotational speed of the joint module at millisecond levels. Upon receiving an emergency stop command, it dynamically selects the optimal deceleration strategy, balancing personnel safety, equipment protection, and energy management. External pins of the MCU module connect to a hardware emergency stop button or safety relay. Once an emergency stop trigger signal (such as a GPIO level transition) is detected, the MCU module immediately publishes an emergency stop topic message ( / emergency / stop) with the highest QoS priority via DDS. Optionally, it also notifies the SOC module via a separate hardware line (such as an interrupt line). The ROS 2 node of the SOC module subscribes to this topic message and interrupts all motion control commands within 10ms.

[0063] This invention utilizes a direct connection between an MCU module and a joint module (CAN FD) + real-time status sensing + DDS emergency stop commands to construct a closed-loop hierarchical emergency stop mechanism, as detailed below: Emergency stop triggers can be external emergency stop buttons, SoC safety decision modules, or MCU module self-test anomalies. All triggers are unified by publishing an emergency stop topic message (QoS: RELIABLE + BEST_EFFORT) via DDS, which is subscribed to by the MCU module. Within 1ms of receiving an emergency stop command, the MCU module reads the latest status from each joint module (via CAN FD LAN), such as bus voltage Vbus, phase current phase, and motor speed.

[0064] Specifically, when an emergency stop trigger signal is received, selecting different deceleration strategies based on the parameters to execute braking control includes: When any parameter of the joint module's bus voltage, motor phase current, or motor speed exceeds a preset threshold, a high-energy discharge braking mode is executed; when none of the parameters of the joint module's bus voltage, motor phase current, or motor speed exceeds the preset threshold, a smooth deceleration and stop mode is executed.

[0065] In this implementation, a graded deceleration strategy is adopted for determination, and the MCU module dynamically selects the braking mode based on a preset threshold: For example, if preset braking conditions are met, such as: joint module motor voltage > maximum voltage (e.g., 50V), joint module line current > maximum current threshold (e.g., 15A), or joint module motor speed V > maximum speed threshold (e.g., 2000 rpm), the high-energy discharge mode will be immediately activated. This could involve immediately activating the energy discharge module (Brake Chopper), using a high-slope T-shaped deceleration curve (deceleration ≥ 5000 rad / s²), and simultaneously cutting off the PWM output to enter free-gliding + discharge mode.

[0066] If the preset braking conditions are not met, such as under low / medium load or other conditions, a smooth acceleration and stop mode is executed, for example, using a low-slope T-shaped deceleration curve (deceleration ≤ 1000 rad / s²); the current loop closed-loop control is maintained until the stop; and the energy discharge module is turned off to avoid unnecessary power loss.

[0067] The high-energy discharge braking mode includes: putting the energy discharge module into a conducting state, generating a deceleration control curve with a preset deceleration upper limit as a constraint, and controlling the motor speed to decrease according to the deceleration control curve; while controlling the motor speed to decrease, turning off the pulse width modulation output channel of the driver.

[0068] Specifically, the formula for the graded deceleration trajectory is as follows: Let the current time be t=0, the current angular velocity of the joint module be ω0 (unit: rad / s), and the target angular velocity be ω. target =0, and the magnitude of the deceleration is a (take a positive value), then: Deceleration time satisfies Where a is the magnitude of the deceleration; ω0 is the current angular velocity of the joint module; t stop This is the deceleration time.

[0069] The function of angular velocity changing with time satisfies Where ω(t) is the angular velocity function, t is time, and t0 is the time interval. stop 'a' represents the deceleration time, and 'a' represents the magnitude of the deceleration. Angular displacement (braking distance) satisfies ; where θ brake Let ω(t) be the angular displacement, ω(t) be the angular velocity function, and t be the time. stop ω is the deceleration time, a is the magnitude of the deceleration; ω0 is the current angular velocity of the joint module; Control commands are output (to the current loop / position loop). The MCU module calculates the target position or target velocity based on ω(t) and sends it to the joint driver: if the driver supports velocity mode, the desired velocity ω(t) is set directly; if it is position mode, the target position is obtained by integrating ω(t). Where ω0 is the current angular velocity of the joint module.

[0070] Specifically, the data for graded deceleration is shown in Table 1 below: Table 1: Data Table of Staged Deceleration ; Execution and Feedback: The MCU module sends corresponding braking commands to the joint modules via the CAN FD local area network; each joint module performs local braking and returns a status; the MCU module summarizes the results and publishes them via DDS (Device Controllers) as / emergency / status, allowing the SoC module to log them or notify the user. Emergency stop messages use a RELIABLE + BEST_EFFORT (high-priority channel) QoS combination to ensure priority delivery even under network congestion.

[0071] In the above implementation process, the present invention upgrades the safety control from "one-size-fits-all shutdown" to "state-adaptive braking", which solves the industry pain point technical problem that compact robot joints cannot deploy traditional safety loops due to physical limitations.

[0072] (2) Power supply abnormality alarm, second highest priority The MCU module continuously monitors the voltage and current output by the PMIC. If overvoltage (e.g., >5.5V), undervoltage (e.g., <3.0V), or overcurrent (>120% of the rated value) is detected, it immediately issues a power / warning alarm message via DDS, including the type and value of the abnormality. Upon receiving the message, the SOC module: logs the information; can choose to operate at a reduced frequency or prompt the user to shut down; and does not immediately stop the device to avoid accidental triggering and task interruption.

[0073] In another embodiment, when an emergency stop trigger signal is received, selecting different deceleration strategies based on the parameters to perform braking control includes: Upon receiving an emergency stop trigger signal, the MCU module estimates the mechanical kinetic energy based on the current motor speed parameters of the joint module, and calculates the absorbable energy capacity based on the bus voltage of the joint module and the rated absorption capacity of the energy discharge module. When the expected reinjection energy corresponding to the mechanical kinetic energy is greater than the absorbable energy capacity, a high-energy discharge braking mode is executed; otherwise, a smooth deceleration mode is executed.

[0074] Specifically, the MCU module estimates the mechanical kinetic energy based on the current motor speed parameters and preset equivalent moment of inertia parameters of the joint module; calculates the expected reinjection energy based on the mechanical kinetic energy and preset energy feedback efficiency coefficient; calculates the remaining energy storage capacity of the bus based on the voltage margin between the current voltage of the joint module bus and the maximum allowable safe voltage of the bus, and calculates the absorbable energy capacity in combination with the rated absorption capacity of the energy discharge module; when the expected reinjection energy is greater than the absorbable energy capacity, a high-energy discharge braking mode is executed; when the expected reinjection energy is not greater than the absorbable energy capacity, a smooth deceleration mode is executed.

[0075] In practice, upon receiving the emergency stop trigger signal, the MCU module reads the current motor speed ω of the joint module and estimates the mechanical kinetic energy based on the preset equivalent moment of inertia J. For example, the equivalent moment of inertia J = 0.015 kg·m². To account for motor feedback efficiency and drive losses, an energy feedback efficiency coefficient η is set. The expected reinjection energy is then: Er = η Em; where Em is mechanical kinetic energy and Er is the expected reinjection energy; For example, the energy feedback efficiency coefficient η = 0.85; Meanwhile, the MCU module calculates the remaining energy storage capacity of the bus based on the voltage margin ΔV between the current bus voltage Vbus and the maximum allowable safe bus voltage Vmax, combined with the bus capacitance C: Where Ec is the remaining energy storage capacity of the bus, Vmax is the maximum allowable safe voltage of the bus, and Vbus is the current voltage of the bus.

[0076] Then, combining the rated absorption power Pd of the energy discharge module and the allowable absorption time window T, the absorbable energy capacity Ea is determined, Ea = Ec + Pd. T; where Ea is the absorbable energy capacity, Ec is the remaining energy storage capacity of the bus, Pd is the rated absorption power of the energy discharge module, and T is the allowable absorption time window, for example, the allowable absorption time T = 0.2 s.

[0077] When the expected reinjection energy Er > the absorbable energy capacity Ea, it is determined that there is a risk of bus overvoltage, and the high-energy discharge braking mode is executed; otherwise, the smooth deceleration mode is executed.

[0078] Step S150: During system operation, if the heartbeat topic message is continuously lost or the watchdog signal timeout is detected, the power supply to the main control module is cut off within a preset time to achieve physical-level security isolation in the case of main control module failure.

[0079] Specifically, step S150 includes the following steps: The security coprocessing module continuously monitors the / system / heartbeat topic published by the main control module; at the same time, it monitors the watchdog feed signal output by the main control module through an independent hardware line. The main control module is deemed to have failed if any of the following occurs: three consecutive DDS heartbeat messages are not received; or the watchdog signal times out (>50ms without a transition). When the main control module is deemed to have failed, the safety co-processing module immediately performs the following: cuts off the power supply to the main control module through the power control unit; writes the fault type, timestamp, and power status to a non-volatile memory (such as EEPROM); enters a low-power standby mode and reports the / emergency / shutdown event to the remote terminal via micro-ROS; and, in response to the local reset button or remote wake-up command, re-executes the dual-channel collaborative startup process to restore system functionality.

[0080] In the above implementation process, the power supply to the main control module is cut off within a preset time to achieve physical-level safety isolation in the case of main control module failure. It can achieve fault response and physical-level safety isolation of less than 100ms, effectively prevent actuator malfunction, and meet the functional safety level requirements of ISO 13849 PLd.

[0081] The method of this invention does not depend on a specific physical interface or chip model and can operate transparently on universal serial links such as UART, SPI+IRQ, and USB. At the same time, adding a new sensor or security event only requires registering a new DDS Topic without modifying the main control polling logic, which significantly improves the maintainability and modularity of the system and has strong compatibility and scalability.

[0082] Example 3 Please see Figure 10 , Figure 10 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention. For example... Figure 10 As shown, the electronic device may include: Memory 310 storing executable program code; Processor 320 coupled to memory 310; The processor 320 calls the executable program code stored in the memory 310 to execute some or all of the steps in the collaborative communication and safety control method of a heterogeneous robot controller in Embodiment 1.

[0083] This invention discloses a computer-readable storage medium storing a computer program that causes a computer to execute some or all of the steps in the collaborative communication and safety control method for a heterogeneous robot controller in Embodiment 1.

[0084] This invention also discloses a computer program product, wherein when the computer program product is run on a computer, the computer executes some or all of the steps in the collaborative communication and safety control method for a heterogeneous robot controller in Embodiment 1.

[0085] This invention also discloses an application publishing platform, which is used to publish computer program products. When the computer program products are run on a computer, the computer executes some or all of the steps in the collaborative communication and safety control method for a heterogeneous robot controller in Embodiment 1.

[0086] In various embodiments of the present invention, it should be understood that the sequence number of each process does not necessarily imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0087] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they can be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0088] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0089] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-accessible memory. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several requests to cause a computer device (which can be a personal computer, server, or network device, specifically a processor in the computer device) to execute some or all of the steps of the methods described in the various embodiments of the present invention.

[0090] In the embodiments provided by this invention, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0091] Those skilled in the art will understand that some or all of the steps in the various methods of the embodiments described can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0092] The above provides a detailed description of a collaborative communication and safety control method, device, electronic device, and storage medium for a heterogeneous robot controller disclosed in the embodiments of the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for collaborative communication and safety control of heterogeneous robot controllers, characterized in that, It includes the following steps: Deploy a communication middleware based on Micro XRCE-DDS on the MCU module, establish a publish-subscribe communication mechanism with QoS policy control capability between the main control module and the MCU module, and configure QoS policies for heartbeat topic messages, power status topic messages and emergency stop topic messages respectively. During the system power-on phase, after the MCU module completes the initialization of the power management unit and confirms that the power supply is stable, it outputs a start enable signal to the main control module through the hardware signal line, and at the same time listens for the ready topic message issued by the main control module, so as to form a dual-channel closed-loop start control mechanism that combines hardware start gating and software ready confirmation. If the ready topic message is not received within a preset time, the power management unit is controlled to cut off the power supply to the main control module and then power it on again after a delay to perform a controlled restart. During system operation, the MCU module collects the bus voltage, motor phase current and motor speed parameters of the joint module in real time. When an emergency stop trigger signal is received, different deceleration strategies are selected according to the parameters to perform braking control. If the heartbeat topic messages are continuously lost or the watchdog signal timeout is detected during system operation, the power supply to the main control module will be cut off within a preset time to achieve physical-level security isolation in the case of main control module failure.

2. The collaborative communication and safety control method for heterogeneous robot controllers according to claim 1, characterized in that, The configuration of Quality of Service (QoS) policies for heartbeat topic messages, power status topic messages, and emergency stop topic messages includes: A reliable transmission mode is enabled for the emergency stop topic message, and an acknowledgment and automatic retransmission mechanism is configured. Deadline monitoring and activity monitoring parameters are configured for the heartbeat topic message as the basis for determining the failure of the main control module. Corresponding timeliness parameters are configured for the power status topic message to achieve differentiated transmission control under different safety levels.

3. The collaborative communication and safety control method for heterogeneous robot controllers according to claim 1, characterized in that, The startup enable signal is a GPIO high-level signal output by the security coprocessor module after the power management chip initialization is completed, and the ready topic message is a startup completion indication message issued by the main control module after the operating system and the communication middleware are loaded.

4. The collaborative communication and safety control method for heterogeneous robot controllers according to claim 1, characterized in that, If the ready topic message is not received within a preset time, the power management unit is controlled to cut off the power supply to the main control module and then power on again after a delay to perform a controlled restart, including: If the ready topic message is not received within a preset time, the power supply to the main control module is cut off, and a preset time is delayed to complete the capacitor discharge, and the power output is re-enabled, with the number of retries not exceeding 2.

5. The collaborative communication and safety control method for heterogeneous robot controllers according to claim 1, characterized in that, When an emergency stop trigger signal is received, different deceleration strategies are selected according to the parameters to perform braking control, including: when any parameter of the joint module's bus voltage, motor phase current, or motor speed exceeds a preset threshold, a high-energy discharge braking mode is executed; when no parameter of the joint module's bus voltage, motor phase current, or motor speed exceeds the preset threshold, a smooth deceleration stop mode is executed.

6. The collaborative communication and safety control method for heterogeneous robot controllers according to claim 1, characterized in that, When an emergency stop trigger signal is received, the step of selecting different deceleration strategies and executing braking control according to the parameters includes: Upon receiving an emergency stop trigger signal, the MCU module estimates the mechanical kinetic energy based on the current motor speed parameters of the joint module, and calculates the absorbable energy capacity based on the bus voltage of the joint module and the rated absorption capacity of the energy discharge module. When the expected reinjection energy corresponding to the mechanical kinetic energy is greater than the absorbable energy capacity, a high-energy discharge braking mode is executed; otherwise, a smooth deceleration mode is executed.

7. The method for collaborative communication and safety control of heterogeneous robot controllers according to claim 5, characterized in that, The execution of the high-energy discharge braking mode includes: putting the energy discharge module into the conduction state, generating a deceleration control curve with a preset deceleration upper limit as a constraint, and controlling the motor speed to decrease according to the deceleration control curve; while controlling the motor speed to decrease, turning off the pulse width modulation output channel of the driver.

8. A collaborative communication and safety control system for heterogeneous robot controllers, characterized in that, It includes: Main control module, MCU module and power management unit; The MCU module is equipped with a communication middleware based on Micro XRCE-DDS. This middleware establishes a publish-subscribe communication mechanism with QoS policy control capabilities between the main control module and the MCU module, and configures QoS policies for heartbeat topic messages, power status topic messages, and emergency stop topic messages. The MCU module is also used to initialize the power management unit and confirm power stability during system power-up, then output a start-up enable signal to the main control module via a hardware signal line, while simultaneously listening for ready topic messages published by the main control module, thus forming a dual-channel closed-loop start-up control mechanism combining hardware start-up gating and software ready confirmation. The MCU module is also used to... If the ready topic message is not received within a preset time, the power management unit is controlled to cut off the power supply to the main control module and then power it back on after a delay to perform a controlled restart. The MCU module is also used to collect the bus voltage, motor phase current and motor speed parameters of the joint module in real time during system operation, and when an emergency stop trigger signal is received, it selects different deceleration strategies to perform braking control according to whether the parameters exceed a preset threshold. The MCU module is also used to cut off the power supply to the main control module within a preset time when the heartbeat topic message is continuously lost or the watchdog signal timeout is detected during system operation, so as to achieve physical-level safety isolation in the failure state of the main control module.

9. An electronic device, characterized in that, It includes: a memory storing executable program code; a processor coupled to the memory; the processor calling the executable program code stored in the memory to execute the collaborative communication and safety control method of the robot heterogeneous controller according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, wherein the computer program causes a computer to execute the collaborative communication and safety control method of the heterogeneous robot controller according to any one of claims 1-7.

Images