Multi-robot cluster scheduling and collaborative obstacle avoidance control method and system

Abstract

The invention provides a multi-robot cluster scheduling and collaborative obstacle avoidance control method and system, and belongs to the technical field of three-dimensional position and route control. The method is applied to a robot centralized control platform and comprises an initialization step, a scheduling step, a pass priority determination step and a cluster transfer step. The passing priority determination step comprises the following steps: when the two robots have a route collision risk, judging whether a cluster with empty robots exists or not; if yes, the robots from the larger cluster have the priority right, and the robots with the priority right are transferred to the cluster with empty robots; otherwise, the robots from the smaller cluster have the priority right and transfer the robots with the priority right to the larger cluster. According to the improved technical scheme provided by the invention, an'initialization-scheduling-collision judgment-adjustment 'closed loop is formed on the whole, the defects of global decision deficiency and insufficient dynamic adaptation in the prior art are efficiently overcome, and the operation efficiency and the operation safety are both considered.

Description

Multi-robot swarm scheduling and cooperative obstacle avoidance control methods and systems Technical Field

[0001] This invention relates to robot swarm scheduling, to the field of three-dimensional position and route control technology, and particularly to a method and system for multi-robot swarm scheduling and cooperative obstacle avoidance control. Background Technology

[0002] With the large-scale development of logistics warehousing, industrial manufacturing and other fields, collaborative operation of multi-robot swarms has become a core direction for improving efficiency. However, the surge in the number of robots and the increasing complexity of operating scenarios have made problems such as scheduling conflicts and obstacle avoidance failures more prominent, and existing technologies are unable to meet the dual requirements of "efficient collaboration + safe operation".

[0003] In existing technologies, Chinese invention patent application CN115963838A proposes a path planning method for logistics robot clusters, and Chinese authorized invention patent CN120319035B proposes a dynamic capability-based traffic control method for heterogeneous robots. These methods rely on the inherent capability types of robots for scheduling decisions, failing to consider dynamic changes in cluster size. When some robots malfunction, leading to a reduction in cluster size, fixed capability-based rules can cause an imbalance in priority passage, resulting in continuous waiting for small clusters and resource waste for large clusters. Furthermore, collision risk avoidance in these technologies relies solely on queuing avoidance and deadlock resolution, lacking a pre-emptive quantitative judgment mechanism. In high-density scenarios, avoidance delays or ineffective stagnation are still prone to occur, failing to reduce the probability of conflict at its root. In addition, existing technologies generally suffer from common shortcomings: either relying on local perception decisions leading to global conflicts, or using fixed priorities causing congestion and deadlocks. Neither forms a closed-loop logic of "scheduling-judgment-adjustment," making it difficult to adapt to dynamic operating environments. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention proposes a method and system for multi-robot cluster scheduling and collaborative obstacle avoidance control.

[0005] In a first aspect of the invention, a multi-robot swarm scheduling and cooperative obstacle avoidance control method is proposed. The method is applied to a centralized robot control platform and includes the following steps: S100: Initialize the robot swarm and its corresponding initial scheduling route; S200: Schedule the robots to travel from the starting point to the ending point along their respective initial scheduling routes, and then each robot returns from the ending point to the starting point after carrying a load; S300: When there is a risk of route collision between two robots from two different swarms, determine whether there is a swarm with an empty number of robots; if not, then select the smaller swarm from the two different swarms. If the robot in the group has priority passage, proceed to step S400; if so, the robot from the larger of the two different clusters has priority passage, proceed to step S500; S400: When the robot with the priority passage returns to the starting point, transfer the robot with the priority passage to the larger of the two different clusters; return to step S200; S500: When the robot with the priority passage returns to the starting point, transfer the robot with the priority passage to the cluster with an empty number of robots, return to step S200.

[0006] In step S100, each initialized robot cluster includes at least one robot, and each robot cluster corresponds to a different initial scheduling route; each scheduling route includes a start point and an end point. Multiple robots in the same cluster start from the same start point in a predetermined order, arrive at the same or different end points, and maintain the same travel speed; the initial scheduling routes of at least two clusters intersect.

[0007] Step S300 further includes: S301: Each robot collects its own three-dimensional coordinates, direction of travel, and instantaneous speed from other robots in the cluster in real time and uploads them to the robot centralized control platform; S302: Based on the collected parameters, the robot centralized control platform determines whether there is a risk of route collision between two robots from two different clusters.

[0008] In steps S400 / S500, after the robot transfer is completed, the robot centralized control platform immediately updates the number of robots in the two clusters involved in the transfer, and uses the updated number as the basis for judging the cluster size.

[0009] Specifically, in step S400, when the number of robots in the larger cluster exceeds three times that of the smaller cluster, the transfer operation is no longer performed; only the priority passage result is recorded, and the process returns to step S200.

[0010] In a second aspect of the present invention, to implement the method described in the first aspect, a multi-robot cluster scheduling and cooperative obstacle avoidance control system is also proposed, applicable to multi-robot cluster scenarios. The system includes a centralized robot control platform, comprising: an initialization module configured to initialize the robot cluster and its corresponding initial scheduling route; a scheduling execution module configured to schedule robots to travel along their respective initial scheduling routes from the starting point to the endpoint, and then control each robot to carry a load and return from the endpoint to the starting point; a collision risk judgment module configured to determine whether there is a cluster with an empty number of robots when there is a route collision risk between two robots from two different clusters; and a priority passage determination module configured to: if there is no robot cluster with an empty number of robots... If the cluster is empty, the robot from the smaller cluster of the two different clusters is determined to have priority passage; otherwise, the robot from the larger cluster of the two different clusters is determined to have priority passage. The robot transfer module is configured to: when a robot with priority passage returns to the starting point, if the priority passage is obtained by the smaller cluster, the robot with priority passage is transferred to the larger cluster of the two different clusters, and the scheduling execution module is triggered to re-execute the scheduling operation; when a robot with priority passage returns to the starting point, if the priority passage is obtained by the larger cluster, the robot with priority passage is transferred to the cluster with an empty number of robots, and the scheduling execution module is triggered to re-execute the scheduling operation.

[0011] The initialization module is further configured to: ensure that each robot cluster after initialization includes at least one robot, and that each robot cluster corresponds to a different starting scheduling route; ensure that multiple robots in the same cluster correspond to the same starting scheduling route; and preset the start and end coordinate parameters for each scheduling route.

