Robotic crowd control system and method

Abstract

This specification provides a robot swarm control system and method. The robot swarm control system includes a swarm controller and multiple robots. When a target robot among the multiple robots forms a temporary wired communication link with the swarm controller via a physical connection interface, it reads the controller identification information corresponding to the swarm controller and establishes a communication identity binding relationship with the swarm controller based on the controller identification information. A wireless channel for bidirectional communication with the swarm controller is established based on the communication identity binding relationship. The wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band. When the swarm controller establishes wireless channels with each of the multiple robots, it responds to robot control operations by sending control commands to each robot through the wireless channels established with each robot. The target robot verifies the control commands through a hardware protocol layer. If the verification passes, it executes the motion task associated with the control commands.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of robot control technology, and in particular to robot swarm control systems and methods. Background Technology

[0002] With the rapid development of automation technology, multi-robot collaborative operations have been widely used in industrial manufacturing, warehousing and logistics, and special detection. In these applications, a central control unit is typically required to simultaneously issue commands and monitor the status of multiple mobile robots to achieve functions such as formation movement, collaborative handling, or distributed detection. Existing robot swarm control solutions mainly rely on wireless communication technology to establish connections between the controller and the robots, with Wi-Fi-based networking being widely adopted due to its high bandwidth and widespread availability. In this type of existing technology, the swarm controller searches for and identifies robot devices within range via a wireless network, establishes a TCP / IP or UDP communication link, and then sends motion control commands via broadcast or unicast. The robots receive the commands, parse them, and execute the corresponding actions, while simultaneously using the same wireless link to feedback their own status information. However, in existing technologies, when the operating environment has complex electromagnetic interference or multiple wireless signal sources, communication links based on general wireless frequency bands are prone to signal instability, data packet loss, or increased latency, leading to decreased synchronization of the swarm control system and even causing robot malfunctions or communication interruptions. Therefore, an effective solution is urgently needed to address these problems. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a robot swarm control system. One or more embodiments of this specification also relate to a robot swarm control method, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a robot swarm control system is provided, including a swarm controller and multiple robots; The target robot among the plurality of robots is configured to, when the swarm controller and the target robot form a temporary wired communication link through a physical connection interface, read the controller identification information corresponding to the swarm controller and establish a communication identity binding relationship with the swarm controller based on the controller identification information; and establish a wireless channel for bidirectional communication with the swarm controller based on the communication identity binding relationship, wherein the wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band; The swarm controller is configured to, in response to robot control operations, send control commands to each robot via the separately established wireless channels with the plurality of robots, when a wireless channel has been established with each of the plurality of robots. The target robot is configured to verify the control commands through a hardware protocol layer; if the verification passes, it executes a motion task associated with the control commands.

[0005] According to a second aspect of the embodiments of this specification, a robot swarm control method is provided, applied to a robot control system, the robot control system including a swarm controller and multiple robots, including: When the target robot among the plurality of robots determines that the swarm controller and the target robot form a temporary wired communication link through a physical connection interface, it reads the controller identification information corresponding to the swarm controller and establishes a communication identity binding relationship with the swarm controller based on the controller identification information; and establishes a wireless channel for bidirectional communication with the swarm controller based on the communication identity binding relationship, wherein the wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band; When the group controller determines that it has established wireless channels with the multiple robots, it sends control commands to each robot through the wireless channels established with the multiple robots in response to robot control operations. The target robot verifies the control commands through a hardware protocol layer; if the verification passes, it executes the motion task associated with the control commands.

[0006] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the above-described robot swarm control method are implemented.

[0007] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the robot swarm control method described above.

[0008] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described robot swarm control method.

[0009] The robot swarm control system provided in this embodiment establishes a temporary wired communication link through a physical connection interface, allowing the target robot to directly read the controller identification information of the swarm controller while in physical contact, thereby quickly establishing a communication identity binding relationship without the need for wireless searching. Based on this binding relationship, the system utilizes an RF communication chip to construct a bidirectional wireless channel in a specific target frequency band, through which the swarm controller then sends control commands to the multiple bound robots. During this process, the target robot rigorously verifies the received control commands through a hardware protocol layer, executing the corresponding motion task only when the verification passes. This method of establishing identity binding through physical connection combined with wireless transmission in a specific frequency band effectively avoids signal search interference and uncertainty in the traditional wireless pairing process, thus effectively solving the problems of communication instability and packet loss in complex electromagnetic environments. Furthermore, since the identity binding process relies on the triggering of the physical connection and subsequent communication undergoes multiple hardware-level verifications, the uniqueness of the source of control commands and the integrity of data are ensured, thereby improving the synchronization accuracy of multi-robot collaborative operations, the reliability of system operation, and the anti-interference capability in harsh environments such as industrial sites. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the structure of a robot swarm control system provided in one embodiment of this specification; Figure 2 This is a schematic diagram illustrating the connection between a robot and a swarm controller in a robot swarm control system according to one embodiment of this specification; Figure 3 This is a flowchart illustrating a robot swarm control method provided in one embodiment of this specification; Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0011] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0012] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0013] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0014] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0015] This specification provides a robot swarm control system. One or more embodiments of this specification also relate to a robot swarm control method, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0016] See Figure 1 , Figure 1 A schematic diagram of a robot swarm control system according to an embodiment of this specification is shown. The robot swarm control system 100 includes a swarm controller 110 and a plurality of robots 120. The target robot 120 among the plurality of robots is configured to, when the swarm controller and the target robot form a temporary wired communication link through a physical connection interface, read the controller identification information corresponding to the swarm controller and establish a communication identity binding relationship with the swarm controller based on the controller identification information; and establish a wireless channel for bidirectional communication with the swarm controller based on the communication identity binding relationship, wherein the wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band. The swarm controller 110 is configured to, in response to a robot control operation, send control commands to each robot via the wireless channels established with the plurality of robots, when a wireless channel has been established with each of the plurality of robots. The target robot 120 is configured to verify the control commands through a hardware protocol layer; if the verification passes, it executes the motion task associated with the control commands.

[0017] Specifically, a swarm controller can refer to a master control device used for centralized management, scheduling, and control of the motion states of multiple robots. In this application, the swarm controller is responsible for initiating communication pairing, broadcasting control commands, and receiving status feedback. It can connect to a host computer to obtain task sequences or independently run pre-stored control logic. The cooperative relationship between the swarm controller and multiple robots is manifested in the swarm controller acting as the master node of the communication link, responsible for establishing a wireless channel within the target frequency band and issuing commands to robots that have completed identity binding.

[0018] Multiple robots can refer to a collection of execution units uniformly scheduled by a swarm controller. The number of robots can be set according to the needs of the actual application scenario, for example, it could be two, ten, or more; this application embodiment does not impose any special limitation on this. Among the multiple robots, any robot currently pairing with the swarm controller or receiving control commands can be referred to as the target robot. The cooperation relationship between the target robot and the swarm controller is manifested in that the target robot first establishes a temporary wired communication link with the swarm controller through a physical connection interface to obtain unique controller identification information, and then switches to wireless mode, executing the corresponding motion task only after verifying the legitimacy of the command source.

[0019] The physical connection interface can refer to the hardware connection component used to establish a temporary wired communication link between the swarm controller and the target robot, such as... Figure 2 The schematic diagram shown illustrates that the specific implementation of the physical connection interface can be set according to actual conditions. For example, it can be a pluggable electrical connector, a magnetic contact interface, or a spring probe interface, etc. This application embodiment does not impose any special limitations on this. In this application solution, the physical connection interface is positioned to provide a highly reliable near-field communication path for securely and accurately transmitting the controller identification information of the swarm controller to the target robot before wireless communication is established. Its cooperation with the target robot is manifested in that when the physical connection interface is in the plugged state, an enable signal is triggered to conduct the data path, enabling the target robot to read the controller identification information; when the connection is disconnected, the link is terminated, thereby ensuring that the identification information is transmitted via wired means only at the moment of pairing, avoiding the risk of wireless leakage. At the same time, no searching or other operations are required, making the connection between the swarm controller and the robot faster and more stable.

