Unmanned aerial vehicle flight control method, device, equipment and storage medium

Abstract

The invention discloses an unmanned aerial vehicle flight control method and device, equipment and a storage medium, and relates to the field of unmanned aerial vehicles, and the method comprises the steps: periodically monitoring the survival state of a host process through a hot standby process; when determining that the survival state of the host process is abnormal, acquiring backup data from a first preset position of a pre-configured shared memory; migrating the backup data to the host process; and after the host process is controlled to be restarted, running the backup data by using the host process so as to continuously control the unmanned aerial vehicle to continuously execute the flight operation. The system ensures that the system can immediately restart the host process and recover the function of the host process through the hot standby process through a dual-process hot standby architecture, so that the unmanned aerial vehicle is prevented from being out of control, backup data is migrated to the restarted host process at the first time, the data recovery degree is improved, the normal flight control state is recovered immediately after loss of communication, and the reliability of the unmanned aerial vehicle is improved. And the risk when the unmanned aerial vehicle executes the disconnection action is reduced.

Description

Technical Field

[0001] This application relates to the field of unmanned aerial vehicle (UAV) technology, and in particular to UAV flight control methods, devices, equipment and storage media. Background Technology

[0002] Flight control platforms typically need to maintain the stable operation of the ground station's flight control software during flight missions. In the event of abnormal scenarios such as program crashes, the drone will become uncontrollable, leading to safety accidents.

[0003] The following technical solutions are proposed in related technologies to address the above problems: Option 1 is a dual-control solution, where one drone is paired with two control devices. However, this solution increases hardware costs.

[0004] Option two involves the ground station flight control software detecting and automatically restarting from a crash. This method allows the software to restart and resume control of the drone after a crash. However, all flight control command data prior to the crash will be lost.

[0005] Option three involves designing loss-of-connection actions in the drone's flight control program, such as returning to home or landing. While this option can mitigate some risks, there are still certain risks involved in executing these loss-of-connection actions.

[0006] Therefore, a low-cost method that can retain data after software recovery and avoid the risks of drones performing disconnected actions is urgently needed in this technical field. Summary of the Invention

[0007] This application provides a method, apparatus, device, and storage medium for unmanned aerial vehicle (UAV) flight control, in order to at least solve the problems in related technologies such as high flight control costs, inability to retain data during software recovery, and the inability to avoid risks when UAVs perform disconnection actions.

[0008] This application provides a method for controlling the flight of an unmanned aerial vehicle (UAV). This method is applied to a UAV flight control system, which includes a main process and a hot standby process, comprising: The hot standby process periodically monitors the liveness status of the main process; When it is determined that the survival status of the main process is abnormal, backup data is obtained from the first preset location of the pre-configured shared memory. The backup data is flight control command data backed up by the hot standby process. The flight control command data is the command of the main process to control the drone to fly. Migrate backup data to the main process; After the main control process restarts, it runs backup data to continue controlling the drone to perform flight operations.

[0009] This application also provides a drone flight control device, including: The monitoring module is used to periodically monitor the survival status of the main process through the hot standby process; The acquisition module is used to acquire backup data from the first preset location of the pre-configured shared memory when it is determined that the survival status of the main process is abnormal. The backup data is the flight control command data generated by the main process during the control of the drone flight by the hot standby process. The migration module is used to migrate backup data to the main process; The runtime module is used to run backup data using the main process after restarting the main process, so as to continue controlling the drone to perform flight operations.

[0010] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described UAV flight control methods.

[0011] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described UAV flight control methods.

[0012] This application describes a UAV flight control system that periodically monitors the main process's liveness through a hot standby process, thereby reducing the time required for main process restart and recovery in the event of anomalies. When the main process's liveness becomes abnormal, to achieve low-latency recovery, the UAV flight control system retrieves its backup data stored in shared memory through the hot standby process. This backup data includes flight control command data, which is the control command data used by the main process to control the UAV's flight. The reason for backing up the flight control command data to a first preset location in shared memory is to prevent the loss of the corresponding UAV flight control command data when the main process's liveness becomes abnormal. Directly restarting the main process in this situation would pose unpredictable risks. Therefore, the system needs to migrate the backup data previously backed up by the hot standby process to the restarted main process for recovery. During the main process recovery process, the high read / write speed of shared memory reduces the time required to migrate the backup data to the restarted main process. When the main process experiences an abnormal state of survival, a dual-process hot standby architecture ensures that the system can immediately restart the main process and restore its functionality through the hot standby process. This prevents the drone from going out of control and allows backup data to be migrated to the restarted main process immediately, improving data recovery accuracy. This enables the system to quickly restore normal flight control after a loss of connection, reducing the risk of the drone performing actions that would otherwise be unresponsive. Since this method is applied to drone flight control systems, such as Android systems, it does not rely on dedicated flight control hardware, achieving broad applicability, strong adaptability, and low application cost. Attached Figure Description

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

