Control method and system of unmanned aerial vehicle, mobile terminal, storage medium

Abstract

Embodiments of the present application disclose a control method of a UAV, a mobile terminal, a control system and a storage medium. The control method comprises: sending a flight control session request to a server through a session portal bound with a target UAV; receiving session configuration information issued by the server, the session configuration information comprising a one-time session token and flight control application configuration information; presenting a flight control interaction interface based on the flight control application configuration information; obtaining a control right lease granted by the server when the one-time session token is valid; establishing a control link between the mobile terminal and the target UAV; and sending a flight control command through the control link, the flight control command carrying the control right lease. The method establishes a temporary flight control session through a session portal bound with a target UAV and issues flight control application configuration matched with the current UAV and task, so that the user can present a unified flight control interface without pre-installing a native application, reduces the temporary use threshold, and reduces problems such as mismatch between the flight control interface and the model.

Description

Technical Field

[0001] This application relates to the field of unmanned aerial vehicle (UAV) technology, and in particular to a control method, mobile terminal, control system, and storage medium for a UAV. Background Technology

[0002] Drones are frequently used in scenarios such as scenic area rentals, emergency rescue, and school teaching, requiring high frequency, short duration, and quick-to-use deployment. Traditional drone ground stations are mostly provided in the form of native desktop or mobile applications. Users typically need to pre-install the application, update the version, and grant system-level permissions before they can establish a control relationship with the drone. For users who only use it once or for a short period, the installation and initialization process is time-consuming, and different system and application versions can easily create a high barrier to entry. Moreover, the coexistence of different operating systems and application versions can easily lead to inconsistencies between the flight control interface's function set and the current drone model's configuration. Summary of the Invention

[0003] This application provides a control method, mobile terminal, control system, and storage medium for a drone, enabling users to load a flight control interface that matches the current drone without pre-installation, thus lowering the barrier to entry for temporary use.

[0004] In a first aspect, embodiments of this application provide a method for controlling a drone, the method being applied to a mobile terminal, the method comprising: sending a flight control session request to a server via a session entry bound to a target drone; receiving session configuration information issued by the server, the session configuration information including a one-time session token and flight control application configuration information; presenting a flight control interactive interface based on the flight control application configuration information; obtaining a control lease granted by the server when the one-time session token is valid; establishing a control link between the mobile terminal and the target drone; and sending flight control commands through the control link, the flight control commands carrying the control lease.

[0005] In one or more embodiments, the flight control application configuration information includes a cache list, and presenting the flight control interaction interface based on the flight control application configuration information includes: loading the flight control application according to the flight control application configuration information; registering a service worker thread after the flight control application is loaded for the first time; having the service worker thread cache flight control resources according to the cache list; and presenting the flight control interaction interface when the cached result meets preset interactive conditions.

[0006] In one or more embodiments, the step of caching flight control resources by the service worker thread according to the cache list includes: determining flight control resources that are allowed to be cached and flight control resources that are prohibited from being cached according to the security level of the flight control resources; obtaining communication quality information; and having the service worker thread cache the flight control resources that are allowed to be cached based on the communication quality information and the security level of the flight control resources.

[0007] In one or more embodiments, sending flight control commands through the control link includes: verifying the flight control commands, the verification including verification of control authority validity, command authorization, flight area compliance, and UAV flight parameter safety; and in response to the flight control commands passing the verification, sending the flight control commands through the control link.

[0008] In one or more embodiments, when the flight control session bound to the target UAV is a multi-terminal session, the method further includes: if the mobile terminal holds a valid control lease, receiving a control takeover request issued by the server, and in response to a takeover confirmation input, sending takeover confirmation information to the server so that the server performs a control transfer; if the mobile terminal does not hold a valid control lease, receiving task status information issued by the server, sending a control takeover request to the server, and receiving a new control lease issued by the server, wherein the new control lease is issued by the server when the original controlling mobile terminal meets a preset takeover strategy.

[0009] In one or more embodiments, presenting the flight control interaction interface based on the flight control application configuration information includes: obtaining the terminal capability parameters, flight permission information, communication quality information, and security configuration information of the mobile terminal; determining the interface mode and the set of available flight control functions based on the terminal capability parameters, the flight permission information, the communication quality information, and the security configuration information; and presenting the flight control interaction interface based on the interface mode and the set of available flight control functions.

[0010] In one or more embodiments, establishing a control link between the mobile terminal and the target UAV includes: acquiring near-field link parameters and far-field link parameters; and selecting and / or switching between a near-field control link and a far-field control link based on the near-field link parameters and the far-field link parameters.

[0011] In a second aspect, embodiments of this application provide a mobile terminal, including: a processor, and a memory communicatively connected to the processor; the memory stores computer program instructions executable by the processor, which, when executed by the processor, cause the mobile terminal to perform the control method as described in any embodiment of the first aspect.

[0012] Thirdly, embodiments of this application provide a control system for an unmanned aerial vehicle (UAV), including the UAV, a server, and a mobile terminal as described in the second aspect; the mobile terminal is communicatively connected to the UAV and the server respectively.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions or programs that, when executed by at least one processor, cause the at least one processor to perform the control method as described in any of the first aspects.

[0014] Fifthly, embodiments of this application also provide a computer program product, the computer program product including a computer program stored on a computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in the first aspect above.

[0015] The beneficial effects of this application are as follows: This application provides a control method, mobile terminal, control system, and storage medium for a drone. In the control method, a flight control session request is initiated through a session entry bound to the target drone. This maps the specific drone on the physical side into a manageable temporary flight control session, allowing users to enter the flight control process via methods such as scanning a code or near-field reading, without needing to pre-install native applications, complete version updates, or grant system-level permissions, thereby lowering the barrier to entry for short-term scenarios. The flight control application configuration information issued by the server along with the session is bound to the current target drone and the task. The mobile terminal then presents the flight control interface accordingly, ensuring that the interface resources and control set are consistent with the current drone model. This helps alleviate the problem of inconsistencies between the flight control interface function set and the drone model configuration when different operating systems and application versions coexist. Attached Figure Description

[0016] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0017] Figure 1 This is a schematic diagram of the architecture of an unmanned aerial vehicle (UAV) control system provided in an embodiment of this application; Figure 2 This is a structural block diagram of a mobile terminal provided in an embodiment of this application; Figure 3 This is a flowchart of a control method for an unmanned aerial vehicle (UAV) provided in an embodiment of this application; Figure 4 This is an interactive schematic diagram of multi-terminal control takeover provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] To facilitate understanding of this application, a more detailed description is provided below with reference to the accompanying drawings and specific embodiments. Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0020] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, the terms "first" and "second" used herein do not limit the data or execution order, but only distinguish between identical or similar items with essentially the same function and effect.

[0021] To facilitate understanding of the methods provided in the embodiments of this application, the unmanned aerial vehicle control system provided in the embodiments of this application will be introduced first.

[0022] Please see Figure 1 , Figure 1 A schematic diagram of the structure of a drone control system provided in some embodiments of this application is shown. The drone control system 1000 includes a mobile terminal 100, a server 200, and a drone 300. The mobile terminal 100 is communicatively connected to both the server 200 and the drone 300.

[0023] Mobile terminal 100 refers to an electronic device that allows operators to access the UAV control system 1000 and complete flight control interaction, including but not limited to smartphones, tablets, laptops, or desktop computers. Mobile terminal 100 is used to request a flight control session with server 200 to bind with the target UAV through a session entry, load and present the flight control interaction interface, establish a control link after obtaining a control lease, and send flight control commands carrying the control lease to UAV 300.

[0024] Specifically, the mobile terminal 100 loads the flight control application through a network-accessible runtime environment, such as through a system browser or a Progressive Web App (PWA). A PWA is an application that utilizes an application manifest, service worker threads, secure transmission protocols, and caching mechanisms to enable pages to be added to the home screen, have local resource caching, and manage background requests. When running the flight control application, the mobile terminal 100 can handle tasks such as sending session requests, parsing configurations, rendering the interface, caching resources, assessing link quality, encoding flight control commands, and interacting with control takeover.

[0025] Server 200 refers to a service platform deployed in a cloud or cloud-edge environment to support the establishment, configuration distribution, and control management of temporary flight control sessions. Server 200 provides functions such as session management, one-time session token issuance, flight control application resource publishing, map and terrain data provision, flight protocol message brokering, mission status synchronization, control lease arbitration, and audit logging. Server 200 can also interface with external services such as user qualification verification, lease or payment verification, equipment and session risk assessment, and no-fly and restricted-fly zone rule bases.

[0026] It should be noted that the physical deployment of server 200 can be a single server, a server cluster, or a collaborative service platform distributed across cloud nodes and edge nodes. The term "server" in the claims and method steps of this application refers to the aforementioned service-side entity capable of communicating with mobile terminal 100 and performing processes such as session management, token issuance, configuration distribution, and control arbitration; it is not limited to being centrally deployed in a single data center.

[0027] The server 200 and the mobile terminal 100 can establish a communication connection using methods such as Hypertext Transfer Security Protocol (HTTP) and WebSocket. The server 200 and the drone 300 can forward flight data and control data through cellular networks, satellite links, or ground gateways. In far-field communication scenarios, the flight protocol proxy in the server 200 can convert messages sent by the mobile terminal 100 into flight protocol frames that the drone can recognize, and then forward them to the drone 300.