[0020] The controller identification information can refer to a data code used to uniquely identify the group controller. The generation method of this controller identification information can be set according to actual conditions. For example, it can be a synchronization code generated based on the hardware unique identifier (such as UUID) of the microcontroller in the group controller after processing by a specific algorithm, or it can be a composite code including a check bit and a version number. This application embodiment does not impose any special limitations on this. In this application scheme, the functional positioning of the controller identification information is as the core basis for communication identity binding. Its cooperation relationship with the target robot is manifested in that after the target robot reads this information, it writes it into its local memory and locks it. Therefore, in subsequent wireless communication, only control commands carrying this specific identification information are recognized, realizing one-to-one or one-to-many identity binding.

[0021] The communication identity binding relationship refers to the logical association state established between the target robot and the swarm controller based on the controller's identification information. This binding relationship can be specifically represented by an identification mapping table stored in the target robot's local memory or by filtering rules configured in the RF communication chip registers; this application does not impose any special limitations on this. In this application, the function of the communication identity binding relationship is to establish the legal basis for wireless communication. Its cooperation with the wireless channel is manifested in the fact that only after a communication identity binding relationship is established will the target robot activate or maintain the wireless channel with the specific swarm controller; unbound robots will ignore signals emitted by that swarm controller.

[0022] A wireless channel can refer to a radio path for bidirectional data transmission between a swarm controller and a target robot. This wireless channel is constructed based on a radio frequency (RF) communication chip, and its operating frequency band is the target frequency band. The specific value of the target frequency band can be set according to actual conditions, such as the 433MHz ISM band, the 2.4GHz band, or other dedicated frequency bands with strong anti-interference capabilities. This application does not impose any special limitations on this. In this application, the wireless channel is positioned as a transmission medium carrying control commands and status data. Its cooperation with the RF communication chip is manifested in the RF communication chip modulating and demodulating signals to transmit and receive data within the specified target frequency band. The physical characteristics of this frequency band are utilized to avoid common interference sources such as Wi-Fi, ensuring the stability of the communication link.

[0023] A radio frequency (RF) communication chip can refer to an integrated circuit component integrated within a swarm controller and a target robot, used for wireless signal transmission and reception. The model of this RF communication chip can be set according to actual needs. The swarm controller and multiple robots can use the same model chip to ensure compatibility, or they can use chips compatible with different protocols but operating in the same frequency band. This application does not impose any special limitations on this. In this application, the RF communication chip functions as the executor of physical layer communication. Its cooperation with the hardware protocol layer is manifested in that the RF communication chip is responsible for the underlying signal processing, while the hardware protocol layer uses the chip's built-in filtering engine or register configuration to quickly verify the preamble, synchronization code, etc., of data packets.

[0024] Control commands can refer to data packets sent by the swarm controller to the target robot, instructing the robot to perform specific actions or change its operating state. The data structure of these control commands can be set according to actual conditions, and may include, for example, a header, length field, hardware type, protocol version, data payload, and checksum. This application embodiment does not impose any special limitations on this. In this application, the function of the control commands is to directly drive the robot's movement. Their cooperation with the hardware protocol layer is manifested in that before reaching the microcontroller, the control commands must first be verified by the hardware protocol layer. Only commands that pass verification will be parsed and converted into specific motion control signals.

[0025] The hardware protocol layer can refer to the protocol processing logic implemented based on the hardware characteristics of the radio frequency communication chip or the underlying firmware. The specific implementation location of this hardware protocol layer can be set according to actual conditions; for example, it can be the packet filtering engine built into the radio frequency communication chip, or it can be the underlying verification module in the microcontroller interrupt service routine. This application embodiment does not impose any special limitations on this. In this application scheme, the function of the hardware protocol layer is to quickly filter and verify the legitimacy of received wireless signals. Its cooperation with control commands is reflected in the hardware protocol layer extracting key fields (such as channel number, preamble, synchronization code, and receive code) from the control commands and comparing them with locally pre-stored information. If they match, the signal is allowed; if they do not match, they are discarded directly, thereby intercepting illegal or erroneous commands before the software application layer intervenes.

[0026] A motion task can refer to the specific physical actions or behavioral sequences performed by the target robot after receiving a legitimate control command. The specific content of the motion task can be set according to actual conditions, such as forward movement, backward movement, turning, grasping, releasing, or formation changing, etc., and this application embodiment does not impose any special limitations on this. In this application, the function of the motion task is positioned as the final execution output of the swarm control system. Its association with the control commands is reflected in the fact that the type, parameters, and execution sequence of the motion task are completely determined by the verified control commands, ensuring that the robot's actions are strictly consistent with the scheduling intent of the swarm controller.

[0027] Based on this, after the system is started, the operator connects the target robot to the swarm controller through the physical connection interface to form a temporary wired communication link. At this time, the target robot automatically reads the controller identification information of the swarm controller and establishes a communication identity binding relationship locally, and then disconnects the physical connection. The swarm controller and multiple bound robots establish wireless channels in the target frequency band respectively. When the swarm controller responds to the control operation and sends control commands, the hardware protocol layer of the target robot verifies the commands in real time. Only when the identity characteristics in the commands match the locally bound controller identification information will the corresponding motion task be executed, thereby realizing stable and safe multi-robot collaborative control.