[0014] Figure 1 A schematic diagram of an unmanned aerial vehicle (UAV) flight control system provided in an embodiment of this application; Figure 2 A schematic diagram of a drone flight control method provided in an embodiment of this application; Figure 3 A schematic diagram of another UAV flight control method provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the normal heartbeat response provided in an embodiment of this application; Figure 5 This is a schematic diagram of the heartbeat packet failure response process provided in an embodiment of this application; Figure 6This is a schematic diagram of the structure of a drone flight control device provided in an embodiment of this application; Figure 7 This is a schematic diagram of an electronic device structure provided in an embodiment of this application. Detailed Implementation

[0015] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0016] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0017] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] Flight control platforms typically need to maintain the stable operation of the ground station's flight control software during flight missions. In the event of program crashes or other abnormal scenarios, the drone can become uncontrollable, leading to safety incidents. The following solutions are proposed in related technologies to address this problem: Option 1 is a dual-control solution, where one drone is paired with two control devices. However, this solution increases hardware costs.

[0019] Option two involves the ground station flight control software detecting and automatically restarting from a crash. This method allows the software to restart and resume control of the drone after a crash. However, all flight control command data prior to the crash will be lost.

[0020] Option three involves designing loss-of-connection actions in the drone's flight control program, such as returning to home or landing. While this option can mitigate some risks, there are still certain risks involved in executing these loss-of-connection actions.

[0021] To address the problems encountered in the solutions of the aforementioned related technologies, this application proposes a drone flight control method. This method involves a real-time backup and seamless recovery of the drone control state after a crash through the collaboration of main and sub-processes. It is applied to the real-time control scenario of a drone flight control system (hereinafter referred to as the system), such as in the Android system of a drone remote control device. This effectively solves the problems of single-process crash and loss of flight state after a crash without increasing hardware costs.

[0022] like Figure 1 As shown, Figure 1 The schematic diagram of the UAV flight control system provided in this application embodiment shows that the main process supports the following functions: user interface, i.e., the user's visual UI; video decoding, i.e., decoding the video data collected by the UAV through the camera to provide the user with a visual video page; flight control software development kit (Flight Control SDK), where the main process encapsulates MAVLink instructions through Binder Inter-Process Communication (Binder IPC) to communicate with the UAV flight system. The running data of the main process and the running data of the hot standby process are both stored in shared memory. The hot standby process backs up the flight control command data of the main process controlling the UAV flight through shared memory. Simultaneously, the hot standby process also persistently stores and backs up the data generated during UAV flight through a preset storage device, such as asynchronously storing it in an SQLite database through SQLite Write-Ahead Logging (SQLite WAL). Based on the above, the embodiments of this application provide a UAV flight control method, see details below. Figure 2 As shown, the method includes the following steps: Step S201 involves periodically monitoring the main process's survival status through a hot standby process. Specifically, this is to prevent risks and financial losses caused by the main process suddenly failing and not being detected in time, and also to rationally allocate system resources and avoid waste. Therefore, in this embodiment, the main process's survival status is periodically monitored through a hot standby process to determine if any abnormalities have occurred in the main process's survival status.

[0023] Step S202: When it is determined that the survival status of the main process is abnormal, backup data is obtained from the first preset location of the pre-configured shared memory.

[0024] The backup data includes flight control command data backed up by the hot standby process, and the flight control command data contains the commands used by the main process to control the drone's flight.

[0025] Specifically, when the hot standby process detects an abnormality in the main process's survival status, such as process freeze, process suspension, process crash, or process false liveness, the system retrieves backup data already stored in a first preset location in shared memory. This first preset location is the specific location in shared memory where the system stores the acquired flight control command data (used by the main process to control the drone) after the hot standby process obtains it in real time. Step S203 involves migrating the backup data to the main process.

