Robot cluster control method and system and storage medium

Abstract

The invention relates to a robot control technology, and discloses a robot cluster control method and system and a storage medium, and the method comprises the steps: receiving motion state data, network link state data and service type information of each robot; predicting a motion track of each robot in a future preset time period based on the motion state data in combination with a digital map, and predicting a communication quality change trend of a current network link of each robot in the future preset time period based on the network link state data; determining a target network link of each robot based on the motion trail, the communication quality change trend, the digital map, the service type information and the received node operation state information of each edge relay node, and generating a network switching instruction containing the target network link and the switching opportunity, and the corresponding robot executes network link switching according to the network switching instruction. According to the invention, global prediction and active switching of robot cluster communication can be realized.

Description

Technical Field

[0001] This application relates to the field of robot control technology, and in particular to a robot swarm control method, system and storage medium. Background Technology

[0002] In robot swarm control systems, especially in wide-area deployment scenarios (such as park inspections, theme park performances, and urban services), robot swarms need to maintain stable communication with the control center during dynamic movement to achieve real-time command issuance, continuous status feedback, and multi-robot collaborative control. However, existing swarm communication mechanisms generally suffer from the following key problems: First, communication link switching strategies are lagging and isolated. Traditional solutions often rely on a single threshold judgment based on signal strength index (RSSI) at the terminal for link switching, lacking a comprehensive evaluation of multi-dimensional network quality indicators and failing to make forward-looking judgments based on robot movement trends. This leads to delayed switching decisions, easily causing service interruptions or video stuttering. Second, there is a lack of predictive and global coordination capabilities. Existing systems typically adopt a distributed or semi-centralized architecture, with link management autonomously completed by the terminal. The cloud cannot grasp the global network status and robot movement status, making cross-node resource coordination difficult. When multiple robots simultaneously enter the coverage area of ​​the same edge relay node, access congestion can easily occur, affecting overall communication quality. Summary of the Invention

[0003] In view of this, embodiments of this application provide a robot swarm control method, system, and computer-readable storage medium.

[0004] In a first aspect, embodiments of this application provide a robot swarm control method, applied to a cloud server, comprising: Receive motion status data, network link status data, and service type information from each robot; Based on the motion state data and digital map, the motion trajectory of each robot in the future preset time period is predicted, and based on the network link status data, the communication quality change trend of the current network link of each robot in the future preset time period is predicted. Based on the motion trajectory, the communication quality change trend, the digital map, the service type information, and the node operation status information of each edge relay node received, the target network link of each robot is determined, and a network switching instruction containing the target network link and the switching timing is generated, so that the corresponding robot can perform network link switching according to the network switching instruction.

[0005] In an optional implementation, determining the target network link for each robot based on the motion trajectory, the communication quality change trend, the digital map, the service type information, and the received node operating status information of each edge relay node includes: Based on the motion trajectory and the digital map, the target area to be reached by each robot within the preset future time period is determined, and at least one candidate edge relay node covering the target area is identified; wherein, the digital map includes the deployment location of the edge relay node and the signal coverage range of each edge relay node; Based on the communication quality change trend, the operating status information of each candidate edge relay node, and the service type information, the target edge relay node is determined from all the candidate edge relay nodes to serve as the target network link.

[0006] In an optional implementation, determining the target edge relay node from the candidate edge relay nodes based on the communication quality change trend, the operating status information of each candidate edge relay node, and the service type information includes: If, based on the communication quality change trend, it is determined that the communication quality of the robot's current network link does not meet the service requirements within the preset future time, then all the candidate edge relay nodes are sorted according to priority based on the running status information of each candidate edge relay node and the service type information. Based on the ranking results and the access load of the candidate edge relay nodes, the target edge relay node is determined.

[0007] In an optional implementation, the switching timing includes: a preset time point before it is predicted that the communication quality of the current edge relay node's network link cannot meet service requirements, or the preset time point before performing network link switching.

[0008] In an optional implementation, the method further includes: when the robot is detected to have entered an area without edge relay node coverage, issuing a self-organizing network configuration policy to the current robot, instructing the current robot to establish a self-organizing network with neighboring robots; wherein the communication link of the self-organizing network is executed according to a centralized policy issued by the cloud, and is used to maintain the communication connection with the cloud.

[0009] In an optional implementation, the method further includes: when sending control instruction frames containing action execution timestamps to each of the robots, compensating for the instruction issuance time based on the predicted communication delay from the cloud server to the robots, so that each of the robots receives the control instruction at the expected unified time point.