[0028] A UAV 300 refers to an unmanned aerial vehicle controlled by radio remote control equipment, a self-contained program control device, or an onboard computer. A UAV 300 can be equipped with sensors such as an inertial measurement unit, satellite positioning module, visual sensor, and ranging radar, and has a built-in flight control system. The flight control system receives control commands and, in conjunction with sensor data, performs attitude calculations, power output control, and flight trajectory execution.

[0029] In this application, the UAV 300 is also equipped with an edge gateway. The edge gateway is a communication and security processing module located on the UAV side, between the mobile terminal 100 or server 200 and the flight control system. The edge gateway is used to establish and maintain near-field control links, verify one-time session tokens and control leases, forward flight protocol messages, broadcast telemetry and status data, and execute security degradation strategies when link quality is insufficient or risk increases.

[0030] Specifically, the edge gateway may include a token verification unit, a security degradation execution unit, a near-field communication unit, and a protocol forwarding unit. The token verification unit verifies information such as the session token, control lease, command sequence number, and signature sent by the mobile terminal 100. The security degradation execution unit restricts the range of allowed commands to safety commands such as hovering, return to home, landing, and emergency stop when communication quality deteriorates, positioning is abnormal, battery is low, or the risk of out-of-bounds movement increases, and also limits speed, altitude, or command frequency. The near-field communication unit establishes a local area network connection, direct wireless connection, or hotspot connection with nearby mobile terminals 100, and can transmit control and telemetry data through a real-time web communication data channel. The protocol forwarding unit, after successful verification, transfers control commands to the flight control system for execution and transmits the status data output by the flight control system back to the mobile terminal 100 or the server 200.

[0031] Specifically, the UAV 300 has a session entry point on its fuselage, parking rack, or rental point. This session entry point can take the form of, but is not limited to, a QR code, a near-field communication tag, a Bluetooth broadcast identifier, an ultra-wideband tag, or a short link. After an operator identifies this session entry point via a mobile terminal 100 (e.g., by scanning the QR code on the UAV 300's fuselage), the mobile terminal 100 sends a flight control session request to the server 200. After verification, the server 200 issues a one-time session token and flight control application configuration information to the mobile terminal 100. The mobile terminal 100 then loads the flight control application and displays the flight control interface. When the one-time session token is valid, the mobile terminal 100 requests a control lease from the server 200. Upon obtaining the control lease, the mobile terminal 100 establishes a near-field control link with the UAV 300's edge gateway, or a far-field control link via the server 200, and sends flight control commands carrying the control lease through this link. After the edge gateway verifies the control lease, it forwards the flight control commands to the flight control system for execution.

[0032] Please see Figure 2 , Figure 2 A schematic diagram of the structure of a mobile terminal provided in some embodiments of this application is shown. The mobile terminal 100 includes at least one processor 110 and a memory 120 connected in communication. Figure 2Taking a bus system connection and a processor 110 as an example, it is understood that the various components in the mobile terminal 100 are coupled together through a bus system. The bus system is used to realize the connection and communication between the various components. In addition to a data bus, the bus system may also include a power bus, a control bus, and a status signal bus, etc. For clarity, Figure 2 The general will label all buses as bus systems. Figure 2 The structure shown is for illustrative purposes only; the mobile terminal 100 may also include components that are more advanced than those shown. Figure 2 More or fewer components, or having with Figure 2 Different configurations.

[0033] Processor 110 provides computational and control capabilities to support mobile terminal 100 in executing the methods provided in the embodiments of this application. Those skilled in the art will understand that processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0034] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the methods in the embodiments of this application. In some embodiments, the memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function. The data storage area may store data created according to the use of the processor 110, etc. The processor 110 executes various functional applications and data processing of the mobile terminal 100 by running the non-transitory software programs, instructions, and modules stored in the memory 120 to implement the methods provided in the embodiments of this application. In some embodiments, the memory 120 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may also include memory remotely located relative to the processor 110, and these remotely located memories may be connected to the processor 110 via a communication network. Examples of the above-mentioned communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] As can be understood from the above, the execution entity of the method provided in this application embodiment can be a mobile terminal 100 with computing and control capabilities. In a feasible implementation, the method provided in this application embodiment can be implemented by a processor executing computer program instructions stored in the memory.

[0036] In this application, the mobile terminal 100 sends a flight control session request to the server 200 through a session entry bound to the target drone, receives session configuration information containing a one-time session token and flight control application configuration information, and presents a flight control interface accordingly. When the token is valid, it obtains a control lease granted by the server 200, establishes a control link with the target drone, and sends flight control commands carrying the control lease. This scheme binds the physical drone to a temporary flight control session, allowing the flight control interface configuration to be issued along with the session, and implementing short-term, verifiable management of command issuance permissions.

[0037] The control method provided in the embodiments of this application is described in detail below with reference to the accompanying drawings. This method is applied to the aforementioned mobile terminal, and the executing entity is one or at least two processors of the mobile terminal. Please refer to... Figure 3 The control methods include, but are not limited to, steps S10 to S60.

[0038] Step S10: Send a flight control session request to the server through the session entry bound to the target UAV.

[0039] A session entry point is an access identifier used to establish a correspondence between a physical drone and a temporary flight control session. The session entry point can be located on the drone's fuselage, parking rack, or rental point, and its form includes at least one of the following: QR code, near-field communication tag, Bluetooth broadcast identifier, ultra-wideband tag, or short link. After obtaining the access information from the session entry point through methods such as camera recognition, near-field reading, or wireless discovery, the mobile terminal 100 can locate the session service address corresponding to the target drone.

[0040] The target drone refers to the drone 300 that is to be observed or controlled during this temporary flight control session.

[0041] Taking a QR code-based session entry as an example, the QR code content can use a Uniform Resource Locator (URL) to carry or index information such as the drone anonymization identifier, QR code version, random prompt value, and signature digest. The drone anonymization identifier distinguishes different drones without directly exposing the flight controller serial number. The QR code version identifies the encoding rules. The random prompt value assists the server (200) in retrieving session records. The signature digest allows the server (200) to verify the integrity and origin of the entry information.

[0042] In dynamic display scenarios, such as e-ink screens, airborne displays, or refreshable patches, the random prompt value and signature digest in the session entry can be updated periodically. In static identification scenarios, the session entry mainly provides the access address and drone index, and the one-time authorization credential is issued by server 200 after receiving the session request, combined with the drone's real-time status.

[0043] A flight control session request refers to a request message sent by mobile terminal 100 to server 200 to establish a temporary flight control session bound to a target UAV. A temporary flight control session is a short-term control session that establishes a correspondence between mobile terminal 100 and the target UAV within a single mission cycle. This session is used to carry subsequent token verification, flight control interface configuration, control authorization, and flight control command transmission, and expires upon mission completion, timeout, or permission revocation. The flight control session request may carry at least one of the following: UAV anonymization identifier, terminal capability information, approximate geographical location, network status, device fingerprint digest, and user authorization credentials. The UAV anonymization identifier is an index identifier used to distinguish different UAVs without directly exposing the flight control serial number or factory serial number, used by server 200 to locate the target UAV and complete the session binding. Terminal capability information refers to parameters describing the hardware conditions and interactive capabilities of mobile terminal 100, which may include screen size, input method, whether it supports specific communication interfaces, operating system type, and operating environment capabilities, used by server 200 to match flight control application configuration and available functionalities. Coarse geographic location refers to the location information reported by the mobile terminal 100, which has limited accuracy. This information is used to assist the server 200 in service area verification, no-fly zone policy matching, or nearby resource scheduling. Network status refers to the connectivity and quality of the network currently accessed by the mobile terminal 100. This may include network type, whether the mobile terminal 100 is online, bandwidth estimation, or signal strength, etc., which the server 200 uses to determine the session establishment method and subsequent link configuration. Device fingerprint digest refers to the identification information generated by a digest algorithm from the terminal's hardware and software characteristics. This information is used to assist in identifying the terminal's identity, associating historical sessions, or performing risk identification, and is usually not exposed in plaintext. User authorization credentials refer to the credentials used to prove that the current operator is qualified to use the target drone. These credentials may originate from rental orders, activity authorization codes, organizational accounts, or other business-side authorization results, and are used by the server 200 to complete the qualification verification.

[0044] By carrying the aforementioned information, the flight control session request enables server 200 to complete target UAV identification, terminal condition assessment, network status judgment, and user qualification verification before establishing a temporary flight control session. This provides a basis for subsequent one-time session token issuance and flight control application configuration distribution. Specifically, after mobile terminal 100 identifies the session entry point, it opens the corresponding session service address and sends a flight control session request to server 200. Server 200 can first verify the entry version, signature digest, and UAV anonymization identifier, and then, in conjunction with the UAV's current status, user authorization status, terminal capabilities, network quality, and location policy, determine whether to allow session establishment. This step maps the physical target UAV to a manageable temporary flight control session request, ensuring that subsequent token issuance, interface configuration, and control authorization all revolve around the same UAV identifier, helping to solve the problem of the session object being disconnected from the specific UAV.

[0045] Step S20: Receive session configuration information sent by the server. The session configuration information includes a one-time session token and flight control application configuration information.

