Task migration and continuation execution method

Abstract

The application relates to a task migration and continuation execution method. The method is applied to a task migration and continuation execution system, the system comprising a migration unmanned aerial vehicle, a continuation unmanned aerial vehicle and a nest, and the method comprises the following steps: the migration unmanned aerial vehicle generates task migration data based on task running state data and multi-modal sensing data in response to a task migration instruction, and sends the task migration data to the continuation unmanned aerial vehicle and the nest; the task migration data comprises an incremental state package and multi-modal breakpoint markers; the continuation unmanned aerial vehicle receives the task migration data, performs state injection on the task migration data, generates injected states, and sends task execution data collected under the injected states to the nest; and the nest receives the task migration data and the task execution data, and performs fusion processing on the task migration data and the task execution data to obtain target task data. The method can improve the timeliness, accuracy and consistency of task handover, thereby improving the success rate of task continuation.

Description

Technical Field

[0001] This application relates to the field of collaborative control technology for unmanned aerial vehicles (UAVs), and in particular to a method for mission migration and succession. Background Technology

[0002] Unmanned aerial vehicle (UAV) swarm collaboration has become a key technology for continuous aerial missions such as wide-area surveillance, emergency communications, and logistics delivery. To ensure uninterrupted missions, when a drone on duty needs to return due to power or load limitations, a successor drone must seamlessly take over its mission status and data stream to achieve mission migration and continuation.

[0003] Traditionally, during migration, the duty drone (i.e., the returning drone or the migrating drone) serializes and compresses a complete snapshot of its mission memory and sends it to the follow-up drone. After receiving the complete data packet, the follow-up drone decompresses and deserializes it, overwriting the state in its local mission module.

[0004] However, traditional solutions rely primarily on global coordinate information provided by the GPS or RTK positioning modules of each UAV when synchronizing handover points. The handover process is triggered by comparing geographical coordinates. Therefore, when dealing with complex, dynamic, and signal-constrained actual operating environments, the handover points may be inaccurate, resulting in insufficient assurance of the accuracy and consistency of task handover. This leads to a low success rate of task continuation and a decline in data stream quality. Summary of the Invention

[0005] Based on this, it is necessary to provide a task migration and succession execution method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the accuracy, timeliness, and consistency of task handover between UAVs, thereby increasing the success rate of task succession and improving the data flow quality during the succession process, in order to address the above-mentioned technical problems.

[0006] In a first aspect, this application provides a task migration and follow-up execution method, applied to a task migration and follow-up execution system, the task migration and follow-up execution system including a migrating UAV, a follow-up UAV, and a UAV nest, the method comprising:

[0007] The drone responds to the mission migration command, generates mission migration data based on mission operation status data and multimodal sensor data, and sends the mission migration data to the successor drone and the drone nest; the mission migration data includes incremental status packets and multimodal breakpoint markers;

[0008] By continuously receiving mission migration data from drones, state injection is performed on the mission migration data to generate an injected state, and the mission execution data collected in the injected state is sent to the drone nest.

[0009] The system receives task migration data and task execution data from the nest, and then merges and processes the task migration data and task execution data to obtain the target task data.

[0010] In one embodiment, task migration data is generated based on task runtime status data and multimodal sensor data, including:

[0011] Acquire lease configuration and task execution status data, and construct a task semantic profile based on the lease configuration and task execution status data; the task semantic profile is used to represent a vectorized description of the task characteristics of the task to be migrated.

[0012] Based on the semantic profile of the task, the task running status data is mapped in layers to generate an incremental status package; the incremental status package includes the L0 key layer, the L1 context layer and the L2 heavy data layer.

[0013] Based on visual features and inertial measurement information in multimodal sensing data, as well as task progress in task operation status data, multimodal breakpoint markers are generated; multimodal breakpoint markers include key fields and extended fields.

[0014] In one embodiment, multimodal breakpoint markers are generated based on visual features and inertial measurement information in multimodal sensing data, and task progress in task execution status data, including:

[0015] Extract stable image patches from visual features and generate visual feature hashes;

[0016] Short-window pre-integration is performed on the inertial measurement information to obtain an inertial measurement summary;

[0017] Key fields are generated based on visual feature hashing, inertial measurement summaries, and task progress identifiers in task running status data.

[0018] In one embodiment, multimodal breakpoint markers are generated based on visual features and inertial measurement information in multimodal sensing data, and task progress in task execution status data, including:

[0019] Extract appearance information corresponding to the task target from visual features to generate a re-identification feature vector; and / or, identify key geometric points of the local environment from visual features to generate local geometric anchor points;

[0020] Extended fields are generated based on re-identified feature vectors and / or local geometric anchors.

[0021] In one embodiment, sending mission migration data to the successor drone and the drone nest includes:

[0022] By establishing a handshake-based configuration within the nest, a dual-active session link is created between the migrating drone, the receiving drone, and the nest.

[0023] Based on the dual-active session link, the task migration data is sent to the successor drone and the drone nest; the task migration data carries a status watermark, which is used to indicate that the same data is injected and consumed in a single instance.

[0024] In one embodiment, the incremental state packet includes an L0 critical layer, an L1 context layer, and an L2 heavy data layer. The multimodal breakpoint marker includes critical fields and extended fields. Sending mission migration data to the successor drone and the drone nest includes:

[0025] Based on the code rate corresponding to the L0 critical layer, the L0 critical layer and key fields after applying forward error correction are sent to the connecting drone and the nest.

[0026] Based on the code rate corresponding to the L1 context layer, the L1 context layer and extended fields are sent to the connecting drone and the nest;

[0027] Based on the bitrate corresponding to the L2 heavy data layer, the L2 heavy data layer is sent to the connecting drone and the nest.

[0028] In one embodiment, by continuously receiving mission migration data from the drone, state injection is performed on the mission migration data to generate an injected state, including:

[0029] By receiving the L0 key layer and key fields from the follow-up drone, the data of the L0 key layer is written into the shadow context, and the key fields are matched with the real-time sensing data collected by the follow-up drone to establish a coarse alignment of the breakpoint location domain.

[0030] By following up with the UAV, upon receiving the extended field, L1 context layer and / or L2 heavy data layer, at the optimal injection time, the L1 context layer and / or L2 heavy data layer are written into the state slot of the upstream task context, and the coarsely aligned residuals are refined and registered based on the extended field.

[0031] Update the shadow context to the production context and generate the injected state.

[0032] In one embodiment, the method further includes:

[0033] Based on link quality observation data and airborne thermal management status, an injection risk function is constructed and solved to determine the optimal injection delay. The injection risk function is obtained by weighting multiple risk items, which include at least two of the following: state staleness risk, link loss risk, and airborne thermal management risk.

[0034] Determine the optimal injection time based on the optimal injection delay and the current time.

[0035] In one embodiment, the task migration data and task execution data are fused to obtain target task data, including:

[0036] Determine the semantic primary key corresponding to each data segment of the task migration data, and the semantic primary key corresponding to each data segment of the task execution data; the semantic primary key serves as the semantic segment index of the corresponding data segment, and is used to indicate the task description information of the corresponding data segment;

[0037] Based on the semantic primary key corresponding to each data segment, determine the semantic conflict type between the current data segment and other data segments;

[0038] Based on the fusion strategy corresponding to the semantic conflict type, the current data segment is fused with other data segments to obtain the target task data.

[0039] In one embodiment, the semantic conflict type includes any one of repetition, overlap, and contradiction. Based on the fusion strategy corresponding to the semantic conflict type, the current data segment and other data segments are fused to obtain the target task data, including:

[0040] If the semantic conflict type is duplication, then retain the data segment with higher hierarchical integrity, or retain the data segment with higher link quality, or retain the data segment corresponding to the task execution data;

[0041] If the semantic conflict type is overlap, then the current data segment and other data segments are merged by frame interpolation;

[0042] If the semantic conflict type is contradiction, then the data fragment corresponding to the task execution data is retained.

[0043] Secondly, this application also provides a task migration and follow-up execution device, applied to a task migration and follow-up execution system, the task migration and follow-up execution system including a migrating UAV, a follow-up UAV, and a nest, the device comprising:

[0044] The migration data generation module is used to generate mission migration data based on mission running status data and multimodal sensor data in response to mission migration commands, and send the mission migration data to the successor UAV and the UAV nest; the mission migration data includes incremental status packets and multimodal breakpoint markers;

[0045] The migration data injection module is used to receive task migration data, inject status into the task migration data, generate an injected status, and send the task execution data collected in the injected status to the machine nest.

[0046] The data fusion module is used to receive task migration data and task execution data, and to fuse the task migration data and task execution data to obtain the target task data.

[0047] Thirdly, this application also provides a migration drone, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the relevant steps in the task migration and continuation execution method described in the first aspect above.

[0048] Fourthly, this application also provides a follow-up drone, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the relevant steps in the task migration and follow-up execution method described in the first aspect above.

[0049] Fifthly, this application also provides a nested system, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the relevant steps in the task migration and continuation execution method described in the first aspect above.

[0050] In a sixth aspect, this application also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the task migration and continuation execution method described in the first aspect above.

[0051] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the task migration and continuation execution method described in the first aspect above.

[0052] The aforementioned task migration and continuation execution method, apparatus, UAV, nest, storage medium, and computer program product are described. The method is applied to a task migration and continuation execution system, which includes a migration UAV, a continuation UAV, and a nest. The migration UAV, responding to a task migration command, generates task migration data based on task operation status data and multimodal sensor data, and sends the task migration data to the continuation UAV and the nest. The task migration data includes incremental state packets and multimodal breakpoint markers. Next, the continuation UAV receives the task migration data, injects a state into the data to generate an injected state, and sends the task execution data collected under the injected state to the nest. Finally, the nest receives the task migration data and the task execution data, and performs fusion processing on the two data to obtain the target task data. In this application, during mission migration, the migrating UAV can generate mission migration data including incremental state packets and multimodal power-off markers. The incremental state packets accurately represent the mission state of the migrating UAV before handover, while the multimodal breakpoint markers accurately represent the UAV's own state and environmental state at the handover point through multimodal feature data. This enables accurate position domain alignment even in signal-limited environments, especially GPS-denied environments, solving the handover failure problem caused by excessive reliance on GPS in existing technologies. This not only improves the accuracy and consistency of mission handover and ensures data stream quality, but also enhances the timeliness and robustness of mission handover, thereby increasing the success rate of mission succession. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is an application environment diagram of the task migration and continuation execution method in one embodiment;

[0055] Figure 2 This is a flowchart illustrating the task migration and continuation execution method in the first embodiment;

[0056] Figure 3 This is a flowchart illustrating the task migration and continuation execution method in the second embodiment;

[0057] Figure 4 This is a flowchart illustrating the task migration and continuation execution method in the third embodiment;

[0058] Figure 5This is a flowchart illustrating the task migration and continuation execution method in the fourth embodiment;

[0059] Figure 6 This is a flowchart illustrating the task migration and continuation execution method in the fifth embodiment;

[0060] Figure 7 This is a structural block diagram of a task migration and continuation execution device in one embodiment;

[0061] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0063] Improving the reliability, real-time performance, and accuracy of collaborative operations in drone swarms can determine the overall efficiency of continuous operation of drone swarms in complex and dynamic environments, thereby enhancing the intelligence and practicality of drone systems.

[0064] Currently, existing technologies for UAV mission handover primarily involve establishing a communication link between onboard computers and transmitting status data at a pre-defined handover point. Specifically, the migrating UAV serializes a complete mission memory snapshot, compresses it, and sends it to the receiving UAV via a single wireless link (such as Wi-Fi or 4G). Upon receiving the complete data packet, the receiving UAV decompresses and deserializes it, overwriting the status data into its local mission module. Regarding positioning, synchronization at the handover point mainly relies on global coordinate information provided by the respective GPS or RTK positioning modules of the UAVs, triggering the handover process by comparing geographical coordinates.

[0065] However, existing technologies still face challenges in ensuring the accuracy, timeliness, and consistency of task handover when dealing with complex, dynamic, and signal-constrained real-world operating environments. These issues are interconnected and collectively lead to low task success rates and degraded data stream quality. Therefore, further research and innovation are needed to address these problems in existing technologies.

[0066] To address the aforementioned issues, the applicant conducted in-depth research and analysis, and discovered that:

[0067] Existing methods rely too heavily on global coordinates to define the handover point (where the handover takes place). Once in a GPS-denied environment (such as an urban canyon or indoors), positioning failure will directly lead to handover failure. Even if GPS is available, coordinate-level alignment cannot capture the visual and motion features of the task context, which can easily result in spatial misalignment.

[0068] Furthermore, state injection (when and how to inject) lacks accurate timing decisions and process control. The commonly used passive receiving and loading mode cannot avoid the risk of state staleness due to network latency, and if the non-atomic injection process fails midway, it can easily contaminate the mission state of the successor drone.

[0069] Based on this, at the data fusion level (what to merge), the nest or backend system simply splices together the data segments of the returning aircraft and the follow-up aircraft. This fails to resolve the data redundancy and semantic conflicts introduced by the overlapping of observations or differences in perspective in the handover area, resulting in inconsistencies and discontinuities in the final generated task data stream, which increases the post-processing burden of downstream applications.