[0010] In an optional implementation, obtaining the predicted communication latency from the cloud server to the robot includes: The communication latency is determined based on the network performance digital profile, the robot's location information, and a prediction model; wherein the network performance digital profile is constructed based on historical communication latency data and the robot's geographical location information.

[0011] In an optional implementation, it further includes: During non-task periods, the robot's communication module is put into a deep sleep mode. When an abnormal event is detected, the communication module is woken up by a hardware interrupt signal and the abnormal status information is reported to the cloud server.

[0012] Secondly, embodiments of this application provide a robot swarm control system, including: a cloud server, at least one edge relay node, and at least one robot; Each of the robots is used to collect its own motion status data, network link status data, and service type information, and transmit them to the cloud server; The cloud server is used to receive motion status data, network link status data and service type information collected by each robot; The cloud server is also used to predict the motion trajectory of each robot within a future preset time period based on the motion state data and digital map, and to predict the communication quality change trend of the current network link of each robot within a future preset time period based on the network link status data. The edge relay node is used to collect its own operating status information and upload it to the cloud server; The cloud server is also used to determine the target network link for each robot based on the motion trajectory, the communication quality change trend, the digital map, the service type information, and the node operation status information of each edge relay node received, and to generate a network switching instruction containing the target network link and the switching timing, so that the corresponding robot can perform network link switching according to the network switching instruction.

[0013] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed on a processor, implements the aforementioned robot swarm control method.

[0014] The embodiments of this application have the following beneficial effects: By centrally receiving motion state data, network link status data, and service type information of each robot on a cloud server, and combining this with digital maps to jointly predict the future motion trajectory of the robots and the communication quality change trend of the current network link, this application achieves global perception and forward-looking judgment of the communication status of robot clusters in a wide-area environment. Based on this, by comprehensively considering motion trends, network conditions, geographical environment, and the operating status of edge relay nodes, the target network link for each robot is determined, and a network switching command containing the switching timing is generated, enabling the robot to proactively complete the link switching before communication quality deteriorates. Compared with the traditional reactive switching mechanism that relies on the robot's local signal strength, this avoids communication interruptions and control delays caused by sudden link changes, thereby improving the stable execution of multi-robot collaborative tasks in dynamic mobile scenarios. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram of a robot swarm control system according to an embodiment of this application is shown; Figure 2 A first flowchart of a robot swarm control method according to an embodiment of this application is shown; Figure 3 A second flowchart of the robot swarm control method according to an embodiment of this application is shown; Figure 4 The diagram illustrates the third process flow of the robot swarm control method according to an embodiment of this application. Detailed Implementation

[0017] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0018] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0021] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0022] In existing technologies, robot swarms typically rely on wireless communication technologies such as 4G / 5G, Wi-Fi, Bluetooth, ZigBee, or LoRa for remote control and status feedback. However, for scenarios requiring highly reliable communication and precise collaborative control of multi-robot systems in wide-area deployment environments, such as the fully automated roaming and interactive performances of biomimetic robot swarms like mechanical dinosaurs and robotic dogs in theme parks, science museums, or large commercial spaces—that is, when applied to complex scenarios involving large-scale, dynamic movement, and multiple robots operating in parallel—existing robot swarm control systems still have some shortcomings, such as unreliable communication, weak fault tolerance, and low synchronization accuracy.

[0023] First, regarding the reliability of wide-area communication, while traditional cellular networks offer the advantage of wide coverage, their uplink bandwidth is limited in high-density robot concurrent transmission scenarios, making it difficult to support high-definition video transmission or simultaneous multimodal command delivery. Meanwhile, short-range communication technologies such as Wi-Fi and Bluetooth have limited coverage, easily creating signal blind spots. Furthermore, during robot movement, factors such as building obstructions, terrain changes, or electromagnetic interference cause significant fluctuations in link quality, leading to data packet loss, latency jitter, and even connection interruptions, severely impacting control continuity.

[0024] Secondly, regarding system fault tolerance and self-healing capabilities, most systems employ a single primary link communication mode, lacking path redundancy mechanisms. Once the primary link fails, terminals often cannot switch to backup channels in a timely manner, leading to partial disconnection or even global loss of control. While some systems introduce Mobile Ad Hoc Networks (MANETs) as a supplement, their route reconstruction relies on distributed negotiation, resulting in slow convergence and disordered topology, easily causing network fragmentation and failing to meet real-time control requirements. Furthermore, terminals generally lack event-driven emergency response mechanisms, still relying on periodic reporting in the event of collisions, abnormal attitudes, or critical component failures, resulting in significant response delays.