[0046] Session configuration information refers to the set of configuration data returned by server 200 to mobile terminal 100 after verifying the flight control session request, which is used to complete the initialization of this temporary flight control session.

[0047] After receiving the flight control session request sent by the mobile terminal 100, the server 200 first verifies the session entry and request content, then determines the session branch based on the current status of the target UAV, and issues a one-time session token and sends flight control application configuration information when the verification is successful and the conditions for establishing a session are met.

[0048] Specifically, first, server 200 verifies the validity of the session entry. Taking a QR code-based session entry as an example, server 200 can verify whether the QR code version is supported, whether the signature digest is correct, whether the random prompt value is still valid, and whether the UAV anonymization identifier can be mapped to a legitimate device. For other forms of session entry such as near-field communication tags, Bluetooth broadcast identifiers, ultra-wideband tags, or short links, server 200 can verify the corresponding integrity check value, validity period, and device index. If the session entry is invalid, the signature is incorrect, the version is unsupported, the entry information has expired, or the user authorization credentials or terminal information are incomplete, server 200 returns a request verification failure indication to mobile terminal 100. After receiving this indication, mobile terminal 100 prompts on the flight control-related page to re-identify the session entry or that session creation has failed, and provides a retry entry or exit entry; in this case, it does not proceed to the subsequent control right application and control-related flight control command sending process, or it terminates the current process.

[0049] After the session entry and request verification are successful, server 200 further determines the current status of the target drone to determine whether a controllable flight control session can be established. Server 200 can query whether the drone is in an idle and allocable state, whether it has been occupied by other terminals, whether observation access is allowed, whether control handover is allowed, and whether it is in an unavailable state such as maintenance, charging, low battery, or located in an unserviceable area.

[0050] If the target drone is currently unavailable for establishing a new control relationship—for example, if it is occupied, undergoing charging and maintenance, has a battery level below the flight threshold, is located in an unserviceable area, or is already occupied and observation or relay is not permitted—the server 200 returns a target drone unavailable indication to the mobile terminal 100. Upon receiving this indication, the mobile terminal 100 enters observation mode or queuing mode and suppresses the sending of control-related flight control commands such as takeoff and attitude control. Observation mode allows viewing public telemetry, video, or mission status, but does not grant active control permissions. Queuing mode allows the drone to register and wait for resources to be released before requesting control. If the policy allows observation access, the server 200 may also issue only limited configurations matching the observation role without granting control permissions.

[0051] If the target drone is idle, or if it is occupied but meets the preset takeover conditions, the server 200 allows the establishment of this temporary flight control session and issues a one-time session token to the mobile terminal 100, while also sending the flight control application configuration information bound to it.

[0052] A one-time session token is a short-term authorization credential issued by server 200, used to prove that mobile terminal 100 is qualified to enter the current flight control session and load matching resources. A one-time session token can be bound to at least one of the following: drone identifier, terminal identifier, user session identifier, cache list version, and initial role. The token's validity period may be shorter than a single lease period or a single flight mission period. Server 200 may invalidate the token upon flight completion, session timeout, transfer of control, or abnormal risk status. It should be noted that a one-time session token is used for session access and is not directly equivalent to long-term flight control permissions, nor does it automatically mean that mobile terminal 100 has obtained active control over the target drone; active control requires a separate application and acquisition of a control lease, provided the token is valid.

[0053] Specifically, the one-time session token can be in the form of a signed token. The token payload may include the UAV's anonymized identifier, user session digest, terminal capability digest, geographic area constraints, issuance time, expiration time, cache list version, and initial role, etc. Server 200 signs the digest of the above information using a signing key. Subsequently, when requesting a control lease or sending flight control commands, server 200 or the edge gateway can verify the token signature, validity period, and consistency of the UAV identifier.

[0054] In one implementation, the one-time session token T_session can be a signed token, whose payload includes the drone's anonymization identifier, user session digest, terminal capability digest, geographic region constraints, issuance time, expiration time, cache manifest version, and initial role. Token generation can be represented as: T_session=Sign_Ks(H(D_a∥U_s∥B_c∥G_r∥t_i∥t_e∥C_v∥R_0)); Wherein, Ks is the signing key on the server 200 side, H(·) is the cryptographic hash function, D_a is the drone anonymization identifier, U_s is the user session digest, B_c is the terminal or browser capability digest, G_r is the geographical region constraint, t_i and t_e are the issuance time and expiration time, respectively, C_v is the cache manifest version, R_0 is the initial role, and ∥ indicates field concatenation. Subsequently, when applying for a control lease or sending flight control commands, the server 200 or edge gateway verifies the consistency of the token signature, validity period, and drone identifier; active control still requires a valid control lease on the premise that the token is valid.

[0055] Flight control application configuration information refers to configuration data used to guide mobile terminal 100 in loading the flight control application and presenting the flight control interactive interface. It may include at least one of the following: flight control application resource version, cache list, link candidate list, and control right request policy. Specifically, the flight control application resource version identifies the version of the flight control application to be loaded in this session, ensuring that the interface resources are consistent with the current aircraft model and task configuration. The cache list indicates the flight control resources that need to be cached in this session and their cache range, allowing subsequent service worker threads to prepare resources according to tasks. The link candidate list provides negotiable parameters for near-field control links and far-field control links, allowing mobile terminal 100 to evaluate, select, or switch links. The control right request policy describes the range of roles that the current terminal can request, lease application conditions, and rules regarding whether relaying is allowed. After completing the above verification and determining that the session can be established, server 200 returns session configuration information containing a one-time session token and flight control application configuration information to mobile terminal 100. Upon receiving this information, mobile terminal 100 enters the flight control application loading and interface presentation process.

[0056] Therefore, before the session configuration is issued, server 200 sequentially completes session entry verification, UAV status judgment, and session branch selection. If verification fails, it prompts for retry or terminates and cancels the control process; if the UAV is unavailable, it enters observation or queuing and suppresses control command issuance; if the UAV is idle or allowed to relay, it issues a one-time session token and issues flight control application configuration. Placing entry verification and UAV status judgment before session configuration issuance can terminate the control process under illegal or unsuitable conditions for establishing a control relationship and provide an executable subsequent branch.

[0057] This step distributes the session access credentials and flight control application configuration together, so that subsequent interface loading, resource caching and permission requests are all bound to the same drone session. This helps reduce the risk of duplicate control relationships being established after the static entry point is copied, and ensures that the flight control interface version is consistent with the current drone and mission configuration.

[0058] Step S30: Based on the flight control application configuration information, present the flight control interactive interface.

[0059] The flight control interface refers to the human-machine interface presented on the mobile terminal 100, which allows operators to view the status of the UAV and input flight control operations. The flight control interface may include an attitude display area, a telemetry parameter area, a map or video window, and at least one of the following operation controls: takeoff, hovering, return to home, landing, and emergency stop.

[0060] Specifically, the mobile terminal 100 loads the flight control application based on the resource version and launch address in the flight control application configuration information. The flight control application can run in PWA form. The application list can describe the application name, icon, launch address, display mode, and theme color, and supports adding the flight control entry to the terminal's main screen. After loading, the mobile terminal 100 renders the flight control interaction interface based on the session role, UAV status, and mission type. For example, in a scenic area rental mission, the interface can display controls for takeoff, follow, hover, return, and landing; in an emergency reconnaissance or professional inspection mission, the interface can display controls for flight path display, layer switching, and multi-sensor status.

[0061] This step ensures that the flight control interface resources and control set are consistent with the configuration of this session, reducing the offset of function sets and mismatch of interface resources caused by inconsistencies between the pre-installed application version on the terminal and the current model or mission configuration.

[0062] Step S40: While the one-time session token is valid, acquire the control lease granted by the server.

[0063] A control lease is a credential object issued by server 200 that grants short-term active control rights over a target drone. Control leases can be revoked and include a version identifier to indicate which terminal currently has the authority to issue commands. A control lease may include at least one of the following: controlling terminal identifier, session identifier, drone identifier, lease version, expiration time, range of executable commands, and relay status. Typically, only one terminal holds an active control lease at any given time, while other terminals may be in observation, assisting, or pending takeover status.

[0064] A valid one-time session token means that the token is still valid, has not been revoked by server 200, and remains consistent with the current binding relationships of the drone identifier, terminal session, etc. After confirming the token's validity, mobile terminal 100 requests a control lease from server 200. The request information may include the drone identifier, session identifier, terminal identifier, and requested role.

[0065] Upon receiving the application, server 200 verifies the drone's status and one-time session token, and queries the edge gateway of drone 300 for its current controllable status or flight mode. If the verification is successful and there are no conflicting authorized terminals, server 200 grants a control lease to mobile terminal 100. Mobile terminal 100 accepts this lease and uses it as authorization credentials for subsequently sending control-related flight control commands.

[0066] During operation, the mobile terminal 100 continuously maintains the validity status of the control lease and the one-time session token. When it does not hold a valid control lease, detects an expired version identifier of the control lease, receives a loss of authorization notification, or the one-time session token expires, the mobile terminal 100 stops sending control-related flight control commands and updates the flight control interface prompts. A loss of authorization notification is a message pushed to the terminal by the server 200 or edge gateway, indicating that its control rights have ended or been transferred. An expired version identifier means that the locally stored lease version is lower than the latest version recorded by the UAV or server 200. In the event of these situations, the mobile terminal 100 switches the interface to an observation state or an invalidation prompt state, such as displaying that control has been transferred, the session has expired, or requesting re-authorization, to avoid continuing to trigger control-related operations when it is not qualified to issue commands.

