Hot plug bus communication networking method and device applied to robot cluster

Abstract

This invention relates to the field of hot-swappable bus communication networking technology for robot swarms, and discloses a method and apparatus for hot-swappable bus communication networking for robot swarms. This invention initially assigns master and slave devices based on hardware configuration after device startup, and then further assigns master and slave devices based on bus status data; establishes handshake connections to generate a bus device table, filters normally connected devices based on heartbeat data, and finally transmits data according to the real-time priority of business data. This achieves hot-swappable bus communication for robot swarms, allowing device access / exit without interrupting overall communication, and automatically reconfiguring the network for remaining devices, adapting to dynamic expansion needs of the swarm; through secondary master / slave allocation and handshake verification, combined with heartbeat monitoring to ensure connection stability, and transmitting data according to real-time priority, the invention improves communication reliability and the real-time performance of critical data transmission.

Description

Technical Field

[0001] This invention relates to the field of hot-swappable bus communication networking technology for robot swarms, and more specifically to a method and apparatus for hot-swappable bus communication networking for robot swarms. Background Technology

[0002] In industrial production, intelligent logistics, and collaborative operations, robot swarms have become a core technological support due to their efficient collaborative capabilities. The stability and flexibility of their communication network directly determine operational efficiency. Currently, robot swarms mostly achieve device interconnection through bus communication. A typical architecture configures each robot with a controller and a bus interface device. After the interface device is serially connected to the controller, status interaction and business data transmission are completed through the device communication bus and the data communication bus. Among them, the device communication bus is responsible for device identity broadcasting and status verification, while the data communication bus transmits business data as needed. The number of buses can be dynamically adjusted according to the swarm size, which has a natural advantage in data real-time performance and reliability compared to wireless networking.

[0003] However, existing bus communication networking methods mainly rely on master-slave identity assignment for networking. However, the master-slave identity assignment mechanism of the above methods is rigid and lacks dynamic adjustment capabilities. The failure of a single device may cause the entire cluster network to be paralyzed, which seriously restricts the dynamic expansion capability and operational stability of the robot cluster. Therefore, there is an urgent need for a bus communication networking method that supports hot-swapping, can quickly realize network reconstruction, and takes into account both real-time performance and reliability. Summary of the Invention

[0004] This invention provides a hot-swappable bus communication networking method and apparatus for robot clusters, which solves the problems of rigid master-slave identity allocation mechanism, lack of dynamic adjustment capability, and the possibility that a single device failure may cause the entire cluster network to be paralyzed, which seriously restricts the dynamic expansion capability and operational stability of robot clusters.

[0005] In a first aspect, the present invention provides a hot-swappable bus communication networking method for robot swarms, wherein all robots in the robot swarm are interconnected via a swarm communication bus, each robot is equipped with an adapted bus interface device, the bus interface device establishes a connection with the swarm communication bus through hot-plugging or disconnects from the swarm communication bus through hot-plugging, and the remaining bus interface devices after hot-plugging can automatically reconstruct the bus communication network; the method includes:

[0006] Power on all the robots and all the bus interface devices, and assign master and slave identities to each bus interface device according to its hardware configuration. Analyze the bus status data of each bus interface device, and perform secondary master / slave identity assignment on each bus interface device based on the analysis results; Establish handshake connections for each bus interface device after secondary allocation and generate a bus device table; Based on the heartbeat data of each bus interface device, determine whether the connection status of each bus interface device in the bus device table is normal, and filter out the bus interface devices with normal connection based on the judgment result. Based on the real-time requirements of robot business data, data priorities are assigned, and robot business data corresponding to normally connected bus interface devices are transmitted through the cluster communication bus according to the data priorities.

[0007] This invention enables hot-swapping of robot cluster bus communication, allowing devices to be added or removed without interrupting overall communication. Remaining devices automatically reconfigure the network to adapt to dynamic cluster expansion needs. Through secondary allocation and handshake verification by master and slave devices, combined with heartbeat monitoring, connection stability is ensured. Data is transmitted according to real-time priority, improving communication reliability and the real-time transmission of critical data.

[0008] In one optional implementation, the step of powering on all the robots and all the bus interface devices, and assigning master / slave roles to each bus interface device according to its hardware configuration, includes: Power on all the robots and all the bus interface devices; Extract the hardware configuration of each of the bus interface devices; Based on the hardware configuration of each bus interface device, the master / slave identity and device parameters of each bus interface device are determined.

[0009] This invention automates the initial configuration of master / slave identities and parameters by activating the robot and bus interface devices, extracting hardware configurations, and assigning them accordingly. This eliminates the need for manual intervention and simplifies the network startup process. Furthermore, the hardware configuration-based allocation method ensures that master / slave identities and parameters match the device hardware capabilities, establishing a stable foundation for subsequent cluster communication and improving the efficiency and accuracy of network initialization.

[0010] In one optional implementation, the step of analyzing the bus status data of each of the bus interface devices and performing secondary master-slave identity allocation for each of the bus interface devices based on the analysis results includes: Collect bus status data from each of the aforementioned bus interface devices; Determine whether at least one host's status data is present among all the bus status data within the same robot cluster; If not, set each of the aforementioned bus interface devices to low-power sleep mode; If so, extract the universal unique identifier of each bus interface device, determine the priority of the universal unique identifier based on each universal unique identifier, and determine the bus interface device with the highest priority of the universal unique identifier as the master and the remaining bus interface devices as slaves.

[0011] This invention collects status data from bus interface devices and detects the cluster communication environment by determining whether host status data exists. When no host status data is available, the device enters low-power sleep mode to reduce energy consumption; when host status data is available, master and slave devices are dynamically allocated based on the priority of a universally unique identifier to ensure the rationality and uniqueness of master and slave device identity allocation and avoid network conflicts.

[0012] In one optional implementation, establishing handshake connections for each bus interface device after secondary allocation and generating a bus device table includes: The host in the robot cluster establishes a handshake connection with each of the slaves in turn, and determines whether the handshake connection between the host and the current slave is successful. If not, then set the current slave device to low-power sleep mode; If so, record the connection status of the slave device and establish a handshake connection between the master device and the next slave device; After the host completes the handshake connection with each of the slave devices, it collects the device status data of the host and each of the slave devices to generate a bus device table.