[0026] Specifically, when the main process's survival status becomes abnormal, since both the main process's and the hot standby process's running data are stored in shared memory, the system can use the hot standby process to migrate the backup data stored in the first preset location in shared memory to the address of the restarted main process in shared memory. This migration of backup data to the main process restores it to its state before the survival status abnormality, allowing the main process to continue controlling the drone's flight operations. Afterward, the system will continue to back up the flight control command data for controlling the drone's flight after the restart through the hot standby process in the first preset location.

[0027] Step S204: After the main control process restarts, the backup data is run using the main process to continue controlling the drone to perform flight operations.

[0028] Specifically, the backup data includes flight control command data, which is a collection of core operating commands collected and transmitted by the system in real time. This data is used by the system to control the drone's flight attitude, position, power, link, and other key states through the main process. This flight control command data is an important basis for the drone operator to control the drone's flight.

[0029] This application provides a drone flight control method. The drone flight control system periodically monitors the survival status of the main process through a hot standby process, thereby reducing the time for restarting and recovering the main process in case of anomalies. When the survival status of the main process becomes abnormal, in order to achieve low-latency recovery of the main process, the drone flight control system retrieves its backup data stored in shared memory through the hot standby process. This backup data includes flight control command data, which is the control command data used by the main process to control the drone's flight. The reason for backing up the flight control command data to a first preset location in shared memory is to prevent the loss of drone flight control command data corresponding to the main process when the main process's survival status becomes abnormal. Directly restarting the main process in this situation would pose unpredictable risks. Therefore, the system needs to migrate the backup data previously backed up by the hot standby process to the restarted main process for recovery. During the recovery process, the high read / write speed of shared memory reduces the time required to migrate the backup data to the restarted main process. When the main process experiences an abnormal state of survival, a dual-process hot standby architecture ensures that the system can immediately restart the main process and restore its functionality through the hot standby process. This prevents the drone from going out of control and allows backup data to be migrated to the restarted main process immediately, improving data recovery accuracy. This enables the system to quickly restore normal flight control after a loss of connection, reducing the risk of the drone performing actions that would otherwise be unresponsive. Since this method is applied to drone flight control systems, such as Android systems, it does not rely on dedicated flight control hardware, achieving broad applicability, strong adaptability, and low application cost.

[0030] In an optional example, based on the aforementioned embodiments, since the system transmits flight control command data to the drone through the main process when controlling the drone to perform flight operations, the system will first back up the flight control command data to a first preset location through a hot standby process, and then send the flight control command data to the drone through the main process.

[0031] When the main process's survival status is determined to be abnormal, before retrieving backup data from the first preset location of the pre-configured shared memory, the system has already backed up the flight control command data to the first preset location via a hot standby process. This is why it is possible to retrieve backup data from the first preset location of the pre-configured shared memory when the main process's survival status is determined to be abnormal. Therefore, before retrieving backup data from the first preset location of the pre-configured shared memory when the main process's survival status is determined to be abnormal, the method may also include the following steps, see details below. Figure 3 As shown, it includes: Step S301: Store the flight control command data in a second preset location in shared memory.

[0032] Specifically, when the system controls the drone to perform flight operations through the main process, the system transmits flight control command data to the drone through the main process. This data is first stored in a second preset location in shared memory. The second preset location is located in a different position from the first preset location in memory and they do not overlap. Since the data stored in the second preset location in shared memory will be cleared when the main process's state becomes abnormal, separating the first and second preset locations can prevent the backup data in the first preset location in shared memory from being cleared when the main process's state becomes abnormal.

[0033] Step S302: Periodically acquire flight control command data from the second preset location through the hot standby process, and back up the flight control command data to the first preset location.

[0034] Specifically, since flight control command data and hot standby process data are temporarily stored in shared memory, the system periodically backs up the flight control command data stored in the second preset location to the first preset location via the hot standby process. When the system backs up the flight control command data stored in the second preset location via the hot standby process, it uses resource locks (such as file locks) to freeze the flight control command data in the second preset location. This prevents other processes (such as the main process) from writing to or performing other operations in the second preset location while the system is reading data via the hot standby process, which could lead to data corruption or duplicate readings.