[0067] For example, if the target drone is already in flight and other terminals have control, server 200 may, according to policy, only grant observation permissions to this terminal, or put this terminal into a takeover state, instead of immediately granting an active control lease. Thus, session admission and control authorization are processed in a layered manner, separating "being able to enter a session" from "being able to actively issue commands".

[0068] In practice, the validity of a control lease can be determined by considering the following conditions: the lease signature is valid, the current time has not exceeded the expiration time, the lease version is not lower than the latest version recorded by the edge gateway, the drone identifier bound to the lease is consistent, the current role is allowed to execute the corresponding command, and the risk status has not exceeded a preset threshold. During a transfer of control, the new lease version can be incremented based on the old lease version, so that the edge gateway can reject commands corresponding to the old version lease.

[0069] For example, the validity of a control lease can be determined by a combination of factors: Valid(Lease)=SigOK∧TimeOK∧VersionOK∧DroneOK∧RoleOK∧RiskOK; Among them, SigOK indicates that the lease signature is valid, TimeOK indicates that the current time has not exceeded the expiration time, VersionOK indicates that the lease version is not lower than the latest version recorded by the edge gateway or server 200, DroneOK indicates that the drone identifier bound to the lease is consistent, RoleOK indicates that the current role is allowed to execute the corresponding command, and RiskOK indicates that the risk status has not exceeded the preset threshold. When control is transferred, the new lease version Version(Lease_new) satisfies: Version(Lease_new)=Version(Lease_old)+1; Version(Lease_old) is the old lease version, so that the edge gateway can reject commands corresponding to the old lease version, reducing the risk of the old terminal continuing to send commands after the handover.

[0070] This step acquires a separate control lease after session admission, giving the command qualification a clear time limit, version, and binding relationship, which helps reduce unauthorized command issuance and multiple terminals controlling the same drone simultaneously.

[0071] Step S50: Establish a control link between the mobile terminal and the target UAV.

[0072] The control link refers to the communication channel between the mobile terminal 100 and the target UAV 300 used to transmit flight control commands, telemetry data, heartbeat information, and mission incremental data. The control link can be a near-field control link or a far-field control link, and can be selected or switched between the two.

[0073] A near-field control link refers to a data channel established between the mobile terminal 100 and the edge gateway under short-range network conditions such as a local area network, direct wireless connection, or shared hotspot. One implementation involves both parties establishing a real-time web communication connection and transmitting telemetry, heartbeat, control commands, and incremental task data through the data channel.

[0074] The far-field control link refers to the data channel through which the mobile terminal 100 communicates with the drone 300 after being forwarded by the server 200. One implementation involves the mobile terminal 100 connecting to the flight protocol proxy of the server 200 via WebSocket. The proxy converts terminal-side messages into flight protocol frames, which are then sent to the drone 300 via a cellular network, satellite link, or ground gateway. The flight protocol can be a lightweight messaging protocol for communication between the drone and ground stations and airborne components. The flight protocol proxy can be deployed in a central computer room, edge node, or rack-mounted local gateway, and provides external access as part of the services offered by the server 200.

[0075] Specifically, the mobile terminal 100 collects near-field and far-field link parameters based on the link candidate list in the session configuration information, evaluates the availability of the two links, and selects the link that meets the latency, packet loss rate, and security conditions as the current control link. After the control link is established, the mobile terminal 100 can receive UAV telemetry data and send flight control commands.

[0076] This step establishes a data channel after obtaining the control lease, ensuring that subsequent commands have a reachable transmission path.

[0077] Step S60: Send flight control commands via the control link. The flight control commands carry the control lease.

[0078] Flight control commands are control instructions triggered by operators on the flight control interface or generated by mission logic to change the flight status or mission status of the UAV. Flight control commands may include at least one of the following: takeoff, hover, return to home, landing, emergency stop, flight path upload, gimbal adjustment, and mission pause.

[0079] When sending flight control commands, the mobile terminal 100 carries key information about the currently held control lease. This key information may include at least one of the following: lease version, lease signature, terminal identifier, and session identifier. Upon receiving the command, the edge gateway on the UAV side or the agent on the server 200 side verifies whether the lease is valid, whether the version is up-to-date, and whether it is bound to the current UAV. If the verification is successful, the command is then forwarded to the flight control system for execution.

[0080] Flight control commands can also include monotonically increasing sequence numbers, timestamps, session signatures, and idempotent keys to identify replays, out-of-order commands, and duplicate commands.

[0081] By requiring control commands to carry a control lease, the system adds permission constraints to the transmission channel. Terminals without a valid lease will have their control commands rejected during the verification phase, even if they can open the session page. After the lease version is updated, commands from older terminals will no longer be accepted, thus reducing the risk of multiple terminals simultaneously issuing commands due to residual permissions.

[0082] The implementation process of this embodiment is described below using a typical task scenario. In a scenic area rental scenario, after the user completes payment or authorization, they use the mobile terminal 100 to identify the session entry on the drone and enter the flight control application page. The server 200 issues a one-time session token and flight control application configuration information according to the scenic area task, and the mobile terminal 100 displays a set of controls consistent with the authorized scope of the task. When the token is valid, the mobile terminal 100 obtains a control lease and sends commands such as takeoff, follow, and return via the near-field control link or far-field control link. After the task ends, the token and lease expire, and sensitive caches can be cleared.

[0083] In emergency rescue scenarios, on-site personnel use mobile terminals to identify the session entry point on the drone or cabinet and load the flight control configuration matching the emergency mission. Once the token is valid, a control lease is acquired and a control link is established, then flight control operations such as searching are performed. When a change of operating terminal is required, a control transfer can be requested within the same session, ensuring continuous mission status.

[0084] In educational classroom scenarios, student or teacher terminals access the course-related flight control session through a session entry point. Different terminals can correspond to different flight permissions and control lease scopes. For example, the teacher terminal can obtain control-type authorization, while the student terminal can be in observation mode or operate only within the authorized command scope. The interface controls and command scope are jointly constrained by the session configuration and control lease.

[0085] This embodiment forms a processing flow of "session entry triggering, one-time token access, flight control interface loading, control lease authorization, and control link command issuance". Step S10 establishes a correspondence between the physical UAV and the current temporary flight control session, allowing users to directly enter the flight control process through methods such as scanning a code or near-field reading, without the need to pre-install native desktop or mobile applications, complete version updates, and grant system-level permissions. This addresses the issues of long installation and initialization times and high usage thresholds for temporary users in the background technology, enabling rapid access to flight control services. The mobile terminal presents the flight control interaction interface based on the flight control application configuration information, ensuring that the interface resource version and control set are uniformly distributed and loaded with the current target UAV. This addresses the issue of inconsistencies between the flight control interface function set and the current model when different operating systems and application versions coexist in the background technology, ensuring the compatibility of the interface with the model and task under the temporary session. When the one-time session token is valid, the user obtains... The system acquires a control lease granted by the server, establishes a control link between the mobile terminal and the target UAV, and sends flight control commands carrying the control lease through this link. This enables layered management of session access and proactive command issuance, with command issuance qualifications having clear validity periods, versions, and UAV binding relationships. Control commands without a valid lease can be rejected, thereby lowering the access threshold while improving the verifiability of control authorization and helping to reduce unauthorized command issuance, permission residue, and multi-terminal command conflicts. By binding the session, interface configuration, and control permissions to the target UAV and a single mission cycle respectively, this embodiment can reduce problems such as mismatch between the flight control interface and the target UAV, unauthorized command issuance, permission residue, and multi-terminal command conflicts, improving the reliability of session establishment and control authorization in temporary flight control scenarios.

[0086] In some embodiments, the flight control application configuration information includes a cache list. Based on the flight control application configuration information, a flight control interface is presented, including but not limited to steps S31 to S34.

[0087] Step S31: Load the flight control application according to the flight control application configuration information.

[0088] Mobile terminal 100 obtains flight control application resources from server 200 or its collaborating edge nodes based on the resource version, startup address, and application list in the flight control application configuration information. Flight control application resources may include page structure, script logic, style files, icons, and basic components. To shorten the first-screen readiness time, a phased loading approach can be adopted, such as loading the application shell and core scripts first, and then loading maps, terrain, or enhanced function modules as needed.

[0089] Step S32: After the flight control application is loaded for the first time, register the service worker thread.

[0090] A service worker is a script thread that runs in the background of an application, used to intercept network requests and manage local caching. After the flight control application is successfully loaded for the first time, the mobile terminal 100 registers a service worker thread, allowing it to handle resource requests in subsequent accesses. Even when the page is refreshed or communication quality degrades, a basic flight control interface can still be provided based on cached resources.

[0091] Step S33: The service worker thread caches flight control resources according to the cache list.

[0092] The cache manifest is a list issued by server 200 that describes the flight control resources that need to be cached in this session and their caching policies. The cache manifest can be associated with the current UAV, mission area, terminal capabilities, and session role, thus it is a resource configuration oriented towards a single mission, rather than indiscriminate caching of all application resources.