[0028] For example, in a program scheduling scenario, one swarm controller and ten humanoid robots can be deployed. The swarm controller operates in the 433MHz ISM band. The operator holds the swarm controller and approaches each robot in turn, inserting the pluggable electrical connector on the swarm controller into the corresponding interface on the side of the robot. At the moment of insertion, the robot detects an enable signal, reads the synchronization code of the swarm controller (generated by the swarm controller MCU's UUID) via a wired link, writes the synchronization code into its own non-volatile memory, and simultaneously configures the synchronization code as the receive filtering condition of the RF communication chip. After pairing one robot, the operator disconnects the connection cable and repeats the above operation for the next robot until all ten robots are paired.

[0029] Subsequently, the operator can issue collective walking commands through the group controller. The group controller encapsulates the commands into data frames containing specific preambles, synchronization codes, and broadcast reception codes, and broadcasts them via a 433MHz wireless channel. Upon receiving the signal, the RF communication chips of the ten robots automatically compare the synchronization codes in the data frames with their locally stored synchronization codes. Since all ten robots have stored the same group controller synchronization code, the verification passes, and the data frames are uploaded to the microcontrollers of each robot, enabling the ten robots to move forward synchronously. If other Wi-Fi devices or 433MHz signals from outside the group control system are present in the environment, the robot's hardware protocol layer will discard these data packets without processing due to their mismatched synchronization codes, thus ensuring control accuracy and interference resistance.

[0030] In summary, by employing a physical connection interface for temporary wired communication to transmit controller identification information, potential signal search delays and mispairing issues during wireless pairing are avoided, significantly reducing connection complexity. Furthermore, the establishment of a communication identity binding relationship based on controller identification information, coupled with verification using a hardware protocol layer, effectively filters illegal commands, enhancing system security. Finally, the wireless channel, based on an RF communication chip and operating in a specific target frequency band (e.g., 433MHz), avoids congested Wi-Fi bands, thus maintaining communication link stability even in complex electromagnetic environments, reducing packet loss, and ensuring the reliability of multi-robot collaborative operations.

[0031] In one or more embodiments of this example, the physical connection interface is a pluggable electrical connector; in the plugged-in state, the target robot is also configured to read the controller identification information from the group controller and write the controller identification information into the local memory in response to the enable signal generated by the plugging operation; in the disconnected state, the local memory is changed to a write-protected state to lock the stored controller identification information.

[0032] Specifically, the physical connection interface can refer to a pluggable electrical connector, which can be any physical contact component capable of enabling temporary electrical conduction and signal transmission between the swarm controller and the target robot. In this application, the pluggable electrical connector not only establishes a temporary wired communication link for data transmission but also serves as a physical switch to trigger the identity binding process. When the user plugs in the male and female terminals of the pluggable electrical connector, in addition to forming an electrical path for the power ground and signal lines, an enable signal is generated due to the closure of the contacts or a change in the level of a specific pin. This enable signal serves as a hardware trigger condition for the system to enter configuration mode, directly linking the target robot's microcontroller to start the reading program. This ensures that the reading and writing of controller identification information is only allowed when the physical connection is definitively established, avoiding the risk of mispairing in a wireless environment.

[0033] An enable signal can refer to an electrical signal transition or level state directly triggered by a plugging operation, such as a high-level pulse, a low-level pull-down, or a specific interrupt request signal. The generation of this signal depends on the coordination between the mechanical structure and circuit design of the pluggable electrical connector. When the connector is fully inserted, the internal contacts close, causing the target robot's detection pins to detect a preset voltage, thereby generating the enable signal. In system linkage, this enable signal is sent to the target robot's processing unit as the sole key to initiating the read-write sequence. If this enable signal is not detected, even if other communication attempts occur, the target robot will not perform the action of reading identification information from the swarm controller, thus achieving physical-level operation authorization.

[0034] Local memory refers to a non-volatile storage medium located inside the target robot, used to persistently store controller identification information. It can be an EEPROM (Electrically Erasable Programmable Read-Only Memory), a memory area with a specific address range in Flash memory, or SRAM with write-protected registers, etc. In this embodiment, the local memory has two operating states: a writable state and a write-protected state. In the plugged-in state, in response to the aforementioned enable signal, the local memory temporarily releases write protection or enters the default writable mode, allowing controller identification information read from the swarm controller to be written into it; once the physical connection is broken, it enters the disconnected state, and the hardware circuitry or firmware logic automatically changes the local memory to the write-protected state. This state switching ensures that the stored controller identification information is permanently locked, preventing malicious wireless commands from tampering with, overwriting, or erasing it during subsequent wireless communication, thus guaranteeing the uniqueness and stability of the swarm control relationship.

[0035] Based on this, the user first physically connects the group controller to the target robot to be bound via a pluggable electrical connector. The mechanical action generated at the moment of connection triggers the generation of an enable signal. Upon detecting this enable signal, the target robot immediately initiates a read request to the group controller through the newly established temporary wired communication link to obtain the controller identification information. Subsequently, the target robot writes this identification information into its internal local memory. When the user completes the write operation and removes the pluggable electrical connector, the physical link is disconnected. The target robot detects the disconnection and immediately controls its local memory to enter write protection mode, locking the stored controller identification information. Afterward, the target robot only recognizes wireless signals matching the locked controller identification information, thus completing the identity binding of a single robot. By repeating the above pluggable operation, multiple robots can be bound to the same group controller in sequence.

[0036] For example, both the swarm controller and the target robot are equipped with matching Type-C interfaces as pluggable electrical connectors. When an operator inserts both ends of the connecting cable into the interfaces of the swarm controller and the target robot respectively, a read command can be sent to the swarm controller through the interface. The swarm controller returns a synchronization code generated by its UUID as the controller identification information. After receiving this synchronization code, the MCU writes it to a specific sector of its on-chip Flash memory. When the operator unplugs the connecting cable, the connection is broken, the voltage level goes low, and the MCU detects the falling edge of the voltage level. It immediately calls the memory management function to set the write-protect register of that Flash sector, preventing any subsequent write operations to that address until the next physical connection occurs.

[0037] In summary, the above processing ensures that the configuration of controller identification information requires manual physical intervention due to the use of pluggable electrical connectors and the generation of an enable signal during plugging to trigger the read and write process, thus avoiding the misconnection problem caused by automatic wireless search. Furthermore, by automatically changing the local memory to write-protected mode in the disconnected state, the stored controller identification information is effectively locked, preventing malicious tampering or accidental overwriting via the wireless channel during operation, thereby improving the security of the robot swarm control system and the reliability of the connection relationships.

[0038] In one or more embodiments of this example, the controller identification information includes a synchronization code and a receiving code; wherein, the synchronization code is determined by processing the hardware identifier corresponding to the microcontroller in the swarm controller, and is used to characterize the identity information of the swarm controller; the receiving code is determined by processing the hardware identifier corresponding to the microcontroller in the target robot, and is used to characterize the identity information of the target robot.

[0039] Specifically, the synchronization code can refer to a feature code generated based on the unique hardware identifier of the microcontroller within the swarm controller. This synchronization code serves to identify the swarm controller in the robot swarm control system. In specific implementations, the microcontrollers within the swarm controller can have a factory-preset globally unique identifier (UUID). The system generates a fixed-length synchronization code by performing hash operations, truncation, or encryption transformations on this hardware identifier. This synchronization code, in conjunction with the currently defined receiving code, constitutes the basic data for the communication identity binding relationship. During communication establishment, the target robot reads and stores this synchronization code, locking its receiving logic to the swarm controller that sent the specific synchronization code, thereby forming a logically exclusive connection path in the wireless channel. This ensures that only control commands carrying this synchronization code can be recognized and processed by the target robot. The specific generation algorithm, bit width, and encoding format of this synchronization code can be set according to actual conditions; for example, it can be a 4-byte value or a binary sequence of other lengths. This application embodiment does not impose any special limitations on this.

[0040] The receive code can refer to a feature code generated based on the unique hardware identifier of the microcontroller inside the target robot. This receive code serves to identify the target robot in the robot swarm control system. In specific implementations, each target robot's microcontroller can also have an independent unique hardware identifier, which the system uses to generate the receive code through a similar preprocessing procedure. This receive code is used to identify a specific robot in bidirectional communication. When the swarm controller needs to send instructions to a specific robot, it can fill the robot's receive code into the control instruction frame; when swarm control broadcasting is required, a preset broadcast code (such as a sequence of all 1s) can be used to replace the specific receive code. There is a linkage between the receive code and the aforementioned synchronization code: the synchronization code ensures the legitimacy of the instruction source (i.e., from the bound controller), while the receive code ensures the accuracy of the instruction destinations (i.e., sent to the bound robot or group). Through this dual-code mechanism, the system can maintain a logical identity binding state even after the physical connection is broken. The specific numerical range, generation method, and update strategy of the receive code can be set according to actual conditions. For example, it can be a fixed value statically written to memory, or a temporary value dynamically generated each time pairing occurs; this application embodiment does not impose any special limitations on this.

[0041] Based on this, during the establishment of a temporary wired communication link between the swarm controller and the target robot via a physical connection interface, the target robot first reads the synchronization code generated by the swarm controller's microcontroller and associates it with the receiving code generated by its own microcontroller, thus establishing a communication identity binding relationship. Subsequently, during the wireless communication phase, each frame of control command issued by the swarm controller carries the synchronization code and the target receiving code (or broadcast code). After receiving the wireless signal, the target robot's RF communication chip or hardware protocol layer first verifies whether the synchronization code in the signal matches the locally stored synchronization code to confirm whether the sending source is the bound swarm controller; if they match, it further verifies whether the receiving code matches the locally stored receiving code or the preset broadcast code. Only when both the synchronization code and the receiving code pass the dual verification will the target robot execute the corresponding motion task. This process utilizes the uniqueness of the microcontroller's hardware identifier, ensuring the exclusivity of the communication link from the source and avoiding interference or misoperation from other irrelevant signals in a complex electromagnetic environment.

[0042] For example, suppose the UUID of the microcontroller built into the swarm controller is A1B2C3D4..., and the UUID of the microcontroller built into the target robot is E5F6G7H8.... During the pairing phase, the target robot reads the UUID of the swarm controller through the wired interface, performs CRC8 checksum verification and shifting, and generates a synchronization code 0x12345678. Simultaneously, the target robot reads its own UUID, processes it using the same algorithm, and generates a receive code 0x87654321. The target robot writes 0x12345678 and 0x87654321 into its local non-volatile memory and locks them. In subsequent wireless operations, the header of the control command frame sent by the swarm controller contains the synchronization code 0x12345678 and the receive code 0x87654321. After receiving the signal, the target robot's hardware layer automatically compares the synchronization code to confirm the legitimate source, then compares the receive code to confirm the target is itself, and then demodulates the data packet and executes motion control. If another unpaired robot receives this signal at this time, it will discard the data packet directly because its locally stored synchronization code does not match, thus achieving precise group control management.

[0043] In summary, the above processing achieves the establishment of a hardware-unique two-way authentication mechanism between the swarm controller and the target robot by using the synchronization code and receiving code generated based on the microcontroller hardware identifier as the controller identification information. This solves the problem of misconnection or signal interference caused by the lack of effective identity verification in existing wireless swarm control systems, and achieves the technical effect of improving the exclusivity, security and anti-interference capability of communication connections.

[0044] In one or more embodiments of this example, the hardware protocol layer's verification of the control commands includes at least one of the following: Verify whether the channel number carried by the control command is the same as the channel number pre-stored by the target robot; Verify whether the control command contains a preamble that matches the group controller; Verify whether the control command contains a synchronization code that matches the group controller; Verify whether the received code carried by the control command is the same as the received code already stored by the target robot; Verify whether the received code carried by the control command is the same as the preset broadcast code stored in the target robot.

[0045] Specifically, verifying whether the channel number carried by the control command is the same as the channel number pre-stored in the target robot can mean that after receiving the radio frequency signal, the target robot first extracts the channel number parameter carried in the signal and compares it with the channel number pre-stored in its local memory. This channel number can be any integer value within the range of 0 to 255. The specific value can be set according to the electromagnetic interference conditions of the actual deployment environment; for example, it could be channel 10 or channel 200. This application embodiment does not impose any special limitations on this. This technical feature plays a role in physical-level communication isolation in the system linkage. Only when the received channel number is completely consistent with the pre-stored channel number will the target robot initiate the subsequent demodulation and parsing process; otherwise, the signal is directly discarded. Thus, isolation from unrelated devices operating on other frequencies or channels is achieved through channel matching, forming the first filtering barrier.

[0046] Verifying whether the control command contains a preamble that matches the swarm controller can refer to the target robot detecting whether the header of the received radio frequency data frame contains a specific preamble sequence. This preamble can be a fixed-length bit sequence used to characterize the signal format specific to this system. Its specific bit width and code pattern can be set according to the hardware characteristics of the radio frequency communication chip. For example, it can be the standard IEEE 802.15.4 preamble, or a custom alternating 0 / 1 sequence; this application embodiment does not impose any special limitations on this. This technical feature, in conjunction with channel number verification, is functionally used to quickly identify whether the signal source belongs to the scope of this system. If the preamble does not match, it indicates that the received signal may be other wireless noise in the environment or a signal from a device not belonging to this system. The target robot will stop receiving signals, thereby avoiding further processing of invalid data and saving hardware resources.

[0047] Verifying whether the control command contains a synchronization code matching the swarm controller can refer to whether the synchronization code field in the target robot's verification data frame matches the swarm controller's identity identifier. This synchronization code can be a unique value determined by hashing or mapping the hardware identifier (such as UUID) corresponding to the microcontroller in the swarm controller, used to characterize the swarm controller's identity information. The specific generation algorithm and length of the synchronization code can be set according to security requirements; for example, it can be a 4-byte random number or an 8-byte encrypted hash value. This application embodiment does not impose any special limitations on this. This technical feature plays a role in confirming the legitimacy of the source controller's identity in the overall technical solution. By echoing the communication identity binding relationship established in the preceding steps, it ensures that only commands issued by the bound specific swarm controller can be recognized, preventing the risk of unauthorized devices impersonating the controller to send commands.

[0048] Verifying whether the received code carried by the control command is the same as the received code already stored in the target robot can refer to the target robot comparing the received code field in the command with its locally stored self-identification identifier. This received code can be a unique value determined by processing the hardware identifier corresponding to the microcontroller in the target robot, used to characterize the target robot's identity information. The received code can be stored in non-volatile memory, and its value range can be set according to the system capacity; this application does not impose any special limitations on this. This technical feature, together with the synchronization code verification, constitutes a two-way authentication mechanism. Functionally, it is used to achieve precise addressing, ensuring that control commands are only executed by the designated target robot, avoiding erroneous actions by non-target robots in group control scenarios.

[0049] Verifying whether the received code carried in the control command is the same as the preset broadcast code stored in the target robot can refer to the target robot determining whether the received code in the command is a specific broadcast address value. This preset broadcast code can be a binary value consisting entirely of 1s (e.g., 0xFFFFFFFF), or it can be other specific reserved values ​​agreed upon by the system. The specific value can be set according to the protocol definition, and this application embodiment does not impose any special limitations on it. This technical feature provides group control compatibility in system linkage relationships. When the received code matches the preset broadcast code, all target robots that have completed identity binding determine that the verification has passed and execute the command, thereby realizing the task scenario where a single group controller simultaneously controls the synchronous movement of multiple robots, meeting the needs of large-scale cluster operations.

[0050] Based on this, the aforementioned verification processes can be automatically completed by the packet filtering engine built into the RF communication chip in the target robot after baseband signal demodulation and before transmission to the microcontroller, or they can be executed sequentially by the microcontroller after reading the raw data through software logic. In actual operation, these verification items can be used individually or in combination. For example, only the channel number and preamble can be verified to achieve low latency, or the channel number, preamble, synchronization code, and receive code can be verified simultaneously to achieve high security. The specific verification combination strategy can be flexibly configured according to the security level requirements of the application scenario. This multi-level verification mechanism constructs a robust command access defense line, filtering out unqualified signals at an early stage through step-by-step screening, ensuring the high reliability of the final executed control commands.

[0051] For example, before sending control commands to the target robot, the swarm controller constructs a data frame containing a header, length, hardware type, protocol version, and data payload. The frame is filled with the current operating channel number (e.g., 50), a fixed preamble, a synchronization code generated based on the swarm controller's UUID (e.g., 0xA1B2C3D4), and the target receive code (e.g., 0x12345678 for single-controller operation and 0xFFFFFFFF for swarm control). After the target robot's RF communication chip receives the RF signal in the 433MHz ISM band, it first checks at the hardware protocol layer whether the channel number is 50. If so, it checks if the preamble matches. If the preamble matches, it further compares the synchronization code to see if it is 0xA1B2C3D4. If the synchronization code matches, it finally checks if the receive code matches the locally stored 0x12345678 or if it is 0xFFFFFFFF. Only when all the selected verification items pass will the RF communication chip mark the data frame as valid and pass it to the microcontroller. The microcontroller then parses the data payload and executes the corresponding motion task. If any verification item fails, the data frame is directly discarded without generating any interruption or processing overhead.

[0052] In summary, the above processing achieves a multi-verification mechanism using channel number, preamble, synchronization code, and receiver code, which effectively filters out co-channel interference signals and forged instructions from unauthorized devices in the environment. This solves the technical problems of unstable connection and susceptibility to interference leading to malfunctions in complex electromagnetic environments, thereby improving the communication robustness and security of the robot swarm control system.

[0053] In one or more embodiments of this example, the processing of the hardware protocol layer to verify the control command is performed by the packet filtering engine built into the radio frequency communication chip, and is completed after the baseband signal is demodulated and before it is transmitted to the microcontroller.

[0054] Specifically, the hardware protocol layer's verification of control commands can refer to the process of validating the received wireless signal data packets based on the physical characteristics of radio frequency communication and preset protocol rules. In this application, this process ensures that only command data originating from a legitimate group controller and conforming to the current communication binding can enter the robot's core control system, thereby preventing malfunctions or malicious interference. This technical feature has a close working relationship with the aforementioned control commands and radio frequency communication chip: when the target robot receives an analog radio frequency signal through the wireless channel, the radio frequency communication chip first performs physical layer reception and preliminary processing, and then immediately triggers this verification mechanism. Its path is as a necessary checkpoint for data flow to the microcontroller. Through the above cooperation, the resulting working result is that data packets are only allowed to be transmitted upwards when the verification logic matches; otherwise, they are directly discarded at the chip's bottom layer. In specific implementation, the content of this verification process can be set according to actual conditions, for example, it can be one or more combinations of verification channel number, preamble, synchronization code, or receive code. This application embodiment does not impose any special limitations on this.

[0055] The packet filtering engine built into the RF communication chip can refer to a dedicated hardware logic circuit or firmware module integrated within the RF communication chip, specifically designed to perform high-speed packet filtering tasks. In this solution, this component is positioned to handle heavy protocol matching calculations, freeing up the main processor's resources. This technical feature, along with the hardware protocol layer's processing of control command verification, constitutes a cooperative relationship between the execution subject and the execution action: the packet filtering engine is configured to automatically run a preset filtering algorithm, independently completing the header information comparison of each arriving packet without microcontroller intervention. Its role in the overall technical solution is located at the end of the RF signal receiving link and the beginning of the digital interface output link. Through this cooperation, the resulting operation is to intercept packets that do not conform to preset protocol characteristics (such as incorrect synchronization codes or mismatched receive codes) within the chip, without generating interrupt requests to the upper layer. The specific architecture of this packet filtering engine can be set according to actual conditions; for example, it can be a hardware comparator array based on a state machine, or a filtering program executed based on microcode within the chip. This application embodiment does not impose any special limitations on this.

[0056] The period between baseband signal demodulation and transmission to the microcontroller can refer to a specific time window or logical stage in the data packet processing flow within the RF communication chip. This stage is defined as follows: the RF signal has completed the conversion from analog waveform to digital bitstream (i.e., demodulation), forming a complete data frame structure, but has not yet been sent to the robot's microcontroller via a physical interface (such as SPI or UART). This technical feature has a strict time-series coordination with the packet filtering engine and the microcontroller: the packet filtering engine is configured to start and perform verification operations precisely within this time window, i.e., comparing immediately after the data frame is assembled, and prohibiting data from being written to the transmit buffer leading to the microcontroller until the comparison result confirms its validity. Its functional role in the overall technical solution is to implement pre-filtering, ensuring that invalid data does not occupy the microcontroller's bus bandwidth and processing cycle. Through this coordination, the result is that the microcontroller only receives hardware-filtered, confirmed valid instruction data, avoiding system delays caused by processing a large number of invalid broadcast or interference signals. The specific criteria for determining this time window can be set according to the actual working mechanism of the chip model. For example, it can be after the demodulation module sends the frame end flag bit and before the DMA transfer starts. This application embodiment does not make any special limitations on this.

[0057] Based on this, when the target robot's RF communication chip receives RF signals in space, it first amplifies, mixes, and demodulates the signals to restore a digital data frame containing a packet header, synchronization code, receive code, and data payload. Then, before the data frame is sent to the microcontroller, the chip's built-in packet filtering engine automatically activates, extracting key protocol fields (such as the synchronization code and receive code) from the data frame and comparing them in real time with locally stored binding information. If the comparison shows that all check items match, the packet filtering engine marks the data frame as valid and allows it to be transmitted to the microcontroller via the internal bus. If any check item does not match, the packet filtering engine directly discards the data frame within the chip without generating any interrupt signal to notify the microcontroller, thus achieving hardware-level cleaning before data is uploaded to the main controller.

[0058] For example, in the actual operation of a robot swarm control system, the swarm controller sends control command data frames carrying specific synchronization and reception codes in the 433MHz frequency band. The target robot's RF communication chip continuously monitors this frequency band. Once the signal is captured and demodulated, its internal packet filtering engine immediately intervenes, without waiting for the microcontroller to wake up or schedule it. The engine first checks whether the channel number of the data frame matches the pre-stored channel, then verifies the preamble format, and then focuses on comparing whether the synchronization code matches the swarm controller's identity, and whether the reception code matches the locally stored binding code or broadcast code (0xFFFFFFFF). Only when all these checks pass, the chip sends the data packet containing the motion task instructions to the microcontroller through the SPI interface. The microcontroller then parses and executes the corresponding motion task. If the received signal is from another controller or environmental noise, the packet filtering engine will filter it out before the microcontroller detects its presence, ensuring that the robot only responds to the instructions of the authorized controller.

[0059] In summary, the above processing significantly reduces the computational burden on the microcontroller by offloading the verification process to the packet filtering engine of the RF communication chip, allowing it to focus more on the execution of motion control algorithms. Furthermore, by scheduling the verification after baseband demodulation and before transmission to the microcontroller, invalid data is intercepted at its source, preventing invalid data from occupying the system bus and triggering unnecessary interrupts. This improves the real-time response speed and operational stability of the group control system in complex electromagnetic environments.

[0060] In one or more embodiments of this example, the target frequency band is the 433MHz ISM band; wherein the swarm controller and the multiple robots use the same type of radio frequency communication chip, and both operate in the 433MHz ISM band.

[0061] Specifically, the target frequency band can refer to the specific range of radio frequencies used by the swarm controller to establish wireless channels between multiple robots. In the technical solution of this application, the target frequency band is limited to the 433MHz ISM (Industrial, Scientific, Medical) band. The 433MHz ISM band is an internationally widely open, unlicensed band with characteristics such as longer wavelength, strong diffraction capability, good penetration, and relatively low environmental background noise. Compared with the common 2.4GHz band (such as the densely used bands like Wi-Fi and Bluetooth), the 433MHz band can provide a more stable signal transmission path in complex electromagnetic environments such as industrial scenarios or applications with many obstacles, reducing packet loss caused by multipath effects or co-channel interference. The specific operating frequency point of the target frequency band can be set according to the actual situation, for example, it can be 433.92MHz or 433.05MHz, or any frequency point within the 433MHz ISM band range. This application embodiment does not make any special limitation on this. The target frequency band is directly associated with the aforementioned established wireless channel, which is carried on the target frequency band and used to transmit control commands and status data.

[0062] Radio frequency (RF) communication chips can refer to integrated circuit devices integrated within the swarm controller and the target robot, used to implement the modulation, demodulation, transmission, and reception functions of RF signals. In this application, it is required that the RF communication chips used by the swarm controller and multiple robots be of the same model. This means that the RF communication chip in the swarm controller and the RF communication chips in each robot have the same hardware architecture, the same register configuration definitions, the same modulation and demodulation algorithms, and the same RF front-end characteristics. Using the same model of RF communication chip ensures that the communicating parties maintain a high degree of consistency in carrier frequency accuracy, frequency offset tolerance, sensitivity, transmission power, and data packet format parsing logic, thereby eliminating communication compatibility issues caused by individual chip differences or different models. The specific model of the RF communication chip can be selected according to actual procurement conditions or performance requirements. For example, it can be a commonly used RF transceiver chip supporting the 433MHz frequency band, such as CC1101, Si4432, or RFM69. This application does not impose any special limitations on this. The radio frequency communication chip is physically connected to the swarm controller and the robot's microcontroller, and performs pre-verification processing through the hardware protocol layer. Its operating frequency band is configured to be locked within the aforementioned 433MHz ISM band.

[0063] Based on this, when the swarm controller needs to communicate with multiple robots, the RF communication chip in the swarm controller and the RF communication chips in each robot are initialized and configured to operate in the 433MHz ISM band. Because the same chip model is used, both sides can operate based on completely consistent hardware timing and signal processing mechanisms during RF handshake, preamble detection, synchronization code matching, and data frame demodulation. The RF signal emitted by the swarm controller propagates in the 433MHz band, utilizing the low frequency characteristics of this band to penetrate obstacles or bypass obstructions to reach the antenna of the target robot. After receiving the signal, the RF communication chip of the target robot quickly completes signal demodulation and hardware filtering based on the same chip architecture. It only reports to the microcontroller interrupt when the signal characteristics (such as channel, preamble, synchronization code, etc.) match the locally pre-stored information, thus achieving stable and reliable swarm control communication.

[0064] For example, in a specific robot swarm control application scenario, the swarm controller and all the robots to be controlled are equipped with a CC1101 RF transceiver chip. After the system powers on, the swarm controller sequentially binds itself to each robot through a physical connection interface and writes operating parameters into each robot's local memory. These operating parameters explicitly specify the communication frequency band as 433.92MHz. Subsequently, in a disconnected state, the swarm controller initiates a swarm control task, and its internal CC1101 chip modulates the control commands onto a 433.92MHz carrier wave for transmission. Multiple robots distributed in the surrounding environment, whose internal CC1101 chips are all in a listening state for this frequency band, receive the RF signal. When a robot receives the signal, its chip hardware automatically compares the preamble and synchronization code. After confirming that the signal originates from the bound swarm controller and that the frequency band is correct, it demodulates the data and transmits it to the robot's main control unit to execute the motion task. During this process, even with a large amount of 2.4GHz Wi-Fi signal interference in the surrounding area, the communication link remained stable due to the isolation of the operating frequency band and the matching of the chip models, which ensured the matching of filtering characteristics. No malfunctions or command loss occurred.

[0065] In summary, the postpartum care described above effectively avoids co-channel interference from congested frequency bands such as 2.4GHz by using the 433MHz ISM band as the target frequency. This band has stronger diffraction capabilities and lower environmental noise density compared to higher frequency bands, thus significantly improving the communication stability of the robot swarm control system in complex electromagnetic environments. Furthermore, the use of the same model of RF communication chip between the swarm controller and multiple robots ensures a high degree of consistency in physical layer parameters and protocol parsing logic between the communicating parties. This reduces the communication failure rate caused by hardware differences, simplifies system debugging and maintenance, and ultimately achieves efficient and reliable robot swarm control.

[0066] In one or more embodiments of this example, the group controller is connected to the host computer via a 3.3V TTL level UART interface; the baud rate of the UART interface is 921600bps, used to receive the group control task sequence from the host computer, and to upload the status data corresponding to the multiple robots to the host computer, the status data including battery level and / or signal strength RSSI.

[0067] Specifically, the host computer can refer to a computing device used to run the group control management software, such as a personal computer, industrial control computer, embedded gateway, or mobile terminal with data processing capabilities. This application embodiment does not impose any special limitations on this. The host computer plays a functional role in task planning and human-machine interaction within the overall technical solution. It establishes a physical connection with the group controller via a wired communication link, forming the starting point of a complete control link from user operation commands to robot action execution. The cooperative relationship between the host computer and the group controller is as follows: the host computer generates a group control task sequence containing motion trajectories, action timing, or formation logic, and sends it to the group controller via the UART interface; simultaneously, the group controller collects the real-time operating status of multiple robots and transmits it back to the host computer for display, recording, or further analysis and processing.

[0068] A 3.3V TTL level UART interface refers to a serial communication interface that uses the Universal Asynchronous Receiver / Transmitter (UART) protocol and conforms to the 3.3V Transistor-Transistor Logic (TTL) specification. This interface typically includes a transmitter (TX), a receiver (RX), and a common ground (GND) in its hardware connections, and may also include flow control signal lines if necessary. The use of 3.3V TTL level instead of 5V TTL level or other level standards (such as RS232) is to adapt to the operating voltage range of current mainstream microcontrollers and RF communication chips, reduce system power consumption, simplify circuit design, and avoid signal delays or noise interference introduced by additional level conversion circuits. As a data transmission channel between the group controller and the host computer, this interface is designed to achieve bidirectional, full-duplex serial data exchange, ensuring that the issuance of control commands and the uploading of status data can proceed synchronously without conflict.

[0069] A baud rate of 921600bps refers to the UART interface transmitting 921600 bits per second per unit time. This value falls under the category of high-speed serial communication. Compared to common low- or medium-speed baud rates such as 9600bps and 115200bps, the 921600bps setting significantly improves data throughput. In this application, the high baud rate is set to meet the real-time requirements of concurrent control scenarios for multiple robots: on the one hand, the group control task sequence may contain complex coordinate point data, attitude parameters, or timestamp information, resulting in a large data volume; a high baud rate can shorten the time for command issuance. On the other hand, if the status data (such as battery level, RSSI signal strength, etc.) reported by multiple robots simultaneously is aggregated and uploaded uniformly, the data traffic will increase linearly with the number of robots; a high baud rate can effectively prevent packet loss or delay caused by data backlog. The specific value of the baud rate can be adjusted according to the real-time requirements, the length of the transmission cable, and the assessment of anti-interference capability in the actual application scenario. For example, it can be 460800bps, 230400bps, or other supported standard baud rates. This application embodiment does not impose any special limitations on this, as long as it can meet the basic requirements of the system for data transmission rate.

[0070] A group control task sequence can refer to a set of structured control instructions generated by a host computer and sent to the group controller. This sequence defines the collaborative action logic of multiple robots in time and space, such as formation travel path points, synchronous start / stop commands, formation change commands, or specific action trigger signals. The data format of the task sequence can adopt a custom data frame structure, including a frame header, length field, instruction type, payload data, and checksum, to ensure reliable transmission. After receiving the sequence, the group controller parses and caches it, and then distributes it to each target robot according to a preset scheduling strategy or via a wireless channel. The method of generating the task sequence can be set according to actual conditions; for example, it can be generated manually by dragging and dropping based on a graphical interface, or it can be generated based on a path file automatically planned by an algorithm. This application embodiment does not impose any special limitations on this.

[0071] Status data refers to a collection of information reflecting the current operating status of a robot, playing a crucial role in the feedback loop of system linkage. Status data is collected from each robot via a wireless channel to the swarm controller, and then uploaded to the host computer via the UART interface, forming a closed-loop control loop of command issuance, execution, and status feedback. Specifically, battery power refers to the current remaining energy percentage or voltage value of the robot's internal power module, characterizing the robot's endurance. By monitoring battery power, the host computer can determine whether to trigger a return-to-home charging command or adjust the task allocation strategy to avoid task interruption due to battery depletion. Received Signal Strength Indicator (RSSI) refers to the signal quality index of the wireless communication link between the robot and the swarm controller, usually expressed in dBm. The RSSI value directly reflects the quality of the communication environment and the distance between the robot and the controller. By uploading RSSI in real time, the host computer can monitor the communication connection stability of each robot. When the RSSI of a robot is detected to be below a preset threshold, it can prompt the operator to intervene or automatically implement signal enhancement measures. In addition to battery level and RSSI, the status data can be expanded to include information such as motor temperature, fault codes, and current location coordinates, depending on actual needs. This application embodiment does not impose any special limitations on this.

[0072] Based on this, the host computer first establishes a physical connection with the swarm controller via a 3.3V TTL level UART interface, with both parties agreeing to communicate at a baud rate of 921600bps. After the user completes the editing or selection of swarm control tasks on the host computer, the host computer encodes the generated swarm control task sequence into a data stream conforming to the protocol format and continuously sends it to the receiver of the swarm controller via the UART interface's transmitter (TX). After receiving the data stream, the microcontroller inside the swarm controller unpacks, verifies, and parses it to extract valid control commands. Subsequently, the swarm controller broadcasts or unicasts these commands to each target robot through the established wireless channel. During execution, each target robot collects its own battery level and detects the RSSI signal strength for communication with the swarm controller in real time, encapsulates this status data, and sends it back to the swarm controller via the wireless channel. The swarm controller integrates and buffers the status data received from different robots, and then uploads it in batches to the host computer via the UART interface's transmitter at a high speed of 921600bps. The host computer parses the received status data and updates the battery level and signal strength of each robot in real time on the human-machine interface, thereby realizing the visual monitoring and dynamic management of the entire robot group.

[0073] For example, in a rehearsal scenario involving 10 robots, the host computer is an industrial panel PC running dedicated group control software. The operator uses this software to plan the movement paths of the 10 robots, generating a group control task sequence containing 500 path points. The industrial panel PC is connected to the UART interface of the group controller via a shielded twisted-pair cable, with communication parameters configured as follows: baud rate 921600bps, 8 data bits, 1 stop bit, no parity, and 3.3V TTL level. During the task sequence distribution process, due to the large data volume, the high baud rate ensures that all path points are transmitted and parsed and stored by the group controller within 200ms. Subsequently, the group controller sends a synchronization start command to the 10 robots via a 433MHz wireless channel. During operation, each robot reports a status data packet every 100ms, including its current battery level (e.g., 85%) and RSSI value (e.g., -65dBm). The group controller aggregates these 10 data streams and continuously pushes them to the host computer via the UART interface. The host software interface refreshes and displays the status panels of the 10 robots in real time. When the RSSI of robot number 3 drops to -85dBm, the system automatically pops up a weak signal warning and suggests that the operator check whether there are any obstructions or interference sources in the area.

[0074] In summary, the above processing achieves compatibility with mainstream embedded system hardware interface standards by adopting a 3.3V TTL level UART interface, reducing hardware adaptation difficulty and cost. The high baud rate of 921600bps ensures rapid distribution of numerous group control task sequences and real-time uploading of massive amounts of status data in multi-robot concurrent scenarios, avoiding management lag caused by communication bottlenecks. Furthermore, the transmission of key status data, including battery level and RSSI signal strength, allows the host computer to comprehensively monitor the operational health and communication quality of the robot group, achieving refined monitoring and intelligent management of the group control system, effectively improving system reliability and maintainability.

[0075] In one or more embodiments of this example, the group controller is further configured to perform data frame verification on the instruction data frame corresponding to the control instruction when sending control instructions to the plurality of robots; wherein the verification range of the data frame verification includes all bytes from the start byte of the packet header to the end byte of the data payload.

[0076] Specifically, data frame verification of the command data frame corresponding to the control command can refer to the group controller performing an integrity check on the command data packet to be sent before issuing motion tasks to the robot via the wireless channel. The function of this verification operation is to ensure the accuracy of transmitted data and prevent data bit flipping caused by wireless signal interference, noise coupling, or encoding errors. This verification operation works closely with the aforementioned step of sending control commands to each robot; that is, it intervenes after data encapsulation and before radio frequency transmission, serving as the final quality checkpoint at the sending end. Through this verification, the group controller can confirm that the command data frame to be sent is complete in terms of logical structure and content values, thereby increasing the reliability of the data received by the receiving robot.

[0077] The data frame verification scope includes all bytes from the start byte of the header to the end byte of the data payload. This means the sequence of bytes used in the verification algorithm (such as cyclic redundancy check, CRC) covers all payload portions of the data frame except for the check bit itself. Specifically, this scope begins with the header byte that identifies the start of the data frame (e.g., a specific ASCII character) and ends with the last byte of the data payload carrying specific motion parameters or control commands. This verification scope means that fields such as length, hardware type, and protocol version within the data frame are included in the calculation. This full-scope coverage ensures that single-bit or multi-bit errors at any point in the data frame can be detected. This verification scope is directly linked to the structural characteristics of the command data frame. By defining clear start and end boundaries, it ensures that both the swarm controller and the robot maintain a consistent understanding of the valid data, avoiding misjudgments or omissions caused by inconsistent verification scopes.

[0078] Based on this, when the swarm controller generates control commands in response to the user's robot control operations, it first assembles a command data frame according to a predetermined data protocol format. This frame includes a header, length information, hardware type, protocol version, and specific data payload. Subsequently, the swarm controller extracts all bytes of data from the first byte of the header to the last byte of the data payload and passes this as input parameters to the verification algorithm module (e.g., a CRC8 or CRC16 calculation unit). The calculated checksum is appended to the end of the data frame or inserted into a reserved position, forming the final complete data packet to be sent. Afterward, the swarm controller modulates this complete data packet and transmits it to the wireless channel via the RF communication chip. This process is executed automatically every time a control command is sent, constituting a data integrity guarantee mechanism at the transmitting end.

[0079] For example, after the swarm controller communicates with the host computer to obtain the swarm control task sequence, it parses the motion instructions for a specific robot. The swarm controller's microcontroller encapsulates this instruction into a data frame. Assuming the header is two bytes (BR), followed by a 2-byte length field, a 2-byte hardware type field, a 2-byte protocol version field, and an N-byte data payload field, the swarm controller initiates a verification procedure. It reads all data from byte 1 ('B') to byte (N+9) (the last bit of the data payload), performs modulo-2 division or a lookup table using a pre-built polynomial generator, and obtains a 1-byte checksum. This checksum is filled into the checksum field of the data frame. If an anomaly is detected in the original data during this process (though rare, it can be detected through internal bus verification), the swarm controller can regenerate the instruction or report an error. After encapsulation and checksum filling, the swarm controller transmits the data frame to the RF communication chip via the UART interface, which then transmits it to the 433MHz frequency band.

[0080] In summary, the above processing achieves full-range byte verification of the instruction data frame at the sending end, thereby locking the integrity of the data before it enters the wireless channel and effectively intercepting bad frames caused by internal processing errors or encapsulation failures. Since the verification range covers all critical information from the packet header to the data payload, it can keenly capture any bit errors that may occur on the transmission path. Combined with the hardware filtering mechanism at the receiving end, it forms end-to-end dual data security protection, significantly improving the communication reliability and instruction execution accuracy of the robot swarm control system in complex electromagnetic environments.

[0081] Corresponding to the above method embodiments, this specification also provides embodiments of robot swarm control methods. Figure 3 A flowchart of a robot swarm control method according to an embodiment of this specification is shown. The method is applied to a robot control system, which includes a swarm controller and multiple robots, and specifically includes the following steps.

[0082] In step S302, when the target robot among the plurality of robots determines that the swarm controller and the target robot form a temporary wired communication link through a physical connection interface, it reads the controller identification information corresponding to the swarm controller and establishes a communication identity binding relationship with the swarm controller based on the controller identification information; and establishes a wireless channel for bidirectional communication with the swarm controller based on the communication identity binding relationship, wherein the wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band. In step S304, when the group controller determines that it has established wireless channels with the multiple robots respectively, it sends control commands to each robot through the wireless channels established with the multiple robots in response to robot control operations. In step S306, the target robot verifies the control command through the hardware protocol layer; if the verification passes, it executes the motion task associated with the control command.

[0083] In an optional embodiment, the physical connection interface is a pluggable electrical connector; in the plugged-in state, the target robot is also configured to read the controller identification information from the swarm controller and write the controller identification information into local memory in response to an enable signal generated by the plugging operation; in the disconnected state, the local memory is changed to a write-protected state to lock the stored controller identification information.

[0084] In one optional embodiment, the controller identification information includes a synchronization code and a receiving code; wherein, the synchronization code is determined by processing the hardware identifier corresponding to the microcontroller in the swarm controller, and is used to characterize the identity information of the swarm controller; the receiving code is determined by processing the hardware identifier corresponding to the microcontroller in the target robot, and is used to characterize the identity information of the target robot.

[0085] In one optional embodiment, the hardware protocol layer's verification of the control commands includes at least one of the following: Verify whether the channel number carried by the control command is the same as the channel number pre-stored by the target robot; Verify whether the control command contains a preamble that matches the group controller; Verify whether the control command contains a synchronization code that matches the group controller; Verify whether the received code carried by the control command is the same as the received code already stored by the target robot; Verify whether the received code carried by the control command is the same as the preset broadcast code stored in the target robot.

[0086] In one optional embodiment, the processing of the control command verification by the hardware protocol layer is performed by the packet filtering engine built into the RF communication chip, and is completed after the baseband signal demodulation and before transmission to the microcontroller.

[0087] In one optional embodiment, the target frequency band is the 433MHz ISM band; wherein the swarm controller and the multiple robots use the same type of radio frequency communication chip, and all operate in the 433MHz ISM band.

[0088] In one optional embodiment, the swarm controller is connected to the host computer via a 3.3V TTL level UART interface; the baud rate of the UART interface is 921600bps, used to receive swarm control task sequences from the host computer, and to upload status data corresponding to the multiple robots to the host computer, the status data including battery level and / or signal strength RSSI.

[0089] In an optional embodiment, the group controller is further configured to perform data frame verification on the instruction data frame corresponding to the control instruction when sending control instructions to the plurality of robots; wherein the verification range of the data frame verification includes all bytes from the start byte of the packet header to the end byte of the data payload.

[0090] The above is an illustrative scheme of a robot swarm control method according to this embodiment. It should be noted that the technical solution of this robot swarm control method and the technical solution of the robot swarm control system described above belong to the same concept. For details not described in detail in the technical solution of the robot swarm control method, please refer to the description of the technical solution of the robot swarm control system described above.

[0091] Figure 4 A structural block diagram of a computing device 400 according to one embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0092] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0093] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0094] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 400 can also be a mobile or stationary server.