[0025] Finally, regarding the synchronization accuracy of multi-machine collaboration, existing technologies mainly rely on general time synchronization protocols such as NTP or PTP. However, in wide-area heterogeneous network environments, due to uncertain end-to-end delays, large and asymmetrical jitter, it is difficult to achieve millisecond-level precise time synchronization. This directly leads to asynchronous execution of multiple robot actions, resulting in a "staggered" phenomenon, which seriously affects the naturalness and aesthetics of group behavior. Furthermore, existing synchronization mechanisms are mostly static calibrations, lacking the ability to dynamically adjust according to network conditions, task requirements, and environmental changes, and thus cannot adapt to complex and ever-changing actual operating conditions.

[0026] To address at least one of the aforementioned problems, this embodiment proposes a robot swarm control method, system, and storage medium for wide-area environments. This embodiment employs a hierarchical hybrid networking architecture of "cloud server—edge relay node—terminal robot," integrating motion state perception, digital map information, and multi-dimensional link quality monitoring to construct a predictive link management method led by the cloud server, thereby achieving intelligent selection and seamless switching of communication links.

[0027] The robot swarm control system of this embodiment will be described first below, such as... Figure 1 As shown, the system includes a cloud server 100, multiple edge relay nodes 200, and multiple robots 300.

[0028] The cloud server 100, serving as the system's global command center, is deployed in a remote data center. Its core functions include, but are not limited to, generating and issuing global task control commands, real-time monitoring and fusion processing of status information from each robot 300, formulating collaborative control strategies, and achieving synchronous coordination among multiple robots 300. The cloud server 100 communicates with each edge relay node 200 via a highly reliable, low-latency wide area network backbone link (such as fiber optic or 5G private network) to ensure the authority, consistency, and reliability of control commands.

[0029] Edge relay nodes 200 are pre-deployed fixed communication facilities, distributed in specific locations within the coverage area (such as existing infrastructure like streetlights and signal towers along park roads), forming fixed access anchors for the system. Each edge relay node 200 provides wireless access services, responsible for receiving uplink data from the robot 300 and forwarding it to the cloud server 100, while simultaneously sending control and switching commands from the cloud to the target robot 300. The stable communication backbone network formed by the edge relay nodes 200 effectively solves the signal blind spot problem caused by mobility in wide-area environments, and its static deployment characteristics ensure the long-term stability of the network topology.

[0030] As a mobile execution unit, robot 300 is equipped with a lightweight multi-mode communication module, which can collect its own motion status data, network link status data, and service type information, and upload the above data to cloud server 100. Under normal operation, robot 300 prioritizes accessing the nearest edge relay node 200 via wireless link to establish a communication connection with cloud server 100, and completes the reception of control commands and the transmission of status feedback.

[0031] When robot 300 is detected to have entered the area covered by edgeless relay node 200, cloud server 100 can issue an ad-hoc network configuration policy to robot 300, instructing it to establish an ad-hoc network with neighboring robots 300. The communication path of this ad-hoc network is executed according to the centralized policy issued by the cloud, which is used to maintain the communication connection with the cloud, realize the relay transmission of critical status information, and thus ensure the continuity of the control link.

[0032] Based on the above system, the following describes the robot swarm control method in conjunction with some specific embodiments.

[0033] Figure 2 A flowchart illustrating a robot swarm control method according to an embodiment of this application is shown. Exemplarily, this robot swarm control method is applied to a cloud server 100 and includes steps S210-S230: Step S210: Receive motion status data, network link status data, and service type information from each robot 300.

[0034] The motion state data can be collected by the sensors configured on each robot. This data includes, but is not limited to, robot 300's position, speed, acceleration, trajectory, posture, and motion mode. Specifically, the position information can be real-time coordinates used to determine the robot 300's specific location on a digital map, which can be obtained using the onboard GPS / BeiDou module sensors. The speed information (including magnitude and direction) is the robot 300's moving speed, which can be used to predict the robot 300's trajectory within a preset time period; this speed information can be collected by the robot 300's onboard inertial measurement unit (IMU). Acceleration information can also be collected by the robot 300's IMU for more accurate prediction of the robot 300's trajectory within a preset time period. The trajectory can be used to analyze the robot 300's motion mode (such as linear motion, turning, etc.), aiding in the prediction of the trajectory within a preset time period. Posture information, such as the robot 300's tilt angle and orientation, can be collected by the robot 300's IMU. Motion modes include walking, running, and stationary states.