[0093] Specifically, flight control resources can be divided into the following categories: The first category is mandatory cached resources, including flight control interface shell, flight protocol encoding and decoding components, UAV attitude display components, basic telemetry display components, return-to-home, landing, emergency stop operation components, and safety prompt components; the second category is mission cached resources, including current mission area map tiles, local terrain data, flight path planning constraints, and no-fly zone and altitude-restricted zone data; the third category is optional enhancement resources, including image recognition models, high-definition map layers, and teaching cases; the fourth category is prohibited caching or short-term cached resources, including long-term tokens, user identity plaintext, payment credentials, and sensitive audit data.

[0094] Service worker threads write cacheable resources to the local cache space according to the cache list. Caching strategies can include cache-first, network-first, or network-only. For core flight control resources, cache-first is usually adopted to ensure that the basic interface can still be restored even if communication quality degrades.

[0095] Step S34: When the cached results meet the preset interactive conditions, the flight control interactive interface is presented.

[0096] Preset interactive conditions refer to the criteria used to determine whether the current cached results are sufficient to support basic flight control interaction. For example, when the flight control interface shell, basic telemetry components, safety operation components, and necessary rule data have all been cached, the interactive conditions can be considered met. At this time, the mobile terminal 100 displays the flight control interaction interface, allowing operators to view the status or perform authorized operations.

[0097] When communication quality is low, the loading of forced cache resources can be completed first, followed by the loading of optional enhancement resources, so that the terminal can still enter an interactive state in the field environment with unstable network conditions.

[0098] This embodiment uses service worker threads and a task-based cache list to ensure that the local readiness range of flight control resources is related to the current UAV and mission. Compared with loading methods that do not distribute cache lists or perform resource tiering, this embodiment can control the local cache range while ensuring the accessibility of the basic flight control interface and reducing the probability of sensitive data being stored for a long time.

[0099] In some embodiments, the service worker thread caches flight control resources according to the cache list, including but not limited to steps S331 to S333.

[0100] Step S331: Based on the security level of the flight control resources, determine the flight control resources that are allowed to be cached and those that are prohibited from being cached.

[0101] Security levels describe the business necessity and sensitivity of flight control resources after they are locally cached. Flight control resources that can be cached typically include the interface shell, encoding / decoding logic, basic control components, map indexes, no-fly rules, and offline command whitelists. Flight control resources that cannot be cached typically include long-term control keys, plaintext user identities, payment credentials, and complete audit details. For moderately sensitive but necessary business data, short-term caching can be used, and the data should be cleared after the session ends or times out.

[0102] Step S332: Obtain communication quality information.

[0103] Communication quality information describes the quality of the network currently accessed by the mobile terminal 100, and may include at least one of the following: round-trip time, packet loss rate, bandwidth estimation, whether it is on a billing network, signal strength, and whether it is under near-field coverage. Communication quality information may come from system network interfaces, link probe results, or terminal network status data.

[0104] Step S333: The service worker thread caches the flight control resources that are allowed to be cached based on the communication quality information and the security level of the flight control resources.

[0105] When the service worker thread executes the cache, it first classifies the resources according to the security level of the flight control resources, and then determines the cache order, cache range and forced cache set of each level of resources in combination with communication quality information, so that the terminal side still has the resource conditions to maintain basic flight control and safe operation when the link fluctuates or is temporarily unavailable.

[0106] Security levels characterize the strength of the correlation between flight control resources and flight safety and controllable landing, serving as a basis for prioritizing local loading of resources. For example, flight control interfaces, telemetry analysis components, attitude display components, return-to-home and landing components, map indexes, and no-fly zones can be classified as higher security levels; enhanced resources such as high-definition map tiles, terrain profiles, recognition models, and teaching resources can be classified as relatively lower security levels. Higher security levels indicate that local loading should be prioritized in weak network or offline scenarios.

[0107] When communication quality is low, prioritize caching resources with higher security levels. When communication quality is high, and provided that high-security resources are already covered, then cache high-resolution map tiles, terrain profiles, recognition models, and teaching resources in sequence. For large-sized enhancement resources that are not currently needed for the task, retrieval can be delayed to reduce the bandwidth consumption of the current control link.

[0108] In one implementation, cache priority can be calculated for flight control resources. The cache priority is determined primarily by the resource's security level, combined with factors such as relevance to the current task area, access probability, and resource size. Higher security levels result in higher base priority values; task relevance and high access probability can increase priority, while excessively large resources can be relatively decreased to avoid blocking the retrieval of necessary resources. The system prioritizes caching higher-priority resources; when storage space is insufficient, lower-priority resources with lower security levels and not belonging to the mandatory caching category are prioritized for eviction. High-security-level or mandatory-caching resources are not evicted or are evicted last. Offline terrain data can be in the form of digital elevation grids, vector contour lines, or pre-calculated safe altitude rasters to support altitude and terrain-related safety assessments under weak network or offline conditions.

[0109] For example, the cache priority P_i of flight control resource i can be calculated according to the following formula: P_i=αF_i+βS_i+γR_i+δA_i ηM_i; Wherein, F_i is the flight necessity parameter, used to characterize the necessity of resource i for completing basic flight control interaction or safety handling. It can be assigned a value according to a preset level and normalized to [0, 1]. For example, flight control interface shell, flight protocol encoding and decoding, telemetry and attitude display, return-to-home / landing / emergency stop components, etc. take higher values; teaching cases, decorative layers, etc. take lower values. S_i is the safety relevance parameter, used to characterize the relevance of resource i to flight safety constraints. It can be assigned a value according to a preset level and normalized to [0, 1]. For example, no-fly zone / restricted-fly zone rules, offline command whitelist, safety prompt components, local safety altitude or fence data, etc. take higher values; display materials unrelated to safety decisions take lower values. R_i is the task area relevance parameter, used to characterize the matching degree of resource i with the current session task area, flight path range or operation boundary. It can be assigned a value according to the degree of overlap between the resource's geographical coverage and the current task area, or whether it belongs to the "current task package" issued by the server, and normalized. Map tiles or terrain blocks unrelated to the current area take lower values. A_i is an access preference parameter, representing the likelihood of resource i being accessed in the current session or its recent usage probability. It can be determined and normalized based on resource type statistics, the default loading path of the interface, the access frequency of historical sessions, or the prefetch markers marked by the server. M_i is a storage cost parameter, representing the cost of resource i occupying local storage or bandwidth. It can be determined and normalized based on the resource's byte size, whether it can be loaded in segments, etc. The larger the size, the higher M_i. α, β, γ, δ, and η are weighting coefficients, all greater than or equal to 0, and can be configured according to machine type, task type, and communication quality. For example, in weak network or emergency scenarios, α, β, and γ can be increased, and δ can be decreased; when storage is scarce, η can be increased. Service worker threads prioritize caching resources with P_i higher than a preset threshold; when storage space is insufficient, resources with lower P_i that do not belong to the mandatory caching category are prioritized for eviction.

[0110] It should be noted that F_i, S_i, R_i, A_i, and M_i can be obtained by means of discrete levels (such as high / medium / low mapped to 1 / 0.5 / 0), rule tables, or normalized scores directly issued by the server in the cache list, and are not limited to a certain scoring model.

[0111] In this step, the security level determines the basic cache order and mandatory retention set of resources, while communication quality determines the current allowed cache depth and whether resources should be compressed and enhanced. Cache priority is the sortable result after combining these two factors with task-related factors. Through the above-mentioned caching based on security level and controlled by communication quality, when the network is unavailable or the link quality is below a preset threshold, the mobile terminal can enter an offline security degradation mode based on the necessary cached resources. The offline security degradation mode refers to a working mode that allows only low-risk flight commands to be executed under communication constraints, and restricts speed, altitude, and command frequency. In this mode, commands such as hovering, low-speed attitude fine-tuning, return to home, nearby landing, gimbal angle adjustment, and mission pause are allowed; high-risk operations such as establishing new flight paths, crossing no-fly zones, increasing altitude limits, and transferring control can be executed only after network recovery or after secondary confirmation by the edge gateway.

[0112] It should be noted that offline security downgrade can be initiated automatically by the terminal based on the local link and cache readiness status, or it can be coordinated with security downgrade instructions issued by server 200 and / or edge nodes (including edge gateways): After receiving the instruction, mobile terminal 100 updates the flight control interface prompts and stops sending flight control commands that conflict with the downgrade strategy. The downgrade strategy may include at least one of the following: prohibiting takeoff commands, limiting maneuverability, and allowing only return-to-home or hovering safety commands. For related interface constraints, command qualification verification, and their connection with control lease maintenance, multi-terminal relay, and other mechanisms, please refer to the relevant embodiments on operational control and command outbound verification; this step focuses on completing graded caching according to security level and communication quality, providing local resource conditions for the above-mentioned downgrade and security operations. After the flight session ends, sensitive cache content can be cleared, non-sensitive application shell resources can be retained, and audit logs can be reported to server 200 as needed to record sessions, leases, and key control events.

[0113] This embodiment links local cache decisions with resource security levels and communication quality, thereby providing basic flight control capabilities subject to range constraints even when communication is limited, and preventing high-risk operations from being executed when constraints are not met.