[0013] This invention establishes a handshake connection between the master and slave devices sequentially. Slave devices that fail to establish a handshake enter a low-power sleep state, reducing unnecessary resource consumption. After a successful handshake, the device connection status is recorded, and finally, all device status data is integrated to generate a bus device table, achieving accurate statistics and unified management of the cluster device connection status. This process ensures the effectiveness of cluster device connections.

[0014] In one optional implementation, the step of determining whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device, and filtering out the bus interface devices with normal connections based on the determination result, includes: Obtain heartbeat data from each bus interface device within the same robot cluster; Based on the heartbeat data of each bus interface device, determine whether the connection status of each bus interface device in the bus device table is normal. If normal, then confirm that the bus interface device is connected correctly; If it is abnormal, then determine whether there is at least one device that has established a connection in the bus device table; If it exists, then proceed to the step of establishing handshake connections between the host and each slave in the robot cluster in sequence, and determining whether the host and the current slave have successfully established a handshake connection. If not, set each of the bus interface devices to low-power sleep mode.

[0015] This invention monitors the heartbeat data of bus interface devices to determine the connection status of devices in the bus device table in real time. Normal devices maintain their connection; in case of an anomaly, if there are still connected devices, the handshake connection process is re-executed; otherwise, the device enters low-power sleep mode. This achieves dynamic monitoring of device connection status and self-healing from faults, ensuring continuous cluster communication, while also reducing unnecessary energy consumption through sleep mode.

[0016] In an optional implementation, the method further includes: Before a new bus interface device establishes a connection with the corresponding cluster communication bus via hot-plugging, the new device information of the new bus interface device is sent to the cluster communication bus. The system receives the new device information by all bus interface devices connected to the cluster communication bus and verifies the information, generating an information verification result. The request to add the new bus interface device is sent to the new robot, and the operating status of the new robot is confirmed. Based on the confirmation result, the new bus interface device is determined to establish a connection with the corresponding cluster communication bus, and the process jumps to execute the step of classifying the master and slave identities of each bus interface device according to the hardware configuration of each bus interface device. Before the bus interface device disconnects from the cluster communication bus via hot-plugging, the bus interface device sends a departure request command to the corresponding cluster communication bus. The cluster communication bus is set to an idle state according to the leave request instruction, and the bus device table is updated. Jump to execute the step of determining whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device, and filtering out the bus interface devices with normal connection based on the determination result.

[0017] When a new device is hot-plugged in according to this invention, it is connected and the master and slave units are reassigned after information verification and robot status confirmation, ensuring the legality and compatibility of the connection. When a device is hot-plugged out, a departure command is sent and the bus device table is updated, and the device connection status is subsequently re-checked. This enables the orderly management of dynamic addition and removal of cluster devices, ensuring that the overall communication is not interrupted during the hot-plugging process.

[0018] Secondly, the present invention provides a hot-swappable bus communication networking device for robot swarms, wherein all robots in the robot swarm are interconnected via a swarm communication bus, each robot is equipped with a compatible bus interface device, the bus interface device establishes a connection with the swarm communication bus through hot-plugging or disconnects from the swarm communication bus through hot-plugging, and the remaining bus interface devices after hot-plugging can automatically reconstruct the bus communication network; the device includes: The startup module is used to power on all the robots and all the bus interface devices, and to classify the master and slave identities of each bus interface device according to the hardware configuration of each bus interface device. The analysis module is used to analyze the bus status data of each bus interface device and perform secondary master-slave identity assignment for each bus interface device based on the analysis results. Establish a module to establish handshake connections for each bus interface device after secondary allocation and generate a bus device table; The judgment module is used to determine whether the connection status of each bus interface device in the bus device table is normal according to the heartbeat data of each bus interface device, and to filter out the bus interface devices with normal connection based on the judgment result. The partitioning module is used to prioritize data based on the real-time requirements of robot business data, and transmit robot business data corresponding to normally connected bus interface devices through the cluster communication bus according to the data priority.

[0019] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the hot-swappable bus communication networking method for robot swarms described in the first aspect or any corresponding embodiment thereof.

[0020] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the hot-swappable bus communication networking method for robot swarms described in the first aspect or any corresponding embodiment thereof.

[0021] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the hot-swappable bus communication networking method for robot swarms described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of the first process of a hot-swappable bus communication networking method for robot clusters according to an embodiment of the present invention; Figure 2 This is a second flowchart illustrating a hot-swappable bus communication networking method for robot swarms according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the connection between the cluster communication bus, the bus interface device, and the robot according to an embodiment of the present invention; Figure 4 This is a logic flowchart of a bus interface device according to an embodiment of the present invention; Figure 5 This is a structural block diagram of a hot-swappable bus communication networking device for robot clusters according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0024] 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 present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0026] This invention provides a hot-swappable bus communication networking method for robot swarms. In the robot swarm, robots are interconnected via a swarm communication bus through adapted bus interface devices, supporting hot-swapping of devices and automatic reconfiguration of the network by remaining devices. The networking method is as follows: after device startup, master and slave devices are initially assigned according to hardware configuration, and then master and slave devices are reassigned again based on bus status data; a handshake connection is established to generate a bus device table, and normally connected devices are filtered based on heartbeat data; finally, data is transmitted according to the real-time priority of business data, so as to realize hot-swappable bus communication in robot swarms. Device access / exit does not interrupt the overall communication, and remaining devices automatically reconfigure the network to adapt to the dynamic expansion needs of the swarm; through secondary allocation and handshake verification of master and slave devices, combined with heartbeat monitoring to ensure connection stability, and data is transmitted according to real-time priority, the effectiveness of communication reliability and real-time transmission of critical data is improved.

[0027] According to an embodiment of the present invention, a hot-swappable bus communication networking method for robot swarms is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0028] This embodiment provides a hot-swappable bus communication networking method for robot clusters, wherein all robots in the robot cluster are interconnected through a cluster communication bus, each robot is equipped with an adapted bus interface device, the bus interface device establishes a connection with the cluster communication bus by hot-plugging or the bus interface device disconnects from the cluster communication bus by hot-plugging, and the remaining bus interface device after hot-plugging can automatically reconstruct the bus communication network. Figure 1 This is a flowchart of a hot-swappable bus communication networking method for robot swarms according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Power on all robots and all bus interface devices, and assign master and slave roles to each bus interface device according to its hardware configuration.

[0029] It should be noted that the bus interface device refers to the communication adapter component adapted to the robot, which is used to connect the robot to the cluster communication bus.

[0030] Hardware configuration refers to the hardware parameter settings built into the bus interface device.

