Heterogeneous uav cluster coordination method and system, electronic device, and storage medium

Abstract

The application discloses a heterogeneous unmanned aerial vehicle cluster cooperation method and system, an electronic device and a storage medium. Node capability information of each unmanned aerial vehicle node is acquired, and node registration information is established. Target nodes of a cooperation message are determined based on the registration information, and message conversion and re-encapsulation between different communication domains are completed by a bridge node. The situation complexity is continuously evaluated to determine a decision level. When a bridge link meets a preset abnormal condition, a key bridge abnormal event is determined, and the decision level is adjusted to a target decision level. A recovery strategy is generated under the target decision level. Task decomposition and distribution are performed on the recovery strategy. Message routing and communication resource configuration are adjusted according to the task distribution result. After the bridge relationship is recovered, cooperative communication and cooperative task execution between different communication domains are recovered, and the decision level is gradually rolled back when a preset recovery condition is met. Through the above method, multi-level cooperative processing of key bridge abnormal events is realized.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) system control technology, and in particular to a method, system, electronic device and storage medium for heterogeneous UAV swarm collaboration. Background Technology

[0002] With the continued application of unmanned aerial vehicle (UAV) platforms in scenarios such as security inspection, emergency response, edge sensing, and autonomous collaboration, multi-UAV swarms have gradually evolved from homogeneous collaboration based on a single model and communication standard to heterogeneous collaboration composed of nodes with different platforms, payloads, communication interfaces, and computing capabilities. In actual deployment, different UAV nodes often form multiple communication domains due to differences in communication interface standards, link protocols, frequency bands, or networking methods. These communication domains typically rely on bridging nodes to maintain cross-domain message passing and collaborative task execution. Against this backdrop, maintaining swarm collaboration under conditions of heterogeneous node coexistence, communication domain differentiation, and continuous topology changes has become a key issue for further improving the engineering applicability of related technologies.

[0003] In existing technologies, one type of solution mainly focuses on centralized task planning or static network management in homogeneous UAV swarms. This type of solution usually assumes that a unified communication method or a stable central control link is used within the swarm. Although it can achieve task assignment and coordinated action in an ideal network environment, when there are multiple nodes with significantly different capabilities within the swarm, or when multiple communication domains need to communicate through bridging nodes, once the bridging link degrades, the bridging node becomes unreachable, or a local communication domain is fragmented, the system often struggles to reorganize the coordination relationship in a timely manner according to the topology changes. This can easily lead to problems such as cross-domain message interruption, task execution disconnection, and failure of coordination among local sub-swarms. Another type of solution, while addressing topology recovery, local task reallocation, or continuation in abnormal scenarios, mostly treats communication anomaly handling, decision-level switching, task allocation, and communication resource adjustment as independent issues, lacking a cross-layer linkage mechanism for critical bridging anomaly events. For example, some solutions can detect link degradation and perform local rerouting, or can reselect execution nodes at the task layer, but they fail to incorporate the impact of bridging link anomalies on the entire cluster collaborative structure into continuous situational complexity assessments. They also fail to further feed back the task decomposition and allocation results corresponding to the recovery strategy to the communication layer after adjustments at the decision-making level, so as to synchronously adjust message routing and communication resource configuration.

[0004] Therefore, during critical bridging link anomalies, temporary communication domain disruptions, or bridging relationship restoration, issues such as delayed decision-making response, unstable task continuation, mismatched communication resource configuration, and hierarchical rollback oscillations can still easily occur. Summary of the Invention

[0005] This application provides a heterogeneous drone swarm collaboration method, system, electronic device, and storage medium to solve the multi-layer collaboration problem of heterogeneous drone swarms facing critical bridging link anomaly events.

[0006] In a first aspect, this application provides a heterogeneous unmanned aerial vehicle (UAV) swarm collaboration method, comprising: acquiring node capability information of each UAV node and establishing node registration information; determining the target node of the collaboration message based on the node registration information, and transmitting the collaboration message between different communication domains through a bridging node; continuously assessing the current situation complexity to determine the current decision level; monitoring the bridging link status, and when the bridging link meets preset key conditions and there is a risk of interruption, determining a key bridging anomaly event, and adjusting the current decision level to the target decision level according to the updated situation complexity; generating a recovery strategy based on the current communication topology constraints at the target decision level to respond to the key bridging anomaly event; decomposing and allocating the task execution corresponding to the recovery strategy, and adjusting message routing and communication resource configuration according to the task allocation result; and restoring collaborative communication and collaborative task execution of the heterogeneous UAV swarm between different communication domains after the bridging relationship is restored.

[0007] Furthermore, the node capability information includes at least one of the following: communication interface capability, computing capability, sensor capability, payload capability, remaining energy information, and supported task types; the establishment of node registration information includes: maintaining a node registry locally on each UAV node, and updating the node registry when a node joins, leaves, or its capability status changes.

[0008] Furthermore, determining the target node for the collaborative message based on the node registration information includes: filtering target nodes that meet the conditions from the node registration information according to the capability condition expression corresponding to the collaborative message; transmitting the collaborative message between different communication domains through the bridging node includes: the bridging node converting and re-encapsulating the collaborative message according to the message format, link protocol, or addressing result corresponding to different communication domains to complete the cross-domain transmission.

[0009] Furthermore, the preset key conditions include the bridging criticality of the bridging link meeting a preset key threshold, wherein the bridging criticality is calculated based on at least one of the following: the number of affected subgroups after the bridging link fails, the cross-domain attribute corresponding to the bridging link, the degree of missing alternative paths, and the control message carrying capacity; the interruption risk includes at least one of the following: the bridging link quality is lower than a preset link threshold, the control message packet loss rate is higher than a preset packet loss threshold, the cross-domain forwarding success rate is lower than a preset success rate threshold, and the bridging node disconnection time reaches a preset duration.

[0010] Furthermore, the decision-making hierarchy includes a reflection layer, a negotiation layer, and a strategic layer; the assessment of the current situation complexity is based on the time urgency, scope of impact, and uncertainty at the current moment; the current decision-making hierarchy is determined as a reflection layer, a negotiation layer, or a strategic layer based on the current situation complexity; when the critical bridging anomaly event meets the preset escalation conditions, the target decision-making hierarchy is adjusted to the strategic layer.

[0011] Furthermore, the recovery strategy includes at least one of the following: selecting a substitute relay node, updating bridging role bindings, suspending non-urgent tasks, allowing affected subgroups to temporarily operate independently, and reorganizing cross-domain collaboration relationships.

[0012] Further, the step of performing task allocation according to the recovery strategy includes: decomposing the recovery strategy into multiple tasks; determining a set of candidate nodes for each task; determining a target node to execute the corresponding task from the set of candidate nodes based on node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load, and allocating each task to the target node.

[0013] Furthermore, the current load is determined based on at least two of the following: the number of currently allocated tasks, the remaining execution time corresponding to currently incomplete tasks, the current computing resource usage, the current communication resource usage, and the current energy usage; the task allocation includes generating a pre-allocation scheme, receiving the executability response of candidate nodes to the pre-allocation scheme, and confirming the task allocation scheme based on the response results.

[0014] Furthermore, the adjustment of message routing and communication resource configuration based on task allocation results includes at least one of the following: updating bridge node binding relationships, updating cross-domain forwarding tables, adjusting message routing paths, adjusting message priorities, and adjusting bandwidth allocation strategies.