[0114] In some embodiments, flight control commands are sent via a control link, including but not limited to steps S61 to S62.

[0115] Step S61: Verify the flight control commands, including verification of control authority validity, command authorization, flight area compliance, and UAV flight parameter safety.

[0116] Operator actions on the interface first generate structured intent commands, which are then mapped to underlying flight protocol messages. These structured intent commands express control intentions, such as takeoff to a specified altitude, return to base, or uploading mission increments. The mobile terminal 100's local or cooperating command verification module performs multi-layered verification before the command leaves the terminal.

[0117] The control validity verification confirms that mobile terminal 100 still holds a valid control lease, and that the lease version, signature, bound drone, and session identifier match. Verification fails if the lease has expired, been revoked, or is outdated.

[0118] Command permission verification is used to confirm that the command is permitted to be executed under the current flight mode, network status, terminal role, and offline command whitelist. For example, attitude control commands are not allowed to be sent under the observer role; new route commands are not allowed to be sent in safety degraded mode.

[0119] Flight area compliance verification is used to confirm that the execution of commands will not cause the drone to enter no-fly zones, exceed altitude restrictions, or exceed the geofence boundaries of the leased area. A geofence is an electronic boundary used to restrict the range of drone activity, and typically includes no-fly zones, restricted flight zones, altitude restrictions, and leased area boundaries.

[0120] The drone flight parameter safety verification is used to confirm that parameters such as speed, acceleration, rate of climb, and rate of change of heading do not exceed the model's safety thresholds. If the parameters corresponding to the user's intent are too high, the command can be rejected or rewritten with more conservative parameters before execution.

[0121] In some implementations, a comprehensive judgment can be made by combining command risk scoring. Risk scoring can take into account factors such as boundary crossing risk, altitude risk, speed and attitude change risk, link instability risk, role mismatch risk, and environmental risk. When the risk score exceeds the corresponding threshold, the command can be rejected or converted into a low-risk alternative action, such as replacing "continue the route" with "hover and wait for confirmation".

[0122] For example, to calculate the risk score R_cmd for the command cmd to be executed: R_cmd=λ1·G_nfz+λ2·H_alt+λ3·V_dyn+λ4·L_link+λ5·U_role+λ6·E_env; Among them, λ1, λ2, λ3, λ4, λ5 and λ6 are weighting coefficients, which can be configured according to mission type, flight phase or safety strategy.

[0123] G_nfz is the risk value for crossing no-fly zones or boundaries. It characterizes the risk level of the drone entering a no-fly zone or restricted flight zone after executing the command (cmd), or breaking through geographical boundaries such as leased areas or operational fences. It can be determined based on the current pose and velocity direction, the expected trajectory or target point corresponding to the command, and fence data such as no-fly zones, restricted flight zones, and operational boundaries. A lower value is taken when the expected trajectory is clearly inside the boundary and far from the boundary; a medium value is taken when it is close to the boundary buffer zone; and a higher value is taken when it will cross a no-fly zone or exceed the operational boundary.

[0124] H_alt is the altitude risk value, used to characterize the altitude-related risks associated with executing the command (cmd), including but not limited to exceeding height limits, falling below the minimum safe altitude, excessive ascent or descent, and insufficient vertical clearance from terrain or obstacles. It can be determined based on the current altitude, the target altitude or rate of ascent / descent, height limit and minimum safe altitude rules, and local terrain or obstacle data. A lower H_alt value is used when the target altitude is within the authorized altitude zone and changes gradually; a medium value is used when approaching the upper or lower altitude limits; and a higher value is used when exceeding height limits or falling significantly below safe clearance.

[0125] V_dyn is the dynamic maneuver risk value, used to characterize whether the speed, acceleration, rate of climb, rate of change of heading, or attitude change corresponding to the executed command (cmd) is close to or exceeds the safety threshold allowed by the aircraft type and the current flight mode. It can be determined based on the flight parameters mapped from the structured intent command, as well as the aircraft's dynamic envelope, current mode limitations, and whether it is in a conservative or safety-degraded mode. Smooth maneuvers such as hovering and low-speed fine-tuning correspond to a lower V_dyn; moderate maneuvers or parameters approaching their upper limits use a moderate value; and situations such as overspeeding, excessively sharp turns, drastic attitude changes, or excessively high command frequency use a higher value.

[0126] L_link is a link instability risk value used to characterize the communication risk of sending and executing the command "cmd" under the current control link conditions. It can be determined based on the round-trip time, jitter, packet loss rate, heartbeat status, bandwidth margin, and whether it is within the link switching window for the near-field and / or far-field control links. A lower L_link value is used when the link quality is stable and meets control requirements; a medium value is used when quality fluctuates or is close to the switching threshold; a higher value is used when there are continuous heartbeat failures, significant deterioration in latency or packet loss, or when the primary / backup switchover is not yet stable. For highly dynamic commands that heavily rely on real-time remote control, the weight or decision threshold of L_link can be increased.

[0127] U_role is a role mismatch risk value used to characterize the degree of mismatch between the current terminal role, control lease scope, or session permissions and the command cmd. It can be determined based on whether a valid control lease is currently held, the range of commands allowed by the lease, the terminal role (e.g., controller, observer, assistant, or teaching sandbox participant), and whether the one-time session token is valid. A lower U_role value is used when the command falls within the current role and lease authorization range; a medium value is used when the command falls within the restricted request range; and a higher value is used when sending gesture control commands under the observer role, sending control commands without a valid lease, or exceeding the lease command range.

[0128] E_env is the environmental and platform status risk value, used to characterize the adverse effects of environmental or platform factors such as wind speed, rain / snow visibility, low battery, positioning anomalies, and sensor health on command execution. It can be determined based on environmental data from telemetry, battery and positioning status, onboard alarms, and risk alerts issued by the server or edge gateway. When the environmental and platform status is normal, E_env takes a lower value; when there is a minor alarm or the battery is low but low-risk actions can still be performed, a medium value is taken; when positioning is unavailable, the battery is below the flyable threshold, environmental conditions exceed limits, or a security degradation has been triggered, a higher value is taken.

[0129] When R_cmd exceeds the risk threshold of the category to which the command cmd belongs, the mobile terminal 100 refuses to send the command, or converts it into a low-risk alternative action before sending it. For example, it replaces "continue the route" with "hover and wait for confirmation", replaces large-scale maneuvers with conservative maneuvers after speed limit, or only retains the entry points for safe commands such as return home, landing, and emergency stop, and displays the reason for rejection or downgrade on the flight control interface.

[0130] It should be noted that G_nfz, H_alt, V_dyn, L_link, U_role, and E_env can be obtained using rule tables, hierarchical thresholds, or normalized scores issued by the server / edge gateway, and are not limited to a single calculation model; some verification items can also be executed as independent pass / reject rules first, and then combined with R_cmd for comprehensive judgment.

[0131] Step S62: In response to the successful verification of the flight control command, send the flight control command through the control link.

[0132] When all the above verifications pass, the mobile terminal 100 encodes the structured intent command into a flight protocol message and sends it to the UAV 300 via the current control link. The sent message may include a monotonically increasing sequence number, timestamp, session signature, and idempotent key. After verifying the signature, sequence number, and lease version, the edge gateway forwards the command to the flight control system. The flight control system combines the current attitude, position, and sensor data to execute the corresponding actions and sends back telemetry and command confirmation.

[0133] If the verification fails, the mobile terminal 100 may not send the command and will provide a reason prompt on the flight control interface, such as control has been lost, the current mode does not allow the operation, the operating area is exceeded, or the parameters exceed the safety threshold.

[0134] This embodiment performs linked verification of lease status, command permission scope, geofence, and flight parameter constraints before the command leaves the station. It can intercept commands that do not comply with authorization or safety constraints before the command enters the flight control execution link, which helps to reduce the risk of misoperation, unauthorized control, and out-of-bounds flight.

[0135] In some embodiments, when the flight control session bound to the target UAV is a multi-terminal session, the method further includes control takeover processing. A multi-terminal session refers to a UAV session containing at least two mobile terminals, where some terminals hold control while others are in observation, assistance, or pending takeover states.

[0136] When the mobile terminal holds a valid control lease, the method includes, but is not limited to, steps S71 to S72.

[0137] Step S71: Receive a takeover request from the server.

[0138] When another terminal enters the session through the same session entry point and requests to take over control, the server 200 can push a takeover request to the currently controlling mobile terminal 100. The takeover request may include at least one of the following: the requester's terminal information, the requester's qualification summary, the current task status summary, and the reason for takeover.

[0139] Step S72: In response to the takeover confirmation input, send a takeover confirmation message to the server so that the server can perform a transfer of control.

[0140] The current authorized operator can confirm or refuse on the flight control interface. If confirmed, the mobile terminal 100 sends a takeover confirmation message to the server 200. Upon receiving the confirmation, the server 200 revokes the old control lease and issues a new control lease to the applicant. The server 200 may also notify the edge gateway to register the new lease and invalidate the old lease. Afterward, the old terminal should cease sending control commands or automatically switch to observation mode.

[0141] In cases where the mobile terminal does not hold a valid control lease, the method includes, but is not limited to, steps S73 to S75.

[0142] Step S73: Receive task status information sent by the server.