[0031] Master-slave roles refer to the role division of devices in cluster communication. The master is responsible for bus resource scheduling, device connection management, and data transmission coordination, while the slave obeys the master's scheduling and completes data transmission and reception and business execution.

[0032] In this embodiment of the invention, all robots and all bus interface devices are powered on and initialized. After each bus interface device completes its power-on self-test and basic configuration loading, it automatically reads its own hardware configuration parameters and determines whether it is the default host based on the preset host enable flag in the hardware configuration. If the hardware configuration marks it as the default host, it is directly identified as the host and the corresponding terminal resistor, communication rate and other adaptation parameters are loaded. If it is not marked as the default host, it is set as a slave by default, uses the base address as the initial communication ID, sends its own device chip information in a low-frequency manner, and listens to the cluster communication bus. It will participate in the secondary master-slave allocation in the future. All bus interface devices complete the initial master-slave identity division according to the above logic.

[0033] It is worth mentioning that each robot in the robot cluster contains a complete robot controller and a bus interface device. A single bus interface device is serially connected to the robot controller, and multiple bus interface devices transmit data according to data priority through several communication buses.

[0034] Specifically, a bus interface device uses the device communication bus to broadcast device data and receive data status information from other devices on the bus. Based on the received data, it automatically assigns unique information to itself and internally records a list of bus devices. Then, it packages its own device information and the bus device list into a heartbeat and broadcasts it on the device communication bus at a fixed frequency. The bus interface device receives the heartbeat packets broadcast on the device communication bus and verifies with each other to confirm the integrity of the device communication status. The device will then decide whether to voluntarily leave the device communication bus based on its own communication quality.

[0035] Step S102: Analyze the bus status data of each bus interface device, and perform secondary master / slave identity assignment for each bus interface device based on the analysis results.

[0036] It should be noted that bus status data refers to data broadcast by bus interface devices during communication, which includes core information such as their own UID (Universally Unique Identifier), communication quality, and operating status.

[0037] Secondary allocation of master-slave roles refers to the process of redetermining master-slave roles based on the initial master-slave assignment and real-time bus status data.

[0038] In this embodiment of the invention, each bus interface device continuously broadcasts its own bus status data to the cluster communication bus. Other devices receive and parse the data in real time, extracting the device chip universal unique identifier (UID), communication quality parameters, and operating status information. Valid data is filtered by verifying the integrity of the data format and the uniqueness of the UID. Priority scores are then calculated based on the hardware level and communication quality performance associated with the UID. The device with the highest priority is determined as the master, and the remaining devices are retained or adjusted to slaves. The communication ID, bus access permissions, and other parameters corresponding to each device are updated synchronously to complete the secondary allocation of master and slave identities.

[0039] Specifically, each bus interface device needs to publish its own bus status data (which also exists as a heartbeat) on the device communication bus at a preset fixed frequency. The bus status data includes: its own device communication ID, its own device chip information UID, its own bus electrical attribute configuration, its own device status (current running status or error status), its own command information, its own software and hardware version information, the number of bus devices it has detected, the chip information UID of the bus devices it has detected, and other custom data.

[0040] It's important to further explain that each bus interface device receives status data from other bus interface devices on the bus. It then has a built-in bus interface device information table (i.e., a bus device table) that records all devices detected by the bus interface device up to power-on. The sequence order of the built-in device information table is primarily based on the device sequence order established by the host. The host-established device sequence order is based on the time sequence in which new bus interface devices are detected. Other bus interface devices still online are detected based on heartbeat timeouts and added to the information in sections 7 and 8 mentioned above. The bus interface device cross-validates its own bus interface device information table with the status data of other devices to determine if it has any undetected bus interface devices. The bus status data is directly broadcast on the device communication bus.

[0041] Step S103: Establish handshake connections for each bus interface device after secondary allocation and generate a bus device table.

[0042] It should be noted that the handshake connection refers to the two-way communication verification process between the master and slave devices.

[0043] The bus device table refers to a structured data table that records key information about all bus interface devices within the cluster.

[0044] In this embodiment of the invention, the host determined by the secondary allocation sends handshake requests to each slave in the order of device discovery in the bus status data. After receiving the request, the slave responds with its own device identifier, running status and other verification information. The host verifies the validity of the verification information. If the verification is successful, the handshake connection is confirmed and the connection status of the slave is recorded. If the verification fails, the slave enters low-power sleep mode, restarts automatically at regular intervals and retryes later. After the host has completed the handshake interaction with all slaves, it integrates the core information such as the device identifier, communication parameters and connection status of the host and all validly connected slaves, and organizes them into a bus device table in a unified format.

[0045] Step S104: Determine whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device, and filter out the bus interface devices with normal connection based on the judgment result.

[0046] It should be noted that heartbeat data refers to data containing core status information sent by bus interface devices at a fixed frequency.

[0047] Connection status refers to the smooth operation of the communication links between the bus interface device and the cluster communication bus and other devices.

[0048] In this embodiment of the invention, each bus interface device sends heartbeat data containing its own device identifier and operating status to the cluster communication bus at a fixed frequency. The system listens for and receives all heartbeat data in real time, and matches it one by one with the device information recorded in the bus device table. By judging the continuity of heartbeat data reception, the integrity of the format, and whether it is within the preset timeout threshold, the connection status of the corresponding bus interface device is determined. If the heartbeat data is received on time and the information is valid, the connection is determined to be normal and it is kept in the list of valid devices. If it is not received or the data is abnormal and exceeds the timeout threshold, the connection is determined to be abnormal and it is removed from the list of valid devices. Finally, all bus interface devices with normal connections are selected.

[0049] Step S105: Based on the real-time requirements of robot business data, data priorities are divided, and robot business data corresponding to normally connected bus interface devices are transmitted through the cluster communication bus according to data priorities.

[0050] It should be noted that robot business data refers to various types of data generated and received by the robot during its operation.

[0051] Real-time requirements refer to the requirements of robot business data on transmission latency and timing stability.

[0052] Data priority refers to the transmission priority level based on the real-time requirements of business data.

[0053] The cluster communication bus refers to the communication channel connecting devices within a robot cluster. It includes a device communication bus and a data communication bus. The device communication bus is the broadcast bus between bus interface devices, while the data communication bus is the data bus for the bus interface devices to broadcast robot business data. The number of data communication buses varies depending on the size of the robot cluster.