[0015] Furthermore, it also includes: when the bridging link status meets the preset recovery conditions, the current situation complexity is lower than the preset rollback threshold, and the high-level recovery action corresponding to the current recovery strategy is completed, the current decision level will be rolled back to the lower level in a step-by-step manner.

[0016] Furthermore, the preset recovery conditions include at least the following: the bridging recovery index is higher than the sum of the recovery threshold corresponding to the current decision level and the preset hysteresis bandwidth, and continues to reach the preset duration; the bridging recovery index is determined based on at least one of the following: bridging link quality, cross-domain forwarding success rate, control message packet loss rate, and inter-subgroup connectivity index.

[0017] Secondly, this application provides a heterogeneous unmanned aerial vehicle (UAV) swarm collaboration system, comprising: multiple UAV nodes, including at least two types of UAV nodes with different node capability information and at least one bridging node, wherein the multiple UAV nodes are configured to form at least two different communication domains; a node capability description and registration module, used to acquire the node capability information of each UAV node and establish node registration information; a cross-domain message transmission module, used to determine the target node of the collaboration message based on the node registration information and transmit the collaboration message between different communication domains through the bridging node; and a hierarchical decision-making module, used to continuously evaluate the current situation complexity to determine the current decision. The system comprises a hierarchy, and when the bridging link meets preset key conditions and there is a risk of interruption, it adjusts the current decision level to the target decision level based on key bridging anomalies; a topology reconstruction and collaborative recovery module, used to generate a recovery strategy based on the current communication topology constraints under the target decision level to respond to the key bridging anomalies; a dynamic task allocation module, used to execute task decomposition and allocation corresponding to the recovery strategy; wherein, the cross-domain message transmission module is also used to adjust message routing and communication resource configuration according to the task allocation results, and restore collaborative communication and collaborative task execution between the different communication domains after the bridging relationship is restored.

[0018] Furthermore, different types of UAV nodes differ in at least one of their node capability information, including communication interface capabilities, computing power, sensor capabilities, payload capacity, remaining energy information, and supported task types. Different communication domains also differ in at least one of their communication interface standards, link protocols, frequency bands, and networking methods. The node capability description and registration module is also used to maintain a node registry locally on each UAV node and update the node registry when a node joins, leaves, or its capability status changes. The cross-domain message transmission module is also used to filter target nodes that meet the conditions from the node registration information based on the capability condition expression corresponding to the collaborative message, and the bridging node converts and repackages the collaborative message according to the message format, link protocol, or addressing result corresponding to different communication domains to complete the cross-domain transmission.

[0019] Furthermore, the hierarchical decision-making module is also used to assess the complexity of the current situation based on the time urgency, scope of impact, and uncertainty at the current moment, and determine the current decision level among the reflection layer, negotiation layer, and strategic layer according to the current situation complexity; when the critical bridging anomaly event meets the preset escalation conditions, the target decision level is adjusted to the strategic layer; the dynamic task allocation module is also used to decompose the recovery strategy into multiple tasks, determine a set of candidate nodes for each task, and determine the target node to execute the corresponding task from the set of candidate nodes based on node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load, wherein the The current load is determined based on at least two of the following: the number of currently assigned tasks, the remaining execution time of currently unfinished tasks, the current computing resource usage, the current communication resource usage, and the current energy usage. The cross-domain message transmission module is also used to perform at least one of the following: updating the bridging node binding relationship, updating the cross-domain forwarding table, adjusting the message routing path, adjusting the message priority, and adjusting the bandwidth allocation strategy. The topology reconstruction and collaborative recovery module is also used to roll back the current decision level to the lower level in a step-by-step manner after the bridging link state has recovered to meet the preset recovery conditions, the current situation complexity is lower than the preset rollback threshold, and the high-level recovery action corresponding to the current recovery strategy has been completed.

[0020] Thirdly, this application provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the heterogeneous UAV swarm collaboration method described in any of the technical solutions provided in the first aspect above.

[0021] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the heterogeneous UAV swarm collaboration method described in any of the technical solutions provided in the first aspect above.

[0022] Compared with existing technologies, the beneficial effects of the above technical solution include at least the following: by acquiring the node capability information of each UAV node and establishing node registration information, determining the target node for collaborative messages based on the node registration information, and transmitting collaborative messages between different communication domains through bridging nodes, a cross-domain collaborative foundation can be established under the condition of heterogeneous UAV nodes and multiple communication domains coexisting; by continuously assessing the current situation complexity to determine the current decision level, and identifying key bridging anomalies when the bridging link meets preset key conditions and there is a risk of interruption, and adjusting the current decision level to the target decision level according to the updated situation complexity, key bridging anomalies can enter a hierarchical decision-making process, thereby improving the timeliness of response to cross-domain collaborative anomalies; by generating recovery strategies based on the current communication topology constraints at the target decision level, decomposing and allocating the tasks corresponding to the recovery strategies, and then adjusting message routing and communication resource configuration according to the task allocation results, the decision level, task level, and communication layer can be linked together, thereby enabling heterogeneous UAV clusters to maintain collaborative communication and collaborative task execution between different communication domains during bridging anomalies and recovery processes.

[0023] The above-mentioned technical solutions also have the following advantages: By further defining the specific fields of node capability information, the filtering method of capability condition expressions, the judgment criteria for bridging criticality and interruption risk, the specific division of decision-making levels, the specific components of recovery strategies, the method for determining candidate nodes for task decomposition and allocation, the method for determining the current load, the pre-allocation scheme and executability response mechanism, the adjustment content of message routing and communication resource configuration, and the step-by-step fallback conditions after bridging link recovery, the node filtering, anomaly identification, level promotion, recovery handling, task confirmation, resource callback, and level recovery stages can be made more specific and implementable. Since the above-mentioned subordinate technical features correspond to the detailed processing stages such as target node filtering, critical bridging anomaly identification, task allocation stability, adaptive adjustment of communication resources, and smooth level fallback, they are conducive to further improving the accuracy of cross-domain collaboration, the executability of recovery strategies, the matching of resource adjustments, and the overall stability of the anomaly recovery process. Attached Figure Description

[0024] The present invention will be further described below with reference to the accompanying drawings and embodiments: Figure 1 This is a schematic diagram of the heterogeneous UAV swarm collaboration method provided in this application; Figure 2 This is a schematic diagram of the heterogeneous UAV swarm collaborative system framework provided in this application; Figure 3 This application provides a schematic diagram of cross-domain networking and semantic addressing. Figure 4 This is a schematic diagram illustrating cross-domain collaborative recovery under a critical bridging anomaly scenario provided in this application. Detailed Implementation

[0025] The content of this application will be further described in detail below with reference to specific embodiments. It should be understood that in this application, the terms "first," "second," etc., are only used to distinguish the objects being described and are not used to limit the importance, order, or quantity of the objects. The terms "comprising," "including," and their variations are intended to indicate the presence of the listed features, steps, units, or components, but do not exclude the presence of other features, steps, units, or components not explicitly listed. The term "based on" can indicate that a certain factor is used as the primary basis, or it can indicate that processing is carried out in combination with other factors based on that factor; as long as it does not depart from the technical concept of this application, it can fall within its ordinary meaning.