[0143] After an unauthorized terminal joins the same drone session, it first receives mission status information pushed by the server (e.g., 200). This mission status information may include at least one of the following: drone location, attitude, battery level, link status, remaining flight path segment, alarm status, and current control lease summary. By synchronizing the status before requesting control, the requesting party can decide whether to take over after understanding the current flight context.

[0144] Step S74: Send a takeover request to the server.

[0145] After an operator triggers a takeover operation, an unauthorized terminal sends a takeover request to server 200. The request may include the terminal's identifier, session identifier, drone identifier, qualification information, and the scope of the requested command.

[0146] Step S75: Receive a new control lease issued by the server, wherein the new control lease is issued by the server when the original mobile terminal with control meets the preset takeover policy.

[0147] Preset takeover policies define the conditions under which control is allowed to be transferred from the original controlling terminal to the requesting terminal. Preset takeover policies may include: the original controlling terminal being online and confirming consent; the original controlling terminal being offline or experiencing a timeout after a heartbeat timeout; forced takeover by an administrator; and takeover based on role priority, etc.

[0148] Please see Figure 4 Taking the example of terminal 110 holding a lease and terminal 120 requesting takeover: Terminal 110 first requests and obtains a control lease from server 200, then sends a control command carrying this lease. After terminal 120 enters the same session, server 200 synchronizes a state snapshot and the current lease summary with it. Terminal 120 initiates a takeover request to server 200. If terminal 110 is online and agrees, it releases the old lease, server 200 grants a new lease to terminal 120, and notifies edge gateway 310 to revoke the old lease and register the new lease. If terminal 110 is offline or its heartbeat times out, server 200 can perform timeout arbitration and risk verification, conditionally granting a new lease to terminal 120 when conditions are met, and forcibly revoking the old lease. Afterwards, terminal 120 sends subsequent commands carrying the new lease, and edge gateway 310 only accepts the latest version of the lease.

[0149] When mobile terminal 100 acts as the control successor (i.e., the party that did not originally hold a valid control lease but has acquired a new lease after takeover), it sends a control succession request (i.e., the aforementioned control takeover request) to server 200, receiving a new, updated control lease issued by server 200 after arbitration. After reconfirming the control link based on the new control lease and simultaneously displaying the same task context and status information as the target UAV, mobile terminal 100 sends flight control commands. That is, the control successor does not immediately issue commands after acquiring the new lease, but first completes status synchronization and link confirmation before entering control. The task context may include information such as current flight path progress, target point, triggered alarms, and operational boundaries to ensure continuous operation after handover. When issuing a new lease, server 200 simultaneously cancels the old lease and notifies the edge gateway to register the new lease version; the edge gateway thereafter only accepts control commands carrying the latest lease version.

[0150] This embodiment models the transfer of control across multiple terminals as a lease revocation and issuance process with version numbers, and ensures that task status synchronization takes effect before control is granted. Compared to simply switching login accounts without updating command credentials, this embodiment reduces the probability of residual permissions on old terminals and simultaneous command issuance by old and new terminals, while maintaining the continuity of task context.

[0151] In some embodiments, a flight control interface is presented based on the flight control application configuration information, including but not limited to steps S301 to S303.

[0152] Step S301: Obtain the mobile terminal's terminal capability parameters, flight permission information, communication quality information, and security configuration information.

[0153] Terminal capability parameters are used to describe the hardware and interaction capabilities of the mobile terminal 100, and may include at least one of the following: screen size, input method, device orientation, computing power level, whether it supports near-field communication interface, operating system type, and operating environment capabilities.

[0154] Flight permission information describes the range of flight control capabilities that the current user or session is allowed to perform. This may include at least one of the following: permission to take off, permission to edit flight routes, permission to enter advanced mode, permitted flight areas, and maximum altitude. Flight permission information may originate from rental orders, training roles, rescue mission authorizations, or policies issued by server 200.

[0155] Communication quality information is used to describe the current link and network status, and may include near-field and far-field latency, packet loss, bandwidth, and online status.

[0156] Security configuration information describes the security policies that should be followed, and may include at least one of the following: no-fly zone rule version, offline command whitelist, maximum speed limit, and whether it is in downgrade mode.

[0157] Step S302: Determine the interface mode and the set of available flight control functions based on the terminal capability parameters, flight permission information, communication quality information, and safety configuration information.

[0158] Interface mode refers to the layout and information density level of the flight control interface, such as a simple mode on a mobile phone, a professional mode on a tablet, or a multi-window mode on a desktop. The set of available flight control functions refers to the list of operating and display functions available to the operator under current conditions.

[0159] Specifically, the mobile terminal 100 does not simply scale the layout according to the screen width; instead, it uses terminal capabilities, flight permissions, communication quality, and security configuration as conditions for unlocking functions. For example, when a mobile terminal is used and the session role is a temporary rental user, controls such as takeoff, hovering, return to home, landing, attitude display, battery level, signal strength, and alarms can be enabled; when a tablet terminal has route permissions, route planning, map layers, terrain profiles, and waypoint editing can be enabled; and when a desktop terminal has a stable link, multi-window situational awareness, audit playback, and task orchestration can be enabled. When in a weak network or security downgrade state, even if the terminal has sufficient computing power, high-risk function entries can be disabled, retaining only the set of safe operations.

[0160] Step S303: Based on the interface mode and the set of available flight control functions, present the flight control interactive interface.

[0161] Mobile terminal 100 renders the page layout according to the determined interface mode and activates only the controls in the set of available flight control functions. For unlocked functions, the entry can be hidden or displayed in a disabled state with an explanation of the reason, such as the current role is unavailable, waiting for the link to be restored, or exceeding the authorized area.

[0162] This embodiment ensures that the set of interface controls is consistent with the terminal conditions, authorization scope, and security status, which can reduce the exposure of operation entry points that exceed the authorization scope and reduce the probability of inconsistencies between the set of functions on different terminals and the current task constraints.

[0163] In some embodiments, a control link is established between the mobile terminal and the target drone, including but not limited to steps S51 to S52.

[0164] Step S51: Obtain near-field link parameters and far-field link parameters.

[0165] Near-field link parameters are a set of parameters used to evaluate the quality and availability of near-field control links. They may include at least one of the following: round-trip time, jitter, packet loss rate, bandwidth margin, whether an encrypted handshake is completed, whether the links are on the same local area network or directly connected to a network, signal strength, and power impact factor.

[0166] Far-field link parameters are a set of parameters used to evaluate the quality and availability of far-field control links. They may include at least one of the following: round-trip latency, jitter, packet loss rate, bandwidth margin, authentication status, link trustworthiness, and tariff or power cost to the server 200-side agent.

[0167] Mobile terminal 100 can collect near-field link parameters and far-field link parameters respectively through tentative handshake, heartbeat detection and statistical sliding window network indicators.

[0168] Step S52: Select and / or switch between the near-field control link and the far-field control link based on the near-field link parameters and the far-field link parameters.

[0169] Based on near-field and far-field parameters, the mobile terminal 100 selects the link most suitable for carrying flight control commands and telemetry data as the primary link, and can reserve another link as a backup link. When selecting, links with lower latency, less packet loss, and that meet safety requirements are typically prioritized. When the near-field link is stable at close range, the near-field control link can be prioritized. When the mobile terminal 100 is far from near-field coverage, or when near-field quality is insufficient but far-field coverage is available, the far-field control link can be selected.

[0170] During flight, link quality may vary. Therefore, mobile terminal 100 can periodically evaluate the quality of the primary link and switch to the backup link when switching conditions are met. Switching conditions may include the primary link falling below a quality threshold for multiple consecutive cycles, consecutive heartbeat failures, or a security layer indicating that the current link is untrusted. The near-field control link can also be implemented using LAN WebSocket, WebTransport, or private LAN protocols; the far-field agent can be deployed as part of server 200 at a central node, edge node, or rack-mounted gateway.

[0171] This embodiment establishes a candidate and switching relationship between the near-field link and the far-field link, enabling the control channel to adjust according to changes in the relative position of the terminal and the UAV and network conditions, thereby improving the continuity of flight control commands and telemetry transmission.

[0172] In some embodiments, selection and / or switching between the near-field control link and the far-field control link is performed based on near-field link parameters and far-field link parameters, including but not limited to steps S521 to S523.

[0173] Among them, near-field link parameters (near-field link quality parameters) refer to a set of indicators used to characterize the communication quality and availability of the near-field control link between the mobile terminal 100 and the edge gateway of the drone 300. Near-field control links are typically based on Bluetooth, Wi-Fi, etc. The link parameters for establishing local communication methods such as Fi Direct and Ultra-Broadband can include: round-trip time, jitter, packet loss rate, available bandwidth or bandwidth margin, signal strength, interference level, encryption and authentication status, link trustworthiness, and the power or energy consumption required by the terminal or airborne side to maintain the link.

[0174] Far-field link parameters (far-field link quality parameters) refer to a set of indicators used to characterize the communication quality and availability of the far-field control link between mobile terminal 100 and UAV 300 via server 200. Far-field control links are typically established based on wide-area communication paths such as cellular networks and the Internet. Their link parameters may include: round-trip time, jitter, packet loss rate, available bandwidth or bandwidth margin, network type and roaming status, encryption and authentication status, link trustworthiness, relay node reachability, and constraint indicators such as traffic cost and link establishment latency.