[0054] In this embodiment of the invention, in accordance with the requirements of robot operation scenarios, robot business data is divided into different priorities according to real-time requirements. Among them, data with extremely high hard real-time requirements, such as motor control data and IMU raw data, are set to the highest priority, while ordinary sensor data and task feedback data are set to medium and low priority. The transmission channels and scheduling permissions of each priority data are clearly defined. Then, the host schedules the transmission resources of the cluster communication bus according to the bus device table and the list of valid devices. According to the rule of "high priority data occupies the bus first and low priority data is transmitted in a staggered manner", the various business data corresponding to the normally connected bus interface devices are accurately transmitted to the target devices.

[0055] It is worth mentioning that data priority depends on the robot system's real-time requirements for critical data. For example, for a robot system, the most important data are the raw motor data, IMU data, or motor control data uploaded at a hard real-time stable timing frequency. These data will be transmitted separately using one or more buses to strictly ensure data timing.

[0056] This invention enables communication networking of multiple robot clusters by mounting a bus interface device on any robot controller, achieving advantages such as hot-swappable communication, high speed, strong real-time performance, and dynamic device updates. Compared to wireless networking, it offers higher data real-time performance and stronger data reliability.

[0057] This embodiment provides a hot-swappable bus communication networking method for robot clusters, wherein all robots in the robot cluster are interconnected through a cluster communication bus, each robot is equipped with an adapted bus interface device, the bus interface device establishes a connection with the cluster communication bus by hot-plugging or the bus interface device disconnects from the cluster communication bus by hot-plugging, and the remaining bus interface device after hot-plugging can automatically reconstruct the bus communication network. Figure 2 This is a flowchart of a hot-swappable bus communication networking method for robot swarms according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Power on all robots and all bus interface devices, and assign master and slave roles to each bus interface device according to its hardware configuration.

[0058] Specifically, step S201 includes: Step S2011: Power on all robots and all bus interface devices.

[0059] In embodiments of the present invention, such as Figure 3 As shown, after all robots and all bus interface devices are powered on, each device automatically enters the power-on initialization process. The robot completes the functional self-test of the core control module and the loading of basic parameters of the operation execution component. The bus interface devices simultaneously perform communication protocol initialization, hardware interface testing and power supply stability verification. After both parties have completed initialization and there are no fault prompts, the bus interface devices automatically establish a physical connection with the control port of the corresponding robot.

[0060] Step S2012: Extract the hardware configuration of each bus interface device.

[0061] In this embodiment of the invention, after the bus interface device completes power-on initialization and establishes a connection with the corresponding robot, it automatically starts the hardware configuration extraction process. It retrieves its own stored inherent hardware parameters through the built-in configuration reading module, including core information such as host enable identifier, chip model, communication interface specification, terminal resistor adaptation parameters, and maximum transmission rate threshold.

[0062] Step S2013: Based on the hardware configuration of each bus interface device, determine the master / slave identity and device parameters of each bus interface device.

[0063] It should be noted that device parameters refer to the communication and functional configuration parameters set to match the master and slave identities, including communication ID, bus speed, terminating resistor configuration, bus access permissions, etc.

[0064] In this embodiment of the invention, the host enable identifier in each hardware configuration is used for determination. If the hardware configuration of a bus interface device is marked with a host enable identifier, it is directly identified as a host and the corresponding device parameters, including bus scheduling permissions, terminal resistor configuration and global broadcast rate, are matched and loaded. If there is no host enable identifier in the hardware configuration, it is identified as a slave by default, the corresponding slave device parameters are assigned, the preset base address is used as the initial communication ID and basic communication rate, and the master and slave identities and corresponding device parameters of all devices are temporarily stored to complete the initial configuration.

[0065] Step S202: Analyze the bus status data of each bus interface device, and perform secondary assignment of master and slave identities for each bus interface device based on the analysis results.

[0066] In some optional implementations, step S202 above includes: Step S2021: Collect bus status data of each bus interface device.

[0067] In this embodiment of the invention, after each bus interface device completes its initial master-slave identity and device parameter configuration, all bus interface devices broadcast their own bus status data to the cluster communication bus at a preset fixed frequency. The system listens to the broadcast information on the cluster communication bus in real time, receives the data sent by each bus interface device one by one, and performs preliminary format verification on the received data to filter out invalid and abnormal data, ensuring that the collected bus status data is complete and valid.

[0068] Step S2022: Determine whether there is at least one host status data among all bus status data within the same robot cluster.

[0069] It should be noted that a robot swarm refers to a collection of devices consisting of multiple robots and compatible bus interface devices, interconnected through a swarm communication bus to collaboratively complete tasks.

[0070] The host status data refers to the specific data in the bus status data that is marked as the host in the master / slave identification field.

[0071] In this embodiment of the invention, the system parses all bus status data in the same robot cluster after collecting and completing format verification, extracts the master / slave identification field contained in each data, and determines whether there is status data marked as master by searching this field.

[0072] Step S2023: If not, set each bus interface device to low-power sleep mode.

[0073] It should be noted that low-power sleep mode refers to the energy-saving operation mode that bus interface devices enter when there is no valid host and normal network formation is not possible.

[0074] In this embodiment of the invention, if no host status data is found, it means that there is no valid host in the robot cluster. Then, all bus interface devices are controlled to enter a low-power sleep mode, and the detection process will be restarted later.

[0075] Step S2024: If yes, extract the universal unique identifier of each bus interface device, determine the priority of the universal unique identifier based on each universal unique identifier, and determine the bus interface device with the highest priority of the universal unique identifier as the master and the remaining bus interface devices as slaves.

[0076] It should be noted that the Universally Unique Identifier (UID) refers to a globally unique identifier that is built into the bus interface device chip. It is non-repeating, tamper-proof, and used to uniquely distinguish each bus interface device in the cluster.

[0077] The priority of a universally unique identifier refers to the priority level based on the UID of each bus interface device, combined with preset rules (such as hardware level and factory settings).

[0078] In this embodiment of the invention, a universally unique identifier (UID) corresponding to each device is accurately extracted from the bus status data of each bus interface device. The extracted UID is uniquely verified, and duplicate or invalid UIDs are removed. Then, the priority score corresponding to each UID is determined by combining the device hardware level associated with the UID and the factory preset priority rules. After sorting the UIDs in descending order, the bus interface device corresponding to the highest priority UID is selected as the final host of the cluster, and all other bus interface devices are uniformly determined as slaves. The master and slave identity identifiers of each device are updated synchronously to complete the secondary allocation of master and slave.