[0035] Network link status data is collected locally by each robot 300 through its communication module, including at least one of the following: latency, jitter, packet loss rate, available bandwidth, and signal strength of the current connection link. The robot 300 measures link latency by sending probe messages and receiving responses, and calculates jitter and packet loss rate based on historical measurement sequences; simultaneously, it reads signal strength and channel quality information from the communication module register. The network link status data is encapsulated in status reporting messages and transmitted to the cloud server 100 along with the motion status data.

[0036] The business type information is determined by each robot 300 based on the currently executed task content and data transmission requirements, including at least one of control commands, status feedback, video streams, environmental perception, or emergency alarms. The robot 300 determines the current business type through task scheduling command parsing, application behavior recognition, or matching with a preset configuration table, and attaches this information as metadata to the status reporting message for the cloud server 100 to evaluate business matching priority during link decision-making.

[0037] Step S220: Based on motion state data and digital map, predict the motion trajectory of each robot 300 in the future preset time period, and based on network link status data, predict the communication quality change trend of the current network link of each robot 300 in the future preset time period.

[0038] The digital map is uniformly maintained and dynamically updated by the cloud server 100, and serves as the basic environmental data for predictive calculations. This digital map supports the determination of network coverage for the future location of the robot 300 and is one of the key inputs for predictive network link switching. The digital map includes, but is not limited to, the following information: the deployment location of the edge relay nodes 200 (the geographical coordinates of each edge relay node 200, such as latitude and longitude, used to determine its spatial distribution); the signal coverage range of each edge relay node 200 (preset or measured effective wireless signal coverage area, characterized as a circular or polygonal area centered on the node, used to determine whether a location is within the accessible range of a certain edge relay node 200); geographical information (including terrain features, such as slope and elevation, road paths, building outlines, and obstacle locations, used to constrain the feasible movement path of the robot 300 and affect the signal propagation model); and business-related area markings (pre-configured key functional area identifiers, such as performance areas, charging areas, signal blind spots, or interference-sensitive areas, used for priority scheduling or avoidance processing during link decision-making).

[0039] The cloud server 100 regularly receives configuration data, historical communication performance statistics, and environmental change notifications from the network operation and maintenance system through a centralized management platform. It then incrementally updates and manages the version of the digital map to ensure it reflects the current deployment status. During the prediction process, this digital map is used in conjunction with the motion status data reported by the robot 300 to infer its possible movement trajectory within a preset future time period and further assess the trend of network service quality changes in the areas traversed by that trajectory.

[0040] Specifically, the motion trajectory of each robot 300 within a preset future time period is predicted based on its reported motion state data and path constraint information from a digital map. The motion state data includes the robot 300's current position coordinates, speed, acceleration, and direction of motion. Based on these parameters, the cloud server 100 uses a linear extrapolation model or a multimodal motion prediction model to predict the robot 300's possible motion path within a future period.

[0041] The geographic information provided by the digital map is used to impose spatial path constraints, ensuring that the predicted trajectory conforms to a practically feasible route. For example, in areas with buildings or obstacles, the prediction model will exclude paths that cross restricted areas; in scenarios with only fixed roads, the prediction results will be limited to the road network. By fusing motion state and environmental constraints, the system can generate more accurate and physically consistent future trajectory predictions.

[0042] Meanwhile, the prediction of communication quality trends of each robot 300's current network links over a preset time period is based on historical sequences of periodically reported network link status data. This network link status data includes at least one of link latency, jitter, packet loss rate, and available bandwidth, forming a continuous time-series record.

[0043] The cloud server 100 utilizes time series forecasting models to analyze and model historical data. These models include, but are not limited to, Kalman filtering, ARIMA models, or machine learning-based regression algorithms. Through this model, the system predicts the changing trends of key communication indicators within a preset time period (e.g., 5 to 10 seconds), such as whether link latency will continue to rise, whether packet loss rate will exceed service thresholds, and whether signal strength will fall below access thresholds. These predictions serve as a crucial basis for subsequent link switching decisions, helping to identify potential communication quality degradation risks in advance.

[0044] Step S230: Based on the motion trajectory, communication quality change trend, digital map, service type information and the node operation status information of each edge relay node 200 received, determine the target network link of each robot 300, and generate a network switching instruction containing the target network link and the switching timing, so that the corresponding robot 300 can perform network link switching according to the network switching instruction.

[0045] In this step, the cloud server 100, based on the obtained motion trajectory prediction results, communication quality change trend prediction results, digital map, service type information, and the operating status information of each edge relay node 200, comprehensively decides the target network link of each robot 300, and generates a network switching instruction containing the target network link and the switching timing, so that the corresponding robot 300 can execute the network link switching according to the instruction to achieve a seamless transition in the communication process.