[0026] Figure 1 This is a schematic diagram of the heterogeneous UAV swarm collaboration method provided in this application. Figure 1 As shown, the heterogeneous UAV swarm collaboration method provided in this application includes at least the following processes.

[0027] In step S1, the node capability information of each UAV node is acquired, and node registration information is established. In some embodiments, the node capability information may include at least one of the following: communication interface capability, computing capability, sensor capability, payload capability, remaining energy information, and supported task types. The heterogeneous UAV swarm system (hereinafter referred to as the system) can maintain a node registry locally on each UAV node based on this information, and update the node registration information when a node joins, leaves, or its capability status changes, thus forming the basis for subsequent collaborative message addressing, bridging node filtering, and task allocation. Through this step, UAV nodes of different types and capabilities in the swarm can be uniformly described and registered, thereby providing data support for the organization and scheduling of heterogeneous UAV swarms in cross-domain collaborative scenarios.

[0028] In step S2, the target node for the collaborative message is determined based on the node registration information, and the collaborative message is transmitted between different communication domains through the bridging node. Specifically, target nodes that meet the conditions can be selected from the node registration information according to the capability condition expression corresponding to the collaborative message. When the target node is located in different communication domains, the bridging node converts and repackages the collaborative message according to the message format, link protocol, or addressing result corresponding to different communication domains to complete the cross-domain transmission. Through this step, message transmission between heterogeneous UAV nodes is no longer limited to a single communication standard or a single networking method, but can maintain the flow of collaborative messages under the condition of multiple communication domains coexisting, providing support for subsequent cross-domain collaborative communication and collaborative task execution.

[0029] In step S2 above, the capability condition expression describes the capability constraints that the target node corresponding to the collaborative message needs to meet. It can be composed of field items, comparison relations, and logical connection relations. The field items can include at least one of the following: communication interface capability, computing capability, sensor capability, payload capability, remaining energy information, supported task type, communication domain, current location, and current load. The comparison relations can include at least equal to, greater than, less than, greater than or equal to, less than or equal to, interval inclusion, and set inclusion. The logical connection relations can include at least simultaneously satisfying, satisfying one of them, and not satisfying. For example, the capability condition expression can be "the communication interface capability includes the first communication domain interface and the second communication domain interface, and the supported task type includes relay replacement task, and the remaining energy is not lower than the preset energy threshold", or "the sensor capability includes a wide-angle visible light camera or infrared sensor, and the supported task type includes inspection or reconnaissance task", or "located near the affected subgroup, and the current load is lower than the preset load threshold, and the communication adaptability meets the cross-domain collaboration requirements".

[0030] In the embodiments provided in this application, a "communication domain" refers to a local communication set formed by a group of UAV nodes that are identical or compatible in at least one of the following: communication interface standard, link protocol, frequency band resources, networking method, or access rules. UAV nodes located in the same communication domain can directly exchange messages without protocol conversion, while message interaction between UAV nodes located in different communication domains usually requires message conversion, re-encapsulation, or forwarding processing by a bridging node. The division of communication domains is not limited to physical frequency band differences, but can also be reflected as logically isolated domains formed by using different link protocols, different access control methods, or different addressing methods under the same frequency band. Therefore, the "different communication domains" in step S2 above and in other embodiments of this application do not require that they be completely independent and unreachable from each other, but rather emphasize that if UAV nodes in different communication domains want to achieve stable collaborative message transmission, they need to rely on bridging nodes or bridging links to complete cross-domain connections.

[0031] In step S3, the complexity of the current situation is continuously assessed to determine the current decision-making level. In some embodiments, the decision-making level is divided into a reflection layer, a negotiation layer, and a strategy layer to address urgent situations with the most stringent latency requirements, moderately complex situations requiring local coordination, and major situations affecting the overall situation, respectively. The complexity of the current situation can be assessed based on the time urgency, scope of impact, and uncertainty at the current moment, and the current decision-making level is determined accordingly among the reflection layer, negotiation layer, and strategy layer. Specifically, the reflection layer can be used to handle local response problems with high timeliness and small scope of impact; the negotiation layer can be used to handle local adjustment problems requiring collaborative decision-making among multiple nodes; and the strategy layer can be used to handle complex anomaly problems with a wider scope of impact and requiring global coordination. Through this step, the system can continuously grasp the current decision-making level of the cluster under normal collaborative conditions, laying the foundation for subsequent level adjustments in abnormal scenarios.

[0032] In step S4, the status of the bridging link is monitored. When the bridging link meets the preset key conditions and there is a risk of interruption, a key bridging anomaly event is identified, and the current decision level is adjusted to the target decision level based on the updated situational complexity. In some embodiments, whether a bridging link meets the preset key conditions can be determined by bridging criticality. Bridging criticality can be calculated based on at least one of the following: the number of affected subgroups after bridging link failure, the cross-domain attribute of the bridging link, the degree of absence of alternative paths, and the degree of control message carrying capacity. For example, when a bridging link is the only available cross-domain connection path between two communication domains, undertakes the main forwarding tasks of cluster key control messages and coordination messages, and its failure will cause multiple subgroups to lose cross-domain coordination capabilities, the bridging criticality of the bridging link can be determined to be high. Conversely, if a bridging link has multiple stable alternative paths and only carries non-critical business messages, its bridging criticality can be determined to be low. The risk of interruption can be characterized by anomalies such as bridging link quality, control message packet loss, cross-domain forwarding success rate, and bridging node connection status. Once a critical bridging anomaly is identified, the system can escalate the current decision-making level based on the updated situational complexity, and adjust the target decision-making level to the strategic level when preset escalation conditions are met. This step ensures that bridging link anomalies are no longer merely considered localized communication layer anomalies, but rather can be treated as critical events affecting the cluster's collaborative structure and enter the hierarchical decision-making process.

[0033] In step S5, at the target decision level, a recovery strategy is generated based on the current communication topology constraints to respond to critical bridging anomalies. In some embodiments, communication topology constraints may include connectivity between current communication domains, availability of bridging nodes, cross-domain forwarding path status, and topology distribution of affected subgroups. The recovery strategy may include at least one of the following: selecting a substitute relay node, updating bridging role bindings, suspending non-urgent tasks, allowing affected subgroups to temporarily operate independently, and reorganizing cross-domain collaborative relationships. This step allows the system to not simply perform local repairs on a single link, but rather to form a holistic handling plan for the current anomaly scenario at the target decision level, thereby improving the targeting of subsequent task continuation and collaborative recovery.

[0034] In step S6, the tasks corresponding to the recovery strategy are decomposed and allocated, and message routing and communication resource configuration are adjusted according to the task allocation results. In some embodiments, the recovery strategy can be decomposed into multiple tasks, and a set of candidate nodes can be determined for each task; then, based on node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load, the target node for executing the corresponding task is determined from the set of candidate nodes. During the task allocation process, a pre-allocation scheme can be generated first, and then the executable response of the candidate node to the pre-allocation scheme can be received, and the task allocation scheme can be confirmed based on the response result. After the task allocation is completed, the system can also synchronously execute at least one of the following: cross-domain forwarding table update, bridge node binding relationship update, message routing path adjustment, message priority adjustment, and bandwidth allocation strategy adjustment. Through this step, the recovery strategy can be concretely implemented into executable node actions, and the task layer processing results can drive the routing and resource reconfiguration of the communication layer in reverse, thereby forming a closed loop of cross-layer linkage in anomaly handling. In this embodiment, the current load is used to characterize the task occupancy and resource occupancy of the candidate node at the current moment, so as to avoid assigning multiple recovery tasks to the same node in the task allocation process, which would lead to node overload. In some specific implementations, the current load can be determined based on at least two of the following: the number of currently assigned tasks, the remaining execution time of currently incomplete tasks, current computing resource usage, current communication resource usage, and current energy usage. Furthermore, these multiple load factors can be normalized and weighted to synthesize a current load index. A higher current load index indicates that the corresponding node is less suitable as an execution node for new recovery tasks. Therefore, the current load not only reflects the task pressure already borne by the node but also the available capacity of the node when continuing to accept new tasks.