[0095] The processor 420 is used to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described robot swarm control method.

[0096] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the robot swarm control method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the robot swarm control method described above.

[0097] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described robot swarm control method.

[0098] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the robot swarm control method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the robot swarm control method described above.

[0099] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described robot swarm control method.

[0100] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the robot swarm control method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the robot swarm control method described above.

[0101] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0102] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0103] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0104] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0105] The preferred embodiments disclosed above are merely illustrative of this specification. Optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described in this specification. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification.

Claims

1. A robot swarm control system, characterized in that, Includes a swarm controller and multiple robots; The target robot among the plurality of robots is configured to, when the swarm controller and the target robot form a temporary wired communication link through a physical connection interface, read the controller identification information corresponding to the swarm controller and establish a communication identity binding relationship with the swarm controller based on the controller identification information; and establish a wireless channel for bidirectional communication with the swarm controller based on the communication identity binding relationship, wherein the wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band; The swarm controller is configured to, in response to robot control operations, send control commands to each robot via the separately established wireless channels with the plurality of robots, when a wireless channel has been established with each of the plurality of robots. The target robot is configured to verify the control commands through a hardware protocol layer; if the verification passes, it executes a motion task associated with the control commands.

2. The robot swarm control system according to claim 1, characterized in that, The physical connection interface is a pluggable electrical connector; in the plugged-in state, the target robot is also configured to read the controller identification information from the group controller and write the controller identification information into the local memory in response to the enable signal generated by the plugging operation; in the disconnected state, the local memory is changed to a write-protected state to lock the stored controller identification information.