[0070] To address a series of existing problems, this application proposes a task migration and succession method. By improving and optimizing the method from three aspects—the migrating UAV, the successor UAV, and the UAV nest—the method comprehensively solves the aforementioned problems in the task migration process, improves the reliability and accuracy of the task migration process, enhances the consistency of task migration, and thus increases the success rate of task migration and succession.

[0071] The task migration and continuation execution method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, the task migration and succession system includes a migration drone 101, a succession drone 102, and a nest 103. The migration drone 101 and the nest 103 communicate via a dual-active session link, and the succession drone 102 and the nest 103 also communicate via a dual-active session link. Furthermore, the migration drone 101 and the succession drone 102 can also communicate via a dual-active session link.

[0072] For example, the mission migration and succession system may include a first UAV, a second UAV, and an edge computing node. The first UAV refers to the migration UAV 101 that is currently performing a mission and is about to or is losing a stable communication link with the ground control system or the UAV nest. The second UAV is the succession UAV 102 that the UAV nest has determined can take over the mission from the migration UAV. The edge computing node refers to a server with computing and storage capabilities deployed in or near the UAV nest, which serves as the central hub for mission succession processing. It is also called the UAV nest 103 or the UAV nest edge node.

[0073] Additionally, dual-active session links refer to the migration of a drone simultaneously establishing and maintaining two or more physically or logically independent communication links with the edge node of the drone nest. Examples include 5G public network links and point-to-point Wi-Fi links, such as 5G+4G, 5G+satellite links, Wi-Fi+Bluetooth, and other concurrent links, to improve the reliability of data transmission. During data transmission, data frames can be used, specifically migration data frames, which are structured data packets encapsulating all the necessary information for mission continuity.

[0074] Before describing the embodiments, the technical terms and data items involved are defined as follows:

[0075] watermark_id: Status watermark, used to ensure that data is processed exactly once;

[0076] task_slot_id: Task slot identifier, used to distinguish concurrent subtasks;

[0077] tile_id: The grid number in the task space (e.g., the map);

[0078] ts_w_start, ts_w_end: The starting point of the world timescale interval;

[0079] model_abi_id: Model and operator version fingerprint;

[0080] FAST corner detection is an algorithm for quickly detecting key pixels in an image. ORB features are an algorithm that combines corner detection and feature description. Both are used to extract key information in an image that can be used for matching.

[0081] Shadow context: A temporary, non-public memory area that stores the memory state of task modules such as trackers and mappers;

[0082] Production context: The memory area for the formal business state that provides services to the outside world, including the effective configuration and data of the storage tracker and mapper.

[0083] In one exemplary embodiment, such as Figure 2 As shown, a method for task migration and continuation execution is provided, which is applied to... Figure 1 Taking the task migration and continuation execution system in the example, the following steps 201 to 203 are used for illustration. Among them:

[0084] Step 201: The migrating UAV responds to the mission migration command, generates mission migration data based on mission operation status data and multimodal sensor data, and sends the mission migration data to the successor UAV and the UAV nest; the mission migration data includes incremental status packets and multimodal breakpoint markers.

[0085] For example, during mission execution, the migrating drone can spontaneously detect or predict whether the migration triggering conditions are met. If the conditions are met, a mission migration command can be generated, triggering the mission migration event. Optionally, the migrating drone can also report real-time status data to the drone nest, where the drone nest detects whether the migration triggering conditions are met. If they are met, a mission migration command is generated and sent to the migrating drone. In other words, each drone can spontaneously detect the conditions during mission execution, or the drone nest can perform status checks on each drone currently executing a mission to determine whether the migration triggering conditions are met.

[0086] For example, the migration trigger condition can be a combination of one or more conditions, including but not limited to the signal strength of the communication link being continuously lower than a preset strength threshold for a first preset duration, and the remaining flight time being less than a second preset duration; for example, when the migrating drone detects that the signal strength (RSRP) of its main communication link (such as 4G / 5G) is lower than -105dBm for 3 consecutive seconds, or when its predicted remaining flight time minus the return flight time is less than 5 minutes, the migration trigger condition is met.

[0087] When a mission migration event is triggered, the migrating drone can generate mission migration data based on the mission operation status data at the current time / time period and multimodal sensor data. This mission migration data includes incremental status packets and multimodal breakpoint markers. In this example, to proactively initiate mission migration before a complete link failure, the migrating drone monitors its own status and communication quality in real time. Once the triggering conditions are met, the migrating drone executes a status snapshot, capturing the context of the current mission execution, including but not limited to the list of targets being tracked, flight path planning, and onboard sensor parameters. This data, combined with multimodal breakpoint markers accurately describing the breakpoint, is assembled into a migration frame, which is then sent to the successor drone and the drone nest.

[0088] For example, the migrating drone can synchronously send task migration data to the successor drone and the drone nest. When a task migration event is triggered, the migrating drone can report the event to the drone nest, allowing the drone nest to determine a successor drone that can take over the relevant task and send its information to the migrating drone. This enables the migrating drone to communicate directly with the successor drone and send task migration data to it. Alternatively, the migrating drone can send the task migration data to the drone nest, which then determines the successor drone and sends the data to it. For example, the drone nest can select drones without task conflicts from the drone cluster as successor drones based on preset predictions. The successor drones can be one or more, each capable of performing different tasks from the migrating drone.

[0089] For example, the migrating drone can send the mission migration data to the successor drone and the nest through a dual-active session link. That is, the migration frame corresponding to the mission migration data can be sent concurrently through the dual-active link. By utilizing the redundancy of the two links, at least one set of mission migration data can successfully reach the nest edge node in order to start the mission succession process.

[0090] In one optional implementation, a dual-active session link can be established between the migrating drone, the receiving drone, and the nest based on a handshake configuration. This includes, but is not limited to, other concurrent link combinations such as 5G+4G, 5G+satellite link, and Wi-Fi+Bluetooth. Based on this, task migration data can be sent to the receiving drone and the nest via the dual-active session link. The task migration data can carry a status watermark, which is used to indicate that the same data is injected and consumed only once. This avoids the same migration frame being used and consumed multiple times after being sent by multiple links, thus preventing data redundancy.

[0091] For example, the drone nest can establish a handshake configuration with both the migrating and follow-up drones via protocol handshakes. This handshake configuration defines the basic agreements at the channel layer, ensuring data transmission compatibility and avoiding silent incompatibility. For example, the handshake configuration may include: QoS agreements, message patterns, and active-active session policies; where QoS agreements define the quality of service levels for different data layers (L0, L1, L2); for example, L0 layer must use reliable transmission (such as TCP or QUIC with retransmission), while L1 / L2 layers can use best-effort transmission. Message patterns define the message middleware mode used for communication between the two parties, such as whether to use a publish / subscribe (Pub / Sub) mode or a request / response (Req / Rep) mode, and define the message topic structure and namespace. Active-active session policies specify the specific scheduling strategy for active-active sessions (5G+Wi-Fi), such as dual transmission at L0 layer (concurrent transmission) or dynamic selection of the optimal path based on link quality.

[0092] For example, by establishing active-active session links between the migrating drone and the nest, and between the receiving drone and the nest, the migrating drone can send task migration data to the nest based on the active-active session link with the nest, while the nest can send task migration data to the receiving drone. Through these active-active session links, the reliable arrival of critical data (Layer 0) can be guaranteed even in weak network and high packet loss environments, improving the success rate of task handover.

[0093] For example, the task migration data can also carry a state watermark. For instance, when the migration drone generates the task migration data, it can attach a state watermark to it. This state watermark is used to confirm idempotency boundaries during subsequent state injection, semantic deduplication, and merging, ensuring that the data is processed exactly once. For example, when the migration drone generates a migration frame F_tx, it attaches a state watermark (watermark_id). For example, this watermark can be generated using a Lamport logical clock or a monotonically increasing sequence number, and its purpose is to ensure that the migration frame is processed exactly once.

[0094] Step 202: Receive mission migration data from the drone, inject state into the mission migration data to generate an injected state, and send the mission execution data collected in the injected state to the drone nest.

[0095] For example, the follow-up drone can receive mission migration data from the migrating drone sent by the nest, or it can directly receive mission migration data sent by the migrating drone. Upon receiving the mission migration data, the follow-up drone can store the mission migration data locally, and perform handover point alignment with the migrating drone based on the mission migration data, i.e., execute state injection. After completing the state injection, it generates an injected state and sends the mission execution data collected in the injected state (i.e., at the handover point) to the nest.

[0096] For example, when performing state injection, the follow-up drone maintains a list of consumed state watermarks (watermark_id). The follow-up drone only performs injection operations on incremental segments corresponding to unconsumed watermarks, avoiding the repeated injection of the same data due to dual-active links.

[0097] For example, before receiving the mission migration data, the follow-up drone can first enter a warm-up process, that is, complete the warm-up based on the lease configuration. This lease configuration is used to define semantic-level conventions so that the state generated by the migrating drone can be correctly understood and reproduced by the follow-up drone. In an optional implementation, the convention model and operator version fingerprint, preprocessing and postprocessing operator hashes, and coordinate system reduction can jointly constitute the lease configuration to ensure semantic consistency in the subsequent migration and injection processes.