[0079] Step S203: Establish handshake connections for each bus interface device after secondary allocation and generate a bus device table.

[0080] Specifically, step S203 includes: Step S2031: The host in the robot cluster establishes a handshake connection with each slave in turn, and determines whether the handshake connection between the host and the current slave is successful.

[0081] In this embodiment of the invention, after the master-slave secondary allocation is completed, the master sends a handshake request instruction containing the master UID and communication parameters to each slave in the order of slaves recorded in the bus status data. After receiving the request, the current slave immediately feeds back its own UID, running status and device parameters and other verification information. The master compares and verifies the received verification information with the bus status data and the uniqueness information of the UID, and determines whether the handshake connection is successful according to the verification result.

[0082] Step S2032: If not, set the current slave device to low-power sleep mode.

[0083] In this embodiment of the invention, if the verification fails, the handshake connection is determined to have failed. At the same time, the slave device is marked as having an abnormal connection and the current slave device is set to a low-power sleep mode and automatically restarted at regular intervals.

[0084] Step S2033: If yes, record the connection status of the slave device and establish a handshake connection between the master device and the next slave device.

[0085] In this embodiment of the invention, if the verification is successful, the handshake connection is determined to be successful. The device connection status of the slave device is immediately marked as "normal connection". Its UID, communication parameters and other related information are recorded synchronously. After the connection record of the current slave device is completed, the master automatically switches to the next slave device and uses the same handshake request and verification process to initiate handshake connection to the remaining slave devices one by one until the handshake interaction of all slave devices is completed.

[0086] Step S2034: After the host and each slave device complete the handshake connection, the device status data of the host and each slave device are collected to generate a bus device table.

[0087] In this embodiment of the invention, the host summarizes its own device status data and the device status data of all slave devices, classifies and organizes the summarized data, performs deduplication and verification to ensure that the data is complete and error-free, and then enters the core information of all devices in an orderly manner according to a preset unified format to generate a bus device table.

[0088] Step S204: Determine whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device, and filter out the bus interface devices with normal connection based on the judgment result.

[0089] In some optional implementations, step S204 above includes: Step S2041: Obtain the heartbeat data of each bus interface device within the same robot cluster.

[0090] In this embodiment of the invention, after the host generates the bus device table, all normally connected bus interface devices (including the host and slave devices) in the robot cluster will continuously send heartbeat data to the cluster communication bus at preset fixed time intervals. The host listens to the bus signal in real time, receives the heartbeat data sent by each device one by one, and associates it with the device information in the bus device table. It performs simple format verification on the received heartbeat data, filters invalid or disordered data, and ensures that each heartbeat data obtained can correspond to a specific bus interface device in the cluster.

[0091] Step S2042: Based on the heartbeat data of each bus interface device, determine whether the connection status of each bus interface device in the bus device table is normal.

[0092] In this embodiment of the invention, the host will associate and match each heartbeat data with the device information in its corresponding bus device table, check whether the sending device identifier of the heartbeat data is consistent with the device UID in the table, whether the data format conforms to the preset specification, and at the same time determine whether the receiving time of the heartbeat data is within the preset timeout threshold, thereby determining whether the connection status of the bus interface device is normal.

[0093] Step S2043: If normal, confirm that the bus interface device is connected correctly.

[0094] In this embodiment of the invention, if the heartbeat data is correctly matched, in the correct format, and received on time, the connection status of the bus interface device is determined to be normal.

[0095] Step S2044: If abnormal, determine whether there is at least one device with an established connection in the bus device table.

[0096] In this embodiment of the invention, if the heartbeat data cannot be matched, the format is disordered, or the heartbeat data of the corresponding device is not received after the timeout threshold is exceeded, the connection status of the bus interface device is determined to be abnormal. The connection status records of all devices in the bus device table are immediately retrieved, and the status identifier of each device is checked one by one to further determine whether there is at least one other device that has established a connection in the bus device table.

[0097] Step S2045: If it exists, then proceed to the step of establishing handshake connections between the host and each slave in the robot cluster in turn, and determining whether the host and the current slave have successfully established a handshake connection.

[0098] In this embodiment of the invention, if a device with an established connection is found, it indicates that the cluster communication link has not been completely interrupted. Then, the process jumps to the step of re-establishing the handshake connection between the host and each slave device to attempt to restore the connection of the abnormal device.

[0099] Step S2046: If not, set each bus interface device to low-power sleep mode.

[0100] In this embodiment of the invention, if no connected device is found, it indicates that the cluster networking has been completely interrupted. In this case, all bus interface devices are controlled to enter a low-power sleep mode, and the networking process will be restarted later.

[0101] Specifically, connection status is determined by status information broadcast by other bus interface devices on the device communication bus. The device communication bus is a bus through which bus interface devices confirm each other's existence. Once communication is established, all bus interface devices continuously send their status information (or heartbeat packets) to each other at a fixed frequency. When all devices except the device itself send status information containing their own device information (UID), the connection is considered successful. When all devices are successfully connected, the communication is complete.

[0102] When a bus interface device can listen to the status information of other bus interface devices besides itself, it means that there is status information of at least one other host.

[0103] Step S205: Based on the real-time requirements of robot business data, data priorities are divided, and robot business data corresponding to normally connected bus interface devices are transmitted through the cluster communication bus according to data priorities.

[0104] Please see details Figure 1 Step S105 of the illustrated embodiment will not be described again here.

[0105] Step S206: Before a new bus interface device establishes a connection with the corresponding cluster communication bus via hot-plugging, the new device information of the new bus interface device is sent to the cluster communication bus.

[0106] It should be noted that hot-plugging refers to a connection method that allows new bus interface devices to be connected to the bus without shutting down the power supply to the robot cluster and the cluster communication bus.

[0107] New device information refers to the core basic information of the newly connected bus interface device itself.

[0108] In embodiments of the present invention, such as Figure 4 As shown, before the new bus interface device establishes a connection with the corresponding cluster communication bus through hot-plugging, and after the new bus interface device completes power-on initialization, it automatically collects its own new device information, including core content such as device UID, hardware configuration, and communication parameters. After the information integrity is verified by its own built-in module, the verified new device information is sent to the cluster communication bus through a preset temporary communication channel, ensuring that the bus and other devices connected to the bus can obtain the basic information of the new device in advance.

[0109] Step S207: Receive new device information through all bus interface devices connected to the cluster communication bus and perform information verification to generate information verification results.