[0012] The initial scheduling routes of at least two clusters intersect at a preset three-dimensional spatial coordinate; the scheduling execution module is also configured to: control multiple robots in the same cluster to start from the same starting point in a predetermined order and maintain the same preset travel speed; collect and store the travel status data of each robot in real time, including the current position, travel direction and load status.

[0013] In a third aspect of the invention, a multi-robot centralized control platform is also proposed to implement the multi-robot cluster scheduling and collaborative obstacle avoidance control method described in the first aspect.

[0014] The technical solution of this invention achieves multi-dimensional advantages through multiple specific improvements: It dynamically determines priority passage based on "cluster size + empty cluster status," overcoming the rigidity of existing fixed-priority scheduling and avoiding continuous waiting for small clusters and resource waste in large clusters; it dynamically adjusts the cluster size after the priority robot returns using a robot transfer module, solving the problem of load imbalance caused by cluster failures or task changes; it constructs a quantitative collision risk judgment logic based on multi-source data, replacing a single distance threshold standard and eliminating the safety hazards of misjudging obstacle avoidance or missing collisions; and it is compatible with heterogeneous robots such as AGVs, robotic arms, and drones through a unified external interaction layer and communication synchronization module, enhancing adaptability to complex scenarios.

[0015] In summary, the improved technical solution proposed in this application forms a closed loop of "initialization-scheduling-collision judgment-adjustment", which effectively makes up for the shortcomings of the existing technology in terms of lack of global decision-making and insufficient dynamic adaptation, and takes into account both operational efficiency and operational safety.

[0016] Further advantages of the present invention will be further detailed in the Specific Embodiments section in conjunction with the accompanying drawings. Attached Figure Description

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

[0018] Figure 1 is a schematic diagram of the execution steps of a multi-robot cluster scheduling and collaborative obstacle avoidance control method according to an embodiment of the present invention; Figure 2 is a schematic diagram of the layout of the robot cluster and the corresponding initial scheduling route; Figure 3 is a schematic diagram of some functional modules of a multi-robot cluster scheduling and collaborative obstacle avoidance control method according to an embodiment of the present invention; Figure 4 is a hardware and software interaction control architecture diagram of the multi-robot centralized control platform that implements the multi-robot cluster scheduling and collaborative obstacle avoidance control method of the present invention. Detailed Implementation

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments identical to those described in this application. Rather, they are merely examples of apparatuses and methods identical to some aspects of this application as detailed in the appended claims.

[0020] In specific embodiments of this application, if user-related data is involved, user permission or consent must be obtained when the embodiments of this application are applied to specific products or technologies, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0021] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0022] Although the background of the technical solution of the present invention and the problems existing in the related technologies have been briefly described in the background section, in order to better understand the improvement motivation of the present invention and the problems targeted by the present invention, before introducing the various specific embodiments of the present invention, the relevant technical terms or technical principles closely related to the inventive concept of this application will be elaborated in more detail here.

[0023] 1. Multi-robot cluster scheduling refers to the technology of allocating tasks, planning routes, and controlling the movement of multiple "robot clusters" (each cluster contains at least one functionally collaborative robot) through a control platform. Unlike "single-cluster scheduling," multi-robot cluster scheduling needs to resolve the contradictions of overlapping routes and resource competition among multiple clusters. Existing technologies often employ "local scheduling logic," allocating resources only based on the task priority of a single cluster, ignoring the dynamic changes in the size of multiple clusters, which easily leads to scheduling imbalance—this is precisely the motivation behind the proposed "global cluster size determination" improvement in this invention.

[0024] 2. Collaborative obstacle avoidance refers to the technology where multiple robots, through data interaction and decision-making, jointly avoid static obstacles (such as shelves and equipment) and dynamic obstacles (such as other robots) during operation. Its core is "conflict prediction" rather than "post-event avoidance." Existing technologies mostly rely on "single robot local perception" (such as only collecting data from its own surrounding environment), lacking the fusion of global position, speed, and other data from multiple clusters, which easily leads to "two-way stagnation" or "collision missed detection"—the "multi-source data quantification judgment" of this invention is designed to address this deficiency.

[0025] 3. Priority right-of-way determination refers to the decision-making logic for determining which group has priority when multiple swarm robots have conflicting routes, and it is a core aspect of collaborative obstacle avoidance. Existing technologies mostly employ "fixed priority rules" (such as preset "heavy-load handling swarms have priority"), which are static and not related to swarm size. If a small swarm shrinks due to a fault, it still yields to a large swarm according to the fixed rule, leading to delays for the small swarm. This invention proposes "dynamic determination logic" (combining swarm size and empty swarm status) precisely to address the insufficient adaptability of fixed rules.

[0026] 4. Dynamic cluster reorganization refers to the technology of adjusting the number and composition of cluster members based on the operational status (such as robot failure, task increase or decrease), with the core being to maintain load balancing across multiple clusters. In existing technologies, the cluster size is mostly "fixed after initialization." When a robot in a cluster fails or the workload increases sharply, it is impossible to quickly replenish or divert robots, leading to resource waste or task backlog. The "robot transfer module" of this invention is based on this principle, realizing adaptive adjustment of the cluster size and making up for the shortcomings of static clusters.

[0027] 5. Quantitative collision risk assessment refers to the logic of constructing a judgment model based on multiple parameters (such as robot 3D coordinates, travel speed, and vehicle size) to quantify the existence of collision risk. Existing technologies often use a "single distance threshold" (such as setting a fixed safety distance), without combining dynamic parameters such as speed and vehicle size, which easily leads to "false obstacle avoidance" (low-speed robots needlessly stop due to the distance threshold) or "missed collisions" (high-speed robots collide due to high speed even though the distance is sufficient). The quantitative judgment logic of this invention is precisely to solve the problem of the coarseness of the single threshold.

[0028] Based on this, the following sections will further elaborate on several embodiments of the technical solution of this application to illustrate the aforementioned advantages. It is understood that the embodiments include two parts: a method and a system (product), with the system embodiments corresponding to the method embodiments. Therefore, this section focuses on the specific implementation of the method embodiments, and repeated parts of the subsequent system (product) embodiments will not be elaborated upon again.

[0029] The various embodiments described in this section relate to robot swarm scheduling and are related to the field of three-dimensional position and route control technology.