[0098] For example, the data structure for lease configuration can be defined as: {Lease_Config={model_id(16B): unique identifier of the core task model (such as YOLOv7, FAST-LIO); pre_ops_hash(8B): code hash of preprocessing operators (such as image normalization, point cloud distortion removal); post_ops_hash(8B): code hash of postprocessing operators (such as NMS, trajectory fusion); quant_profile: quantization configuration (such as INT8 symmetric quantization); coord_spec: coordinate system reduction (such as WGS-84, ENU Northeast-Sky coordinate system); abi_ver: application binary interface (ABI) version number of the model and operators; ttl_s: lease validity period (Time-To-Live), in seconds; update_policy: update policy (such as STRICT or GRACE); rollback_flag: rollback flag;}. Among them, the unique identifier model_id of the core task model, the code hash pre / post_ops_hash of the pre / post-processing operators, and the coordinate system specification coord_spec together constitute the version fingerprint, operator hash, and coordinate system specification.

[0099] For example, the lease configuration also includes an update policy (update_policy), which is a lease configuration update mechanism. This mechanism is used for version conflict detection. When the drone verifies the lease, it compares the local model operator version number (abi_ver) with the abi_ver in the lease configuration issued by the drone's pod. The comparison policy can include a STRICT policy and a GRACE policy. When the STRICT policy is executed, if update_policy is STRICT, then the drone's local version... This version must be strictly consistent with the lease version; if inconsistent, the verification will fail, and the successor drone must immediately pull the new model or operator micropackage from the nest. Otherwise, the injection process will be aborted, and a lease inconsistency alarm will be reported. When executing the GRACE policy, if update_policy is GRACE, and the local version of the successor drone is behind the lease version (e.g., only minor version incompatibility), the system allows the successor drone to continue using the old version to complete this succession injection before the current lease's ttl_s expires, but the asynchronous update must be completed before the next task handshake.

[0100] For example, machine B reads the agreed lease configuration and verifies whether its local model identifier (model_id) and operator hash (pre / post_ops_hash) are consistent with the lease. If they are consistent, the required model and operators are loaded from flash memory into the inference cache (e.g., GPU memory), a preheating mapping table is generated, and lightweight preheating is completed. If the model is missing or the version is incompatible (and the lease policy is STRICT), machine B must pull the corresponding components from the nest in micro-package increments, load them, and then proceed to the next step. This preheating process ensures that the interpreter used by machine B to restore the state is consistent with the encoder used by machine A to generate the state, ensuring that machine B can accurately parse the task migration data sent by machine A and ensuring the consistency of the migration data.

[0101] In addition, the lease configuration also includes a rollback mechanism. If rollback_flag is set, it means that the nest requires a forced rollback, and the next drone must abandon injection and roll back to the self-check state.

[0102] Furthermore, after completing the status injection, the follow-up drone can continue its mission from the point of interruption of the migration drone and collect mission execution data to send to the nest.

[0103] Step 203: Receive task migration data and task execution data through the machine nest, and perform fusion processing on the task migration data and task execution data to obtain target task data.

[0104] When using a dual-active session link for data transmission, the task migration data and task execution data may be received by the nest multiple times. Therefore, the nest needs to perform data fusion processing on at least one copy of the task migration data and at least one copy of the task execution data it receives. In addition, there may be some duplicate data in the task migration data and task execution data near the handover point. Therefore, data fusion processing is also required to obtain complete and continuous target task data.

[0105] For example, when the data fusion (i.e., semantic merging) is performed, the state watermark_id is used as the transaction boundary of exactly-Once, so that the same state watermark_id is consumed only once for the same semantic primary key (K_sem). Specifically, for each migration frame of task migration data and each data frame of task execution data, a semantic primary key can be constructed. This semantic primary key is used to indicate the task description information of the data frame at the task level. The semantic primary key is used to perform fusion processing on each migration frame and each data frame to obtain the complete target task data.

[0106] For example, the nest edge node receives and parses the migration frame, generates a semantic primary key based on the multimodal breakpoint marker, and performs deduplication and merging on migration frames with the same semantic primary key sent by different migrating drones or the same drone at different times to obtain continuous and non-redundant task segments.

[0107] Task information is understood and reorganized at the semantic level, rather than the data packet level. The semantic key is a unique identifier used to refer to a specific spatiotemporal event, even if that event is observed by different drones from different perspectives. Merging migration frames with the same semantic key allows for the integration of multi-source information and the filling of gaps in single-source information, resulting in a more complete and accurate task description. For example, if two drones simultaneously observe an area, their respective migration frames may only contain partial target information due to occlusion. However, since they share the same semantic key, the nest edge node can perform a union operation on their target lists to reconstruct the complete scene.

[0108] Furthermore, the nest can publish target task data, such as performing atomic recovery releases. It can use a two-phase commit to lock resources. The first phase is a pre-commit, which is used to lock batch resources. The second phase is a formal commit, which is used to generate a recovery release stream carrying a release watermark.

[0109] The aforementioned task migration and follow-up execution method is applied to a task migration and follow-up execution system, which includes a migrating UAV, a follow-up UAV, and a nest. The migrating UAV responds to a task migration command, generates task migration data based on task operation status data and multimodal sensor data, and sends the task migration data to the follow-up UAV and the nest. The task migration data includes incremental state packets and multimodal breakpoint markers. Next, the follow-up UAV receives the task migration data, injects a state into the data to generate an injected state, and sends the task execution data collected under the injected state to the nest. Finally, the nest receives the task migration data and the task execution data, and fuses them to obtain the target task data. In this application, during mission migration, the migrating UAV can generate mission migration data including incremental state packets and multimodal power-off markers. The incremental state packets accurately represent the mission state of the migrating UAV before handover, while the multimodal breakpoint markers accurately represent the UAV's own state and environmental state at the handover point through multimodal feature data. This enables accurate position domain alignment even in signal-limited environments, especially GPS-denied environments, solving the handover failure problem caused by excessive reliance on GPS in existing technologies. This not only improves the accuracy and consistency of mission handover and ensures data stream quality, but also enhances the timeliness and robustness of mission handover, thereby increasing the success rate of mission succession.

[0110] In one exemplary embodiment, a method for generating task migration data is provided, such as... Figure 3 As shown, step 201 above, "generating task migration data based on task running status data and multimodal sensing data," may include steps 301 to 303. Wherein:

[0111] Step 301: Obtain lease configuration and task running status data, and construct a task semantic profile based on the lease configuration and task running status data.

[0112] Among them, the task semantic profile is used to represent the vectorized description of the task features to be transferred.

[0113] For example, the UAV reads the mission operation status data and lease configuration to construct a mission semantic profile P_sem, which is a vectorized description of the core features of the current mission; for example, P_sem={mission type, number of key targets, fault tolerance window, map coupling degree, target dynamics, remaining time slots}.

[0114] For example, the method for constructing partial vectors in the task semantic profile P_sem can be as follows: the target dynamics can be quantified as the average value of the pixel velocity vector magnitudes of all key targets (such as human figures and vehicles) within the most recent N frames (e.g., N=10), i.e., Σ|v_i | / n, where v_ i Let be the optical flow velocity of the i-th target, and n be the total number of targets. The map coupling degree can be set according to the task type. For example, the mapping task strongly depends on the SLAM map, so the value is high (e.g., 1.0). The target tracking task weakly depends on the map, so the value is medium (e.g., 0.5). The routine inspection task does not depend on the map, so the value is low (e.g., 0.1).

[0115] Step 302: Based on the task semantic profile, perform hierarchical mapping of the task running status data to generate incremental status packages.

[0116] The incremental data packet includes the L0 critical layer, the L1 context layer, and the L2 heavy data layer.

[0117] Based on this, the migrating UAV can generate a hierarchical mapping table based on the task semantic profile P_sem and lease configuration, defining three layers: L0 key layer: containing data that must be reliably reached, such as task pointer, progress index, key field MBM.L0 reference, model version fingerprint, and status watermark sequence number; L1 context layer: containing context that affects the continuity of the task, such as short-term trajectory fragments, simplified detection results (boxes, labels), and local map summaries; L2 heavy data layer package: containing high-bandwidth data, such as keyframes, sparse point cloud blocks, and high-dimensional appearance features.

[0118] Furthermore, the migration drone can also configure a corresponding bitrate for each layer of data. For example, the bitrate configuration process may include: calculating the bandwidth budget based on link quality observation data; calculating the bitrate for each layer based on the weights assigned to each layer according to the task semantic profile, combined with the bandwidth budget, to form an encoding configuration that includes the bitrate. In other words, read the link quality observation data, estimate the bandwidth budget; and allocate the bitrate to each layer based on the weights and bandwidth budget for each layer.

[0119] For example, machine A reads the link quality observation data of the dual-active session (such as bw_ meas The measured bandwidth is used to perform exponential smoothing prediction, which is then used to calculate the bandwidth budget bw for the next window. # _ next (i.e., bw_) total For example, the bandwidth budget bw for the next window. # _ next =α*bw_ meas +(1-α)*bw # _ prev The packet loss budget for the next window. # _ next =α*loss_ meas +(1-α)*loss # _ prevWhere # represents the _hat symbol, and bw # _ prev loss # _ prev For historical predicted values ​​of link bandwidth and packet loss, loss_ meas To accurately measure packet loss, the smoothing factor α is preferably 0.6, an empirical value obtained through extensive field communication tests. This value is effective in scenarios involving high-speed drone movement and frequent link jitter, significantly impacting link bandwidth (bw). # ) and packet loss # The prediction achieves a good balance between stability and sensitivity. If α is too high (e.g., 0.9), the predicted value is too sensitive to instantaneous jitter; if α is too low (e.g., 0.2), it is sluggish in responding to trend changes in the link.

[0120] The above code control solution performed on machine A is to allocate code rates b_ for layers L0, L1, and L2. L0 b_ L1 b_ L2 For example, an objective function can be constructed such as maximizing Σw_ i *U(b_ Li ), where i belongs to {L0, L1, L2}, and the weight w_ i From the task semantic profile P_sem; for example: in a static inspection scenario, w_ L0 =0.4、w_ L1 =0.5、w_ L2 =0.1 (L1 context layer is more important); in target tracking scenarios, w_ L0 =0.55、w_ L1 =0.35、w_ L2 =0.10 (critical layer L0 is the most important); in the surveying scenario, w_ L0 =0.35、w_ L1 =0.25、w_ L2 =0.40 (L2 importance for heavy data layers). Here, the utility function U(b) = log(1 + b / k) represents the diminishing marginal returns of the bitrate; k is a smoothing constant, for example, k = 0.1 * bw_ total (Based on testing experience). Among them, Σb_ Li ≤bw_ total (Total bandwidth constraint), and b_ L0 ≥bw_ L0_min (Minimum guaranteed bandwidth constraint for critical layers).

[0121] For example, this solution process can employ a hybrid strategy of water-filling with lower bound constraints and projected gradient. The water-filling algorithm is used to obtain an initial solution without lower bound constraints, and the projected gradient method is used for iterative adjustment to make b_ L0 The iteration termination condition can be set to a relative gain of less than 1% if its lower bound constraint is satisfied; the obtained solution result (b_ L0 b_ L1 b_ L2 This will be written into the encoding configuration C_enc.

[0122] Based on this, the application encoding configuration C_enc and the layer mapping table are used to generate incremental state packets. For example, machine A uses C_enc (bitrate) and the layer mapping table (content) to locate the difference fields through keyed hashing and generate incremental state packets (L0 / L1 / L2). Subsequently, priority scheduling can be performed on the incremental state packets through a dual-active session. For example, the L0 critical layer is concurrently transmitted and forward error correction is applied on the dual-active session.

[0123] Step 303: Based on the visual features and inertial measurement information in the multimodal sensing data, and the task progress in the task running status data, generate multimodal breakpoint markers.

[0124] The multimodal breakpoint marker includes key fields and extended fields. By fusing visual features from multimodal sensor data, inertial measurement information, and mission progress from mission operation status data, a multimodal breakpoint marker that can be resolved across different aircraft is generated. In other words, by combining the UAV's own state and the reason for mission interruption, a multimodal breakpoint marker (MBM) is generated. The MBM is a lightweight and highly robust data structure that establishes a unified and accurately reproducible spatiotemporal anchor point (breakpoint) between aircraft A and aircraft B, even in environments where GPS signals are missing.

[0125] The integration is reflected in the field composition of MBM, such as: visual features for providing spatial geometric anchoring (what aircraft A sees); inertial measurement information for providing short-term relative attitude and motion estimation (how aircraft A moves); providing track continuity when visual features fail or matching is difficult; and mission progress for providing mission-level context (which step aircraft A has completed, such as task_slot_id or task space grid number tile_id). Cross-body resolution means that MBM does not rely on aircraft A's unique internal coordinate system or temporary state, but uses features that can be independently resolved and matched by aircraft B (such as hash values ​​and pre-integrated summaries).

[0126] The generation of multimodal breakpoint markers (MBMs) can include constructing key fields and extended fields. For example, the generation process of key fields can include: extracting stable image patches from visual features to generate a visual feature hash; performing short-window pre-integration on inertial measurement information to obtain an inertial measurement summary; and generating key fields based on the visual feature hash, the inertial measurement summary, and the task progress identifier in the task running status data. The key fields correspond to the MBM.L0 field, characterized by extremely small data size (e.g., ≤256 bytes) and high reliability requirements. They are typically prioritized and transmitted concurrently along with the L0 key layer in the incremental state packet.

[0127] In one alternative implementation, the specific implementation of constructing the key fields may include:

[0128] Obtaining the visual feature hash (vo_keypatch_hash): From the visual features of machine A (such as the FAST corner points or ORB features of the current frame), select the top-K (e.g., K=16) image patches (keypatch) that are stable in time (e.g., continuously tracked for more than N frames) and evenly distributed; uniformly scale and normalize the top-K image patches to a standard size (e.g., 32×32 pixels) to generate the visual feature hash (vo_keypatch_hash).

[0129] For example, the SimHash (Similarity Hash) algorithm (instead of cryptographic hashing such as SHA) can be used to hash the descriptors (such as BRIEF) of K normalized patches, generating, for example, a 64-bit vo_keypatch_hash. In SimHash, similar inputs (i.e., similar image patches observed by machine B at the same location) will produce hash values ​​with very close Hamming distances. In some scenarios, machine B only needs to calculate the vo_keypatch_hash of its current field of view and compare it with the hash value of machine A (e.g., Hamming ≤ 6) to quickly achieve coarse alignment of the location domain. Alternatively, vo_keypatch_hash can also be generated using other perceptual hashing algorithms (such as pHash, aHash) or a location recognition index based on the bag-of-words (BoW) model.

[0130] Acquisition of Inertial Measurement Summary (imu_Δ): Pre-integration is performed on the IMU measurements (angular velocity, acceleration) of machine A within the most recent short time window (e.g., 100ms before the MBM timestamp ts_w). The result of the pre-integration, imu_Δ (i.e., Δ angular velocity, Δ acceleration), constitutes a relative motion summary independent of the initial attitude, which is used to assist vo_keypatch_hash in coarse attitude alignment. Especially when machine B matches the hash value but the attitude is inconsistent, imu_Δ provides a verification of the motion trend.

[0131] Furthermore, the visual feature hash vo_keypatch_hash, inertial measurement summary imu_Δ, task progress identifier (such as task_slot_id), world timestamp ts_w, frame ID frame_id, map hash map_hash, etc., are combined to form the key field MBM.L0.

[0132] For example, the process of generating the extended field may include: extracting appearance information corresponding to the task target from the visual features contained in the multimodal sensing data to generate a re-identification feature vector; and / or, identifying key geometric points of the local environment from the visual features to generate local geometric anchor points; and generating the extended field based on the re-identification feature vector and / or the local geometric anchor points.

[0133] In one alternative implementation, the extended field may contain re-identification feature vectors or local geometric anchors for target refinement registration, to support refinement registration during subsequent state injection processes.

[0134] Correspondingly, this extended field corresponds to the MBM.L1 extended field, and its data size can be slightly larger than L0, used to correct the coarse alignment results. The specific construction process may include:

[0135] A re-identification feature vector (reid_vec) is generated. If the task is target tracking, machine A extracts the appearance information of the currently tracked key target (e.g., a specific pedestrian or vehicle) from visual features. Using a lightweight re-identification (Re-ID) model, this appearance information is encoded into a feature vector (reid_vec), for example, reid_vec_8×2 bytes (8 targets, each with 2 bytes of quantized features). Machine B uses this reid_vec to match candidate targets within its field of view, achieving accurate handover of key targets.

[0136] Local geometric anchors (local_geom_anchor) are generated. If the task is mapping or surveying, machine A identifies stable and easily triangulated key geometric points (e.g., building corners, geometric centers of landmarks) in the local environment from visual features. The position of the anchor in the local coordinate system (e.g., (u, v, σ), i.e., pixel coordinates and depth / parallax) is recorded as local_geom_anchor. Machine B uses the local geometric anchors and their local map or real-time observations to perform Perspective-n-Point (PnP) solving or graph optimization to accurately correct the L0 coarse alignment residuals.

[0137] In this embodiment, a task semantic profile is constructed based on lease configuration and task running status data. Based on the task semantic profile, the task running status data is hierarchically mapped to generate an incremental status package. Furthermore, multimodal breakpoint markers are generated based on visual features and inertial measurement information in multimodal sensor data, as well as task progress in task running status data. Using this method, complete incremental status packages and multimodal breakpoint marker data can be obtained, providing reliable data support for subsequent task continuation and improving the completeness and accuracy of migration data.

[0138] In one exemplary embodiment, another process for constructing a semantic profile P_sem is provided, which specifically includes quantizing one or more of the following dimensions:

[0139] Target dynamism D_ target This dimension characterizes the intensity of motion of the core target in the mission. For video reconnaissance missions, the average velocity of the tracked target in the frame can be calculated; for example, the velocity can be estimated using optical flow or the displacement of the target's centroid between consecutive frames. The calculation formula can be: D_ target =(Σ|v_ i |*w_ i ) / Σw_ i , where v_ i w_ represents the velocity of the i-th target, in meters per second. i The focus weight for the i-th target is specified by the task instruction, or defaults to 1 if not specified; summation is performed across all tracked targets. High-speed moving vehicles (e.g., D_target > 15) require lower migration latency than stationary buildings (D_target = 0).

[0140] Scenario complexity C_ scene This dimension characterizes the richness and disorder of elements in the task scenario. A simple implementation is to count the number of independent targets detected per unit time (e.g., 1 second), and the calculation formula can be: C_ scene =N_ obj / T_ interval; where N_ obj For time interval T_ interval The average number of targets detected within the scene. A busy intersection with 50 pedestrians (higher C_scene value) is more likely to have a higher C_scene value than an empty field (C_ scene (Low values) require higher coding rates and computing resources to process.

[0141] Information Value V_ info This dimension represents the contribution of the currently collected information to the task objective and can be evaluated based on rules or models. For example, in a task to find a specific vehicle, when the vehicle appears in the frame, V_ info It can be set to a high value (e.g., 0.9); when the scene only contains irrelevant street views, V_ info This is a low value (e.g., 0.1). In some implementations, a pre-trained scene classification or event detection model can be used to output a score of information value.

[0142] In this embodiment, to achieve efficient data transmission and intelligent resource scheduling, a semantic profile P_sem is embedded into each frame of migration data. Nest edge nodes and follow-up drones can parse this profile and adaptively adjust their behavior. For example, when D_ target When C_ is high, the system will prioritize ensuring transmission latency; when C_ scene When V_ is very high, a higher compression ratio may be used to ensure transmission within limited bandwidth; when V_ info At very low levels, the system can even decide to temporarily reduce the frame rate or resolution.

[0143] Furthermore, the semantic profile P_sem can also include the target occlusion rate O_ target This metric, calculated by analyzing the proportion of pixels within the target detection bounding box that are covered by other objects, helps determine whether multi-UAV collaborative observation is needed to obtain a complete view. Optionally, the dimensions and calculation method of the semantic profile can be customized according to specific task types, and this configuration can be distributed as part of the lease configuration to ensure the consistency of the entire system.

[0144] In an exemplary embodiment, where the incremental state packet includes an L0 critical layer, an L1 context layer, and an L2 heavy data layer, and the multimodal breakpoint marker includes critical fields and extended fields, such as Figure 4 As shown, step 201 above, "sending mission migration data to the successor drone and the drone nest," may include steps 401 to 403. Wherein:

[0145] Step 401: Based on the code rate corresponding to the L0 key layer, send the L0 key layer and key fields after applying forward error correction to the connecting drone and the nest.

[0146] Step 402: Based on the code rate corresponding to the L1 context layer, send the L1 context layer and extended fields to the connecting drone and the nest.

[0147] Step 403: Based on the code rate corresponding to the L2 heavy data layer, send the L2 heavy data layer to the connecting drone and the nest.

[0148] For example, machine A can perform priority scheduling through a dual-active session. This means that the L0 critical layer and the critical field MBM.L0 of the breakpoint marker are transmitted concurrently on the dual-active session (5G and Wi-Fi), i.e., both links send the same data packets simultaneously to maximize the arrival probability. Simultaneously, forward error correction (FEC) is performed on the L0 critical layer, and fec_mode (e.g., RS (Reed-Solomon) encoding, Turbo encoding, LDPC encoding, etc.) is applied to the L0 layer to further improve reliability in weak network conditions. Then, at the L1 context layer, based on b_ L1 Flexible bitrate transmission. In the L2 heavy data layer, transmission is done in blocks using the remaining bandwidth, and can be interrupted or preempted.

[0149] Based on this priority scheduling strategy, the follow-up UAV can also perform a two-stage state injection. In the first stage, coarse alignment is performed based on the L0 key layer and the key field MBM.L0. In the second stage, fine alignment is performed based on the L1 context layer and / or the L2 heavy data layer, as well as the extended field MBM.L1.

[0150] Based on this, such as Figure 5 As shown, step 202 above, "receiving mission migration data via a follow-up UAV, injecting state into the mission migration data, and generating an injected state," may include steps 501 to 503. Among them,

[0151] Step 501: When the follow-up drone receives the L0 key layer and key fields, it writes the data of the L0 key layer into the shadow context, and matches the key fields with the real-time sensing data collected by the follow-up drone to establish a coarse alignment of the breakpoint location domain.

[0152] For example, before the injection is performed on machine B (the follow-up drone), a series of preparation and self-check operations need to be performed. For instance, machine B creates a shadow subscriber based on the agreed handshake configuration. This shadow subscriber subscribes to the migration data topic of machine A without affecting machine B's current (if any) task. Machine B uses this to verify the compatibility of message patterns, QoS, and data structures (schemas). If the self-check fails, it is reported immediately and does not proceed to the subsequent warm-up.

[0153] After warm-up, the follow-up UAV writes the received L0 key layer data into the shadow context before the optimal injection time, and matches it with the real-time sensor data collected by the follow-up UAV to establish a coarse alignment of the breakpoint location domain. It should be noted that before performing state injection, the B-machine needs to determine the optimal injection time. For example, the B-machine can construct and solve the injection risk function based on link quality observation data and airborne thermal management status to determine the optimal injection delay. The injection risk function is obtained by weighting multiple risk items, including at least two of the following: state staleness risk, link loss risk, and airborne thermal management risk. Then, based on the optimal injection delay and the current time, the optimal injection time is determined. It should be noted that the specific form of the injection risk function can be adjusted according to the actual application scenario, adding or removing risk items.

[0154] The injection risk function is used to determine the optimal injection timing to minimize the risk function. Injecting into machine B as early as possible is not necessarily better. Injecting too early may result in incomplete L0 / L1 data (link risk) or the state being outdated before machine B takes off (staleness risk).

[0155] For example, the injected risk function can be composed of at least three risk weighted fusions: state staleness risk obtained by assessing state staleness and target motion error, link loss risk obtained by assessing link round-trip delay and packet loss probability, and airborne thermal management risk inferred based on device temperature and power consumption models.

[0156] For example, the staleness risk can be defined as: staleness(t) = Δt / TTL + γ_1*V_ target *Δt; where Δt is the (estimated) total latency from state generation to injection; TTL is the state tolerance window (e.g., 500ms) defined in the lease or semantic profile; V_ target γ_1 is the target velocity estimated in P_sem; γ_1 is the motion error coefficient (e.g., 0.3). This term represents the risk that the state will fail due to the passage of time and the target's motion.

[0157] For example, the risk of link loss can be defined as: loss_ risk (t)=1-P_ L0 (t). Where P_ L0 (t) is the probability that the L0 critical layer (via dual-active concurrent transmission) will be fully present before time t. In one alternative implementation, this risk can be approximated as: loss_ risk (t)=1-exp(-(rtt / rtt_ ref +pkt_ loss )); where rtt and pkt_ lossIt is the estimated average round-trip time and packet loss rate for a dual-active link; rtt_ ref This is a reference latency (e.g., 100ms). This indicates the risk of injection failure due to poor network conditions causing critical data (L0) to fail to arrive.

[0158] For example, airborne thermal management risk can be defined as: therm_ risk (t)=max(0,(T_ cpu -T_ safe ) / (T_ crit -T_ safe )); where T_ cpu This is the current processor (CPU / GPU / NPU) temperature of machine B; T_ safe This is the safe temperature threshold (e.g., 70°C); T_ crit This is the critical temperature (e.g., 90°C). This indicates the risk that the injection operation (involving model loading and calculation) may cause thermal overload on the B machine.

[0159] Furthermore, machine B discretly searches for t within the allowed injection window using a fixed step size (e.g., 100 ms), selecting the moment that minimizes R(t) as the optimal moment t_. inject * This is used to minimize the total risk function R(t):

[0160] R(t)=λ_1*staleness(t)+λ_2*loss_ risk (t)+λ_3*therm_ risk (t);

[0161] Where t is the future injection time evaluated by machine B (the delay relative to the current time t_now), staleness(t) is the state staleness risk, and loss_ risk (t) represents the risk of link loss, therm_ risk (t) represents airborne thermal management risk. The weights λ_1, λ_2, and λ_3 are derived from the task semantic profile P_sem, reflecting the task's sensitivity to different risks. For example, in the inspection (static) scenario, the weights are [0.4, 0.3, 0.3] (slightly higher tolerance for obsolescence); in the tracking (dynamic) scenario, the weights are [0.6, 0.3, 0.1] (most sensitive to obsolescence λ_1); and in the surveying scenario, the weights are [0.35, 0.25, 0.4] (sensitive to thermal management λ_3 due to high computational cost).

[0162] The following provides a specific numerical calculation example to illustrate the calculation process for minimizing the risk of injection timing.

[0163] In a target tracking scenario, aircraft A is tracking a dynamic target and preparing to return, while aircraft B is preparing to take over. The corresponding task type is target tracking. This scenario is most sensitive to state staleness, and the risk weights are set as follows: λ_1 = 0.6 (staleness weight), λ_2 = 0.3 (link loss weight), and λ_3 = 0.1 (hot management weight).

[0164] Assume that after machine B has finished preheating, at t_ deadline (For example, 500ms after takeoff) before the optimal injection time t_ is searched in steps of 100ms, within the interval t = [100ms, 200ms, 300ms, 400ms, 500ms]. inject * .

[0165] Next, input the state parameters (observed at t=0), RTT (average round-trip time) = 80ms, pkt_loss (average packet loss rate) = 2%, V_target (target velocity estimate) = 5m / s, TTL (state effective window) = 500ms, RTT_ ref (Reference delay) = 100ms, γ_1 (motion error coefficient) = 0.3, T_ cpu (Current CPU temperature of machine B) = 75°C, T_ safe (Safe temperature) = 70°C, T_ crit (Critical temperature) = 90°C.

[0166] Furthermore, the risk function is defined as staleness(t) = Δt / TTL + γ_1*V_ target *Δt, loss_ risk (t)=1-exp(-(rtt / rtt_ ref +pkt_ loss (This is a simplified example, assuming the risk does not change with t; in practice, it can be modeled as a function of t.) therm_ risk (t)=max(0,(T_ cpu -T_ safe ) / (T_ crit -T_ safe (This is also a simplified example, assuming that the risk does not change with t, but in reality it can be modeled as the instantaneous temperature rise caused by the injected computational load).

[0167] Taking t=200ms as an example, the system assesses the risk of performing injection after 200ms (t=0.2s). Here, Δt (total latency) is assumed to be t, i.e., Δt=0.2s. The staleness(0.2) is calculated as (0.2s / 0.5s) + (0.3*5m / s*0.2s), resulting in staleness(0.2) = 0.4 + 0.3 = 0.7. The loss is then calculated. risk (t=0.2s) (For simplicity, assume rtt and pkt_loss are constant predictions within the evaluation window), loss_ risk (0.2) = 1 - exp(-(80ms / 100ms + 0.02)) = 1 - exp(-(0.8 + 0.02)) = 1 - exp(-0.82) ≈ 1 - 0.4404 = 0.5596, (for simplicity, assume T_cpu is a constant prediction value within the evaluation window) therm_ risk (0.2) = max(0, (75°C-70°C) / (90°C-70°C)) = max(0, 5 / 20) = 0.25, calculate the total risk R(0.2) = λ_1*staleness(0.2) + λ_2*loss_risk(0.2) + λ_3*therm_ risk (0.2) = (0.6 * 0.7) + (0.3 * 0.5596) + (0.1 * 0.25) = 0.42 + 0.16788 + 0.025 = 0.61288.

[0168] Furthermore, machine B will repeat the above calculation for all t values ​​(100ms, 300ms, 400ms, 500ms) within the search window. For example, if the calculated value of R(t=100ms) is 0.65, and the calculated value of R(t=300ms) is 0.60, the system will compare all R(t) values ​​and select the moment that minimizes R(t) (in this example, t=300ms, with the lowest risk value of 0.60) as the optimal injection time t_inject*. If the calculated t_ inject * If t_ arrives before the L0 critical layer is complete, then inject * It will be postponed until L0 is fully assembled.

[0169] Based on this, machine B performs a two-stage injection. The first stage is L0 atomic injection and coarse alignment, which involves injecting the L0 key layer and the key field MBM.L0 of the multimodal breakpoint marker in the migration data to establish coarse alignment of the breakpoint location domain. The second stage is patch injection and fine registration, which involves injecting the L1 context layer and the extended field of the multimodal breakpoint marker at the optimal injection time to refine the coarse alignment and produce the injected state.

[0170] Accordingly, in t_ preheat Time (earlier than the optimal time t_) inject * Once the B-series aircraft confirms that the L0 key layer and MBM.L0 (key fields) are complete, it writes the L0 fields (such as task pointers and progress indexes) into its shadow context and uses MBM.L0's vo_keypatch_hash and imu_Δ to match it with its own real-time sensor data to establish a coarse alignment of the breakpoint location domain. It should be understood that this stage is lightweight, does not involve heavy L2 data or complex calculations, and can be completed quickly before the B-series aircraft takes off.

[0171] Step 502: When the UAV receives the extended field, L1 context layer and / or L2 heavy data layer, at the optimal injection time, write the L1 context layer and / or L2 heavy data layer into the state slot of the upstream task context, and refine the registration of the coarsely aligned residuals based on the extended field.

[0172] For example, at the calculated optimal time t_ inject * (Typically, this occurs when Unit B has just taken off or is about to reach the breakpoint), Unit B performs patch injection. Idempotency boundaries are confirmed based on the state watermark_id, and only incremental fragments of the unconsumed L1 context layer and L2 heavy data layer are applied. Feature vectors or local geometric anchors in MBM.L1 (extended field) are used to refine the registration of the coarse alignment residuals of L0. L1 / L2 data (such as trajectories, detection results, and map tiles) are written to the state slots of the upstream task context (such as the tracker and mapper).

[0173] Step 503: Update the shadow context to the production context and generate the injected state.

[0174] After completing the two-stage injection, the shadow context switches to the production context, the B machine officially produces the injected state, and an injection confirmation watermark is generated and sent back to the machine nest.

[0175] Furthermore, after the second stage of refined registration is completed, the follow-up UAV can also detect the location domain residual and lease verification results; when the location domain residual exceeds the preset threshold or the lease verification fails, state rollback is performed; state rollback is used to restore the state before injection and generate an injection rollback record.

[0176] The injection rollback can be implemented using a memory snapshot (checkpoint) mechanism. Accordingly, before performing L0 atomic injection, the B machine performs a memory snapshot of its shadow context (i.e., the memory state of task modules such as the tracker and mapper), saving this snapshot (the state before injection). After refined registration is completed, the system immediately detects defined abnormal conditions, including: position domain residual > θ_ pos (For example, excessive reprojection error after refined registration); confidence level of key objects decreases by more than θ_ conf (For example, B loses the target that A was tracking immediately after taking over); the lease verification result is inconsistent with the current inference output (e.g., coordinate system mapping error); no confirmation acknowledgment is received from the nest within the specified time limit. Where θ_ pos θ_ pos This corresponds to the preset threshold.

[0177] Once any of the above conditions are triggered, Machine B will discard the currently modified (dirty) shadow context and use the previously saved memory snapshot to overwrite and restore its state to the state before injection. Machine B generates an injection rollback record, reports it to the nest, and requests re-injection or downgrades to a relay-only collection mode according to the strategy (e.g., injection plan).

[0178] Based on this, if the rollback is not triggered, machine B will also perform post-injection consistency verification. Machine B compares the predicted trajectory of the two time windows before and after injection with the real-time observation. If the deviation is within the threshold, the shadow context will be officially switched to the production context, the external release stream will be started, and the injection completion report will be recorded.

[0179] In this embodiment, by employing hierarchical priority scheduling, two-stage state injection, and optimal injection timing calculation, issues such as state obsolescence and state contamination due to injection failures can be avoided. Furthermore, injection rollback is achieved through memory snapshots, improving the real-time performance and reliability of task handover. Moreover, through active-active sessions and hierarchical priority scheduling, stable and reliable execution of task migration and continuation in signal-constrained environments can be ensured, further enhancing the success rate of task handover.

[0180] In one exemplary embodiment, such as Figure 6 As shown, step 203 above may include steps 601 to 603. Wherein:

[0181] Step 601: Determine the semantic primary key corresponding to each data segment of the task migration data and the semantic primary key corresponding to each data segment of the task execution data.

[0182] The semantic primary key serves as the semantic fragment index for the corresponding data fragment, indicating the task description information of the corresponding data fragment.

[0183] For example, at the nest edge node, migration data ingestion and candidate set construction can be performed. The nest aggregates all migration frames (incremental status packets, MBM) from migrating and follow-up drones, as well as the injected status and injection confirmation watermark of the follow-up drone. The nest performs integrity and lease consistency checks on the received data (e.g., hash verification, whether the model and operator version fingerprint model_abi_id is consistent with the current nest lease, etc.). Based on the verified frames, a replayable index and arrival records (recording link quality) are built according to the status watermark watermark_id, stored in a buffer, forming a candidate fragment set; those that fail verification are recorded in the unqualified fragment list.

[0184] Nest can perform task-level semantic deduplication and merging, including parsing task migration data and lease configurations, constructing semantic primary keys for fragments in the task migration data, and using the semantic primary keys to index and identify fragments. Nest does not use packet IDs or status watermarks (watermark_id) as primary keys (these are only used for idempotency), but instead generates a semantic primary key K_sem for each candidate fragment. This primary key defines what the data segment describes at the task level.

[0185] For example, the semantic primary key K_sem may include at least one of the following: task space tile identifier in the spatiotemporal domain of the data fragment, world timescale interval, model and operator version fingerprint, multimodal anchor hash, view encoding, and task slot identifier; the nest can read the task space tile identifier (tile_id) and world timescale interval (ts_w_start, ts_w_end) in the spatiotemporal domain of the limited fragment, where tile_id is the grid number of the task space (e.g., a map).

[0186] Optionally, Nest can extract model and operator version fingerprints (model_abi_id) from the lease configuration to prevent the incorrect merging of detection results from different models (e.g., YOLOv5 and YOLOv7). Nest can also parse multimodal anchor hashes (mbm_anchor_hash) from the multimodal breakpoint markers contained in the task migration data. This hash can be taken from vo_keypatch_hash of MBM.L0 and used to anchor spatial locations.

[0187] Optionally, the system can quantize and generate view codes based on sensor attitude information in the mission migration data. For example, it can read the yaw, pitch, and roll angles from the sensors, quantize each angle (e.g., yaw) to a specific level (e.g., 5° per level, ranging from 0 to 71), and package the three level codes (e.g., 7+7+7 bits) into a compact view code (e.g., 3 bytes). The semantic primary key K_sem can also include a task slot identifier (task_slot_id, used to distinguish concurrent subtasks). The system uses the semantic primary key for indexing and segment identification; in other words, the system builds a semantic segment index (draft) based on the semantic primary key K_sem.

[0188] Similarly, the nest can also construct a corresponding semantic primary key for each data segment of the mission execution data sent by the drone.

[0189] Step 602: Based on the semantic primary key corresponding to each data segment, determine the semantic conflict type between the current data segment and other data segments.

[0190] Among them, semantic conflict types include any one of repetition, overlap, and contradiction.

[0191] For example, the nest can determine semantic conflicts between fragments based on the semantic primary key constructed for any data fragment. The types of semantic conflicts can be classified as repetition, overlap, or contradiction. Based on the determination results, a conflict set is generated for subsequent merging decisions. The nest traverses the index draft and calculates the similarity between fragments to determine conflicts, such as repetition, overlap, or contradiction. For example, if the fragment signatures (sig_frag) are exactly the same, or if S_time (time overlap) ≈ 1 and S_anchor (anchor proximity) ≥ θ_a and S_view (view similarity) ≥ θ_v and S_semantic (semantic consistency) ≥ θ_s, then it can be determined that the fragment is a repetition. Repetition is usually caused by concurrent transmission of dual active links.

[0192] For example, if S_time > 0 and (S_anchor ≥ θ_a or S_semantic ≥ θ_s), then it can be determined as segment overlap, which is usually caused by the migrating drone and the following drone observing the same target in the handover area. If S_time > 0 and S_semantic < θ_s, such as the migrating drone and the following drone giving mutually exclusive labels to the same target in the same space-time (K_sem is similar) (e.g., truck vs. bus), then it can be determined as segment contradiction.

[0193] Wherein, θ_a is the anchor nearest neighbor threshold. For example, S_anchor uses the Hamming distance from mbm_anchor_hash, and θ_a (e.g., Hamming distance ≤ 6) is obtained by optimizing the ROC curve on the development set. θ_v is the view similarity threshold. For example, S_view uses the quantization level difference of view_code, and θ_v (e.g., level difference ≤ 2) is considered too close. θ_s is the semantic consistency threshold, set according to the task type. For example, for detection tasks, the IoU of the detection boxes is used, and θ_s ≥ 0.5 (PASCALVOC standard); for mapping tasks, the overlap of map tiles is used, and θ_s ≥ 0.6 (experimental calibration value).

[0194] As one possible implementation, if the task transfer data (e.g., an L2 heavy data layer) contains depth information or point cloud blocks, the computation of S_semantic preferentially uses 3D IoU. For example, the point clouds of two segments are voxelized in world coordinates (aligned according to MBM and coord_spec) (e.g., at 10cm resolution), and then their 3D voxel IoU is calculated, which provides a more robust consistency criterion than 2D IoU. If there is no depth, it degenerates to projecting onto a common plane and then calculating 2D IoU.

[0195] Step 603: Based on the fusion strategy corresponding to the semantic conflict type, the current data segment and other data segments are fused to obtain the target task data.

[0196] Based on the semantic conflict type identified in the conflict set, a corresponding merging strategy is adopted, and based on the applied merging strategy, merged fragments for subsequent release are generated. This semantic merging process can be completed during decision-making and execution.

[0197] For example, if the semantic conflict type is duplication, then the data segment with higher hierarchical integrity, or the data segment with higher link quality, or the data segment corresponding to the task execution data is retained. If the semantic conflict type is overlap, then the current data segment and other data segments are frame-matched and merged; wherein, when the semantic conflict type is determined to be overlapping with complementary views, a frame-matching and merging strategy is executed; when the semantic conflict type is determined to be overlapping with overly close views, a selective coverage strategy is executed. If the semantic conflict type is contradiction, then the data segment corresponding to the task execution data is retained.

[0198] For example, the nest can generate a merge plan with the following priorities:

[0199] Inconsistent leases will result in direct isolation and exclusion from merging. If a duplicate is identified, the one with higher hierarchical completeness will be retained (e.g., a copy with all L0 / L1 / L2 present is preferred over one with only L0). If they are the same, the one with higher link quality (based on arrival records) will be retained. If they are still the same, the segment from the state already injected by the follow-up drone will be prioritized.

[0200] If an overlap is determined, and if S_view ≤ θ_v is complementary (e.g., θ_v is very low, indicating a large difference in viewpoints) and semantics are consistent, then frame interpolation merging (complementary viewpoints) is performed. Additionally, frame interpolation merging includes: aligning the time sequence of segments from the migrating and following drones for frame-level filtering (e.g., deblurring, removing low-confidence segments), fusing viewpoints (e.g., taking the union of point clouds, or fusing depth in mapping mosaics), and generating merged segments with richer information. If S_view ≥ θ_v (e.g., a difference in position ≤ 2), then optimal coverage is performed, retaining the better segment based on at least one metric such as priority, completeness, link quality, and injection confirmation.

[0201] If a contradiction is determined, the data segment from the successor drone supported by the injected confirmation watermark will be given priority; otherwise, a vote will be taken based on the confidence level; if no resolution can be reached, the data will be moved to the queue of pending evidence.

[0202] Further, execute the merge plan, generate merge fragments, and update the index draft to a semantic fragment index (e.g., update from draft to official).

[0203] Based on this, candidate release batches are assembled according to the merged fragments, release transaction IDs are assigned to the candidate release batches, and a two-phase commit consisting of a pre-commit and a formal commit is executed. The pre-commit is used to lock batch resources, and the formal commit is used to generate a recovery release stream carrying a release watermark. Alternatively, candidate release batches are assembled based on the merged fragments, given release transaction IDs, and a two-phase commit is executed, which includes a pre-commit for locking batch resources and a formal commit for generating a recovery release stream carrying a release watermark.

[0204] Accordingly, based on the merged fragments and the formal index, candidate release batches are assembled according to time and task slot identifier (task_slot_id), and each batch is assigned a unique pub_txn_id (release transaction ID) and pub_watermark (release watermark). Next, a pre-commit is performed to lock the batch resources (this lock is a logical lock, not an operating system lock). The nest writes the mapping relationship between the pub_txn_id and all the original status watermarks (watermark_ids) contained in the batch (from migrating or relaying drones) into the release ledger (release ledger record). Simultaneously, the status watermarks (watermark_ids) are marked as Pending in the replayable index. When assembling a new batch, all Pending status watermarks (watermark_ids) are skipped, achieving logical locking of data fragments and preventing duplicate releases.

[0205] For example, the Nest generates a recovery release stream (initial version) carrying the pub_watermark and pushes it to downstream consumers. Upon receiving confirmation (Ack) from the downstream, the Nest marks the pub_txn_id in the release ledger as effective and the corresponding watermark_id as published. If the commit fails or times out, a rollback is performed (the ledger record is deleted, and the watermark_id status is reset to available), releasing the logical lock.

[0206] In one optional implementation, the nest also performs consistency and replayability verification on the recovery release stream (initial version). For example, it initiates replay sampling, retrieves the original migration frames from the replayable index, reruns the merge and release logic, and compares the results with the initial version to ensure release traceability; batches that pass the verification are upgraded to the recovery release stream (stable).

[0207] In this embodiment, semantic deduplication and merging at the semantic primary key task level can solve the problems of data redundancy and semantic conflicts, improving the continuity and consistency of task data flow. Furthermore, through a two-phase commit and replayable review mechanism, precise one-time processing can be achieved, ensuring the traceability and consistency of the published flow.

[0208] In an exemplary embodiment, a complete implementation process for UAV-nest collaborative task migration and continuation execution is also provided, which can be summarized as follows: In the last 10 seconds before UAV A is about to return, the nest first aligns the protocol and model semantics and establishes a dual-active link; UAV A sends the task state differential and multimodal breakpoint marker (MBM) according to the critical layer priority; after predictive warm-up, UAV B atomically injects the critical layer and patch layer at the optimal injection time; the nest performs task semantic-level deduplication and merging on the fragments of A and B, and resumes the release flow in a two-phase commit release. The entire process is guaranteed to be exactly-once and replayable by state watermarking and release transactions, forming a true collaborative migration and continuation execution.

[0209] The following example, using a typical handover sequence (T-10s to T~0), illustrates the collaborative process of this application. This embodiment involves three parties: A (migrating drone), B (relay drone), and the drone nest (edge ​​node), and includes the following steps:

[0210] Step 1, Preparation Phase (T-10s); In this phase, the nest and B-machine perform baseline preparation before handover. In some embodiments, the nest generates lease configurations and dual-active sessions including concurrent 5G and LAN links based on fleet configuration and link quality observation data.

[0211] For example, the nesting device generates and distributes handshake and lease configurations based on on-site link quality observation data and task type. The handshake configuration is used to lock QoS and message patterns; the lease configuration is used to ensure model and operator consistency. Simultaneously, the nesting device establishes a dual-active session (e.g., 5G+Wi-Fi concurrent link). The B-machine creates a shadow subscription and performs data structure (schema) and QoS self-checks based on the handshake configuration. If the self-check passes, the B-machine loads or pulls a consistent model and operators from the nesting device based on the lease configuration, completing the warm-up process.

[0212] In this phase, the drone nest reads fleet configuration and link quality observation data, and establishes a consistency baseline between the middleware and the model on the nest side: through protocol handshake and capability negotiation, it generates handshake configuration (QoS and message pattern) and lease configuration (model and operator agreement), and creates a dual-active session (5G and LAN concurrent session) based on the current field communication status. Then, the nest distributes the handshake configuration and lease configuration to the connecting drone, and starts the dual-active session to carry subsequent migration data, as well as to constrain the format of encoding and tagging, check injection, and version consistency during warm-up.

[0213] By configuring leases and handshakes, we can ensure the consistency of migrating and receiving drones at the semantic level, such as models, operators, and coordinate systems. This avoids the problem of incorrect parsing of state data due to version inconsistencies and improves the accuracy of task handover.

[0214] Step 2, Migration Data Generation and Transmission (T-5s); In this stage, machine A begins outputting task migration data. In some embodiments, lease configuration and active-active sessions are used to process task runtime status data and multimodal sensor data to generate task migration data, which includes incremental status packets and multimodal breakpoint markers.

[0215] Accordingly, Machine A generates incremental state packets (L0 / L1 / L2) and multimodal breakpoint markers (MBM) (L0 / L1) based on link budget and task semantics. Machine A adds a state watermark to these data frames and encapsulates them into migration frames. Machine A, through a dual-active session, prioritizes (e.g., concurrent transmission with forward error correction (FEC)) sending the L0 critical layer and the multimodal breakpoint markers (MBM.L0); the L1 / L2 layers are sent elastically depending on bandwidth. The nest receives the migration frames and establishes a replayable index and candidate buffer.

[0216] For example, during the return countdown phase, Machine A reads mission running status data and multimodal sensor data (visual, inertial, and localization) based on the handshake configuration and lease configuration, and performs two collaborative processes: First, it performs adaptive incremental encoding of the mission state according to mission semantics and link quality, distinguishing between the critical layer and the context layer to obtain an incremental state packet (a hierarchical sequence containing the critical layer and extended layers). Second, it fuses visual features, inertial measurements, and mission progress to generate a breakpoint marker MBM (multimodal breakpoint marker) that can be parsed across different machine bodies. The critical layer and breakpoint marker MBM are transmitted preferentially using a dual-active session, with a replayable state watermark for subsequent verification.

[0217] Step 3: Perform predictive warm-up and state injection (T-3s to T-1s); In this stage, the B machine takes over the execution state. In some embodiments, task migration data is received, execution state injection is configured according to the lease, and the injected state is generated.

[0218] Correspondingly, light injection (T-3s) refers to the process where, after receiving L0 and MBM.L0, machine B performs atomic injection of L0 in the shadow context (a temporary, non-public memory region) to establish coarse alignment of the breakpoint location domain and output an echo checksum. If the checksum fails, machine B can request a retransmission or delayed injection. Patch injection (T-1s) refers to the process where machine B performs patch injection at the optimal computation time t_ inject * The L1 / L2 and multimodal breakpoint marker MBM.L1 are patched and refined for registration. After successful injection, aircraft B generates an injected status and sends an injection confirmation watermark back to the nest. Aircraft A continues its return journey and stops migration output.

[0219] In this phase, after the drone connects to the dual-active session, the lease configuration, incremental state packets, breakpoint marker MBM, and link quality observation data are read to calculate the balance between injection risk and timeliness, and determine the timing of state injection. A lightweight warm-up is first performed to load and verify the model and operators. Then, patch-style injection is performed at the optimal time, outputting the injected state (with the same task context as the deployed drone) and an injection confirmation watermark for atomic recovery deployment. Simultaneously, injection rollback records are generated in case of failure or version incompatibility for necessary retries and alerts.

[0220] Step 4: Perform semantic merging and atomic recovery release (T~0); In this stage, the machine nest is responsible for data fusion and external release. In some embodiments, the migrated data and injected state are aggregated, semantic deduplication and merging are performed at the task level, and the release recovery release stream is launched.

[0221] Alternatively, after completing state injection, the follow-up drone resumes the interrupted task and sends the new task execution data to the nest edge node in the form of a recovery release stream. The recovery release stream is the data stream generated by the follow-up drone, and its format, content, and semantics are consistent with the task data stream of the migration drone before the interruption.

[0222] Furthermore, the nest edge nodes aggregate incremental state packets, breakpoint markers (MBM), injected states, and injection confirmation watermarks from machines A and B. While ensuring consistent lease configurations, they perform task-level semantic deduplication and merging, construct a semantic fragment index, and deduplicate and merge nest assembly batches based on semantic primary keys. They then assign release transaction IDs and release watermarks, execute two-phase commit, and form a recovery release stream (stable). Based on this, the recovery release stream (continuous task output) is released to downstream task consumers (such as path planning, target identification, target tracking, mapping modules, or surveying mosaicking) for continuous consumption. This is used for energy and heat management and round-robin scheduling optimization, while the injection confirmation watermark is used for closed-loop handover transactions. At this point, machine B seamlessly continues executing field tasks based on the injected state.

[0223] Optionally, read the runtime load metrics generated by the recovery release stream and the energy and heat monitoring data (charging power, nest temperature rise, edge computing power occupancy) on the nest side, calculate the energy-heat-computing power budget for the handover window, and generate energy and heat budget strategies and migration parameter tuning suggestions. Make minor adjustments to the handshake configuration and adaptive incremental coding parameters before the next round of handover (e.g., minimum code rate for critical layers, latency threshold for extended layers), update the round-robin scheduling records, and form a closed-loop optimization.

[0224] In this embodiment, QoS and message patterns are locked through handshake configuration to avoid incompatibility with silent operations; dual-active sessions use concurrent links to ensure priority arrival at the critical layer (L0); lease configuration ensures consistency of models, operators, and coordinate systems between A and B. Breakpoint markers (MBM) anchor the visual-inertial-task system as cross-machine identifiable breakpoints. Incremental state packet layering (L0 / L1 / L2) ensures a minimum sustainable dataset even in weak network conditions. Predictive warm-up and two-stage injection transform the timing of injection from passive reception to a computable optimal decision (such as subsequent risk calculation), avoiding injection of expired or mismatched states. Task-level merging is performed using semantic primary keys via nesting, rather than data block concatenation. State watermarking and publishing transactions achieve precise one-time processing, two-stage commit, and replayable verification, ensuring data stream continuity, stable delivery, and traceability.

[0225] Furthermore, this embodiment defines three types of key atomic transactions to ensure the provability and reliability of the migration and continuation process. Among them, the watermarking atom carries a state watermark for each migration frame. Machine B only injects watermarks that have not been consumed, and the nest uses watermark reconciliation to prevent duplicates / leakage. The injection atom is a two-phase process for Machine B using L0 shadow injection → verification → L1 / L2 patch injection. If any step fails (such as detecting residual exceeding limits), it rolls back to the pre-injection state (such as Checkpoint recovery). The publishing atom is a two-phase commit performed by the nest using the publishing transaction ID. If the commit fails, it automatically rolls back to the previous stable batch, ensuring that downstream consumers see a continuous data stream. For example, in a video surveillance task, the backend will present the user with a continuous, uninterrupted video stream; even if the user switches drones, they will not notice any jumps or interruptions in the image.

[0226] In this embodiment, the successful condition for complete cooperative migration and follow-up execution can be defined as: machine B at the optimal time t_ inject * The incremental status packet L0 and the key field MBM.L0 were successfully received and verified. Machine B successfully generated the injected status and injection confirmation watermark. Machine Nest completed the semantic merging of the time window and submitted the recovery release stream (stable) for downstream applications to continuously consume.

[0227] Optionally, this embodiment also provides alternative paths for failure or degradation. If L0 / MBM.L0 are not all present or verification fails, Machine B postpones injection and requests a retransmission. If the retransmission still fails, Machine B abandons injection and switches to a data acquisition relay mode, where the data nest is responsible for stitching the data stream. Optionally, if leases are inconsistent, Machine B fails verification, refuses relay, and can trigger a hot model update (or switch to data acquisition mode). Optionally, if the release submission fails, the data nest can roll back to the previous stable batch, retain replay evidence, and retry.

[0228] The method provided in this application embodiment can significantly improve the success rate of task handover in complex environments such as weak network and GPS denial, ensure the continuity and consistency of task data flow, and improve the overall efficiency of UAV swarm collaborative operation.

[0229] In an exemplary embodiment, a closed-loop optimization mechanism is also provided, which enables the entire collaborative migration and continuation execution method to have adaptive and iterative optimization capabilities. Based on this, the above method may further include the following steps:

[0230] Step 1: Based on the operational load metrics and energy / thermal monitoring data of the restored release stream, generate migration parameter tuning recommendations.

[0231] After the nest edge nodes resume stable publishing, they continuously monitor the performance of the publishing stream and, combined with the nest's own operational status, generate operational load metrics and energy / heat monitoring data. Specifically, operational load metrics are derived from statistics on the publishing stream, including, for example: Deduplication Rate (DR), which represents the ratio of deduplicated or merged segments to the total number of candidate segments; False Merging Rate (MER), representing the proportion of erroneously merged segments identified through replay sampling verification or manual checking; End-to-End Deployment Latency (T_e2e), representing the time difference from receiving the first frame of relevant migration data from the nest to its merging and publishing; Publishing Jitter (J_pub), representing the standard deviation of T_e2e between adjacent stable publishing batches (pub_txn_id); and Merge Quality Score (Q_merge), representing a comprehensive score, for example, Q_merge = w1 * hierarchical completeness + w2 * viewpoint complementarity gain - w3 * retransmission overhead, where w1, w2, and w3 are dynamically determined by the task semantic profile.

[0232] The thermal monitoring data comes from real-time monitoring of the nest edge nodes and charging equipment, and includes, for example: edge computing power occupancy, which refers to the load percentage of the nest edge node's CPU / GPU / NPU when executing the semantic merging algorithm; nest temperature rise, which refers to the real-time temperature of the edge computing unit and charging pile; and charging power, which refers to the current nest's fast charging power curve, used to determine whether the handover window affects the fast charging priority strategy.

[0233] Based on the above statistical data, the system calculates the energy-heat-computing power budget for the handover window and generates migration parameter tuning suggestions. For example, if the release jitter (J_pub) is too large and the edge computing power consumption is too high, the parameter tuning suggestion may be: appropriately increase the minimum bitrate bw_L0_min of the L0 critical layer in S24, while reducing the bitrate b_L2 of the L2 heavy data layer, sacrificing the integrity of L2 in exchange for the stable arrival of L0, and reducing the merging computation pressure.

[0234] If thermal monitoring data shows that the cell temperature rises too quickly, one possible parameter tuning suggestion is to adjust the weight λ_3 of thermal management risk therm_risk(t) so that the injection timing t_inject* of machine B tends to avoid the peak power consumption period of cell computing and charging.

[0235] Step 2: Apply the migration parameter tuning recommendations to the next round of migration data generation process to form a closed-loop optimization.

[0236] In this embodiment, the migration parameter tuning suggestions are stored and fed back into the next handshake and migration data generation phase. For example, the code-controlled solver calculates b_ in the next round. L0 At that time, it will read the updated bw_ L0_min The injection timing calculator reads the updated λ_3 weights. Based on this, migration strategies (such as encoding rate and injection timing) can adaptively iterate according to actual merge quality, network fluctuations, and nest load, improving the system's robustness and overall performance under continuous operation.

[0237] In this embodiment, a closed-loop optimization mechanism can adaptively adjust the migration strategy according to the actual operating conditions, thereby improving the overall efficiency under continuous operation.

[0238] In one exemplary embodiment, an optional implementation process for GPS denied scenario (V-INS) handover is also provided to illustrate the robustness of the method of this application in environments where GPS (Global Positioning System) signals are denied or unreliable (e.g., urban canyons, indoors, or under interference), particularly the application of multimodal breakpoint markers (MBM).

[0239] In this embodiment, when machine A performs a task (e.g., indoor inspection) in a GPS-denied environment, the positioning information in its multimodal sensor data is unavailable or has low confidence when machine A generates MBM. Therefore, the pose_slam (SLAM pose) field in the MBM.L0 field may be empty or marked as invalid. Due to the multimodal characteristics of MBM, machine A can still rely on vision and inertial sensors. For example, machine A can still extract stable image patches and generate vo_keypatch_hash (e.g., 64-bit SimHash). This hash value is only related to what machine A sees and is independent of GPS. Machine A can still perform short-window pre-integration on IMU data to obtain imu_Δ (inertial measurement summary). If machine A is performing a mapping task, it can still generate local_geom_anchor (local geometric anchor). The anchor is extracted based on V-INS (visual inertial navigation system) in machine A's own coordinate system. Machine B (the follow-up machine) also prepares for the follow-up in a GPS-denied environment (e.g., taking off from an indoor nest).

[0240] Correspondingly, after receiving the L0 layer and MBM.L0, Machine B performs coarse alignment. Since there is no GPS, Machine B cannot perform global coordinate comparison. Instead, it relies on the visual feature hash vo_keypatch_hash. In its real-time visual stream within its V-INS system, Machine B calculates the vo_keypatch_hash of its current field of view and quickly matches it with the hash value sent by Machine A in the database (e.g., Hamming distance comparison). Once a match is successful (e.g., Hamming distance less than the threshold of 6), Machine B completes the coarse alignment of the position domain, confirming that it has seen the same scene seen by Machine A at the breakpoint. Simultaneously, imu_Δ is used to verify whether the motion trends of the two are consistent.

[0241] Furthermore, in the optimal injection t_ inject * At a certain time, machine B injects the L1 / L2 layer. At this point, machine B utilizes the `local_geom_anchor` (local geometric anchor point) in the extended field of `MBM.L1` to match and triangulate the geometric anchor point from machine A's coordinate system with the map (or real-time feature points) maintained by its local V-INS system, for example, through PnP solving or graph optimization. This process (refined registration) is used to accurately calculate the rigid body transformation (rotation and translation) between machine A's and machine B's coordinate systems, correcting the residuals from the L0 coarse alignment.

[0242] In the above, even if neither device A nor device B has GPS, device B can accurately recover the task status of device A (e.g., device A's V-INS map, the position of the target tracked by device A in device B's coordinate system) through visual hash matching (coarse) + geometric anchor point alignment (fine), achieving seamless execution. This demonstrates the decoupling and robustness of the MBM design of this invention for positioning signals.

[0243] In one exemplary embodiment, an exemplary scheme for degradation and recovery under extreme weak network (high packet loss rate) scenarios is also provided to illustrate the robustness and degradation guarantee mechanism of the method of this application under extremely poor network conditions (e.g., the overall link packet loss rate of dual-active sessions is consistently higher than 30%).

[0244] In this scenario, when machine A (the migrating drone) performs link quality estimation, it will detect extremely low effective throughput (bw). # ) and extremely high prediction packet loss rate (loss # Accordingly, when configuring the adaptive incremental encoder, the code control solver triggers a minimum guarantee mechanism. Specifically, b_ L0 ≥bw_ L0_min The constraint of (minimum guaranteed bandwidth for L0 critical layer) is forcibly activated, and the system allocates almost all available bandwidth budget to b_ L0(Critical layer), while compressing or even pausing b_ L1 (Context layer) and b_ L2 The bitrate allocation of the (heavy data layer) sacrifices the integrity of L1 / L2 to fully guarantee the transmission of L0.

[0245] Meanwhile, the encoding configuration C_enc will select a high-redundancy forward error correction (FEC) mode (fec_mode), such as using RS encoding with strong error correction capabilities, to increase data redundancy before physical layer transmission.

[0246] When performing dual-active priority scheduling, the system activates the highest reliability policy. Specifically, the L0 critical layer and the breakpoint marker MBM.L0 are transmitted concurrently on the dual-active session (5G and Wi-Fi). Concurrent transmission here means that the same data packets (carrying the same watermark_id) are copied and sent simultaneously through two physical links. Through the combination of semantic layering (L0 priority), high-redundancy FEC coding, and dual-path concurrent transmission, the L0 critical layer data logically obtains the highest transmission guarantee, maximizing its probability of reaching the B machine (the connecting drone), even though a large number of L1 / L2 layers may be dropped in the process.

[0247] In some scenarios, when machine B performs L0 atomic injection on the receiving side, its receiver will perform out-of-order reassembly and FEC decoding. Two situations may occur in this case: if machine B performs L0 atomic injection on t_ inject * Before the optimal injection time, if the complete L0 critical layer and MBM.L0 are successfully assembled through recovery via any link or FEC, coarse alignment can be performed. Then, machine B only uses the already arrived (potentially incomplete) L1 data for refined registration. Although the accuracy of the injected state may be compromised (e.g., loss of heavy data in L2, leading to a decrease in mapping accuracy), the critical pointer (L0) of the task is continued, and machine B can continue to execute the task, achieving system degradation.

[0248] If until t_ deadline If, by the latest injection deadline, the L0 layer of machine B is still not complete (e.g., critical packets are lost and FEC cannot be recovered), the injection verification will fail. At this point, the rollback mechanism is triggered. Machine B will not report the injection confirmation watermark, but will instead report the injection rollback record. According to the preset strategy, it will automatically switch to the relay-only collection mode.

[0249] Among them, the relay mode only means that machine B abandons the restoration of machine A's historical state, and instead starts from the current moment (T=0), as a brand new task executor, only collects multimodal sensor data within its field of view, and sends it to the nest according to the standard process (layering, encoding, watermarking).

[0250] In the case of downgrading, the hive will receive (incomplete) migration data from machine A and (new) acquisition data from machine B. Since machine B has not injected the state of machine A, the two data segments will be judged as contradictory or non-overlapping but with adjacent time sequences. The hive merging strategy will stitch the last valid segment of machine A with the starting segment of machine B at the breakpoint (e.g., align the timestamps) and release them in a unified manner to restore the release flow.

[0251] In summary, by prioritizing L0 and implementing a failover and degradation path for data collection after injection failure, the task data stream will not be interrupted even under extremely weak network conditions, ensuring the highest availability of the service.

[0252] In one exemplary embodiment, a specific process for semantic merging and conflict resolution in multi-machine (three-machine) handover is also provided to illustrate the scalability of the method of this application (especially semantic deduplication and merging) in more complex multi-machine handover scenarios.

[0253] Suppose aircraft A is about to return to base, and the nest simultaneously assigns aircraft B and C to take over aircraft A's mission. For example, aircraft B is responsible for taking over aircraft A's mapping mission in area A, and aircraft C is responsible for taking over aircraft A's tracking mission in area B. Alternatively, aircraft B and C are required to coordinate and take over the mission in the same area from different perspectives.

[0254] Around the handover point (T~0), the candidate fragment set of the nest may simultaneously gather fragments from machine A (migrated data), machine B (sequence data generated after injection), and machine C (sequence data generated after injection). All fragments must pass the lease verification to ensure that the model_abi_id (model and operator version fingerprint) used by the three parties A, B, and C are mutually compatible.

[0255] The nest constructs a unified semantic primary key (K_sem) for all fragments from parties A, B, and C, where K_sem = ⟨tile_id, ts_w_start, ts_w_end, model_abi_id, mbm_anchor_hash, view_code, task_slot_id>. K_sem maps all the heterogeneous data sources from the three parties (which may be executing different subtasks in their respective coordinate systems) into a unified task semantic space. Among them, tile_id and ts_w define the spatiotemporal domain, mbm_anchor_hash anchors the spatial position, view_code defines the viewpoint, and task_slot_id (task slot identifier) ​​is used to distinguish different subtasks (e.g., mapping vs. tracking).

[0256] In some scenarios, the system detects conflicts based on K_sem, which may lead to more complex conflict sets. Assume that the K_sem of machines A, B, and C all point to the same spatiotemporal tile (tile_id and ts_w overlap), and S_view (viewpoint) is determined to be too close (e.g., difference in tile size ≤ 2), triggering the optimal coverage strategy. The system will sort the fragments from A, B, and C according to a preset priority. This priority can be exemplarily set as follows: fragments carrying injection confirmation watermarks (from the injected state of B or C) are prioritized; fragments with higher hierarchical integrity (L0 / L1 / L2) are prioritized; and fragments with higher link quality (based on arrival records) or higher signal-to-noise ratio are prioritized. The system retains only the optimal fragment among the three for publication, achieving an N-to-1 optimal selection.

[0257] Suppose that S_ of A and B are detected view Complementary perspectives (e.g., A is looking directly ahead, B is looking from the side), while the S_ of C and B view If the viewing angle is too close, the merging plan will be implemented in two stages: Specifically, a best coverage strategy will be applied to C and B (as in the above case), retaining the better one (e.g., retaining B); further, the retained B segment and A segment will be combined with a frame interpolation merging strategy to generate a merged segment that integrates the viewing angle information of A and B (front view + side view).

[0258] Suppose A and B give contradictory L1 detection results for the same K_sem (same time and space, same target) (e.g., S_ semantic When <θ_s), the conflict resolution strategy is activated. The system checks the injected confirmation watermark. If fragment B carries the injected confirmation watermark while fragment A does not (A is migration data), the system prioritizes B (i.e., the injected state takes precedence). If neither A nor B has a watermark, or both have watermarks but still contradict each other, the fragment set corresponding to K_sem is moved to the pending confirmation queue for replay or manual arbitration. The fragment is temporarily not published to avoid publishing erroneous data.

[0259] The semantic merging mechanism in this embodiment decouples the merging logic of the data source (whether it is A, B, C or N devices) from the data content through K_sem; no matter how many drones participate in the collaboration, they can all be uniformly incorporated into the framework of conflict detection and merging strategy (optimization, frame supplementation), so that the recovery release flow finally released by the drone nest is single, complete and consistent at the task level, demonstrating its scalability.

[0260] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0261] Based on the same inventive concept, this application also provides a task migration and continuation execution apparatus for implementing the task migration and continuation execution method described above. The solution provided by this apparatus is similar to the solution described in the above method; therefore, the specific limitations in one or more task migration and continuation execution apparatus embodiments provided below can be found in the limitations of the task migration and continuation execution method described above, and will not be repeated here.

[0262] In one exemplary embodiment, such as Figure 7 As shown, a task migration and follow-up execution device is provided, applied to a task migration and follow-up execution system. The task migration and follow-up execution system includes a migrating UAV, a follow-up UAV, and a nest, and includes: a migration data generation module 701, a migration data injection module 702, and a data fusion module 703, wherein:

[0263] The migration data generation module 701 is used to generate task migration data based on task running status data and multimodal sensor data in response to the task migration command, and send the task migration data to the follow-up UAV and the nest; the task migration data includes incremental status packets and multimodal breakpoint markers.

[0264] The migration data injection module 702 is used to receive task migration data, inject status into the task migration data, generate an injected status, and send the task execution data collected in the injected status to the machine nest.

[0265] The data fusion module 703 is used to receive task migration data and task execution data, and to fuse the task migration data and task execution data to obtain target task data.

[0266] In one embodiment, the migration data generation module 701 includes:

[0267] The task profile building unit is used to acquire lease configuration and task running status data, and to build a task semantic profile based on the lease configuration and task running status data; the task semantic profile is used to represent the vectorized description of the task characteristics of the task to be migrated.

[0268] The status data generation unit is used to perform hierarchical mapping of task running status data based on task semantic profiles and generate incremental status packages; the incremental status packages include L0 key layer, L1 context layer and L2 heavy data layer.

[0269] The marker data generation unit is used to generate multimodal breakpoint markers based on visual features and inertial measurement information in multimodal sensing data, as well as task progress in task running status data; the multimodal breakpoint markers include key fields and extended fields.

[0270] In one embodiment, the labeled data generation unit is specifically used to extract stable image patches from visual features to generate a visual feature hash; perform short-window pre-integration on inertial measurement information to obtain an inertial measurement summary; and generate key fields based on the visual feature hash, the inertial measurement summary, and the task progress identifier in the task running status data.

[0271] In one embodiment, the labeled data generation unit is specifically used to extract appearance information corresponding to the task target from visual features to generate a re-identification feature vector; and / or to identify key geometric points of the local environment from visual features to generate local geometric anchor points; and to generate extended fields based on the re-identification feature vector and / or local geometric anchor points.

[0272] In one embodiment, the migration data generation module 701 further includes:

[0273] The session creation unit is used to establish a dual-active session link between the migrating drone, the receiving drone, and the drone nest based on the handshake configuration;

[0274] The data transmission unit is used to send task migration data to the successor drone and the drone nest based on a dual-active session link; the task migration data carries a status watermark, which is used to indicate that the same data is injected and consumed in a single instance.

[0275] In one embodiment, the incremental state packet includes an L0 critical layer, an L1 context layer, and an L2 heavy data layer. The multimodal breakpoint marker includes a key field and an extended field. The data transmission unit is specifically used to send the L0 critical layer and key field after forward error correction to the connecting drone and the drone nest according to the code rate corresponding to the L0 critical layer; to send the L1 context layer and extended field to the connecting drone and the drone nest according to the code rate corresponding to the L1 context layer; and to send the L2 heavy data layer to the connecting drone and the drone nest according to the code rate corresponding to the L2 heavy data layer.

[0276] In one embodiment, the migration data injection module 702 includes:

[0277] The first injection unit is used to write the data of the L0 key layer into the shadow context when the L0 key layer and key field are received, and to match the key field with the real-time sensing data collected by the drone to establish a coarse alignment of the breakpoint location domain.

[0278] The second injection unit is used to write the L1 context layer and / or L2 heavy data layer into the state slot of the upstream task context at the optimal injection time when the UAV receives the extended field, L1 context layer and / or L2 heavy data layer, and refine the registration of the coarsely aligned residuals based on the extended field.

[0279] The injection state generation unit is used to update the shadow context to the production context and generate the injected state.

[0280] In one embodiment, the device further includes:

[0281] The risk function construction module is used to construct and solve the injection risk function based on link quality observation data and airborne thermal management status, and determine the optimal injection delay. The injection risk function is obtained by weighting multiple risk items, which include at least two of the following: state staleness risk, link loss risk, and airborne thermal management risk.

[0282] The injection timing determination module is used to determine the optimal injection timing based on the optimal injection delay and the current time.

[0283] In one embodiment, the data fusion module 703 includes:

[0284] The semantic primary key configuration unit is used to determine the semantic primary key corresponding to each data segment of the task migration data and the semantic primary key corresponding to each data segment of the task execution data; the semantic primary key serves as the semantic segment index of the corresponding data segment and is used to indicate the task description information of the corresponding data segment.

[0285] The semantic conflict determination unit is used to determine the semantic conflict type between the current data segment and other data segments based on the semantic primary key corresponding to each data segment;

[0286] The fusion processing unit is used to fuse the current data fragment with other data fragments based on the fusion strategy corresponding to the semantic conflict type to obtain the target task data.

[0287] In one embodiment, the semantic conflict type includes any one of repetition, overlap, and contradiction. The fusion processing unit is configured to retain the data segment with higher hierarchical integrity, or the data segment with higher link quality, or the data segment corresponding to the task execution data if the semantic conflict type is repetition; to perform frame interpolation and merging on the current data segment and other data segments if the semantic conflict type is contradiction; and to retain the data segment corresponding to the task execution data if the semantic conflict type is contradiction.

[0288] Each module in the aforementioned task migration and continuation execution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0289] In an exemplary embodiment, a task migration and follow-up execution system is provided. The system includes a migration drone, a follow-up drone, and a drone nest. The migration drone is used to generate task migration data based on task operation status data and multimodal sensor data in response to a task migration command, and sends the task migration data to the follow-up drone and the drone nest. The task migration data includes incremental status packets and multimodal breakpoint markers. The follow-up drone is used to receive the task migration data, inject status into the task migration data to generate an injected status, and send the task execution data collected in the injected status to the drone nest. The drone nest is used to receive the task migration data and the task execution data, and perform fusion processing on the task migration data and the task execution data to obtain target task data.

[0290] For specific implementation methods, please refer to the relevant descriptions of the task migration and continuation execution methods above, which will not be repeated here.

[0291] When using this system for mission migration, the migrating UAV can generate mission migration data including incremental status packets and multimodal power-off markers. The incremental status packets accurately characterize the mission state of the migrating UAV before handover, while the multimodal breakpoint markers accurately characterize the UAV's own state and environmental state at the handover point through multimodal feature data. This enables accurate position domain alignment even in signal-limited environments, especially GPS-denied environments, solving the handover failure problem caused by the over-reliance on GPS in existing technologies. It not only improves the accuracy and consistency of mission handover and ensures data stream quality, but also enhances the timeliness and robustness of mission handover, thereby increasing the success rate of mission succession.

[0292] In one exemplary embodiment, a computer device is provided, which can be a migrating drone, a rendezvous drone, or a nest edge node, and its internal structure diagram can be as follows. Figure 8 As shown, the computer device includes a processor, memory, input / output interfaces, and a communication interface. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external devices; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a task migration and continuation execution method.

[0293] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0294] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the task migration and continuation execution method in any of the above embodiments.

[0295] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the task migration and continuation execution method in any of the above embodiments.

[0296] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the task migration and continuation execution method in any of the above embodiments.

[0297] It should be noted that the data involved in this application (including but not limited to data used for analysis, data stored, data displayed, etc.) are all information and data that have been fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0298] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0299] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0300] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for task migration and continuation execution, characterized in that, The method is applied to a task migration and follow-up execution system, which includes a migrating UAV, a follow-up UAV, and a UAV nest. The migrating drone responds to the mission migration command, generates mission migration data based on mission operation status data and multimodal sensor data, and sends the mission migration data to the successor drone and the drone nest; the mission migration data includes incremental status packets and multimodal breakpoint markers. The drone receives the mission migration data, injects a state into the mission migration data to generate an injected state, and sends the mission execution data collected in the injected state to the drone nest. The task migration data and the task execution data are received through the nest, and the task migration data and the task execution data are fused to obtain the target task data; The generation of task migration data based on task running status data and multimodal sensor data includes: Acquire lease configuration and task running status data, and construct a task semantic profile based on the lease configuration and task running status data; the task semantic profile is used to represent a vectorized description of the task characteristics of the task to be migrated. Based on the task semantic profile, the task running status data is mapped in layers to generate the incremental status package; the incremental status package includes an L0 key layer, an L1 context layer, and an L2 heavy data layer. Based on the visual features and inertial measurement information in the multimodal sensing data, and the task progress in the task running status data, the multimodal breakpoint marker is generated; the multimodal breakpoint marker includes key fields and extended fields.

2. The method according to claim 1, characterized in that, The generation of the multimodal breakpoint markers based on the visual features and inertial measurement information in the multimodal sensing data, and the task progress in the task running status data, includes: Stable image patches are extracted from the visual features to generate visual feature hashes; Short-window pre-integration is performed on the inertial measurement information to obtain an inertial measurement summary; The key field is generated based on the visual feature hash, the inertial measurement digest, and the task progress identifier in the task running status data.

3. The method according to claim 1, characterized in that, The generation of the multimodal breakpoint markers based on the visual features and inertial measurement information in the multimodal sensing data, and the task progress in the task running status data, includes: Extract appearance information corresponding to the task target from the visual features to generate a re-identification feature vector; and / or, identify key geometric points of the local environment from the visual features to generate local geometric anchor points; The extended field is generated based on the re-identification feature vector and / or the local geometric anchor point.

4. The method according to any one of claims 1 to 3, characterized in that, Sending the task migration data to the successor drone and the drone nest includes: A dual-active session link is established between the migrating drone, the receiving drone, and the nest based on the handshake configuration of the nest; Based on the dual-active session link, the task migration data is sent to the successor drone and the drone nest; the task migration data carries a status watermark, which is used to indicate that the same data is injected and consumed in a single instance.

5. The method according to any one of claims 1 to 3, characterized in that, The incremental state packet includes an L0 critical layer, an L1 context layer, and an L2 heavy data layer. The multimodal breakpoint marker includes critical fields and extended fields. Sending the task migration data to the successor drone and the drone nest includes: Based on the code rate corresponding to the L0 key layer, the L0 key layer and the key field after applying forward error correction are sent to the follow-up drone and the nest. Based on the code rate corresponding to the L1 context layer, the L1 context layer and the extended field are sent to the connecting drone and the nest; Based on the bitrate corresponding to the L2 heavy data layer, the L2 heavy data layer is sent to the connecting drone and the nest.

6. The method according to claim 5, characterized in that, The step of receiving the mission migration data through the follow-up drone, injecting a state into the mission migration data, and generating an injected state includes: Upon receiving the L0 key layer and the key field, the follow-up drone writes the data of the L0 key layer into the shadow context and matches it with the real-time sensing data collected by the follow-up drone to establish a coarse alignment of the breakpoint location domain. Upon receiving the extended field, the L1 context layer, and / or the L2 heavy data layer, the successor drone writes the L1 context layer and / or the L2 heavy data layer into the status slot of the upstream task context at the optimal injection time, and refines the registration of the coarsely aligned residuals based on the extended field. Update the shadow context to the production context and generate the injected state.

7. The method according to claim 6, characterized in that, The method further includes: Based on link quality observation data and airborne thermal management status, an injection risk function is constructed and solved to determine the optimal injection delay. The injection risk function is obtained by weighting multiple risk items, which include at least two of the following: state staleness risk, link loss risk, and airborne thermal management risk. The optimal injection time is determined based on the optimal injection delay and the current time.

8. The method according to any one of claims 1 to 3, characterized in that, The process of fusing the task migration data and the task execution data to obtain the target task data includes: Determine the semantic primary key corresponding to each data segment of the task migration data and the semantic primary key corresponding to each data segment of the task execution data; the semantic primary key serves as the semantic segment index of the corresponding data segment, and is used to indicate the task description information of the corresponding data segment; Based on the semantic primary key corresponding to each data segment, determine the semantic conflict type between the current data segment and other data segments; Based on the fusion strategy corresponding to the semantic conflict type, the current data segment and the other data segments are fused to obtain the target task data.

9. The method according to claim 8, characterized in that, The semantic conflict type includes any one of repetition, overlap, and contradiction. The fusion strategy based on the semantic conflict type is used to fuse the current data segment and the other data segments to obtain the target task data, including: If the semantic conflict type is repetition, then retain the data segment with higher hierarchical integrity, or retain the data segment with higher link quality, or retain the data segment corresponding to the task execution data; If the semantic conflict type is overlap, then the current data segment and the other data segments are frame-filled and merged. If the semantic conflict type is contradiction, then the data fragment corresponding to the task execution data is retained.

10. A task migration and continuation execution device, characterized in that, An apparatus for use in a mission migration and follow-up execution system, the mission migration and follow-up execution system comprising a migrating UAV, a follow-up UAV, and a UAV nest, the apparatus comprising: The migration data generation module is used to generate task migration data based on task running status data and multimodal sensor data in response to a task migration command, and send the task migration data to the successor UAV and the nest; the task migration data includes incremental status packets and multimodal breakpoint markers; The migration data injection module is used to receive the task migration data, inject a state into the task migration data, generate an injected state, and send the task execution data collected in the injected state to the nest. The data fusion module is used to receive the task migration data and the task execution data, and to fuse the task migration data and the task execution data to obtain the target task data; The migration data generation module includes: The task profile building unit is used to acquire lease configuration and task running status data, and construct a task semantic profile based on the lease configuration and task running status data; the task semantic profile is used to represent a vectorized description of the task characteristics of the task to be migrated. The status data generation unit is used to perform hierarchical mapping on the task running status data based on the task semantic profile to generate the incremental status package; the incremental status package includes an L0 key layer, an L1 context layer, and an L2 heavy data layer; The marker data generation unit is used to generate the multimodal breakpoint markers based on the visual features and inertial measurement information in the multimodal sensing data and the task progress in the task running status data; the multimodal breakpoint markers include key fields and extended fields.

Images