3. The robot swarm control system according to claim 1, characterized in that, The controller identification information includes a synchronization code and a receiving code; wherein, the synchronization code is determined by processing the hardware identifier corresponding to the microcontroller in the swarm controller, and is used to characterize the identity information of the swarm controller; the receiving code is determined by processing the hardware identifier corresponding to the microcontroller in the target robot, and is used to characterize the identity information of the target robot.

4. The robot swarm control system according to claim 1, characterized in that, The hardware protocol layer's verification of the control commands includes at least one of the following: Verify whether the channel number carried by the control command is the same as the channel number pre-stored by the target robot; Verify whether the control command contains a preamble that matches the group controller; Verify whether the control command contains a synchronization code that matches the group controller; Verify whether the received code carried by the control command is the same as the received code already stored by the target robot; Verify whether the received code carried by the control command is the same as the preset broadcast code stored in the target robot.

5. The robot swarm control system according to claim 1 or 4, characterized in that, The hardware protocol layer performs verification of the control commands, which is executed by the packet filtering engine built into the RF communication chip, and is completed after the baseband signal is demodulated and before it is transmitted to the microcontroller.

6. The robot swarm control system according to claim 1, characterized in that, The target frequency band is the 433MHz ISM band; wherein, the swarm controller and the multiple robots use the same model of radio frequency communication chip, and all of them operate in the 433MHz ISM band.