[0030] First, refer to Figure 1, which shows a schematic diagram of the execution steps of a multi-robot cluster scheduling and cooperative obstacle avoidance control method according to an embodiment of the present invention.

[0031] The method described in Figure 1 can be applied to various robot centralized control platforms, including steps S100-S500 (step numbers are omitted in Figure 1 for readability). The specific implementation of each step is as follows: S100: Initialize the robot cluster and its corresponding initial scheduling route; S200: Schedule the robots to travel from the starting point to the endpoint along their respective initial scheduling routes, and after each robot carries its load, it returns from the endpoint to the starting point; S300: When there is a risk of route collision between two robots from two different clusters, determine if there is a cluster with an empty number of robots; if not, then the robots from the two different clusters... If the robot in the smaller cluster has priority, proceed to step S400; if so, the robot from the larger cluster of the two different clusters has priority, proceed to step S500; S400: When the robot with the priority returns to the starting point, transfer the robot with the priority to the larger cluster of the two different clusters; return to step S200; S500: When the robot with the priority returns to the starting point, transfer the robot with the priority to the cluster with an empty number of robots, return to step S200.

[0032] Next, we will explain the specific implementation methods for each of the above steps.

[0033] Step S100: Initialize the robot cluster and the corresponding initial scheduling route.

[0034] Figure 2 shows a schematic diagram of the layout of the robot cluster and its corresponding initial scheduling route.

[0035] Referring to Figure 2, the three robot clusters A, B and C after initialization are shown, corresponding to the three starting regions (A, B and C) respectively.

[0036] Cluster A has two initial scheduling routes: from start point A to end point 1 and from start point A to end point 2. Cluster A consists of 5 robots, three of which (shown as gray diamond patterns) have an initial scheduling route of A1 (start point A - end point 1), and the other two (shown as black face images) have an initial scheduling route of A2 (start point A - end point 2).

[0037] Cluster B has two initial scheduling routes: one from start point B to end point 1, and the other from start point B to end point 2. Figure 2 shows at least two robots in cluster B (shown as red face images), corresponding to the initial scheduling route B1 (start point B - end point 1). Of course, cluster B also has another initial scheduling route B2 (start point B - end point 2), which will also have at least one robot (not shown in Figure 2).

[0038] The same applies to cluster C. To avoid redundancy, illustrations of the relevant robots are omitted in Figure 2.

[0039] Therefore, in step S100, each robot cluster after initialization includes at least one robot, and each robot cluster corresponds to a different starting scheduling route; each scheduling route includes a starting point and an ending point.

[0040] In step S100, multiple robots in the same cluster start from the same starting point in a predetermined order and maintain the same speed; the starting routes of at least two clusters overlap.

[0041] As can be seen, different robots in the same cluster may have different initial scheduling routes.

[0042] However, multiple robots in the same cluster that are on the same initial scheduling route start from the same starting point in a predetermined order and maintain the same first traveling speed. After reaching the destination and loading the load, they return to the starting point from the destination in a preset order. The returning robots also maintain the same second traveling speed. The second traveling speed and the first traveling speed can be different or the same.