[0175] It should be noted that near-field link parameters and far-field link parameters can share some of the same metric types (such as latency, jitter, packet loss, bandwidth, and encryption status), but the sampling path, calibration method, and weight configuration can differ. For example, near-field links can focus more on local signal strength and short-range stability, while far-field links can focus more on cross-network latency, relay reachability, and traffic cost. Mobile terminal 100 can collect the above parameters separately during the link evaluation period for subsequent score calculation and primary / backup link decisions.

[0176] Step S521: Determine the near-field link score and the far-field link score based on the near-field link parameters and the far-field link parameters.

[0177] The link score is used to quantitatively compare the overall quality of candidate links. The higher the score, the more suitable the link is as the current main link. Specifically, after starting the link evaluation, the mobile terminal 100 collects parameters such as round-trip delay, jitter, packet loss rate, bandwidth margin, encryption authentication status, link trustworthiness, and cost factor for the near-field control link and the far-field control link, and calculates the near-field link score and the far-field link score accordingly.

[0178] In one optional calculation method, the parameters are first normalized, and then a weighted sum is obtained to obtain the link score. Unfavorable indicators such as latency, jitter, and packet loss rate can be scored by subtracting the normalized value from 1; favorable indicators such as bandwidth margin, encryption authentication status, and link trustworthiness are scored directly using the normalized value; cost factors such as traffic cost and power consumption cost can be deducted. All weight coefficients are non-negative, and their sum can be 1. Different weights can be used for near-field and far-field links: for example, increasing the weight of latency and jitter for near-field links, and increasing the weight of reachability, stability, and cost factors for far-field links, thus better meeting the actual control requirements of the two types of links.

[0179] For example, the link score S_l for candidate link l can be expressed as: S_l=w_r(1 _l)+w_j(1 _l)+w_p(1 _l)+w_b· _l+w_e·ê_l+w_t· _l w_c· _l in, _l represents the normalized round-trip time. _l represents the normalized jitter. _l represents the normalized packet loss rate. _l represents the normalized bandwidth margin, ê_l represents the encryption and authentication status score, and τ _l represents the link feasibility score. _l represents the electricity or tariff cost factor; w_r, w_j, w_p, w_b, w_e, w_t, and w_c are non-negative weighting coefficients, and satisfy the following: w_r+w_j+w_p+w_b+w_e+w_t+w_c=1; In this calculation formula, adverse indicators such as latency, jitter, and packet loss are expressed as "1". Normalized values ​​are used in the scoring, while bandwidth, encryption status, and trustworthiness are directly included. Cost factors are deducted as a penalty. Furthermore, different weights can be applied to near-field and far-field links; for example, near-field links may have increased weights for latency and jitter, while far-field links may have increased weights for reachability, stability, and cost factors. When S_l falls below a preset threshold and fails to meet the standard for N consecutive heartbeat cycles, a backup link switchover is triggered. If both near-field and far-field links fall below the threshold, an offline security degradation mode is entered, allowing only whitelisted commands such as hovering, return to home, landing, and emergency stop.

[0180] Step S522: Based on the near-field link score and the far-field link score, determine the main link, which is either a near-field control link or a far-field control link.

[0181] Mobile terminal 100 compares the near-field link score and the far-field link score, and selects the primary link based on a preset security threshold. If the near-field link score is higher and meets the minimum security and quality thresholds, the near-field control link is selected as the primary link. If the near-field link does not meet the conditions, but the far-field link score meets the thresholds, the far-field control link is selected as the primary link; the other link can be continuously monitored as a backup link. If neither the near-field nor the far-field candidate link meets the minimum security and quality thresholds, an offline security degradation mode can be entered, allowing only whitelisted commands such as hovering, return to home, landing, and emergency stop, while suppressing the issuance of other highly dynamic control commands.

[0182] Step S523: Periodically acquire the link quality parameters of the main link, and in response to the link quality parameters meeting the switching conditions, switch the control link to the backup link and downgrade the flight control mode of the target UAV to the conservative mode.

[0183] When the primary link is a near-field control link, the backup link is a far-field control link; conversely, when the primary link is a far-field control link, the backup link is a near-field control link. During primary link operation, the mobile terminal 100 periodically sends heartbeat / probe packets to continuously update the link parameters and scores of the primary and backup links. If the primary link falls below a preset threshold for N consecutive evaluation cycles, or if triggering conditions such as continuous heartbeat loss, latency exceeding limits, or a sharp increase in packet loss occur, a primary / backup switchover is performed. N is a positive integer and can be configured based on the mission risk level, flight phase (e.g., takeoff, cruise, landing), and operational environment.

[0184] After switching to the backup link, the target UAV's flight control mode can be downgraded to conservative mode. Conservative mode refers to a flight mode that limits maximum speed, maximum climb rate, maximum command frequency, and aggressive maneuvers when the link is unstable or has just been switched. Its purpose is to prioritize controllability and safety boundaries when communication conditions deteriorate or the link has just been restored, avoiding the continuous issuance of highly dynamic commands on an unstable link. Once the backup link (or the original primary link) is restored and its quality remains stable for several consecutive cycles, the original flight mode can be restored according to the strategy, or the conservative mode can be maintained until the end of the current mission phase. Simultaneously, the flight control interface prompts are updated to reduce the risk of misoperation during the switching window.

[0185] This embodiment forms a closed-loop link consisting of "parameter acquisition, score evaluation, main link selection, operational monitoring, main / backup switching, and flight control degradation," which links the selection / switching of near-field control links and far-field control links with flight control mode constraints. This reduces the probability of high-dynamic commands continuing to be issued when link quality deteriorates, and improves control continuity and security during temporary flight control sessions.

[0186] As another aspect of the embodiments of this application, the embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for causing an electronic device to perform the methods provided in the embodiments of this application.

[0187] In some embodiments, the storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0188] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0189] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborative files.

[0190] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected by a communication network.

[0191] As another aspect of the embodiments of this application, the embodiments of this application also provide a computer program product, the computer program product including a computer program stored on a computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method as described in the foregoing embodiments.

[0192] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0193] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A control method for an unmanned aerial vehicle (UAV), characterized in that, The control method is applied to a mobile terminal, and the control method includes: A flight control session request is sent to the server through the session entry bound to the target drone; Receive session configuration information sent by the server, the session configuration information including a one-time session token and flight control application configuration information; Based on the flight control application configuration information, a flight control interaction interface is presented; When the one-time session token is valid, acquire the control lease granted by the server; Establish a control link between the mobile terminal and the target drone; Flight control commands are sent through the control link, and the flight control commands carry the control lease.

2. The control method according to claim 1, characterized in that, The flight control application configuration information includes a cache list, and the presentation of the flight control interaction interface based on the flight control application configuration information includes: The flight control application is loaded according to the flight control application configuration information; After the flight control application is loaded for the first time, register the service worker thread; The service worker thread caches flight control resources according to the cache list; When the cached results meet the preset interactive conditions, the flight control interface is presented.

3. The control method according to claim 2, characterized in that, The process of caching flight control resources by the service worker thread according to the cache list includes: Based on the security level of the flight control resources, determine the flight control resources that are allowed to be cached and those that are prohibited from being cached; Obtain communication quality information; The service worker thread caches the flight control resources that are allowed to be cached based on the communication quality information and the security level of the flight control resources.

4. The control method according to claim 1, characterized in that, Sending flight control commands through the control link includes: The flight control commands are verified, including verification of control authority validity, command authorization, flight area compliance, and UAV flight parameter safety. In response to the successful verification of the flight control command, the flight control command is sent through the control link.

5. The control method according to claim 1, characterized in that, When the flight control session bound to the target UAV is a multi-terminal session, the method further includes: When the mobile terminal holds a valid control lease, it receives a control takeover request from the server and, in response to the takeover confirmation input, sends takeover confirmation information to the server so that the server executes the transfer of control. When the mobile terminal does not hold a valid control lease, it receives task status information from the server, sends a control takeover request to the server, and receives a new control lease from the server. The new control lease is issued by the server when the original controlling mobile terminal meets the preset takeover policy.

6. The control method according to claim 1, characterized in that, The flight control interface, based on the flight control application configuration information, is presented, including: Obtain the terminal capability parameters, flight permission information, communication quality information, and security configuration information of the mobile terminal; Based on the terminal capability parameters, flight permission information, communication quality information, and security configuration information, determine the interface mode and the set of available flight control functions; Based on the interface mode and the set of available flight control functions, the flight control interaction interface is presented.

7. The control method according to claim 1, characterized in that, Establishing the control link between the mobile terminal and the target drone includes: Obtain near-field link parameters and far-field link parameters; Based on the near-field link parameters and the far-field link parameters, selection and / or switching are performed between the near-field control link and the far-field control link.

8. A mobile terminal, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer program instructions executable by the processor, which, when executed by the processor, cause the mobile terminal to perform the control method as described in any one of claims 1 to 7.

9. A control system for an unmanned aerial vehicle (UAV), characterized in that, Includes drones, servers, and the mobile terminal as described in claim 8; The mobile terminal is communicatively connected to both the drone and the server.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions or programs that, when executed by at least one processor, cause the at least one processor to perform the control method as described in any one of claims 1 to 7.

Images