[0046] Exemplary, such as Figure 3 As shown, determining the target network link for each robot 300 based on motion trajectory, communication quality change trend, digital map, service type information, and node operation status information received from each edge relay node 200 includes steps S310-S320: Step S310: Based on the motion trajectory and digital map, determine the target area that each robot 300 will reach in a future preset time period, and determine at least one candidate edge relay node 200 covering the target area.

[0047] By example, the system identifies the geographic area that the robot 300 will enter or pass through in a future preset time period (e.g., 5-10 seconds) by overlaying and analyzing the predicted motion trajectory with a digital map, and further filters out one or more edge relay nodes 200 that can cover the target area as candidate edge relay nodes 200.

[0048] For example, if it is predicted that a robot 300 will move from the area currently covered by edge relay node 200 to an adjacent area in 8 seconds, and that area is within the signal coverage range of edge relay node 200, then edge relay node 200 will be included in the candidate list. When multiple accessible nodes exist (such as nodes B and C both partially covering the target area), all of them will be included in the candidate set for subsequent optimization decisions.

[0049] Step S320: Based on the communication quality change trend, the operating status information of each candidate edge relay node 200 and the service type information, determine the target edge relay node 200 from all candidate edge relay nodes 200 to serve as the target network link.

[0050] like Figure 4 As shown, step S320 specifically includes steps S410-S420: Step S410: If, based on the trend of communication quality changes, it is determined that the communication quality of the current network link of the robot 300 will not meet the business requirements within a preset time in the future, then all candidate edge relay nodes 200 are sorted according to priority based on the running status information and business type information of each candidate edge relay node 200.

[0051] Step S420: Based on the sorting results and the access load of the candidate edge relay nodes 200, determine the target edge relay node 200.

[0052] More specifically, if, based on the prediction result of step S220, it is determined that the communication quality of the network link currently connected to the robot 300 will deteriorate to the point of not meeting the current business requirements within a preset time (e.g., within 3 seconds) in the future (e.g., latency exceeding 100ms, packet loss rate exceeding 5%), then the link switching evaluation process is triggered.

[0053] Subsequently, the system prioritizes all candidate edge relay nodes 200 according to a preset strategy based on the operating status information of each candidate edge relay node 200 (including but not limited to backhaul link health, processing capacity, historical latency performance, etc.) and the service type information of the robot 300 (such as whether it is a high-priority control command, video stream transmission, etc.).

[0054] In some implementations, the priority ordering follows these principles: Same standard priority, that is, the edge relay node 200 with the same communication standard as the current link is selected first (such as 5G→5G) to reduce protocol adaptation overhead.

[0055] Prioritize service matching. For services requiring high bandwidth and low latency (such as video backhaul), prioritize candidate nodes that support high-speed communication standards and have a good historical performance. For low-power services (such as status reporting), prioritize low-power wide area network access nodes such as LoRa.

[0056] Prioritize path stability, which means excluding edge relay nodes 200 where the signal is easily blocked by combining the distribution of obstacles in the digital map.

[0057] It's understandable that when prioritizing tasks, factors like communication standards, service compatibility, and path stability can be ranked based on their importance, and then a specific priority order can be established. For example, when performing high-definition video transmission tasks, service compatibility has the highest weight, so 5G links with sufficient bandwidth are prioritized. In low-power inspection scenarios, the weights of path stability and load balancing can be increased, favoring the connection of edge nodes with lower loads. When the robot enters a signal-blocked area, the weight of path stability is increased to avoid areas affected by obstacles.

[0058] After prioritizing the candidate edge relay nodes 200, the system further adjusts the load balancing based on the access load of each candidate edge relay node 200 (such as the number of currently connected terminals and bandwidth utilization). For example, when multiple candidate nodes have similar performance, the one with the lower load is selected first to avoid local congestion caused by concentrated switching. Finally, considering the above multi-dimensional factors, the optimal candidate edge relay node 200 is determined as the target edge relay node 200 and designated as the target network link for the robot 300.

[0059] After identifying the target network link, the cloud server 100 further calculates the switching timing. Subsequently, the cloud server 100 generates a network switching instruction containing information such as the target network link identifier, switching timing, and access parameters, and sends it to the corresponding robot 300. Upon receiving the instruction, the robot 300 actively disconnects the original link and connects to the target edge relay node 200 at the specified time, completing the communication link switch. After the switch is completed, the robot 300 reports the switch status to the cloud for updating the network performance digital profile and model training.

[0060] It should be noted that the handover timing is not passively triggered after communication interruption or quality degradation, but rather actively set based on prediction results before communication quality significantly deteriorates, in order to reserve sufficient time for link negotiation and handover execution.