[0035] In some embodiments of step S6 above, "communication adaptability" is used to characterize the communication support capability of a candidate node for the assigned task. It reflects not only whether the candidate node can maintain connectivity with other nodes or modules required to execute the task, but also whether the candidate node can meet the link quality, message interaction frequency, and cross-domain forwarding requirements required for task execution under the current communication topology. In some implementations, communication adaptability can be determined based on at least one of the following: whether the candidate node and task-related nodes are located in the same communication domain; the reachability of the candidate node to the target communication domain via a bridging node; the availability of the current cross-domain forwarding link; the increased link load after the candidate node undertakes the task; and the carrying capacity of the path where the candidate node is located for control messages and coordination messages. Therefore, communication adaptability is not simply equivalent to link reachability, but rather considers the node's connectivity conditions in the current communication topology, cross-domain access conditions, and communication support conditions during task execution simultaneously.

[0036] In step S7, after the bridging relationship is restored, the collaborative communication and collaborative task execution between the heterogeneous UAV clusters in different communication domains are restored. In some embodiments, if the bridging link state meets the preset recovery conditions, the current situation complexity is lower than the preset rollback threshold, and the high-level recovery action corresponding to the current recovery strategy is completed, the current decision level can be rolled back to the lower level in a step-by-step manner to reduce the risk of frequent oscillations in the decision level due to link state fluctuations during the bridging recovery process. Specifically, the preset recovery conditions include at least a bridging recovery index that is higher than the sum of the recovery threshold corresponding to the current decision level and the preset hysteresis bandwidth, and continues to reach a preset duration. The bridging recovery index is determined based on at least one of the following: bridging link quality, cross-domain forwarding success rate, control message packet loss rate, and inter-subgroup connectivity index, to characterize the degree of recovery of the bridging relationship after anomaly handling. It is not limited to a single link quality parameter, but is a comprehensive index that can reflect the overall recovery status of the bridging link and cross-domain collaborative relationship. The higher the bridging recovery index, the closer the bridging relationship between different communication domains is to a stable recovery state. Furthermore, to avoid premature recovery determination due to short-term jitter in the bridging link, the bridging recovery index is preferably considered to meet the bridging recovery conditions only after it has continuously reached the preset recovery threshold and remained at that threshold for a preset duration.

[0037] In step S7 above, the "inter-subgroup connectivity index" is used to characterize the degree of connectivity recovery between different subgroups before and after a bridging anomaly. A subgroup represents a group of UAV nodes that can maintain local direct communication or stable local collaboration under the current communication topology. The inter-subgroup connectivity index can reflect at least one of the following: the existence of available cross-domain paths between different subgroups, the number of cross-domain paths, the stability of cross-domain paths, the success rate of cross-domain message round trips, and the reachability of messages required for maintaining collaborative control between subgroups. When a bridging anomaly causes the original cluster to be decomposed into multiple local subgroups, the inter-subgroup connectivity index typically decreases; when a substitute relay node is connected, cross-domain message transmission resumes stable delivery, or the bridging relationship is re-established, the inter-subgroup connectivity index gradually increases. Therefore, this index can characterize not only the recovery status at the link level but also the degree of recovery of collaborative relationships between different communication domains. The "preset recovery conditions" are used to characterize whether the system has the basis for a step-by-step fallback from higher decision-making levels to lower decision-making levels. The preset recovery conditions may include at least the sum of the bridging recovery index being higher than the recovery threshold corresponding to the current decision level and the preset hysteresis bandwidth, and lasting for a preset duration. Furthermore, a comprehensive judgment can be made on whether to execute a hierarchical rollback by combining whether the current situation complexity is lower than the preset rollback threshold and whether the higher-level recovery action corresponding to the current recovery strategy has been completed. By incorporating the bridging recovery index, hysteresis bandwidth, and duration into the preset recovery conditions, the risk of frequent switching of the current decision level due to short-term fluctuations in the bridging link near the threshold can be reduced. Here, "higher-level recovery action" refers to the action corresponding to the recovery strategy executed at a higher decision level in response to a critical bridging anomaly. For example, in some embodiments of step S3 above, the higher decision level is set to at least the higher of the negotiation layer and the strategic layer, preferably the strategic layer. The "recovery action" does not include routine inspections, routine formation maintenance, or general business task execution, but specifically refers to the handling action executed to eliminate the adverse effects of critical bridging anomalies on cross-domain collaboration. Specifically, high-level recovery actions may include at least one of the following: a substitute relay node taking over the bridging role, updating the cross-domain forwarding table, switching the binding relationships of key bridging nodes, establishing temporary autonomous status for affected subgroups, pausing non-urgent tasks, and reorganizing cross-domain collaboration relationships. Therefore, when determining whether to allow the current decision-making level to roll back to a lower level, the prerequisite should be that the high-level recovery action corresponding to the current recovery strategy has been completed, rather than the completion of any arbitrary high-level action.

[0038] To facilitate understanding of the decision-making hierarchy in this application by those skilled in the art, the decision-making hierarchy in step S3 above is further explained as follows: The reflection layer is mainly used to handle situations with high latency requirements, localized impact, and where a small number of nodes can quickly complete the response; the negotiation layer is mainly used to handle situations where multiple nodes need to exchange states and complete local consensus decisions; the strategy layer is mainly used to handle situations where bridging anomalies significantly affect the collaborative relationships between multiple communication domains or multiple subgroups, requiring global or cross-domain recovery measures. Therefore, the above-mentioned "high-level recovery action" preferably corresponds to the recovery action triggered by the negotiation layer or the strategy layer, and more preferably corresponds to the recovery action executed at the strategy layer to restore cross-domain collaborative relationships.

[0039] Through the above steps S1 to S7, this application forms a complete processing mainline from node capability description and registration, cross-domain message passing, continuous assessment of situational complexity, identification of key bridging anomalies, generation of recovery strategies, task decomposition and allocation, communication resource callback to collaborative recovery, so that heterogeneous UAV clusters can maintain collaborative communication and collaborative task execution between different communication domains during bridging link anomalies and recovery under cross-domain networking conditions.