[0035] In the above method, since the system controls the drone to perform flight operations through the main process, after the system backs up the flight control commands through the hot standby process, it sends them to the drone through the main process. Therefore, the flight control command data stored in the second preset location is backed up to the first preset location before the survival status of the main process becomes abnormal. After the main process recovers, the system can migrate the backup data stored in the first preset location to the second preset location corresponding to the main process through the hot standby process, so as to achieve seamless recovery after the survival status of the main process becomes abnormal.

[0036] In an optional example, since backup data anomalies may occur during the hot standby process of backing up flight control command data, if abnormal data that differs from flight control command data can be discarded through data verification before the backup data is injected into the first preset location, and then the backup data after discarding the abnormal data is migrated as new backup data to the second preset location, the accuracy of the system's flight operations on the UAV after the main process recovers can be further improved. Therefore, before migrating the backup data to the main process, the method may also include the following steps: Step a1: Verify each flight control command data stored in the second preset location, and determine a first verification value for each flight control command data.

[0037] Step a2: Verify each piece of data in the backup data stored in the first preset location, and determine the second verification value of each piece of data in the backup data.

[0038] Specifically, before the main process's survival status becomes abnormal, the system verifies each flight control command data stored in the second preset location. For example, the system uses CRC32 (Cyclic Redundancy Check 32-bit) to perform polynomial operations on each flight control command data to generate a 32-bit check value, i.e., the first check value. Based on the first check value, it can monitor whether errors have occurred in the flight control command data during transmission or storage, such as bit flipping, loss, or tampering. Similarly, after the main process's survival status becomes abnormal, the above verification process is performed on each piece of data in the backup data stored in the first preset location to determine the second check value for each piece of data in the backup data.

[0039] Step a3: After comparing the first check value with its corresponding second check value, determine the check result.

[0040] Step a4: When it is determined from the verification results that there is abnormal data in the backup data, discard the abnormal data and migrate the new backup data after discarding the abnormal data to the main process.

[0041] Specifically, based on the flight control command data stored in the second preset location, when the second checksum differs from the first checksum, it indicates that the backup data corresponding to the second checksum is abnormal. Therefore, according to the verification result after comparing the first and second checksums, this data in the backup data corresponding to the second checksum is considered abnormal and discarded. All backup data after discarding the abnormal data is then migrated to the second preset location, providing accurate backup data for main process recovery. In the above method, when the system backs up flight control command data through the hot standby process, abnormal backup data may occur. If, before injecting the backup data into the first preset location, abnormal data inconsistent with the flight control command data is filtered out and discarded using data verification, and then the new backup data formed after discarding the abnormal data is migrated to the second preset location, when the main process recovers, since the new backup data is used, the accuracy of the system's execution of UAV flight operations after the main process recovery can be further improved, ensuring the accuracy and reliability of data usage and avoiding execution errors during UAV flight caused by erroneous and / or incomplete data.

[0042] In an optional example, during system operation, since the various processes of the system run in shared memory, the system can continuously monitor the main process through a hot standby process and back up various key flight data of the main process in real time, such as MAVLink instructions. MAVLink instructions are commands that control the UAV to perform various flight operations. Backing up MAVLink instructions is used to continue executing MAVLink instructions that were not executed before the main process's abnormal state after the main process recovers, so as to continue the flight operations. This achieves a seamless transition of the UAV's flight operations after the flight operations are paused due to the main process's recovery from an abnormal state. Therefore, the backup data contains at least one MAVLink instruction, and the MAVLink instruction contains a MAVLink sequence number and a recovery flag. When the main process restarts, it uses the backup data to continue controlling the UAV to continue performing flight operations. The method may also include the following steps: Step b1: Set a preset value for the recovery flag bit of the first MAVLink instruction through the main process.

[0043] The first MAVLink instruction is the MAVLink instruction with the smallest MAVLink sequence number among at least one MAVLink instruction. Step b2 involves the main process sending the first MAVLink instruction, which has already been set with a preset value in the recovery flag bit, to the drone.

[0044] Specifically, the main process sends a first MAVLink command to the drone, which has a preset value set in the recovery flag. The purpose is to enable the drone to continue the flight process according to the MAVLink serial number based on the first MAVLink command.