[0061] Specifically, the switching timing includes the following two scenarios: Scenario 1: A preset time point before it is predicted that the network link communication quality of the current edge relay node 200 cannot meet the business requirements.

[0062] Based on the prediction results of the current network link communication quality change trend in step S220, the cloud server 100 determines whether the link will be unable to meet the needs of the robot 300's current business type in the near future. For example, for high-priority control command business, the latency threshold is set to 100ms and the packet loss rate threshold is 5%; if the prediction model output shows that the latency of the current connection link will rise to 110ms in 3 seconds, or the packet loss rate will exceed 6%, then it is determined that it will soon fail to meet the business requirements.

[0063] Based on this, the system further determines a preset time point as the handover timing. This time point is located before the moment when communication quality deteriorates, and sufficient time window is reserved for the discovery, authentication, access, and parameter synchronization of the new link. In some implementations, the preset time window is 1-2 seconds, and the specific value can be dynamically adjusted according to the communication standard (e.g., 5G access is usually faster than LoRa), terminal processing capabilities, and historical handover times. For example, if it is predicted that the current link will start to fluctuate drastically at T=10:00:10.000, the handover timing is set to T=10:00:08.500 (1.5 seconds in advance) to ensure that the handover is completed before performance deteriorates.

[0064] Scenario 2: At a preset time point before the network link switch is performed.

[0065] When the system has identified the target network link and the handover triggering conditions are met, a pre-configured, fixed, or adaptively calculated time advance can be directly used as the execution time of the handover command.

[0066] This preset time point is obtained by the cloud server 100 based on statistical analysis of historical switching data. For example, by measuring the actual switching process of a large number of robots 300, the average link reconstruction time is found to be 1.2 seconds. Therefore, the switching timing is uniformly set to 1.2 seconds before the target action is executed or 1.2 seconds before the predicted disconnection.

[0067] In some implementations, the preset time point is not a fixed constant, but is dynamically adjusted according to factors such as the current wireless environment interference intensity, the access load of the target edge relay node 200, the capabilities of the robot 300 communication module (supporting multi-band concurrency, fast roaming, etc.), historical handover success rate and time consumption records, etc.

[0068] Through the switching method of this embodiment, robot 300 can complete the establishment of a new link while the existing link is still stable and available, avoiding the problem of data loss due to signal attenuation.

[0069] In some implementations, when robot 300 is detected to have entered an area covered by edgeless relay node 200, a self-organizing network configuration policy is issued to the current robot 300, instructing the current robot 300 to establish a self-organizing network with neighboring robots 300.

[0070] As an example, the cloud server 100 determines whether the robot 300 is about to enter or has already entered an area without the coverage of edge relay nodes 200 based on the predicted motion trajectory of the robot 300, its current location information, and the coverage area of ​​the preset edge relay nodes 200 in the digital map. For example, if the digital map shows that there are no edge relay nodes 200 deployed within 500 meters of the current location of the robot 300, and its movement trend does not deviate from this area, it is determined that it has entered a wide-area communication blind zone.

[0071] Once the above conditions are met, the cloud server 100 generates and sends a self-organizing network configuration policy instruction to the robot 300. This instruction includes, but is not limited to, whether to allow the start of the self-organizing network, neighbor communication parameters (such as operating frequency band, channel, power level), data forwarding rules (such as maximum hop count, routing protocol type), security authentication information (used for neighbor identity verification), and link management policies such as reporting frequency and sleep policies.

[0072] Upon receiving the instruction, the robot 300 switches its communication module to Ad-hoc mode and actively detects and connects to other nearby robots 300 according to the configuration strategy, forming a local ad-hoc network. During this process, the participating robots 300 interact with each other via direct wireless links (such as Wi-Fi Direct, ZigBee, or a dedicated LoRa Mesh) to achieve state sharing and relay transmission.

[0073] Furthermore, the communication links of the self-organizing network are not established by the terminals through autonomous negotiation in a traditional distributed structure, but are executed according to centralized policies issued by the cloud server 100. That is, although the connection between the physical layer and the link layer occurs between robots 300, key control decisions such as routing topology, path selection, and forwarding priority are all uniformly formulated by the cloud and distributed through policy instructions.

[0074] In some implementations, the cloud server 100 combines the real-time location, remaining battery power, communication quality, and task priority of all robots 300 to calculate the optimal data relay path. For example, a robot 300 that is close to the edge relay node 200, has sufficient battery power, and a stable link is selected as the relay forwarding node. Other blind spot robots 300 are then guided to transmit data hop-by-hop back to the nearest edge relay node 200 via this node, and finally to the cloud server 100.