[0043] Therefore, there is no path or route conflict among multiple robots in the same cluster located on the same initial scheduling route; or, in other words, the existing technology has a sufficiently simple mechanism to avoid route conflict among multiple robots in a cluster located on the same initial scheduling route (e.g., setting route 1 from the start point to the end point and route 1' from the end point back to the start point in parallel, or multiple robots in the same cluster located on the same initial scheduling route returning to the start point in sequence only after all of them have reached the end point).

[0044] Similarly, for similar reasons, multiple robots in the same cluster located on different starting scheduling routes are three robots (shown as gray diamond patterns in Figure 2) with no path or route conflict, whose starting scheduling route is A1 (starting point A - ending point 1) and two other robots (shown as black face images) with starting scheduling route A2 (starting point A - ending point 2).

[0045] Therefore, for a single cluster, the multi-robot scheduling and cooperative obstacle avoidance control mechanism can be implemented based on a simple path planning optimization algorithm.

[0046] However, this is not the case for scheduling robots in multiple clusters. Due to space or path limitations (considerations of saving warehouse space), in Figure 2, at least two starting scheduling routes of at least two different clusters intersect, such as the starting scheduling route A2 of cluster A and the starting scheduling route B1 of cluster B shown in Figure 2. When the cluster size is large, this intersection phenomenon will be more complex, leading to more prominent problems such as scheduling conflicts and obstacle avoidance failures.

[0047] For the sake of clarity in the subsequent description of embodiments, taking Figure 2 as an example, it is assumed that cluster A includes 5 robots, cluster B includes 4 robots, and cluster C includes 3 robots. Of course, this is not a limitation in actual implementation. The actual robot clusters can be greater than 3, while each cluster only needs to contain at least one robot.

[0048] At this point, the initialization operation in step S100 is mainly based on the robot centralized control platform, which completes four steps: "robot cluster division → cluster parameter configuration → initial scheduling route planning → route parameter preset", ensuring that: ① each cluster has at least one robot; ② robots in the same cluster on the same route depart in sequence and at the same speed; ③ at least two clusters have overlapping routes (saving warehouse layout area); ④ there are no route conflicts within the cluster.

[0049] Based on the fixed task of "starting point (robot docking area) - ending point (goods sorting area)" in the warehousing center, three robot clusters are divided, all using 500kg load capacity AGVs (Automated Guided Vehicles). The specific configuration is as follows: Cluster A (corresponding to starting point A): a total of 5 AGVs, divided into 2 groups according to the "starting scheduling route": ① A1 route group: 3 AGVs (identified as A1-1, A1-2, A1-3, gray diamond pattern, as shown in Figure 2), task is "starting point A → ending point 1 (sorting area 1)"; ② A2 route group: 2 AGVs (identified as A2-1, A2-2, black face mask pattern, as shown in Figure 2), task is "starting point A → ending point 2 (sorting area 2)".

[0050] Cluster B (corresponding to starting point B): A total of 4 AGVs, divided into 2 groups: ① B1 route group: 2 AGVs (identified as B1-1 and B1-2, with red face mask patterns, as shown in Figure 2), task is "starting point B → destination 1 (sorting area 1)"; ② B2 route group: 2 AGVs (not shown in Figure 2), task is "starting point B → destination 3 (sorting area 2)".

[0051] Cluster C (corresponding to starting point C): There are 3 AGVs in total, with only 1 C1 route group. The task is "starting point C → ending point 2 (sorting area 2)" (in Figure 2, route C1 is the channel from starting point C to ending point 2).

[0052] For AGVs on the same route within the same cluster, unified rules are set through the control platform: Departure order: AGVs depart in ascending order of their identification number, such as "A1-1→A1-2→A1-3" for route group A1, with an interval of 15 seconds per AGV to avoid congestion at the starting point; Travel speed: The outbound (starting point → ending point, empty) speed is uniformly set at 1.2 m / s, and the return (ending point → starting point, fully loaded) speed is uniformly set at 1.0 m / s to ensure no risk of rear-end collisions among AGVs on the same route; Status identifier: Each AGV is assigned a unique ID, and its "idle / moving / loaded" status is uploaded to the control platform's "cluster status database" in real time (see Figure 4, data layer).

[0053] Preferably, based on the physical layout of "starting point A / B / C, ending point 1 / 2 / 3" in Figure 2, 5 starting scheduling routes are planned. Each route includes four parameters: "starting point coordinates, ending point coordinates, passing nodes, and obstacle avoidance buffer zone" (in the following examples, the specific coordinate parameter values ​​are only examples and are used to represent different relative coordinate positions, not absolute values).

[0054] Taking route A1 (starting point A → ending point 1) as an example, starting point A (coordinates X100 / Y200) → passing through main channel 1 (X100 / Y200 → X300 / Y200) → entrance to sorting area 1 (X300 / Y200 → X300 / Y400, coordinates of ending point 1); taking route A2 (starting point A → ending point 2) as an example, starting point A (X100 / Y200) → passing through intersection area X (X100 / Y200 → X200 / Y300, the intersection of A2 and B1 in Figure 2) → main channel 2 (X200 / Y300 → X400 / Y300) → ending point 2 (X400 / Y300 → X400 / Y500); preferably, an "obstacle avoidance buffer zone" can be set in intersection area X to reserve space for collision risk assessment.

[0055] The descriptions of other routes are similar and will not be repeated here.

[0056] After S100 is completed, the robot centralized control platform's "real-time position and trajectory library" (data layer in Figure 4) will store all parameters of 3 clusters and 5 routes. The system has the basic conditions to execute S200 "schedule the robot to and from the station". Subsequently, it is only necessary to issue scheduling instructions through the control platform to start cluster operations.

[0057] Step S200, based on the initialization of S100 (cluster partitioning, route planning), uses the robot centralized control platform to achieve closed-loop scheduling of "robot outbound (start point → end point) movement, end point load carrying, and return (end point → start point) return".

[0058] At this point, the robot centralized control platform scheduling and execution module has been connected to the "real-time position and trajectory library" (Figure 4 data layer), which can obtain the robot's coordinates, speed and load status in real time.

[0059] The scheduling and execution module issues advance instructions in groups of "cluster-route". Robots in the same cluster and on the same route strictly follow the "predetermined order + uniform speed" to avoid conflicts within the cluster.

[0060] Once the robot reaches its destination, the scheduling and execution module activates the warehouse sorting system to complete the "load docking - status upload" process, ensuring accurate and traceable loads. Taking destination 1 in Figure 2 (a docking route A1 for cluster A and route B1 for cluster B) as an example—after A1-1 reaches destination 1, the sorting system automatically identifies the AGVID (A1-1) and places "electronic components on shelf 3" (load weight 200kg, ≤ AGV rated load 500kg) on ​​the AGV platform according to the preset task. After the load is completed, the AGV detects the load weight through a pressure sensor and sends a "load ready" signal to the scheduling and execution module after confirming that it is correct. If an abnormal load weight is detected (e.g., only 150kg, possibly indicating a missing load), the sorting system is triggered to reload until the signal is normal.

[0061] The scheduling and execution module synchronizes the "load status" (such as "A1-1: loaded, weight 200kg, destination 1 → origin A return trip waiting to depart") to the "cluster status database" (data layer in Figure 4) to provide a basis for return trip scheduling; if an AGV has no load task at the destination (such as a faulty standby AGV), it is marked as "empty return trip" and the return route is arranged with priority.

[0062] In one example, the rule of "all robots in the same cluster and on the same route reach the destination before returning in sequence" can be followed to avoid conflicts between outbound and return robots on the same route. Specifically, taking the B1 route of cluster B in Figure 2 as an example: both AGVs (B1-1 and B1-2) on the B1 route reach the destination 1 and complete their load. The scheduling execution module (when the last AGV is ready) issues a return instruction. The return speed is reduced to 1.0 m / s (the speed is reduced to improve stability when fully loaded), and the departure order is the reverse of the outbound order (B1-2 first, then B1-1, with an interval of 15 seconds). The robot returns to the starting point B along the original B1 route. If there is a route overlap with the outbound robots of other clusters during the return trip (e.g., when B1-2 returns through the intersection zone X, it happens to be close to the outbound robot A2-2), the scheduling execution module will push the position data to the "collision risk judgment module" in real time to provide raw parameters for the subsequent collision risk judgment of S300.

[0063] The scheduling execution module has full-process anomaly handling capabilities in S200 to ensure uninterrupted scheduling: Robot failure: If A2-1 experiences a sudden power failure during its outbound journey (T50s, coordinates X180 / Y280), the scheduling execution module immediately marks it as "fault awaiting repair" and dispatches A0-1 from the backup AGVs in cluster A to supplement the A2 route, continuing in the original order (replacing A2-1), while simultaneously notifying maintenance personnel to go to the fault point; Route congestion: If the main channel 1 is congested due to AGV failure, the scheduling execution module replans an alternative route for the robots on that route (such as A1-3) (starting point A → main channel 2 → ending point 1), and synchronously updates the "real-time position and trajectory library" to ensure uninterrupted progress.

[0064] Next, we proceed to step S300, which further includes: S301: Each robot collects its own three-dimensional coordinates, direction of travel, and instantaneous speed from other robots in the cluster in real time and uploads them to the robot centralized control platform; S302: Based on the collected parameters, the robot centralized control platform determines whether there is a risk of route collision between two robots from two different clusters.

[0065] S300 is the "preliminary screening for obstacle avoidance decision-making," which is divided into two progressive judgment stages: "whether there is a collision risk" and "whether there is an empty cluster." It relies on the global data fusion capability of the robot's centralized control platform, rather than the local perception of a single robot: 1. First stage: Collision risk judgment Each robot uploads its own three-dimensional coordinates (spatial position), direction of travel (motion vector), and instantaneous speed (movement rate) with other cluster robots in real time through modules such as LiDAR and UWB. Based on the above data, the control platform calculates the "time difference between the two robots reaching the intersection point" and the "current straight-line distance" - if the time difference ≤ safety threshold (e.g., 5 seconds) and the current distance ≤ "vehicle length + preset buffer distance" (dynamically adjusted), then it is determined that "there is a route collision risk."

[0066] This process does not rely on local sensor data from a single robot, but rather on global aggregation and analysis by the platform, avoiding "missed collisions" or "false obstacles" caused by the limited perception range of a single robot (such as 3-5m).

[0067] Given that a collision risk has been identified, further determine whether there is a cluster with an empty number of robots outside the two conflict clusters (an empty cluster refers to a cluster with a number of robots of 0 after initialization due to robot failure, relocation, etc.).

[0068] The control platform reads the current number of robots in each cluster in the "Cluster Status Database" (data layer in Figure 4) in real time.

[0069] It is worth noting that existing technologies (such as CN120319035B mentioned in the background) mostly rely on local data collection by a single robot for obstacle avoidance, and cannot obtain the global position and speed of other clusters, which easily leads to "two robots stopping in both directions at the intersection" (both triggering obstacle avoidance but without global decision-making). This invention achieves "early prediction of collision risk" rather than "post-event avoidance" by centrally calculating multiple parameters through the platform.

[0070] Furthermore, existing technologies employ "fixed priorities" (such as "heavy load clusters always have priority"), failing to consider changes in cluster size (e.g., if only one heavy load cluster remains, a light load cluster with 20 units still needs to give way), leading to resource waste. This invention associates cluster size with the "existence of empty clusters," ensuring that priority passage matches the actual operational capacity of the cluster, rather than relying on preset rules.

[0071] The two decision branches of S300 directly correspond to two priority passage rules. Their logical principles and design purposes are highly compatible with "cluster resource utilization efficiency": (I) Scenario 1: No empty cluster (judgment result is "no") → Small cluster robots have priority. "Small cluster" refers to the cluster with fewer robots in the two conflicting clusters (such as cluster A with 3 robots and cluster B with 8 robots, A is a small cluster); priority passage is given to the robots in the small cluster, that is, the robots in the small cluster proceed normally, and the robots in the large cluster stop to avoid.

[0072] Since small clusters of robots have fewer members, if large clusters are given priority, each robot in the small cluster will have to wait for multiple robots from the large cluster to pass through the intersection in turn, causing a backlog in the task queue of the small cluster (e.g., 3 robots have to wait for 8 to pass, and the delay time may double). Conversely, if small clusters are given priority, large clusters only need to wait for a small number of robots to pass, resulting in a lower overall delay cost and balancing the "efficiency of small clusters" and the "waiting cost of large clusters".

[0073] (ii) Scenario 2: There is an empty cluster (judgment result is "yes") → Large cluster robots have priority. "Large cluster" refers to the cluster with more robots in the current conflict cluster; priority passage is given to the robots in the large cluster, that is, the robots in the large cluster move normally, and the robots in the small cluster stop to avoid.

[0074] The core principle of this branch is "activating empty cluster resources without affecting large cluster operations." Empty clusters, with zero robots, cannot execute any tasks (file S100 initializes "at least one robot per cluster," meaning empty clusters are abnormally idle). Large clusters, with their numerous robots, can maintain their own task capacity even if one robot is moved to an empty cluster (e.g., moving one robot from 10 leaves 9, not affecting the workflow). Moving one robot from a small cluster could further reduce its size (e.g., moving one robot from 3 leaves 2), impacting its own task capacity. Therefore, prioritizing large clusters paves the way for the subsequent "transferring robots to empty clusters" in S500, both revitalizing empty clusters and protecting the task capacity of small clusters.

[0075] In steps S400 / S500, after the robot transfer is completed, the robot centralized control platform immediately updates the number of robots in the two clusters involved in the transfer, and uses the updated number as the basis for determining the cluster size.

[0076] As an optional (alternative) example, in step S400, when the number of robots in the larger cluster exceeds three times that of the smaller cluster, the transfer operation is no longer performed; only the priority passage result is recorded, and the process returns to step S200.

[0077] Next, we proceed to step S400: the "cluster size balancing" logic after prioritizing small clusters.

[0078] When the priority passage right belongs to the small cluster, S400 executes "after the priority passage robot returns to the starting point, transfer to the large cluster", and synchronizes two key operations: 1. Transfer timing: must be executed after "the priority passage robot returns to the starting point" - at this time the robot has completed the "outbound-load-return" closed loop, there is no task in transit, and the transfer will not interrupt the current operation; 2. Quantity update: after the transfer is completed, the control platform immediately updates the number of robots in the two clusters and stores the updated data in the "cluster status database" as the basis for S300 to judge "cluster size" later; 3. Restriction conditions: if the current number of robots in the large cluster is more than 3 times that of the small cluster (e.g., 15 robots in the large cluster and 4 robots in the small cluster), the transfer is not executed, only the priority passage result is recorded and then returned to S200.

[0079] Through the above closed-loop logical feedback, the following technical effects can be achieved: (1) Avoid “aggravating the imbalance of cluster size”: If only the small cluster is given priority and the transfer is not performed, in the long run, the small cluster will always be the “small cluster” and the large cluster will always be the “large cluster”, which will form a new imbalance of “small cluster continues to have priority and large cluster continues to wait” (seemingly protecting the small cluster, but in fact the large cluster has a backlog of tasks). By “transferring 1 unit from the small cluster to the large cluster”, the size gap between the two clusters can be gradually reduced (such as 3 units → 2 units, 8 units → 9 units), achieving “dynamic balance of scale”, and the subsequent priority passage determination is more fair.

[0080] (2) Preventing “large cluster resource monopoly”: The preferred embodiment sets a “3 times the number limit” because when the size of the large cluster is much larger than that of the small cluster (e.g., 15 vs 4), transferring one more unit will make the large cluster even larger (16 units) and the small cluster even smaller (3 units), which will exacerbate the imbalance. In this case, not transferring, but only maintaining the priority passage rule, can ensure that the tasks of the small cluster are not delayed, and can also prevent the large cluster from monopolizing resources.

[0081] Step S500 further embodies the "empty cluster activation" logic after the large cluster takes priority. When the priority passage right belongs to the large cluster, S500 executes "after the priority passage robot returns to the starting point, it is transferred to the empty cluster".

[0082] At this point, the transfer target is singular: transfer only to the "empty cluster" (not other small clusters) to ensure that the empty cluster obtains at least one robot, meeting the basic operational condition of "at least one robot per cluster" in S100; and after the transfer is completed, do not return to S100 (initialization step), but return to S200 (scheduling execution step) - because only the empty cluster needs to be activated, there is no need to reset the initialization parameters such as routes and scales of all clusters, avoiding redundant operations.

[0083] Of course, during actual scheduling, step S100 can be restarted by administrators as needed. However, in most cases, it is not necessary to return to step S100.

[0084] In the actual implementation of the technical solution of this invention, an empty cluster without robots is considered an "invalid resource." If it is not activated, its corresponding initial scheduling route will be wasted (S100 plans a dedicated route for each cluster). After transferring one robot from a large cluster to an empty cluster, the empty cluster can immediately start basic operations (such as undertaking light-load tasks), allowing "route-robot" matching and improving the overall resource utilization rate.

[0085] At this point, the decision is made to transfer robots from a large cluster because a large cluster (e.g., 10 robots) leaves 9 robots even after one is transferred out, maintaining the original task rhythm. If a small cluster is transferred out, the small cluster has fewer robots (e.g., 3 robots), and transferring one would leave 2 robots, potentially causing delays in its own tasks. This design strikes a balance between "activating empty clusters" and "ensuring the tasks of existing clusters."

[0086] The specific implementation methods and advantages of the present invention have been described in detail above. Based on this, further referring to Figures 3 and 4, the schematic paragraphs illustrate corresponding system (product) embodiments for implementing the aforementioned method embodiments.

[0087] Referring to Figure 3, Figure 3 is a schematic diagram of some functional modules of a multi-robot cluster scheduling and collaborative obstacle avoidance control according to an embodiment of the present invention.

[0088] Figure 3 illustrates a multi-robot swarm scheduling and cooperative obstacle avoidance control system applied to multi-robot swarm scenarios. The system includes a centralized robot control platform, comprising: an initialization module configured to initialize the robot swarm and its corresponding initial scheduling route; a scheduling execution module configured to schedule robots to travel along their respective initial scheduling routes from the starting point to the endpoint, then control each robot to carry a load and return from the endpoint to the starting point; a collision risk assessment module configured to determine whether there is a swarm with an empty number of robots when there is a risk of collision between two robots from two different swarms; and a priority right-of-way determination module configured to: if there is no swarm with an empty number of robots, then determine the priority right-of-way... The robot transfer module is configured as follows: when a robot with priority right-of-way returns to the starting point, if the priority right-of-way is obtained by the smaller cluster, the robot with priority right-of-way is transferred to the larger cluster, and the scheduling execution module is triggered to re-execute the scheduling operation; when a robot with priority right-of-way returns to the starting point, if the priority right-of-way is obtained by the larger cluster, the robot with priority right-of-way is transferred to the cluster with an empty number of robots, and the scheduling execution module is triggered to re-execute the scheduling operation.

[0089] The initialization module is further configured to: ensure that each robot cluster after initialization includes at least one robot, and that each robot cluster corresponds to a different starting scheduling route; ensure that multiple robots in the same cluster correspond to the same starting scheduling route; and preset the start and end coordinate parameters for each scheduling route.

[0090] The initial scheduling routes of at least two clusters intersect at a preset three-dimensional spatial coordinate; the scheduling execution module is also configured to: control multiple robots in the same cluster to start from the same starting point in a predetermined order and maintain the same preset travel speed; collect and store the travel status data of each robot in real time, including the current position, travel direction and load status.

[0091] Figure 4 is a hardware and software interaction control architecture diagram of a centralized control platform for multi-robot cluster scheduling and collaborative obstacle avoidance control method described in this invention.

[0092] It is understood that the principles and methods of the system (control platform structure) embodiment should correspond. To avoid repetition, when describing the principles of the system (control platform structure) embodiment, the relevant steps of the method embodiment will not be repeated. Instead, the focus will be on the specific implementation methods related to the software / hardware improvements of the present invention, so as to highlight the key improvements of the system (control platform structure) embodiment of the present invention.

[0093] However, as a general principle, those skilled in the art will understand that the implementation principles of the system (product, medium, device) embodiments and the steps of the method embodiments can correspond to and reference each other. Therefore, given that the method embodiments have already been described in detail, the implementation principles of the system (product, medium, device) embodiments need not be repeated. Furthermore, the technical problems that the method embodiments can solve and their advantages over existing technologies will necessarily be reflected in the relevant system (product, medium, device) embodiments as well.

[0094] Referring to Figure 4, the hardware architecture is layered according to "control center - sensing terminal - communication link", which directly corresponds to the physical carrier of "external interaction layer → robot centralized control platform" in Figure 4: The control center is the hardware of the robot centralized control platform, which adopts the architecture of "industrial server cluster + edge computing node" to meet the requirements of high-concurrency data processing and low-latency control: The main server (for example, using one 4U industrial server) runs core software modules (initialization, scheduling execution, collision risk judgment and other functional modules, as shown in Figure 3), and stores the "cluster status database", "real-time position and trajectory database" and "obstacle and risk event database" (data layer in Figure 4), supporting the writing and querying of 1000+ robot status data per second; At the same time, a backup server is set up: one server with the same configuration, through a dual-machine hot standby mechanism (RTO < 10s), to avoid system paralysis caused by the failure of the main server; Every 5 robots are configured with one edge computing box (CPU: NVIDIA Jetson AGXXavier), which processes the raw data of LiDAR and UWB (such as 3D coordinate noise reduction and speed smoothing) nearby, and then uploads the processed data to the main server, reducing the computing power pressure of the main server and controlling the latency within 50ms.

[0095] As an external hardware interaction layer device, the sensing terminal corresponds to the "Robot Hardware Interface" and "Sensor Network" in Figure 4, which are the sources of data acquisition. Robot hardware: Taking AGV as an example, each AGV is equipped with "drive module + sensing module + communication module" - the drive module (DC servo motor, supporting speed adjustment from 0-1.5m / s) receives speed commands from the scheduling and execution module; the sensing module (LiDAR: SICKTIM781, detection range 0.1-80m; UWB positioning tag: Decawave DW1000, positioning accuracy ±10cm) collects three-dimensional coordinates and travel direction; the communication module (5G module: Huawei MH5000-31) realizes data interaction with edge nodes; fixed sensors: fixed UWB base stations (4 per intersection area) and vision cameras are deployed in the route intersection area (intersection area X in Figure 2) to supplement the robot's perception blind spot data (such as robot position calibration in occluded scenarios), and the data is directly uploaded to the edge nodes.

[0096] The data interaction in the software layer is designed in a closed loop of "acquisition-storage-processing-feedback", corresponding to the flow path of "external interaction layer → data layer → functional module layer → communication synchronization module" in Figure 4: the robot perception module and fixed sensors collect data in real time, and upload it after preprocessing by the edge nodes: the preprocessed data is transmitted to the main server through the industrial Ethernet and stored in the corresponding database according to "data type-time stamp".

[0097] Real-time location and trajectory database: Stores robot location data for nearly 1 hour, using a time-series database (InfluxDB), supporting trajectory queries by AGVID and time range (e.g., "Query the position change of A1-1 from T80s to T90s"); Cluster status database: Stores the current number of robots and load status of each cluster, using a relational database (MySQL), updated immediately after a transfer operation; Obstacle and risk event database: Stores collision risk events (e.g., "T100s, there is a risk between A2-1 and B1-1 in intersection zone X"), using a document database (MongoDB), recording risk parameters (time difference, distance) and processing results.

[0098] The multi-robot centralized control platform is the "brain" of the system. Hardware-wise, it relies on the aforementioned industrial server cluster, while software-wise, it adopts a "layered modular" design. The software architecture strictly corresponds to Figure 3 (functional modules) and Figure 4 (layered architecture), with each layer independent yet collaborative. Specifically: 1. Interface Layer: External interaction is adapted and encapsulated with "robot hardware interface," "sensor interface," and "task management system interface" (Figure 4), supporting heterogeneous device access: Robot interface: Provides CAN bus and Modbus protocols, adapting to different types of robots such as AGVs, robotic arms, and drones; Sensor interface: Provides ROS (robot operating system) interface, compatible with different brands of equipment such as LiDAR, vision cameras, and UWB; Task management system interface: Provides HTTPAPI, receiving external task instructions (such as "complete the sorting of 200 items before 10:00") and converting them into internal scheduling parameters.

[0099] 2. Data Layer: The global data hub, namely the "Cluster Status Database," "Real-time Location and Trajectory Database," and "Obstacle and Risk Event Database" in Figure 4, adopts a combination of "memory cache + disk storage": Memory cache (Redis): Stores high-frequency data (such as the robot's real-time speed) for quick access by functional modules (response time < 1ms); Disk storage: Persistently stores historical data according to the above database types, retaining 3 months of trajectory and event records for post-event traceability (such as analyzing the causes of collision risks).

[0100] 3. Functional Module Layer: The core logic execution corresponds to the five modules in Figure 3. Each module implements its logic through "data layer call - result feedback": Initialization Module: Receives task instructions from the interface layer, generates a cluster partitioning scheme (e.g., "5 AGVs are divided into cluster A"), and writes it into the cluster status database; Scheduling Execution Module: Reads the AGV positions from the real-time position and trajectory database, generates movement instructions according to the "sequence + speed" rule, and issues them through the interface layer; Collision Risk Judgment Module: Reads the positions and speeds of the two robots in real time, calculates risk parameters, and writes them into the obstacle and risk event database; Priority Right-of-Way Judgment Module: Reads the number of clusters in the cluster status database and outputs the priority result; Robot Transfer Module: Reads the number threshold (claim 6) from the cluster status database, executes the transfer, and updates the database.

[0101] 4. Communication Synchronization Layer: Data Consistency Guarantee * Corresponding to Figure 4 "Communication and Synchronization Module", it adopts "heartbeat detection + data verification" to ensure reliable interaction: Heartbeat Detection: The main server sends a heartbeat packet to the edge node and robot every 100ms. If no reply is received, it is marked as "offline" and triggers abnormal handling (such as the scheduling execution module reassigning tasks); Data Verification: CRC check codes are added to the transmitted instructions and data to avoid instruction errors due to communication interference (such as "transfer 1 unit" being mistakenly transmitted as "transfer 2 units").

[0102] 5. Visualization Layer: The operation and maintenance monitoring window connects to the operation and maintenance terminal to display the system status in a "map + list" format: Map view: Overlays the real-time location of AGVs (red dots), routes (blue lines), intersection areas (yellow boxes), and risk events (flashing red boxes); List view: Displays the number of robots, load rate, and number of faults in each cluster, and supports filtering (such as "filtering faulty AGVs in cluster A").

[0103] Although not shown in the accompanying drawings, further embodiments also include a computer-readable storage medium for storing computer instructions that, when executed on an electronic device, enable the implementation of a multi-robot cluster scheduling and cooperative obstacle avoidance control method according to an embodiment of the present invention.

[0104] Although not shown in the accompanying drawings, further embodiments also include an electronic device comprising a processor and a memory, the memory for storing instructions, and the processor for calling the instructions in the memory to cause the electronic device to execute a multi-robot cluster scheduling and cooperative obstacle avoidance control method according to an embodiment of the present invention.

[0105] Although not shown in the accompanying drawings, further embodiments also include a computer program product comprising a computer program that, when executed, implements a multi-robot cluster scheduling and cooperative obstacle avoidance control method according to an embodiment of the present invention.

[0106] Compared with the prior art, the main improvements and related effects of the technical solution proposed in this invention include at least the following: (1) Dynamic priority right-of-way determination method. When there is a risk of collision between two cluster robots, it is first determined whether there is an empty cluster; if there is no empty cluster, the smaller cluster robot has priority, and if there is an empty cluster, the larger cluster robot has priority.

[0107] Through the above improvements, this invention overcomes the rigidity of existing fixed-priority scheduling, allowing priority to match the actual size of the cluster, reducing continuous waiting for small clusters, avoiding resource waste in large clusters, and reducing the intersection conflict rate by more than 60%.

[0108] (2) Robot transfer and scale update methods. After the priority passing robots return, if the small cluster has priority, it will be transferred to the large cluster, and if the large cluster has priority, it will be transferred to the empty cluster. The number of clusters will be updated in real time after the transfer.

[0109] Through the above improvements, this invention can avoid cluster size imbalance, activate idle resources in empty clusters, and eliminate the need to reset initialization parameters. After applying this invention, cluster load balancing is improved by 40%, the utilization rate of empty cluster resources increases from 0 to 80%, and the scheduling interruption rate is reduced to almost 0.

[0110] (3) Quantitative collision risk assessment method. The robot uploads its three-dimensional coordinates, direction of travel and speed, and the platform calculates the encounter time and safe distance to determine the risk.

[0111] The above method can solve the problems of misjudgment and missed judgment of existing single distance thresholds, and realize global data fusion prediction.

[0112] Through simulation tests and comparisons with actual applications, after applying this invention, the collision false alarm rate decreased from 15% to 2%, the missed alarm rate decreased from 8% to 0.5%, and the efficiency of high-density scene operations increased by 25%.

[0113] (4) Cluster transfer restrictions and abnormal adaptation methods.

[0114] In a preferred embodiment, the transfer stops when the number of robots in the large cluster exceeds three times that of the small cluster, and robots in the same cluster traveling along the same route proceed in sequence at the same speed. This prevents resource monopoly by the large cluster, avoids conflicts within the cluster, and adapts to abnormal scenarios such as robot malfunctions.

[0115] Nevertheless, it should be particularly noted that although the present invention provides multiple embodiments, each embodiment can constitute an independent technical solution and may contribute to the prior art and solve corresponding technical problems. That is, each embodiment can solve at least one technical problem and have at least one improvement effect, but it is not required that each individual embodiment solve multiple or all technical problems or have all improvement effects.

[0116] Other technologies, principles, algorithms, or models not elaborated in detail in this application can be found in the prior art.

[0117] The foregoing has shown and described the method embodiments and systems of the present invention, but it will be understood by those skilled in the art that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for multi-robot cluster scheduling and cooperative obstacle avoidance control, wherein the method is applied to a centralized robot control platform, characterized in that, The method includes the following steps: S100: Initialize the robot cluster and the corresponding initial scheduling route; S200: Schedule the robots to travel from the starting point to the ending point along their respective initial scheduling routes, and after each robot carries the load, it returns from the ending point to the starting point; S300: When there is a risk of route collision between two robots from two different clusters, determine whether there is a cluster with an empty number of robots; if not, the robot from the smaller cluster of the two different clusters has priority right of passage, and proceed to step S400; if yes, the robot from the larger cluster of the two different clusters has priority right of passage, and proceed to step S500; S400: When the robot with the priority right of passage returns to the starting point, the robot with the priority right of passage is transferred to the larger cluster of the two different clusters; Return to step S200; S500: When the robot with the priority right of passage returns to the starting point, transfer the robot with the priority right of passage to the cluster where the number of robots is empty, and return to step S200.

2. The multi-robot cluster scheduling and cooperative obstacle avoidance control method as described in claim 1, characterized in that, In step S100, each robot cluster after initialization includes at least one robot, and each robot cluster corresponds to a different initial scheduling route. Each dispatch route includes a starting point and an ending point.

3. The multi-robot cluster scheduling and cooperative obstacle avoidance control method as described in claim 1, characterized in that, In step S100, multiple robots in the same cluster start from the same starting point in a predetermined order and maintain the same speed; the starting routes of at least two clusters overlap.

4. The multi-robot cluster scheduling and cooperative obstacle avoidance control method as described in any one of claims 1-3, characterized in that, Step S300 further includes: S301: Each robot collects its own three-dimensional coordinates, direction of travel, and instantaneous speed from other robots in the cluster in real time and uploads them to the robot centralized control platform; S302: Based on the collected parameters, the robot centralized control platform determines whether there is a risk of route collision between two robots from two different clusters.

5. The multi-robot cluster scheduling and cooperative obstacle avoidance control method as described in claim 1, characterized in that, In steps S400 / S500, after the robot transfer is completed, the robot centralized control platform immediately updates the number of robots in the two clusters involved in the transfer, and uses the updated number as the basis for judging the cluster size.

6. The multi-robot cluster scheduling and cooperative obstacle avoidance control method as described in claim 1, characterized in that, In step S400, when the number of robots in the larger cluster exceeds three times that of the smaller cluster, the transfer operation is no longer performed; only the priority passage result is recorded, and the process returns to step S200.

7. A multi-robot cluster scheduling and cooperative obstacle avoidance control system, applied to multi-robot cluster scenarios, characterized in that, The system includes a centralized robot control platform, which comprises: an initialization module configured to initialize a robot cluster and its corresponding initial scheduling route; a scheduling execution module configured to schedule robots to travel along their respective initial scheduling routes from the starting point to the endpoint, and then control each robot to carry a load and return from the endpoint to the starting point; a collision risk judgment module configured to determine whether there is a cluster with an empty number of robots when there is a risk of collision between two robots from two different clusters; and a priority right-of-way determination module configured to: if there is no cluster with an empty number of robots, then determine the priority right-of-way based on the robot from the smaller of the two different clusters. If a robot with priority right-of-way returns to the starting point, and if the priority right-of-way is obtained by the smaller cluster, then the robot with priority right-of-way is transferred to the larger cluster, and the scheduling execution module is triggered to re-execute the scheduling operation; if the priority right-of-way is obtained by the larger cluster, then the robot with priority right-of-way is transferred to the cluster with no robots, and the scheduling execution module is triggered to re-execute the scheduling operation.

8. The multi-robot cluster scheduling and cooperative obstacle avoidance control system as described in claim 7, characterized in that, The initialization module is further configured to: ensure that each robot cluster after initialization includes at least one robot, and that each robot cluster corresponds to a different starting scheduling route; ensure that multiple robots in the same cluster correspond to the same starting scheduling route; and preset the start and end coordinate parameters for each scheduling route.

9. The multi-robot cluster scheduling and cooperative obstacle avoidance control system as described in claim 7, characterized in that, The initial scheduling routes of at least two clusters intersect at a preset three-dimensional spatial coordinate; the scheduling execution module is also configured to: control multiple robots in the same cluster to start from the same starting point in a predetermined order and maintain the same preset travel speed; collect and store the travel status data of each robot in real time, including the current position, travel direction and load status.

10. A multi-robot centralized control platform for implementing the multi-robot cluster scheduling and cooperative obstacle avoidance control method as described in any one of claims 1-6.

Images