[0045] Each MAVLINK instruction is transmitted sequentially according to its serial number. Therefore, when the drone receives the first MAVLink instruction, that is, the MAVLink instruction with the smallest MAVLink number, it will execute the MAVLink instructions sequentially from the first MAVLink instruction according to the MAVLink serial number.

[0046] Since the transmission needs to be resumed from the point of interruption in the previous transmission process after the main process is resumed, a recovery flag is included in each MAVLink instruction. This flag allows the drone to identify which MAVLink instruction has the smallest MAVLink sequence number among all the received MAVLink instructions.

[0047] The system operates by having the main process set a preset value for the recovery flag of the MAVLink instruction with the smallest sequence number in the backup data, and then sending the backup data with the recovery flag set to the drone through the main process. For example, the recovery flag of the first MAVLink instruction is set to 1, and the recovery flags of the remaining MAVLink instructions are set to 0. When the drone receives one or more MAVLink instructions transmitted from the main process, it can identify the recovery flags in all the MAVLink instructions and execute the MAVLink instructions sequentially according to their sequence numbers. For example, if the recovery flag of the current MAVLink instruction is identified as 1, then the current MAVLink instruction with a recovery flag of 1 is used as the reference, and the MAVLink instructions are executed sequentially according to their sequence numbers.

[0048] In the above method, by setting a preset value for the backup flag bit in the MAVLink command of the backup data, the drone is provided with a basis to identify the MAVLink command with the smallest corresponding MAVLink serial number. This enables the drone to continue executing MAVLink commands in sequence according to the MAVLink serial number after the flight operation is paused due to the main process going from an abnormal state to recovery, thus achieving a seamless sequential connection of flight operations.

[0049] In an optional example, this method is applied to real-time control scenarios of drone flight control systems. Taking the Android system used in drone remote control devices as an example, since the main process will be restarted and the backup data will be migrated to the restarted main process when the main process is in an abnormal state, but the main process needs the support of the runtime environment and flight control SDK to run the backup data, the method also includes the following steps before using the main process to run the backup data to continue controlling the drone to perform flight operations after the main process restarts: Step c: Rebuild the runtime environment and flight control software development kit instance through the main process.

[0050] The runtime environment is the environment in which the main process runs backup data, and the flight control software development kit instance is used to encapsulate the MAVLink commands sent to the UAV through the main process.

[0051] Specifically, since the Android system uses Java as its core development language and operating basis, when the system (referring to the Android system in this case) runs backup data through the main program, it is necessary to rebuild JNI to enable interaction between Java code and native code written in other programming languages, and to provide a runtime environment for running backup data.

[0052] The system reconstructs the flight control SDK instance through the main process for encapsulating MAVLink commands, providing the basis for the system to send MAVLink commands to the UAV through the main process.

[0053] In the above approach, by rebuilding the JNI (Java Native Interface) and flight control SDK instances, the system is provided with the operational foundation for running backup data through the main process and sending MAVLink commands to the UAV.

[0054] As an alternative example, if the system only backs up the flight control command data generated by the main process during the drone's flight via the hot standby process, although it can enable the system to control the drone through the main process after the main process recovers from an anomaly, it is not conducive to the analysis of the cause of the main process's anomaly after the drone's flight ends if the various flight data generated during the drone's flight is not backed up before the main process's survival status becomes abnormal. Therefore, based on the above embodiment, the method further includes the following steps: Step d1: Obtain flight data generated during the flight process of the UAV based on flight control command data through the main process.

[0055] Step d2 involves storing the flight data in a third preset location on a preset storage device, so that after the UAV performs flight operations, the operator can analyze the reasons for any abnormalities in the main process's survival status.

[0056] Specifically, when the system controls the drone to perform flight operations through the main process, the main process generates flight data. The flight data includes waypoint mission information, flight parameter logs, and other flight data. The waypoint mission information is used to record a series of waypoint information for the drone during flight, including longitude, latitude, altitude, etc., as well as the drone's flight speed, heading mode, turning method, and custom actions such as taking pictures, recording videos, and hovering at each waypoint.