[0075] In some implementations, to achieve high-precision collaborative control of multiple robots 300 in a wide area network environment, the system adopts a predictive instruction compensation mechanism to offset the problem of asynchronous actions caused by network latency. When sending control instruction frames containing action execution timestamps to each robot 300, the system compensates for the instruction issuance time based on the predicted communication latency between the cloud server 100 and the robot 300, so that each robot 300 receives the control instruction at the expected unified time.

[0076] The acquisition of the predicted communication latency from cloud server 100 to robot 300 includes: determining the communication latency based on the network performance digital profile and the location information of robot 300, combined with the prediction model; wherein the network performance digital profile is constructed based on historical communication latency data and the geographical location information of robot 300.

[0077] Specifically, when the cloud server 100 issues control commands to the robot 300, the control commands embed an action execution timestamp. This action execution timestamp is generated based on a high-precision global clock source (such as GPS / BeiDou time synchronization) accessed by the cloud server 100, serving as the absolute time reference for the entire cluster system, with an accuracy reaching milliseconds or even microseconds. For example, when all robots 300 need to... Simultaneously, when the queuing start action is executed, the timestamp is embedded in each control command frame issued to the participating robot 300.

[0078] Because actual communication links have non-negligible transmission delays, if we follow... When commands are issued in real time, the robot 300 terminal will receive them with a lag, resulting in coordination deviations. To address this, the system introduces a predictive delay compensation mechanism, the core of which lies in accurately estimating the future communication delay from the cloud server 100 to the target robot 300.

[0079] The predicted communication latency is obtained as follows: First, the cloud server 100 continuously collects the status messages returned by each robot 300 and extracts two key time parameters from them: That is, the locally generated timestamp carried in the status message is obtained by the robot 300 recording the message generation time on its local clock; This refers to the current global time at which the cloud receives the message, recorded by a high-precision clock in the cloud. This indicates the uplink communication delay. This value reflects the time taken for data transmission from robot 300 to cloud server 100.

[0080] Furthermore, the system assumes that under the same region and similar network conditions, the uplink and downlink have approximately symmetry, therefore it can... This serves as a solid foundation for estimating downlink (cloud → robot 300) latency. Subsequently, combining historical communication latency data and the geographic location information of the target robot 300, a comprehensive digital profile of network performance is constructed. This profile, organized by geographic grid, records average latency, jitter, packet loss rate, and other metrics for different locations at different times, forming a dynamically updated communication quality heatmap. Based on this, using the digital profile of network performance, the current location information of robot 300, and its motion state (such as speed and direction), a predictive model is used to predict future end-to-end communication latency trends.

[0081] The prediction model can be a Kalman filter, an ARIMA time series model, or a machine learning-based regression algorithm. Model inputs include current and historical data. By combining environmental information such as the sequence of events, historical network performance data of the area (from digital profiling), motion trajectory prediction results, and signal blind spot markers in the digital map, a predicted communication delay value for a future time can be output. In determining Subsequently, the cloud server 100 compensates for the timing of control command issuance: it no longer... Instead of sending instructions at any time, instructions should be sent in advance. Time of issuance. That is, the actual issuance time is... .

[0082] For cluster tasks consisting of multiple robots (300 in total), the system can predict the performance of each terminal separately. It also adjusts the timing of its command issuance to ensure that all 300 robots complete their action responses at the same absolute time point, achieving millisecond-level collaborative precision.

[0083] In some implementations, to reduce power consumption and extend battery life, the robot 300 enters an energy-saving mode during non-task periods, controlling its communication module to enter a deep sleep state, reducing the overall power consumption to approximately 10mA, and only keeping a low-power timer running to support periodic wake-ups. For example, it briefly wakes up every 30 seconds to listen for control commands from the cloud server 100, enabling remote standby response. When the robot 300 enters the task execution phase, the wake-up frequency of the communication module is dynamically adjusted according to the complexity of the action: for example, it can be set to wake up once every 500ms in the normal inspection mode, and shortened to once every 100ms in the performance mode with high coordination requirements, ensuring real-time command reception. In addition, when the local sensors detect abnormal events (such as collisions, tipping over, or failure of critical components), the communication module in sleep mode is immediately woken up by a hardware interrupt signal, without waiting for the timer cycle, thereby enabling communication to start within milliseconds and quickly reporting abnormal status information to the cloud server 100 to ensure system security and emergency response capabilities.