7. The robot swarm control system according to any one of claims 1 to 4, characterized in that, The group controller is connected to the host computer via a 3.3V TTL level UART interface; the baud rate of the UART interface is 921600bps, used to receive the group control task sequence from the host computer, and to upload the status data corresponding to the multiple robots to the host computer, the status data including battery level and / or signal strength RSSI.

8. The robot swarm control system according to any one of claims 1 to 4, characterized in that, The group controller is further configured to perform data frame verification on the instruction data frame corresponding to the control instruction when sending control instructions to the plurality of robots; wherein the verification range of the data frame verification includes all bytes from the start byte of the packet header to the end byte of the data payload.

9. A method for controlling a robot swarm, characterized in that, This is applied to a robot control system, which includes a swarm controller and multiple robots, including: When the target robot among the plurality of robots determines that the swarm controller and the target robot form a temporary wired communication link through a physical connection interface, it reads the controller identification information corresponding to the swarm controller and establishes a communication identity binding relationship with the swarm controller based on the controller identification information; and establishes a wireless channel for bidirectional communication with the swarm controller based on the communication identity binding relationship, wherein the wireless channel is constructed based on a radio frequency communication chip and operates in the target frequency band; When the group controller determines that it has established wireless channels with the multiple robots, it sends control commands to each robot through the wireless channels established with the multiple robots in response to robot control operations. The target robot verifies the control commands through a hardware protocol layer; if the verification passes, it executes the motion task associated with the control commands.

10. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method of claim 9.

11. A computer-readable storage medium, characterized in that, It stores computer-executable instructions that, when executed by a processor, implement the steps of the method of claim 9.

12. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the steps of the method of claim 9.

Images