[0040] Figure 2 This is a schematic diagram of the heterogeneous UAV swarm collaborative system framework provided in this application. Figure 2 As shown, the heterogeneous drone swarm collaborative system 100 provided in this application includes multiple drone nodes, including at least different types of drone nodes. Specifically, it includes, for example, a fixed-wing small drone node 101 equipped with a wide-angle visible light camera, a multi-rotor medium-sized drone node 102 equipped with a high-resolution visible light camera and a close-range interception device, and a multi-rotor large drone node 103 equipped with an edge computing module and a communication relay device. Furthermore, the aforementioned multiple drone nodes are configured to form at least two different communication domains, for example, at least one... Figure 2The system is divided into communication domains A and B. The three types of UAV nodes differ from each other in at least one of the following: communication interface capabilities, computing power, sensor capabilities, payload capacity, remaining energy information, and supported task types. Large UAV node 103 acts as a bridging node to maintain cross-domain transmission of collaborative messages between communication domains A and B. Based on this system architecture, heterogeneous UAV nodes can complete cross-domain networking and collaborative execution under the condition of coexistence in different communication domains, providing a system foundation for cluster collaboration in abnormal scenarios such as multiple intrusion targets 201. Multiple intrusion targets 201 represent the system's potential simultaneous exposure to multiple external disturbance sources or multiple anomaly triggers during actual operation. These targets may directly trigger the cluster's regular collaborative tasks, or indirectly increase the current time urgency, impact range, and uncertainty under conditions of bridging link resource pressure, increased communication load, or node role adjustments, thereby affecting the complexity of the current situation and its corresponding decision-making level. This design allows the system to distinguish between regular collaborative tasks and anomaly recovery tasks even when multiple targets occur concurrently, and prioritizes the execution of recovery strategies corresponding to critical bridging anomaly events when necessary.

[0041] In the above Figure 2 In the illustrated implementation, system 100 may include a node capability description and registration module 110, a cross-domain message transmission module 120, a hierarchical decision-making module 130, a topology reconstruction and collaborative recovery module 140, and a dynamic task allocation module 150. The node capability description and registration module 110 is used to acquire node capability information of each UAV node and form node registration information. Node capability information can be periodically reported by each UAV node or actively updated when capability status changes, thereby enabling the system to continuously monitor node capability differences and availability. The cross-domain message transmission module 120 is used to determine the target node for collaborative messages based on node registration information and transmit collaborative messages between communication domain A and communication domain B through bridging nodes, such as large UAV node 103; simultaneously, the cross-domain message transmission module 120 can also perform message routing adjustments and communication resource configuration adjustments according to recovery strategies and task allocation results. Through the cooperation of the node capability description and registration module 110 and the cross-domain message transmission module 120, the system can achieve capability-based message addressing and cross-domain message transmission under heterogeneous node conditions.

[0042] The hierarchical decision-making module 130 continuously assesses the complexity of the current situation to determine the current decision-making level. When the bridging link meets preset key conditions and there is a risk of interruption, it adjusts the current decision-making level to the target decision-making level based on key bridging anomaly events. Taking the three-level decision-making hierarchy consisting of the reflection layer, negotiation layer, and strategy layer as an example, when the bridging link anomaly only affects local coordination, it can be handled by the lower-level negotiation layer; when the bridging link anomaly meets preset escalation conditions and has a significant impact on the coordination relationship between multiple communication domains, the hierarchical decision-making module 130 can adjust the target decision-making level to the strategy layer to improve the response capability to key anomaly scenarios. Figure 2 The information flow, such as "target decision level" and "situation complexity", represents the interaction between the hierarchical decision module 130 and other modules, as well as with UAV nodes.

[0043] The topology reconstruction and collaborative recovery module 140 is used to generate recovery strategies based on the current communication topology constraints at the target decision level to respond to critical bridging anomaly events. Specifically, the topology reconstruction and collaborative recovery module 140 can integrate the topology relationships between current communication domains, bridging node availability, cross-domain forwarding path status, and the distribution of affected subgroups to generate a recovery strategy that includes at least one of the following: selecting a substitute relay node, updating bridging role binding relationships, suspending non-urgent tasks, allowing affected subgroups to temporarily operate independently, and reorganizing cross-domain collaborative relationships. Figure 2 The "target decision level" information flow from the hierarchical decision module 130 to the topology reconstruction and collaborative recovery module 140, and the "recovery strategy" information flow output by the topology reconstruction and collaborative recovery module 140, are both used to characterize the formation and transmission process of the recovery strategy under abnormal scenarios.

[0044] The dynamic task allocation module 150 is used to decompose and allocate tasks according to the recovery strategy. Specifically, the dynamic task allocation module 150 can decompose the recovery strategy into multiple tasks and determine a set of candidate nodes for each task; then, combining factors such as node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load, it determines the target node to execute the corresponding task from the set of candidate nodes. Furthermore, the dynamic task allocation module 150 can first form a pre-allocation plan, then receive the candidate nodes' responses to the feasibility of the pre-allocation plan, and confirm the task allocation plan based on the responses. Figure 2The "task allocation result" information stream output by the dynamic task allocation module 150 is used to characterize the mapping process of the recovery strategy to the execution actions of specific nodes. In this embodiment, the pre-allocation scheme refers to the candidate allocation result initially formed by the dynamic task allocation module 150 based on the recovery strategy and the status of candidate nodes before the final confirmation of the task allocation result. This pre-allocation scheme does not take effect immediately after its formation, but is used to query the candidate nodes or the local control entities corresponding to the candidate nodes to determine whether the corresponding task is executable under the current node status. The executability response is used to characterize the feedback result of the candidate nodes to the pre-allocation scheme. This feedback result may include at least one of the following: executable, temporarily not executable, need to adjust the execution sequence, and need to adjust the resource configuration. The system can filter, modify, or confirm the pre-allocation scheme based on the executability response to form the final task allocation scheme. By setting the pre-allocation scheme and its executability response mechanism, the risk of allocation results failing due to momentary node unavailability, changes in resource status, or insufficient communication support conditions can be reduced.

[0045] exist Figure 2 In the system framework shown, the modules do not operate independently but rather form a cross-layered, interconnected closed loop around key bridging anomalies, encompassing the decision-making, task, and communication layers. Specifically, the cross-domain message transmission module 120, while maintaining collaborative message passing between communication domain A and communication domain B, can also feed back changes in the bridging link status to the hierarchical decision-making module 130. After continuously assessing the situational complexity and determining the target decision level, the hierarchical decision-making module 130 drives the topology reconstruction and collaborative recovery module 140 to generate a recovery strategy. The topology reconstruction and collaborative recovery module 140 then transmits the recovery strategy to the dynamic task allocation module 150, which generates task allocation results. The cross-domain message transmission module 120 further adjusts message routing and communication resource configuration based on the task allocation results to maintain collaborative communication and collaborative task execution between different communication domains during recovery. Thus, Figure 2 The system 100 shown not only presents the composition structure of the heterogeneous UAV cluster, but also provides the overall system framework for abnormal scenarios, from capability description, cross-domain transmission, hierarchical decision-making, recovery strategy generation, task allocation to collaborative recovery.

[0046] Figure 3 This is a schematic diagram illustrating cross-domain networking and semantic addressing provided in this application. Figure 3 As shown, in this embodiment, the cross-domain message transmission module 120 determines the target nodes that meet the conditions in communication domain A and communication domain B based on node registration information and capability condition expressions, and completes the cross-domain transmission of collaborative messages through bridging nodes. Figure 3The diagram illustrates two types of capability condition expressions. Expression 1 corresponds to the backup relay scenario, and Expression 2 corresponds to the inspection and reconnaissance scenario. For Expression 1, the system can filter nodes with edge computing capabilities and dual-interface communication capabilities from the registered node capability information and identify them as target node 1 as a candidate backup relay node. For Expression 2, the system can filter nodes with wide-angle camera capabilities and corresponding mission payload capabilities and identify them as target node 2 as the execution node for the inspection and reconnaissance mission.