[0110] It should be noted that information verification refers to the process of checking the validity, uniqueness, and compatibility of new device information according to preset rules before connecting to the bus interface device.

[0111] The information verification result refers to the final conclusion generated by the host after summarizing the verification opinions of all devices to be connected, which clearly determines whether the information of the new device meets the access standards.

[0112] In this embodiment of the invention, after the new device information is sent to the cluster communication bus, all bus interface devices that have established a stable connection with the bus synchronously listen to and receive the new device information. Each device checks the uniqueness of the device UID, hardware configuration compatibility, and communication parameter standardization in the new device information one by one according to the preset verification rules, and eliminates abnormal situations such as missing information, duplicate UIDs, or incompatible parameters. After all devices have completed the verification, they feed back their respective verification results to the host. The host summarizes all verification opinions and finally generates a unified information verification result.

[0113] Step S208: Send the request to add the new bus interface device to the new robot and confirm the operating status of the new robot.

[0114] It should be noted that the "join request" refers to the access request sent by the new bus interface device to the corresponding new robot and cluster host, which includes information such as its own UID, hardware configuration, and access requirements.

[0115] Operational status confirmation refers to the process of checking the operational status of the new robot's core components (control module, execution component, etc.) after receiving a request to join.

[0116] In this embodiment of the invention, after the information verification result is qualified, the new bus interface device automatically generates a join request application containing its own UID, hardware configuration and access requirements, and sends it to the corresponding new robot through the cluster communication bus. After receiving the join request application, the new robot immediately starts its own operation status detection process to check the operation status of the core control module, operation execution component and sensing unit, and confirm whether it has normal operation and communication capabilities. After the detection is completed, the new robot feeds back its own operation status confirmation result (normal or abnormal) to the corresponding new bus interface device, and simultaneously pushes it to the cluster host to verify the access qualification of the new bus interface device for the host.

[0117] Step S209: Based on the confirmation result, determine the connection relationship between the new bus interface device and the corresponding cluster communication bus, and jump to execute the step of classifying the master and slave identities of each bus interface device according to the hardware configuration of each bus interface device.

[0118] It should be noted that the connection relationship refers to the physical connection and data exchange link established between the bus interface device and the cluster communication bus.

[0119] In this embodiment of the invention, if the new robot's operating status confirmation result is normal, the host, combining the previous information verification result with the confirmation result, allows the new bus interface device to establish a stable physical connection and data interaction link with the cluster communication bus. Simultaneously, the core information of the new bus interface device is updated to the bus device table to ensure that the table completely covers all bus interface devices in the cluster. Then, the process immediately jumps to step S201, where the new bus interface device and all existing bus interface devices in the cluster synchronously extract their own hardware configuration parameters and participate in the reclassification and adaptation of master and slave identities, ensuring the new access device is compatible with the existing cluster devices and maintaining the integrity and stability of the cluster communication network. If the new robot's operating status confirmation result is abnormal, it is determined that the new bus interface device does not yet meet the access conditions, and its connection with the cluster communication bus is rejected. The device is marked as having an abnormal access and relevant records are retained. This step and subsequent related processes are restarted after the new robot's operating status returns to normal and the access verification and status confirmation are completed again.

[0120] Step S210: Before the bus interface device disconnects from the cluster communication bus via hot-plugging, a departure request command of the bus interface device is sent to the corresponding cluster communication bus.

[0121] It should be noted that hot-swapping refers to the method of removing and disconnecting the bus interface device from the bus by turning off the power to the robot cluster and the cluster communication bus.

[0122] A departure request instruction is a command sent by a bus interface device before it intends to disconnect from the cluster communication bus. It includes core information such as the device UID, device identifier, and reason for departure.

[0123] In this embodiment of the invention, if a bus interface device wishes to disconnect from the cluster communication bus via hot-plugging, the bus interface device first checks its current connection status with the cluster communication bus and the running status of the corresponding robot. After confirming that there are no unfinished data transmission tasks, it automatically generates a departure request instruction containing its own UID, device identifier, and departure reason. After its own functional module verifies that the instruction format is correct, it sends the departure request instruction to the cluster communication bus through the existing data interaction link. This ensures that the bus and the host and other slaves in the cluster can obtain the device's departure intention in a timely manner, which prepares for the host to update the bus device table, adjust the cluster network structure, and release the corresponding bus resources. This ensures that the hot-plugging process does not interrupt the normal communication of the cluster and does not affect the collaborative operation of other devices.

[0124] Step S211: Set the cluster communication bus to an idle state according to the leave request instruction, and update the bus device table.

[0125] It should be noted that the idle state refers to the link state in the trunking communication bus that is not occupied by any bus interface device and can be allocated to new access devices or used temporarily by existing devices at any time.

[0126] In this embodiment of the invention, after receiving a leave request instruction transmitted on the cluster communication bus, the host first parses the device UID in the instruction to accurately locate the bus interface device to be left. Then, it detects the bus communication link corresponding to the device. After confirming that there are no residual data transmission tasks and the link status is stable, it sets the link corresponding to the cluster communication bus occupied by the device to an idle state, releases the bus transmission resources occupied by the device, and retrieves the bus device table. It deletes all relevant information of the bus interface device to be left from the table, including its UID, master / slave identity, communication parameters and connection status, etc., updates the table version and pushes it synchronously to all remaining bus interface devices in the cluster. This ensures that the bus device table can accurately reflect the current device access status in the cluster and avoids subsequent data transmission conflicts or network anomalies caused by residual device information.

[0127] It is worth mentioning that if a bus interface device malfunctions and is unable to send a departure request command in a timely manner, the connection status of the bus interface device can be determined to be abnormal after the heartbeat data of the bus interface device is not received, and the bus device table will be updated.

[0128] Step S212: Jump to execute the step of judging whether the connection status of each bus interface device in the bus device table is normal according to the heartbeat data of each bus interface device, and filtering out the bus interface devices with normal connection based on the judgment result.

[0129] In this embodiment of the invention, after updating the bus device table, it is necessary to jump back to step S204 until the remaining bus interface devices reconstruct the bus communication network.

[0130] Specifically, the method for restoring the environment of the device communication bus is strongly related to the device communication bus used (strong hardware dependence). Taking the CAN bus as an example, to achieve CAN bus communication, it is necessary to ensure that the impedance on the bus is continuous and matched, and the resistance value of the terminating resistor needs to be set appropriately.