[0057] Flight parameter logs are digital files automatically recorded by the flight control system during UAV flight, covering key data throughout the entire flight process; they are essentially the UAV's "flight black box." The recorded data is comprehensive, including basic flight data such as positioning information, altitude, speed, and heading, as well as device status data such as battery level, voltage, sensor readings, and remote controller signal strength. Some logs also record mission-related data such as camera operation and gimbal angle. This flight data is stored on a preset storage device, which differs from the shared memory storage device mentioned in the previous embodiments. For example, this storage device is an SQLite database. The system asynchronously stores the flight data using SQLite WAL mode and stores the flight data in a third preset location within the SQLite database.

[0058] Because the system's storage of flight data on the preset storage device via the main process lacks real-time reliability and does not store data every moment—for example, if the main process malfunctions at time t, the data stored on the preset storage device might only include data from time t-1 and earlier—due to the lack of real-time reliability. Therefore, a hot standby process is needed to perform real-time backups of the UAV's flight data, storing the backed-up data in a third preset location on the preset storage device. This addresses the risk of data loss after the main process resumes due to the lack of real-time data storage reliability.

[0059] In one alternative example, a stable and efficient method is needed to monitor the liveness of the main process, for timely detection of abnormal liveness and to reduce the time required for the main process to recover from an anomaly. Therefore, the liveness of the main process is periodically monitored through a hot standby process, including: Step e1 involves periodically sending heartbeat signals to the main process through the hot standby process.

[0060] Step e2: After sending the heartbeat signal, start timing. If no response is received from the main process after a preset time period, it is determined that the main process's survival status is abnormal.

[0061] Specifically, the system periodically sends heartbeat signals to the main process through the hot standby process and starts timing. If no ACK (Acknowledgment) response signal is received from the main process after a preset time period (more than 50ms), it is determined that the survival status of the main process has become abnormal.

[0062] In the above method, monitoring whether a heartbeat packet is received by setting a preset time achieves a millisecond-level recovery time (<80ms, although other operations, such as sending an ACK response signal, still require about 30ms), which is better than the time consumed by process restart in traditional systems (300ms+), thus reducing the recovery time.

[0063] In a specific embodiment, such as Figure 4 and Figure 5 As shown, Figure 4 This is a flowchart illustrating the normal heartbeat response process. Figure 5 This is a flowchart illustrating a heartbeat packet failure. It's important to understand that in the diagram, the main process and the hot standby process both belong to the UAV flight control system. Neither process has independent processing capabilities; the diagram is only shown to explain the process flow. The main process and hot standby process are not independent execution entities but are controlled to run corresponding program code and perform corresponding operations, as shown below: See Figure 4 When the system uses the hot standby process to send heartbeat packets to the main process to monitor the survival status of the main process, if the main process sends an ACK response within a preset time period, i.e., 50ms, it indicates that the survival status of the main process is normal.

[0064] See Figure 5 When the system monitors the main process's liveness by sending heartbeat packets through the hot standby process, if the hot standby process does not receive the ACK response from the main process within a preset time period (i.e., after 50ms), it indicates that the main process's liveness has become abnormal. In this case, the hot standby process sends a termination signal (SignalKill, SIGKILL) to the main process to prevent the forced release of exclusive resources such as serial ports in case of an abnormality. This helps the system restart a new main process, ensuring the safe release of resources. Afterwards, the hot standby process sends an Intent to the system to request the restart of the new process. The system then uses the CPU to execute the task of restarting the main process, which becomes the new main process. The new master process will acquire the backup data (shared memory file descriptor (fd)) from the hot standby process and the flight data (SQLite backup) stored in the preset storage device. After acquiring the backup data and flight data, it will send a MAVLink instruction with a recovery flag to the drone's flight system, so that the drone can execute the MAVLink instructions in sequence according to the smallest MAVLink instruction sequence number. When the drone's flight system confirms receipt, it will return an ACK confirmation message to the new master process.

[0065] In the above embodiment, the system achieves dual-process collaborative hot standby through a main control process and a hot standby process. The main process focuses on real-time flight control, such as the transmission of MAVLink commands and video processing, while the hot standby process continuously backs up the flight control command data and flight data of the main process. Seamless recovery of the main process is achieved through a heartbeat mechanism and Intents. SIGKILL is used to forcibly release the exclusive resources of the main process upon crash, helping the system create a new main process and ensuring the safe release of resources. In summary, this embodiment achieves low recovery costs, high data retention, and reduces the risk of the UAV performing actions that would otherwise be unreachable, as it immediately restores normal flight control after a loss of connection.