[0047] In the above embodiments, the cross-domain message transmission module 120 does not rely on static addressing based on fixed node identifiers. Instead, it dynamically filters target nodes that meet the conditions from the node registration information according to the capability constraints corresponding to the collaborative messages. Therefore, the same cross-domain message transmission module 120 can filter nodes with relay capabilities for bridging recovery scenarios, and also filter nodes with corresponding perception capabilities for routine inspection and reconnaissance scenarios, enabling heterogeneous UAV nodes to form differentiated target node sets based on different collaborative needs.

[0048] When the target nodes are located in different communication domains, the bridging node can perform conversion and re-encapsulation of the cooperative message according to the message format, link protocol or addressing result corresponding to the different communication domains, and deliver the cooperative message to target node 1 and target node 2 respectively. Figure 3 The dashed lines in the diagram illustrate the cross-domain connection between the bridging node and communication domains A and B, and the term "cooperative message" indicates the direction of cross-domain message transmission. Through this process, the cross-domain message transmission module 120 can establish task-oriented message paths between different communication domains, so that cooperative messages are no longer limited to direct reachability within a single communication domain.

[0049] thus, Figure 3 The illustrated implementation further explains the operation of the cross-domain message transmission module 120 in this application: first, the target node is determined based on the capability condition expression and node registration information; then, the cross-domain message is converted, repackaged, and transmitted through the bridging node, thereby realizing cross-domain networking and semantic addressing for heterogeneous UAV nodes. This process can support the stable transmission of conventional collaborative messages between different communication domains and also provide a cross-domain message support foundation for the generation of recovery strategies, task decomposition and allocation, and adjustment of communication resources after subsequent critical bridging anomaly events.

[0050] Figure 4 This diagram illustrates cross-domain collaborative recovery under a critical bridging anomaly scenario provided in this application. The following is combined with... Figures 1 to 4 Provide detailed descriptions of application scenarios.

[0051] like Figure 4As shown, in this embodiment, multiple drone nodes are organized into two different communication domains, communication domain A and communication domain B. Communication domain A and communication domain B maintain cross-domain message transmission of cooperation through a bridging node R1. Drone nodes A1, A2, and A3 in communication domain A differ from drone nodes B1, B2, and B3 in communication domain B in terms of node capability information. Specifically, A1 and A2 can be used to perform tasks such as patrolling and interception; B1 can serve as a backup relay candidate node; A3 can serve as another candidate node or a local support node; and R1 plays a crucial bridging role between the two communication domains. Figure 4 The high-value target area is used to characterize the core area that the system prioritizes for protection, and multiple intruding drones I1 and I2 are used to characterize the changes in time urgency, scope of impact and uncertainty caused by the approach of external targets at the current moment.

[0052] like Figure 4 As shown, the downward arrow in R1 indicates a decline in the current node status of the bridging node, or represents a decrease in the quality of the bridging link carried by the bridging node. For example, the cross-domain message transmission module 120 continuously monitors the bridging link quality, controls message packet loss rate, cross-domain forwarding success rate, and the online status of the bridging node, and determines critical bridging anomaly events when the bridging link meets preset key conditions and there is a risk of interruption. Since R1 undertakes the critical bridging function between communication domain A and communication domain B, its anomaly will directly affect the cross-domain collaborative message transmission and collaborative task execution around the high-value target area. Therefore, the above-mentioned critical bridging anomaly events can be regarded as high-priority events affecting the entire cluster collaborative structure.

[0053] In this embodiment, the hierarchical decision-making module 130 is deployed on each UAV node to continuously assess the current situation complexity to determine the current decision level. When the bridging link carried by R1 degrades and I1 and I2 are approaching a high-value target area, the system can update the current situation complexity based on the current time urgency, impact range, and uncertainty, and adjust the current decision level to the target decision level based on the updated current situation complexity. The decision level in this embodiment adopts a three-layer structure consisting of a reflection layer, a negotiation layer, and a strategy layer as described in the previous embodiments. Figure 4 In the scenario shown, since the critical bridging anomaly event corresponding to R1 will simultaneously affect the cross-domain collaboration between communication domain A and communication domain B, and the anomaly has an overlapping effect with multiple intruding drones, the target decision level is adjusted to the strategic level when the preset upgrade conditions are met.

[0054] At the target decision-making level, i.e., the strategic level, the topology reconstruction and collaborative recovery module 140 generates a recovery strategy based on the current communication topology constraints to respond to critical bridging anomalies. Combined with... Figure 4In one specific implementation of the scenario shown, the system can generate the following recovery strategy: A1 and A2 are invoked to intercept I1 and I2, allowing R1 to take over the patrol mission outside the high-value target area. Simultaneously, B1 is selected from communication domain B as a backup relay candidate node, and its bridging role is switched from its original execution role to R2, to take over R1's cross-domain bridging task. In another implementation, the system can also use A3 as a secondary candidate node R3, so that when B1 cannot meet the cross-domain support conditions, A3 can assume a local compensation or auxiliary connection role. From the above recovery strategy execution process, it can be seen that in this application, the recovery strategy is not a simple link repair action, but a comprehensive handling solution for the entire cross-domain collaborative relationship formed around key bridging anomaly events.

[0055] After the recovery strategy is generated, the dynamic task allocation module 150 decomposes and allocates the tasks corresponding to the recovery strategy. Specifically, the recovery strategy can be decomposed into multiple tasks, such as backup relay takeover tasks, bridging role binding update tasks, local patrol maintenance tasks, interception task maintenance tasks, and cross-domain route adjustment support tasks. Subsequently, the dynamic task allocation module 150 determines a set of candidate nodes for each task, and, in conjunction with node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load, determines the target node to execute the corresponding task from the set of candidate nodes. In some embodiments, for the first... The first task, the... The overall score of each candidate node It can be determined according to the following formula: ,in, Indicates the matching degree of node capabilities. Indicates communication adaptability. The score represents the distance between the node and the task execution location. This indicates the score corresponding to the remaining energy. Indicates the current load. to These represent the corresponding weights. Based on the comprehensive scoring above, the system can prioritize selecting nodes that meet the bridging task capability requirements, are located in suitable execution positions, have low current loads, and have sufficient remaining energy as the execution nodes for backup relay tasks.

[0056] exist Figure 4In the scenario shown, when B1 is marked as "B1→R2", it indicates that the dynamic task allocation module 150 has determined the UAV node B1 in communication domain B as the priority execution node for the backup relay task based on the aforementioned comprehensive scoring and recovery strategy, and switched its target role to R2. When A3 is marked as "A3→R3", it indicates that A3 can serve as another candidate recovery node, used as a substitute or supplementary execution node when the pre-allocation response result shows that B1 is temporarily unexecutable, or when B1's execution process encounters insufficient resources or insufficient link support. In some embodiments, the dynamic task allocation module 150 does not immediately perform the final switch after forming the initial allocation result, but first generates a pre-allocation scheme, then receives the candidate node's response to the executability of the pre-allocation scheme, and confirms the final task allocation scheme based on the response result. This reduces the risk of recovery task allocation failure due to momentary node unavailability, changes in communication support conditions, or fluctuations in resource status.