[0131] Take a complete communication establishment process as an example: Assuming there are two independent robots, A and B, connecting to establish cluster communication, they first enter a handshake phase. Both devices default to being slaves, sending their device chip's UID data at a low frequency using the communication ID of the base address. Then, both robots simultaneously listen for bus information without terminating resistors. If no data is detected, they attempt to listen for bus information again with terminating resistors. This process overlaps in timing, ensuring the necessary electrical environment for the communication bus is present. Because the same base address is used as the communication ID, data is transmitted contentiously. Regardless, if either device successfully detects other data, it enters a high-frequency transmission state and sets itself as the master. This electrical configuration is written into the device's state information and remains unchanged unless the device needs to leave the communication bus. If no data is detected, the device enters a low-power sleep state and restarts periodically.

[0132] Hot-plugging of bus interface devices may cause disturbances to the bus electrical environment, so a time window is designed in the software to specifically reconstruct the communication bus environment.

[0133] The specific refactoring method is: 1) If the command requests the device to leave the communication bus: The communication bus has entered an idle state.

[0134] If the device leaving is the one that established the communication connection for the first time, then according to the existing complete host device information table sequence, the next device adjusts its electrical attribute configuration in sequence. Simultaneously, the bus interface device leaving restores its electrical attribute configuration and leaves the communication bus. After a certain period, other devices continue sending status information according to the original device information table, and communication is restored. If communication fails, the communication environment is re-established using the same method as the initial communication setup.

[0135] 2) If the disconnection from the communication bus is due to abnormal reasons (machine crash / loose communication interface components causing disconnection, etc.): The communication environment should be re-established using the same method as the initial communication.

[0136] Each time a bus interface device needs to have its electrical properties configured, there is a time limit for restoring the bus environment. If the time limit is exceeded, the system will jump to the next bus interface device to restore the bus interface device according to the device table information. If the bus environment is still not successfully restored after all devices have been polled, the device will enter a low-power timed restart.

[0137] This embodiment also provides a hot-swappable bus communication networking device for robot swarms. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0138] This embodiment provides a hot-swappable bus communication networking device for robot swarms. All robots within the swarm are interconnected via a swarm communication bus. Each robot is equipped with a compatible bus interface device. The bus interface device establishes a connection with the swarm communication bus through hot-plugging or hot-plugging to disconnect it. The remaining bus interface devices after hot-plugging can automatically reconstruct the bus communication network. Figure 5 As shown, it includes: The startup module 301 is used to power on all robots and all bus interface devices, and to classify the master and slave identities of each bus interface device according to its hardware configuration. Analysis module 302 is used to analyze the bus status data of each bus interface device and perform secondary master-slave identity assignment for each bus interface device based on the analysis results. Module 303 is established to establish handshake connections for each bus interface device after secondary allocation and generate a bus device table. The judgment module 304 is used to judge whether the connection status of each bus interface device in the bus device table is normal according to the heartbeat data of each bus interface device, and to filter out the bus interface devices with normal connection based on the judgment result. The partitioning module 305 is used to prioritize data based on the real-time requirements of robot business data, and transmit the robot business data corresponding to the normally connected bus interface devices through the cluster communication bus according to the data priority.

[0139] In some alternative implementations, the startup module 301 includes: The startup unit is used to power on all robots and all bus interface devices. The extraction unit is used to extract the hardware configuration of each bus interface device. The initial master-slave unit is used to determine the master-slave identity and device parameters of each bus interface device based on the hardware configuration of each bus interface device.

[0140] In some alternative implementations, the analysis module 302 includes: The acquisition unit is used to acquire bus status data from each bus interface device. The status determination unit is used to determine whether there is at least one host status data among all bus status data within the same robot cluster. Low-power unit, used to set each bus interface device to low-power sleep mode if not. The identifier extraction unit is used to extract the universally unique identifier of each bus interface device if the condition is met, and to determine the priority of the universally unique identifier based on each universally unique identifier. The bus interface device with the highest priority of the universally unique identifier is identified as the master, and the remaining bus interface devices are identified as slaves.

[0141] In some alternative implementations, the establishment module 303 includes: The handshake unit is used to establish handshake connections between the host and each slave in the robot cluster in sequence, and to determine whether the handshake connection between the host and the current slave is successful. The mode change unit is used to set the current slave device to low-power sleep mode if no. The recording unit is used to record the connection status of the slave device if the condition is met, and to establish a handshake connection between the master device and the next slave device. The aggregation unit is used to aggregate the device status data of the host and each slave device after the host has completed the handshake connection and generate a bus device table.

[0142] In some optional implementations, the determination module 304 includes: The acquisition unit is used to acquire the heartbeat data of each bus interface device within the same robot cluster. The connection status determination unit is used to determine whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device. Connect to a normal unit; if normal, then determine the bus interface device that is connected. The connection failure unit is used to determine whether there is at least one device with an established connection in the bus device table if the connection is abnormal. A connection unit exists, which, if it exists, jumps to execute the steps of establishing handshake connections between the host and each slave in the robot cluster in sequence, and determining whether the host and the current slave have successfully established a handshake connection. There is no connection unit, which is used to set each bus interface device to low-power sleep mode if it does not exist.

[0143] In some alternative embodiments, the device further includes: The hot-insertion unit is used to send the new device information of the new bus interface device to the cluster communication bus before the new bus interface device establishes a connection with the corresponding cluster communication bus through hot-insertion. The verification unit is used to receive new device information through all bus interface devices connected to the cluster communication bus, verify the information, and generate information verification results. The join request unit is used to send a join request for a new bus interface device to the new robot and to confirm the operating status of the new robot. The confirmation unit is used to determine the connection relationship between the new bus interface device and the corresponding cluster communication bus based on the confirmation result, and jump to execute the step of classifying the master and slave identities of each bus interface device according to the hardware configuration of each bus interface device. The hot-pull-out unit is used to send a departure request command of the bus interface device to the corresponding cluster communication bus before the bus interface device is disconnected from the cluster communication bus by hot-pull-out. The update unit is used to set the cluster communication bus to an idle state according to the leave request instruction and update the bus device table; The jump-to-filter unit is used to jump to the execution step of judging whether the connection status of each bus interface device in the bus device table is normal according to the heartbeat data of each bus interface device, and filtering out the bus interface devices with normal connection based on the judgment result.

[0144] The hot-swappable bus communication networking device for robot swarms provided in this embodiment of the invention can execute the hot-swappable bus communication networking method for robot swarms provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method. Further functional descriptions of the various modules and units are the same as in the corresponding embodiments described above, and will not be repeated here.