[0066] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0067] Embodiments of this application also provide a drone flight control device, which is applied to a drone flight control system. The drone flight control system includes a main process and a hot standby process. See details... Figure 6 As shown, the device includes: The monitoring module 601 is used to periodically monitor the survival status of the main process through the hot standby process; The acquisition module 602 is used to acquire backup data from a first preset location of pre-configured shared memory when it is determined that the survival status of the main process is abnormal. The backup data is flight control command data generated by the main process of the hot standby process during the control of the drone flight. Migration module 603 is used to migrate backup data to the main process; The running module 604 is used to run backup data using the main process after restarting the main process, so as to continue to control the drone to continue to perform flight operations.

[0068] In an optional example, the device further includes: a processing module 605 and a backup module 606; The processing module 605 is used to store flight control command data in a second preset location in shared memory before retrieving backup data from a first preset location in the pre-configured shared memory when it is determined that the survival status of the main process is abnormal. The backup module 606 is used to periodically obtain flight control command data from a second preset location through a hot standby process and back up the flight control command data to a first preset location.

[0069] In an optional example, the device further includes: a determining module 607; The determination module 607 is used to verify the flight control command data stored in the second preset location and determine the first verification value before migrating the backup data to the main process; and to verify the backup data stored in the first preset location and determine the second verification value. The processing module 605 is also used to determine the verification result after comparing the first verification value and the second verification value; and to discard the abnormal data when it is determined from the verification result that there is abnormal data in the backup data. Migration module 603 is also used to migrate new backup data after discarding abnormal data to the main process.

[0070] In an optional example, the device further includes: a transmitting module 608; The running module 604 is specifically used to: set a preset value for the recovery flag bit of the first MAVLink instruction through the main process, wherein the first MAVLink instruction is the MAVLink instruction with the smallest MAVLink sequence number among at least one MAVLink instruction; The sending module 608 is used to send a first MAVLink instruction with a preset value set in the recovery flag bit to the UAV through the main process, so that the UAV can continue to execute the flight process according to the MAVLink serial number based on the first MAVLink instruction.

[0071] In an optional example, the device further includes: a reconstruction module 609; The reconstruction module 609 is used to rebuild the runtime environment and flight control software development kit instance by the main process before the main process runs backup data to continue controlling the drone to perform flight operations after the main process restarts. The runtime environment is the environment in which the main process runs backup data, and the flight control software development kit instance is used to encapsulate the MAVLink commands sent to the drone through the main process.

[0072] In an optional example, module 602 is specifically used to acquire flight data generated by the UAV during flight execution based on flight control command data through the main process; The processing module 605 is also used to store flight data to a third preset location in a preset storage device, so that after the UAV performs flight operations, the operator can analyze the reasons for the abnormal survival status of the main process.

[0073] The description of the features in the embodiment of the UAV flight control device provided in this application can be found in the relevant description of the embodiment of the UAV flight control method, and will not be repeated here. The UAV flight control device provided in this application involves a UAV flight control system that periodically monitors the survival status of the main process through a hot standby process, thereby reducing the time for restarting and recovering the main process in case of anomalies. When the survival status of the main process becomes abnormal, in order to achieve low-latency recovery of the main process, the UAV flight control system obtains its own backup data stored in shared memory through the hot standby process. This backup data includes flight control command data, which is the control command data used by the main process to control the UAV flight. The reason for backing up the flight control command data to a first preset location in shared memory is to prevent the loss of the UAV flight control command data corresponding to the main process when the survival status of the main process becomes abnormal. In this case, directly restarting the main process would pose unpredictable risks. Therefore, the system needs to migrate the backup data previously backed up by the hot standby process to the restarted main process to restore the main process. During the recovery process, the fast read / write speed of shared memory can be utilized to reduce the time for migrating the backup data to the restarted main process. When the main process experiences an abnormal state of survival, a dual-process hot standby architecture ensures that the system can immediately restart the main process and restore its functionality through the hot standby process. This prevents the drone from going out of control and allows backup data to be migrated to the restarted main process immediately, improving data recovery accuracy. This enables the system to quickly restore normal flight control after a loss of connection, reducing the risk of the drone performing actions that would otherwise be unresponsive. Since this method is applied to drone flight control systems, such as Android systems, it does not rely on dedicated flight control hardware, achieving broad applicability, strong adaptability, and low application cost.