[0057] After task allocation is completed, the cross-domain message transmission module 120 adjusts message routing and communication resource configuration based on the task allocation results. Specifically, when B1 is identified as a substitute relay node R2, the cross-domain message transmission module 120 can simultaneously update at least one of the following: bridge node binding relationship, cross-domain forwarding table, message routing path, message priority, and bandwidth allocation strategy. For example, during the transition period when R1 has not completely exited the bridging link and R2 begins to take over, priority can be given to the transmission of cross-domain control messages, bridging maintenance messages, and collaborative messages related to high-value target areas, while reducing the bandwidth usage of non-critical business messages. As can be seen from the above example process, the allocation results at the task layer of the system in this application can drive the routing and resource reconfiguration at the communication layer, thereby forming a cross-layer linkage closed loop between the decision layer, task layer, and communication layer.

[0058] In some implementations, the current load is used to characterize the task and resource occupancy of candidate nodes at the current moment, to avoid concentrating multiple critical tasks on the same node during recovery strategy execution. The current load can be determined based on at least two of the following: the number of currently assigned tasks, the remaining execution time of currently incomplete tasks, current computing resource occupancy, current communication resource occupancy, and current energy occupancy. Further, the above factors can be normalized and then weighted to synthesize the current load index. For example, the following formula can be used to represent the current load index. Current load of each candidate node: ,in, This represents the normalized metric corresponding to the number of tasks currently assigned. This represents the normalized metric corresponding to the remaining execution time. This represents the normalized index corresponding to computational resource usage. This represents a normalized index corresponding to communication resource usage. This represents the normalized index corresponding to energy consumption. to These represent the corresponding weights. The higher the current load, the worse the adaptability of the corresponding node to continue undertaking new recovery tasks.

[0059] In this embodiment, communication adaptability is Figure 4 In the scenario shown, B1 is selected as R2 not only because its node capabilities meet the requirements of the bridging and replacement task, but also because of its location in the communication domain B, its accessibility to provide cross-domain support to the surrounding high-value target area, and its link carrying capacity after undertaking the bridging task.

[0060] After the bridging relationship is restored, the topology reconstruction and collaborative recovery module 140 can also cooperate with the hierarchical decision-making module 130 to perform hierarchical rollback. Specifically, when the bridging link status meets the preset recovery conditions, the current situation complexity is lower than the preset rollback threshold, and the higher-level recovery action corresponding to the current recovery strategy is completed, the current decision level can be rolled back to the lower level in a step-by-step manner. In this embodiment, the preset recovery conditions include at least one of the following: the substitute relay node R2 takes over the bridging role, the cross-domain forwarding table is updated, the binding relationship of key bridging nodes is switched, the temporary autonomous state of the affected subgroup is established, the non-urgent task is suspended, and the cross-domain collaborative relationship is reorganized. To determine whether the bridging relationship has reached the recovery state, a bridging recovery index R(t) can be introduced. In some implementations, the bridging recovery index can be determined according to the following formula: Where Q(t) represents the bridging link quality metric, S(t) represents the cross-domain forwarding success rate metric, and P... loss G(t) represents the message loss rate metric, and G(t) represents the inter-subgroup connectivity metric. 1 to 4 represents the corresponding weights. The higher the bridging recovery index, the closer the bridging relationship between different communication domains is to a stable recovery state. Preferably, the hierarchical backoff judgment process is only allowed when the bridging recovery index is continuously higher than the sum of the recovery threshold corresponding to the current decision level and the preset hysteresis bandwidth, and continues to reach the preset duration, thereby avoiding frequent hierarchical oscillations caused by short-term fluctuations in the bridging link.

[0061] In this embodiment, when the bridging link corresponding to R1 is abnormal, causing the original cluster to be decomposed into multiple local subgroups, the connectivity index between subgroups decreases; when B1 completes the role switch and acts as R2 to re-establish cross-domain message paths between different communication domains, the connectivity index between subgroups gradually increases.

[0062] In other embodiments, the topology reconstruction and cooperative recovery module 140 can be used for... Figure 4In addition to recovery processing in bridging anomaly scenarios, the system can also be used for collaborative recovery in target loss scenarios. When any target among multiple intruding drones is not observed by any node within a preset time window, the system can determine it as a lost target, and the topology reconstruction and collaborative recovery module 140 determines the target motion model by combining the target's historical trajectory information before loss. The target motion model can be selected based on the target's speed, heading, and acceleration information before loss; for example, a uniform speed model is used when the speed and heading changes are small, and a maneuvering model is used when the speed and heading changes are significant. Subsequently, the system can extrapolate the target's future position based on the target motion model and form a target search probability distribution. In some embodiments, the probability that the target is at position (x,y) at time t+Δt can be expressed as: ,in This indicates the predicted center position obtained by extrapolation based on the target motion model. This represents the diffusion parameter characterizing the uncertainty of the prediction. This represents the normalization coefficient. The system can define a search priority area based on the above target search probability distribution, and the dynamic task allocation module 150 can allocate the corresponding search tasks to UAV nodes with corresponding perception and communication capabilities to maintain collaborative search capabilities in target loss scenarios.

[0063] In summary, the heterogeneous UAV swarm collaboration method and system in this application are not designed only for static cross-domain message passing scenarios. Instead, they are capable of forming a cross-layer linkage self-healing mechanism around key bridging anomalies, including continuous assessment of situational complexity, adjustment of decision-making levels, generation of recovery strategies, task decomposition and allocation, adjustment of message routing and communication resource configuration, bridging recovery, and smooth hierarchical rollback, under conditions such as declining state of key bridging nodes, deterioration of bridging link quality, concurrent approach of multiple intruding UAVs, and increased protection requirements for high-value target areas. This mechanism enables the heterogeneous UAV swarm to continuously maintain collaborative communication and collaborative task execution between different communication domains during bridging anomalies and recovery processes under cross-domain networking conditions.

[0064] The above embodiments are merely illustrative of the technical concept and features of the present invention, intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly, and should not be construed as limiting the scope of protection of the present invention. It will be apparent to those skilled in the art that the present invention is not limited to the details of the above exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects. The scope of the present invention is defined by the appended claims rather than the foregoing description, and thus all changes falling within the meaning and scope of the equivalents of the claims are intended to be included within the present invention.

Claims

1. A heterogeneous UAV swarm coordination method, characterized in that, include: Obtain the node capability information of each drone node and establish node registration information; The target node for the collaborative message is determined based on the node registration information, and the collaborative message is transmitted between different communication domains through the bridging node; Continuously assess the complexity of the current situation to determine the current decision-making level; Monitor the status of the bridging link. When the bridging link meets the preset key conditions and there is a risk of interruption, identify the key bridging anomaly event and adjust the current decision level to the target decision level according to the updated situation complexity. Under the target decision level, a recovery strategy is generated based on the current communication topology constraints to respond to the critical bridging anomaly event; The tasks corresponding to the recovery strategy are decomposed and allocated, and message routing and communication resource configuration are adjusted according to the task allocation results; After the bridging relationship is restored, the collaborative communication and collaborative task execution of the heterogeneous UAV cluster between different communication domains are resumed.