[0145] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0146] The following is a detailed reference. Figure 6 This diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 401, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 402 or a program loaded from memory 408 into random access memory (RAM) 403. RAM 403 also stores various programs and data required for the operation of the electronic device. The processor 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0147] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 408 including, for example, magnetic tapes, hard disks, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0148] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 409, or installed from memory 408, or installed from ROM 402. When the computer program is executed by processor 401, it performs the functions defined in the hot-swappable bus communication networking method for robot swarms according to embodiments of the present invention.

[0149] Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0150] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the hot-swappable bus communication networking method for robot swarms shown in the above embodiments is implemented.

[0151] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0152] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A hot-swappable bus communication networking method for robot swarms, characterized in that, All robots within the robot cluster are interconnected via a cluster communication bus. Each robot is equipped with a compatible bus interface device. The bus interface device establishes a connection with the cluster communication bus via hot-plugging or disconnects from the cluster communication bus via hot-plugging. The remaining bus interface devices after hot-plugging can automatically reconstruct the bus communication network. The method includes: Power on all the robots and all the bus interface devices, and assign master and slave identities to each bus interface device according to its hardware configuration. Analyze the bus status data of each bus interface device, and perform secondary master / slave identity assignment on each bus interface device based on the analysis results; Establish handshake connections for each bus interface device after secondary allocation and generate a bus device table; Based on the heartbeat data of each bus interface device, determine whether the connection status of each bus interface device in the bus device table is normal, and filter out the bus interface devices with normal connection based on the judgment result. Based on the real-time requirements of robot business data, data priorities are assigned, and robot business data corresponding to normally connected bus interface devices are transmitted through the cluster communication bus according to the data priorities.

2. The method according to claim 1, characterized in that, The step of powering on all the robots and all the bus interface devices, and assigning master / slave roles to each bus interface device according to its hardware configuration, includes: Power on all the robots and all the bus interface devices; Extract the hardware configuration of each of the bus interface devices; Based on the hardware configuration of each bus interface device, the master / slave identity and device parameters of each bus interface device are determined.

3. The method according to claim 1, characterized in that, The analysis of the bus status data of each bus interface device, and the secondary allocation of master / slave identities for each bus interface device based on the analysis results, includes: Collect bus status data from each of the aforementioned bus interface devices; Determine whether at least one host's status data is present among all the bus status data within the same robot cluster; If not, set each of the aforementioned bus interface devices to low-power sleep mode; If so, extract the universal unique identifier of each bus interface device, determine the priority of the universal unique identifier based on each universal unique identifier, and determine the bus interface device with the highest priority of the universal unique identifier as the master and the remaining bus interface devices as slaves.

4. The method according to claim 3, characterized in that, The process of establishing handshake connections for each bus interface device after secondary allocation and generating a bus device table includes: The host in the robot cluster establishes a handshake connection with each of the slaves in turn, and determines whether the handshake connection between the host and the current slave is successful. If not, then set the current slave device to low-power sleep mode; If so, record the connection status of the slave device and establish a handshake connection between the master device and the next slave device; After the host completes the handshake connection with each of the slave devices, it collects the device status data of the host and each of the slave devices to generate a bus device table.

5. The method according to claim 4, characterized in that, The step of determining whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device, and filtering out the bus interface devices with normal connections based on the determination results, includes: Obtain heartbeat data from each bus interface device within the same robot cluster; Based on the heartbeat data of each bus interface device, determine whether the connection status of each bus interface device in the bus device table is normal. If normal, then confirm that the bus interface device is connected correctly; If it is abnormal, then determine whether there is at least one device that has established a connection in the bus device table; If it exists, then proceed to the step of establishing handshake connections between the host and each slave in the robot cluster in sequence, and determining whether the host and the current slave have successfully established a handshake connection. If not, set each of the bus interface devices to low-power sleep mode.

6. The method according to claim 1, characterized in that, The method further includes: Before a new bus interface device establishes a connection with the corresponding cluster communication bus via hot-plugging, the new device information of the new bus interface device is sent to the cluster communication bus. The system receives the new device information by all bus interface devices connected to the cluster communication bus and verifies the information, generating an information verification result. The request to add the new bus interface device is sent to the new robot, and the operating status of the new robot is confirmed. Based on the confirmation result, the new bus interface device is determined to establish a connection with the corresponding cluster communication bus, and the process jumps to execute the step of classifying the master and slave identities of each bus interface device according to the hardware configuration of each bus interface device. Before the bus interface device disconnects from the cluster communication bus via hot-plugging, the bus interface device sends a departure request command to the corresponding cluster communication bus. The cluster communication bus is set to an idle state according to the leave request instruction, and the bus device table is updated. Jump to execute the step of determining whether the connection status of each bus interface device in the bus device table is normal based on the heartbeat data of each bus interface device, and filtering out the bus interface devices with normal connection based on the determination result.

7. A hot-swappable bus communication networking device for robot swarms, characterized in that, All robots within the robot cluster are interconnected via a cluster communication bus. Each robot is equipped with a compatible bus interface device. The bus interface device establishes a connection with the cluster communication bus via hot-plugging or disconnects from the cluster communication bus via hot-plugging. The remaining bus interface devices after hot-plugging can automatically reconfigure the bus communication network. The device includes: The startup module is used to power on all the robots and all the bus interface devices, and to classify the master and slave identities of each bus interface device according to the hardware configuration of each bus interface device. The analysis module is used to analyze the bus status data of each bus interface device and perform secondary master-slave identity assignment for each bus interface device based on the analysis results. Establish a module to establish handshake connections for each bus interface device after secondary allocation and generate a bus device table; The judgment module is used to determine whether the connection status of each bus interface device in the bus device table is normal according to the heartbeat data of each bus interface device, and to filter out the bus interface devices with normal connection based on the judgment result. The partitioning module is used to prioritize data based on the real-time requirements of robot business data, and transmit robot business data corresponding to normally connected bus interface devices through the cluster communication bus according to the data priority.

8. An electronic device, characterized in that, include: A memory and a processor are interconnected, the memory stores computer instructions, and the processor executes the computer instructions to perform the hot-swappable bus communication networking method for robot swarms as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the hot-swappable bus communication networking method for robot swarms as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes computer instructions for causing a computer to execute any one of claims 1 to 6 of the hot-swappable bus communication networking method applied to robot swarms.

Images