[0074] Embodiments of this application also provide an electronic device, such as... Figure 7 As shown, it includes a memory 10 and a processor 20. The memory 10 stores a computer program, and the processor 20 is configured to run the computer program to perform the steps in any of the above embodiments of the UAV flight control method.

[0075] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the UAV flight control method when it is run.

[0076] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0077] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the UAV flight control method.

[0078] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0079] The foregoing has provided a detailed description of a drone flight control method, apparatus, device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for controlling the flight of an unmanned aerial vehicle (UAV), characterized in that, The method is applied to a drone flight control system, which includes a main process and a hot standby process. The method further includes: The hot standby process periodically monitors the survival status of the main process; When it is determined that the survival status of the main process is abnormal, backup data is obtained from the first preset location of the pre-configured shared memory. The backup data includes flight control command data backed up by the hot standby process. The flight control command data is the command of the main process to control the drone to fly. Migrate the backup data to the main process; After the main process is restarted, the backup data is run using the main process to continue controlling the drone to perform flight operations.

2. The method according to claim 1, characterized in that, When it is determined that the survival status of the main process is abnormal, before retrieving backup data from the first preset location of the pre-configured shared memory, the method further includes: The flight control command data is stored in a second preset location in the shared memory; The flight control command data is periodically acquired from the second preset location through the hot standby process, and the flight control command data is backed up to the first preset location.

3. The method according to claim 2, characterized in that, Before migrating the backup data to the main process, the method further includes: Each of the flight control command data stored in the second preset location is verified, and a first verification value is determined for each of the flight control command data. Each piece of data in the backup data stored in the first preset location is verified to determine a second verification value for each piece of data in the backup data; After comparing the first check value with the second check value, the check result is determined; When it is determined from the verification result that there is abnormal data in the backup data, the abnormal data is discarded, and the new backup data after discarding the abnormal data is migrated to the main process.

4. The method according to claim 1 or 2, characterized in that, The backup data contains at least one MAVLink instruction, which includes a MAVLink serial number and a recovery flag. When the main process restarts, the backup data is run using the main process to continue controlling the drone to perform flight operations, including: The main process sets a preset value for the recovery flag bit of the first MAVLink instruction, wherein the first MAVLink instruction is the MAVLink instruction with the smallest MAVLink sequence number among at least one MAVLink instruction; The main process sends a first MAVLink instruction to the drone, which has a preset value set in the recovery flag bit, so that the drone can continue to execute the flight process according to the first MAVLink instruction and the MAVLink serial number.

5. The method according to claim 4, characterized in that, Before the backup data is run using the main process after the main process restarts to continue controlling the drone to perform flight operations, the method further includes: The main process reconstructs the operating environment and flight control software development kit instance, wherein the operating environment is the environment in which the main process runs the backup data, and the flight control software development kit instance is used to encapsulate the MAVLink instructions sent to the UAV through the main process.

6. The method according to claim 1, characterized in that, The method further includes: The main process acquires flight data generated by the UAV during flight execution based on the flight control command data. The flight data is stored in a third preset location in a preset storage device, so that after the UAV performs flight operations, the operator can analyze the reasons for the abnormal survival status of the main process.

7. The method according to claim 1, characterized in that, The step of periodically monitoring the survival status of the main process through the hot standby process includes: The hot standby process periodically sends heartbeat signals to the main process; After sending the heartbeat signal, a timer is started. If no response is received from the main process after a preset time period, it is determined that the main process's survival status has become abnormal.

8. A flight control device for unmanned aerial vehicles (UAVs), characterized in that, The device is applied to a drone flight control system, the system including a main process and a hot standby process, and the device includes: The monitoring module is used to periodically monitor the survival status of the main process through the hot standby process; The acquisition module is used to acquire backup data from a first preset location of pre-configured shared memory when it is determined that the survival status of the main process is abnormal. The backup data is flight control command data generated by the main process backed up by the hot standby process during the control of the drone flight. The migration module is used to migrate the backup data to the main process; The running module is used to restart the main process and then run the backup data using the main process to continue controlling the drone to perform flight operations.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the unmanned aerial vehicle flight control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the UAV flight control method as described in any one of claims 1 to 7.

Images