2. The collaborative method according to claim 1, characterized in that, The node capability information includes at least one of the following: communication interface capability, computing capability, sensor capability, payload capability, remaining energy information, and supported task types. The establishment of node registration information includes: maintaining a node registry locally on each drone node, and updating the node registry when a node joins, leaves, or its capability status changes.

3. The collaborative method according to claim 1, characterized in that, The step of determining the target node for the collaborative message based on the node registration information includes: filtering target nodes that meet the conditions from the node registration information according to the capability condition expression corresponding to the collaborative message; The step of transmitting the collaborative message between different communication domains through a bridging node includes: the bridging node converting and re-encapsulating the collaborative message according to the message format, link protocol, or addressing result corresponding to the different communication domains to complete the cross-domain transmission.

4. The collaborative method according to claim 1, characterized in that, The preset key conditions include the bridging criticality of the bridging link meeting a preset key threshold, wherein the bridging criticality is calculated based on at least one of the following: the number of affected subgroups after the bridging link fails, the cross-domain attribute corresponding to the bridging link, the degree of missing alternative paths, and the degree of control message carrying capacity. The interruption risks include at least one of the following: the bridging link quality is lower than a preset link threshold, the control message packet loss rate is higher than a preset packet loss threshold, the cross-domain forwarding success rate is lower than a preset success rate threshold, and the bridging node disconnection time reaches a preset duration.

5. The collaborative method according to claim 1, characterized in that, The decision-making hierarchy includes a reflection layer, a negotiation layer, and a strategic layer; The assessment of the complexity of the current situation is based on the time urgency, scope of impact, and uncertainty at the current moment; The current decision-making level is determined as a reflection layer, a negotiation layer, or a strategic layer based on the complexity of the current situation. When the critical bridging anomaly event meets the preset escalation conditions, the target decision level is adjusted to the strategic level.

6. The collaborative method according to claim 1, characterized in that, The recovery strategy includes at least one of the following: selecting a substitute relay node, updating bridging role bindings, suspending non-urgent tasks, allowing affected subgroups to temporarily run independently, and reorganizing cross-domain collaboration relationships.

7. The collaborative method according to claim 1, characterized in that, The step of performing task allocation according to the recovery strategy includes: The recovery strategy is broken down into multiple tasks; For each task, a set of candidate nodes is determined; Based on node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load, target nodes for executing corresponding tasks are determined from the candidate node set, and each task is assigned to the target node.

8. The collaborative method according to claim 7, characterized in that, The current load is determined based on at least two of the following: the number of currently assigned tasks, the remaining execution time for currently unfinished tasks, the current computing resource usage, the current communication resource usage, and the current energy usage; The task allocation includes generating a pre-allocation scheme, receiving the executability response from candidate nodes to the pre-allocation scheme, and confirming the task allocation scheme based on the response results.

9. The collaborative method according to claim 1, characterized in that, The adjustment of message routing and communication resource configuration based on task allocation results includes at least one of the following: updating bridge node binding relationships, updating cross-domain forwarding tables, adjusting message routing paths, adjusting message priorities, and adjusting bandwidth allocation strategies.

10. The synergic method of claim 1, wherein, Also includes: Once the bridging link status meets the preset recovery conditions, the current situation complexity is lower than the preset rollback threshold, and the high-level recovery action corresponding to the current recovery strategy is completed, the current decision level will roll back to the lower level in a step-by-step manner.

11. The collaborative method according to claim 10, characterized in that, The preset recovery conditions include at least the following: the bridging recovery index is higher than the sum of the recovery threshold corresponding to the current decision level and the preset hysteresis bandwidth, and continues to reach the preset duration; The bridging recovery metrics are determined based on at least one of the following: bridging link quality, cross-domain forwarding success rate, control message packet loss rate, and inter-subgroup connectivity metrics.

12. A heterogeneous UAV swarm coordination system, comprising: include: Multiple drone nodes, including at least two types of drone nodes with different node capability information and at least one bridging node, and the multiple drone nodes are configured to form at least two different communication domains; The node capability description and registration module is used to obtain the node capability information of each UAV node and establish node registration information; A cross-domain message transmission module is used to determine the target node of the collaborative message based on the node registration information, and to transmit the collaborative message between different communication domains through the bridging node; The hierarchical decision-making module is used to continuously assess the complexity of the current situation to determine the current decision level, and when the bridging link meets the preset key conditions and there is a risk of interruption, it adjusts the current decision level to the target decision level based on key bridging anomaly events. The topology reconstruction and collaborative recovery module is used to generate a recovery strategy based on the current communication topology constraints to respond to the critical bridging anomaly event under the target decision level; The dynamic task allocation module is used to perform task decomposition and allocation corresponding to the recovery strategy according to the recovery strategy. The cross-domain message transmission module is also used to adjust message routing and communication resource configuration according to task allocation results, and to restore collaborative communication and collaborative task execution between the different communication domains after the bridging relationship is restored.

13. The heterogeneous unmanned aerial vehicle (UAV) swarm collaborative system according to claim 12, characterized in that, Different types of UAV nodes differ in at least one of the following node capability information: communication interface capability, computing power, sensor capability, payload capability, remaining energy information, and supported mission types. Different communication domains also differ in at least one of the following: communication interface standard, link protocol, frequency band, and networking method. The node capability description and registration module is also used to maintain a node registry locally on each UAV node and update the node registry when a node accesses, exits, or its capability status changes. The cross-domain message transmission module is also used to filter target nodes that meet the conditions from the node registration information according to the capability condition expression corresponding to the collaborative message, and the bridging node converts and repackages the collaborative message according to the message format, link protocol or addressing result corresponding to different communication domains to complete the cross-domain transmission.

14. The heterogeneous unmanned aerial vehicle (UAV) swarm collaborative system according to claim 12, characterized in that, The hierarchical decision-making module is also used to assess the complexity of the current situation based on the time urgency, scope of impact, and uncertainty at the current moment, and to determine the current decision-making level in the reflection layer, negotiation layer, and strategic layer according to the complexity of the current situation; When the critical bridging anomaly event meets the preset escalation conditions, the target decision level is adjusted to the strategic level; The dynamic task allocation module is further configured to decompose the recovery strategy into multiple tasks, determine a set of candidate nodes for each task, and determine the target node for executing the corresponding task from the set of candidate nodes based on node capabilities, communication adaptability, distance between the node and the task execution location, remaining energy, and current load. The current load is determined based on at least two of the following: the number of currently allocated tasks, the remaining execution time of the currently unfinished tasks, the current computing resource usage, the current communication resource usage, and the current energy usage. The cross-domain message transmission module is also used to perform at least one of the following: updating the bridge node binding relationship, updating the cross-domain forwarding table, adjusting the message routing path, adjusting the message priority, and adjusting the bandwidth allocation strategy; The topology reconstruction and collaborative recovery module is also used to roll back the current decision level to the lower level in a step-by-step manner after the bridged link state is restored to meet the preset recovery conditions, the current situation complexity is lower than the preset rollback threshold, and the high-level recovery action corresponding to the current recovery strategy is completed.

15. An electronic device, comprising: It includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the heterogeneous unmanned aerial vehicle swarm collaboration method according to any one of claims 1 to 11.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the heterogeneous human-machine cluster collaboration method according to any one of claims 1 to 11.

Images