[0084] This embodiment constructs a hierarchical hybrid networking architecture consisting of a cloud-based central control unit (cloud server), an edge relay node 200, and a controlled terminal (corresponding to the robot 300). By integrating motion state perception and digital map information, it achieves joint prediction of communication link quality change trends and the future position of the robot 300. This supports intelligent link decision-making and predictive seamless switching based on multi-dimensional factors, effectively solving the communication interruption and service delay problems caused by link mutations in traditional systems.

[0085] This application also provides a computer-readable storage medium for storing the computer program used in the cloud server 100 described above. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0086] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0087] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0088] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0089] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A robot swarm control method, characterized in that, Applications to cloud servers include: Receive motion status data, network link status data, and service type information from each robot; Based on the motion state data and digital map, the motion trajectory of each robot in the future preset time period is predicted, and based on the network link status data, the communication quality change trend of the current network link of each robot in the future preset time period is predicted. Based on the motion trajectory, the communication quality change trend, the digital map, the service type information, and the node operation status information of each edge relay node received, the target network link of each robot is determined, and a network switching instruction containing the target network link and the switching timing is generated, so that the corresponding robot can perform network link switching according to the network switching instruction.

2. The robot swarm control method according to claim 1, characterized in that, The process of determining the target network link for each robot based on the motion trajectory, the communication quality change trend, the digital map, the service type information, and the node operation status information of each edge relay node received includes: Based on the motion trajectory and the digital map, the target area to be reached by each robot within the preset future time period is determined, and at least one candidate edge relay node covering the target area is identified; wherein, the digital map includes the deployment location of the edge relay node and the signal coverage range of each edge relay node; Based on the communication quality change trend, the operating status information of each candidate edge relay node, and the service type information, a target edge relay node is determined from all the candidate edge relay nodes to serve as the target network link.

3. The robot swarm control method according to claim 2, characterized in that, The step of determining the target edge relay node from the candidate edge relay nodes based on the communication quality change trend, the operating status information of each candidate edge relay node, and the service type information includes: If, based on the communication quality change trend, it is determined that the communication quality of the robot's current network link does not meet the service requirements within the preset future time, then all the candidate edge relay nodes are sorted according to priority based on the running status information of each candidate edge relay node and the service type information. Based on the ranking results and the access load of the candidate edge relay nodes, the target edge relay node is determined.

4. The robot swarm control method according to claim 1, characterized in that, The switching timing includes: a preset time point before it is predicted that the communication quality of the current edge relay node's network link cannot meet the service requirements, or the preset time point before performing network link switching.

5. The robot swarm control method according to claim 1, characterized in that, Also includes: When the robot is detected to have entered an area without edge relay node coverage, a self-organizing network configuration policy is issued to the current robot, instructing the current robot to establish a self-organizing network with neighboring robots; wherein, the communication link of the self-organizing network is executed according to a centralized policy issued by the cloud, which is used to maintain the communication connection with the cloud.

6. The robot swarm control method according to claim 1, characterized in that, Also includes: When sending control command frames containing action execution timestamps to each of the robots, the command issuance time is compensated according to the predicted communication delay from the cloud server to the robots, so that each of the robots receives the control command at the expected unified time point.

7. The robot swarm control method according to claim 6, characterized in that, The acquisition of the predicted communication latency from the cloud server to the robot includes: The communication latency is determined based on the network performance digital profile, the robot's location information, and a prediction model; wherein the network performance digital profile is constructed based on historical communication latency data and the robot's geographical location information.

8. The robot swarm control method according to claim 1, characterized in that, Also includes: During non-task periods, the robot's communication module is put into a deep sleep mode. When an abnormal event is detected, the communication module is woken up by a hardware interrupt signal and the abnormal status information is reported to the cloud server.

9. A robot swarm control system, characterized in that, include: A cloud server, at least one edge relay node, and at least one robot; Each of the robots is used to collect its own motion status data, network link status data, and service type information, and transmit them to the cloud server; The cloud server is used to receive motion status data, network link status data and service type information collected by each robot; The cloud server is also used to predict the motion trajectory of each robot within a future preset time period based on the motion state data and digital map, and to predict the communication quality change trend of the current network link of each robot within a future preset time period based on the network link status data. The edge relay node is used to collect its own operating status information and upload it to the cloud server; The cloud server is also used to determine the target network link for each robot based on the motion trajectory, the communication quality change trend, the digital map, the service type information, and the node operation status information of each edge relay node received, and to generate a network switching instruction containing the target network link and the switching timing, so that the corresponding robot can perform network link switching according to the network switching instruction.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed on a processor, implements the robot swarm control method according to any one of claims 1-8.

Images