Unmanned aerial vehicle emergency control method and system based on multi-module switching

Abstract

This application discloses an emergency control method and system for unmanned aerial vehicles (UAVs) based on multi-module switching. The method includes: constructing a priority sequence based on the functions and operating status of each software module, and determining the master module for UAV control based on this sequence; constructing a communication network with the master module as the central node and the other software modules, flight control computer, and ground control system as peripheral nodes; transmitting the operating data of the other software modules to the ground control system through the master module via periodic communication between the nodes; monitoring the communication status, and when a communication anomaly occurs and it is determined that the master module has failed, updating the master module according to the priority sequence to take over control of the UAV. This solves the problem that existing UAV core control systems cannot easily take over tasks after a failure. It effectively reduces the risk of UAV loss of control, avoids unexpected situations due to control vacuum, and improves the system's fault tolerance, task continuity, and reliability.

Description

Technical Field

[0001] This application relates to the field of aircraft control technology, and in particular to an emergency control method and system for unmanned aerial vehicles based on multi-module switching. Background Technology

[0002] As a complex intelligent flight platform, the core control system of an unmanned aerial vehicle (UAV) consists of an onboard mission computer and a flight control computer working together. The onboard mission computer is responsible for generating high-level commands such as flight paths, payload delivery strategies, and mission area division; while the flight control computer focuses on low-level real-time control such as attitude stabilization, trajectory tracking, and power distribution. Under this architecture, the software modules of the onboard mission computer are typically deployed in two modes: one is to integrate functions such as mission planning, data processing, and human-machine interaction into a single executable program (monolithic); the other is to divide functions into multiple independently compiled / running modules (such as planning modules, monitoring modules, and interface modules), with each module interacting through inter-process communication (IPC) or a custom protocol. During software operation, the onboard mission computer sends periodic or event-triggered control commands (such as waypoint updates and speed adjustments) to the flight control computer and receives status information such as attitude, position, and fault codes from the flight control computer, forming a closed loop of "planning-execution-feedback".

[0003] The core control system of existing UAVs revolves around the logic of "hardware unit collaboration + software deployment and execution," with specific implementation methods including hardware interaction and software deployment. Hardware interaction establishes a core control link between the onboard mission computer and the flight control computer, with a fixed communication channel between them. Flight mission commands and path planning data generated by the onboard mission computer are transmitted to the flight control computer through this channel. The flight control computer then drives the UAV to execute corresponding flight maneuvers based on the received data and feeds back flight status data to the onboard mission computer. When software deployment adopts a monolithic approach, all control functions (including mission planning, flight attitude control, and data processing) are integrated into a single software package and run within a unified process on the onboard mission computer. When using a multi-module deployment, although different functions are separated into independent software modules, each module still relies on the unified resource scheduling of the onboard computer. Data interaction between software modules does not adopt a standardized distributed architecture, essentially remaining within the scope of a centralized software architecture.

[0004] In the existing centralized software architecture, the strong coupling between the onboard mission computer and the flight control computer means that failure of any component (such as software failure or crash due to code errors, memory overflow, or external interference) can directly lead to the core control system losing effective command input, causing the UAV to go out of control. Furthermore, the system cannot automatically restart after a crash. Even with manual intervention to restart the software, the restarted system needs to reinitialize all software modules, and cannot inherit the mission context before the crash (such as executed flight segments and incomplete payload operation states), resulting in forced mission interruption and difficulty in resuming the mission, significantly reducing mission reliability. Summary of the Invention

[0005] This application provides an emergency control method and system for unmanned aerial vehicles (UAVs) based on multi-module switching, which solves the problem that the core control system of existing UAVs is difficult to continue tasks after a failure.

[0006] In a first aspect, embodiments of this application provide an emergency control method for unmanned aerial vehicles (UAVs) based on multi-module switching, comprising: constructing a priority sequence according to the functions and operating status of each software module in an airborne mission computer, and determining a master module in each software module to control the UAV according to the priority sequence; constructing a communication network with the master module as the central node and the other software modules, flight control computer, and ground control system as peripheral nodes; sending the operating data of the other software modules to the ground control system through the master module via periodic communication between the nodes in the communication network; monitoring the periodic communication, and when a communication anomaly occurs and it is determined that the master module has failed, updating the master module according to the priority sequence to take over control of the UAV; wherein, the UAV undergoes functional downgrading or functional restoration according to the priority of the updated master module.

[0007] In conjunction with the first aspect, in one possible implementation, the step of constructing a priority sequence based on the functions and operating states of each software module in the airborne mission computer includes: dividing the airborne mission computer into multiple software modules according to their functions; determining and sorting the priorities of each software module based on its functions and operating states to obtain a priority sequence.

[0008] In conjunction with the first aspect, in one possible implementation, the step of determining that a communication anomaly has occurred and that the supervisor module has failed includes: determining that a communication anomaly has occurred in the supervisor module or other software modules when the requests of the supervisor module or other software modules do not respond or time out; and / or determining that a communication anomaly has occurred in the supervisor module or other software modules when the supervisor module or other software modules in the communication network do not receive a response within a predetermined time; and determining that the supervisor module has failed when a communication anomaly is detected from at least two peripheral nodes and the communication anomaly continues to occur within a continuous first time period.

[0009] In conjunction with the first aspect, in one possible implementation, when a communication anomaly occurs and it is determined that the supervisor module has failed, the following further applies: the failed supervisor module releases the CPU resources it occupies and triggers an update of the priority sequence; and / or, saves the data of the failed supervisor module's most recent normal communication; and / or, the flight control computer enters hover mode until the updated supervisor module communicates with it and takes over control of the UAV.

[0010] In conjunction with the first aspect, in one possible implementation, the construction of a communication network with the main module as the central node and the other software modules, flight control computer, and ground control system as peripheral nodes further includes: a basic service module electrically connected to the main module and the other software modules respectively; wherein, the basic service module is used to store operational data and convert various received data into commands for UAV control.

[0011] In conjunction with the first aspect, one possible implementation also includes: when a communication anomaly occurs and it is determined that other software modules have failed, the supervisor module controls the corresponding other software modules to restart.

[0012] In conjunction with the first aspect, one possible implementation also includes: control of the same function in different software modules is downgraded as their priority decreases; and / or, lower-priority software modules contain fewer additional functions than higher-priority software modules.

[0013] Secondly, this application provides an emergency control system for unmanned aerial vehicles (UAVs) based on multi-module switching, including an airborne mission computer, a flight control computer electrically connected to it, and a ground control system. The airborne mission computer comprises a functionally divided and electrically connected main module, multiple alternative modules, and a basic service module. The main module periodically communicates with the multiple alternative modules and the flight control computer at a set frequency. The main module is used to: control the UAV; acquire operational data from the alternative modules through the periodic communication and send it to the basic service module and the ground control system; the multiple alternative modules are used to: monitor whether the main module has failed through the periodic communication; when the main module fails, update an alternative module to the main module, and at least when updated to the main module, retrieve data from the basic service module to take over the control of the UAV; the basic service module is used to: store operational data; and convert various received data into commands for UAV control.

[0014] In conjunction with the second aspect, in one possible implementation, the plurality of alternative modules include priorities determined based on their own functions and operating status, the priorities being used to determine the order in which each alternative module takes over control of the drone from the master module.

[0015] In conjunction with the second aspect, in one possible implementation, the alternative module includes its primary function and additional functions; when the alternative module is not updated to the main module, it only performs its primary function, and when the alternative module is updated to the main module, it performs both its primary function and additional functions.

[0016] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0017] This application employs a UAV emergency control method and system based on multi-module switching, enabling emergency handling of UAVs when software modules malfunction. By updating the master module, the strong coupling limitations of traditional centralized software architecture are broken, making the system more flexible in the face of failures. This reduces the risk of the entire system crashing due to a single software module failure, improving the stability and success rate of UAVs performing tasks in complex environments. It can determine the current task status based on stored operational data to continue task execution. The UAV's functions are downgraded or restored according to the priority of the updated master module, ensuring that the UAV can maintain a certain level of flight capability and task execution capability even in the event of a failure. This effectively solves the problem that existing UAV core control systems cannot continue tasks after a failure. Furthermore, it effectively reduces the risk of UAV loss of control, avoids unexpected situations due to control vacuums, and improves the system's fault tolerance, task continuity, and reliability. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating the UAV emergency control method based on multi-module switching provided in this application embodiment;

[0020] Figure 2 An architecture diagram of a core control system for an unmanned aerial vehicle (UAV) provided in an embodiment of this application;

[0021] Figure 3 Provided for the embodiments of this application Figure 2 Example diagram of core board resource usage in the core control system;

[0022] Figure 4 An architecture diagram of the core control system in case of failure of the supervisor module (airborne management module) provided in the embodiments of this application;

[0023] Figure 5 Provided for the embodiments of this application Figure 4 Example diagram of core board resource usage in the core control system;

[0024] Figure 6 An architecture diagram of the core control system when the supervisor module (airborne management module and obstacle avoidance module) fails, as provided in the embodiments of this application;

[0025] Figure 7 Provided for the embodiments of this application Figure 6 Example diagram of core board resource usage in the core control system;

[0026] Figure 8 An architecture diagram of the core control system when the other software modules (obstacle avoidance modules) provided in the embodiments of this application fail;

[0027] Figure 9 A flowchart of a disconnected connection pipe for communication monitoring provided in an embodiment of this application;

[0028] Figure 10 This is a schematic diagram of the structure of an unmanned aerial vehicle (UAV) emergency control system based on multi-module switching, provided in an embodiment of this application. Detailed Implementation

[0029] 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, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0030] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0031] The existing centralized software architecture is incompatible with the core operational requirements of UAVs, and this incompatibility cannot be resolved by introducing a mature microservice architecture. The specific points of contention are as follows: First, UAV flight control has extremely high real-time requirements for data transmission and command response. If the existing functional modules are split into a microservice architecture, data interaction between modules will generate additional latency, directly affecting the real-time response of flight control and failing to meet the core requirements for safe UAV flight. Second, UAV mission data has strong continuity. If a microservice architecture is adopted, frequent write, read, and load operations on historical mission data are required. Excessive data I / O operations will significantly increase the burden on the onboard system, further deteriorating system real-time performance and affecting mission execution efficiency. Third, unlike ground equipment, UAV design must strictly adhere to the principles of low cost and miniaturization. Limited by hardware size and cost control, onboard hardware resources (such as computing power, storage, and power consumption) are very limited, unable to provide sufficient software support for microservice architecture. Therefore, the shortcomings of the existing centralized architecture cannot be remedied by architectural upgrades.

[0032] Figure 1 This is a flowchart of an emergency control method for unmanned aerial vehicles (UAVs) based on multi-module switching, provided in an embodiment of this application, including steps 101 to 106. Figure 1 This is merely one execution order shown in the embodiments of this application and does not represent the only execution order of the UAV emergency control method based on multi-module switching. Where the final result can be achieved, Figure 1 The steps shown can be performed in parallel or in reverse order.

[0033] Step 101: Construct a priority sequence based on the functions and operating status of each software module in the airborne mission computer, and determine the master module for UAV control in each software module according to the priority sequence. In this embodiment, the airborne mission computer is divided into multiple software modules according to function; the priority of each software module is determined and sorted based on its function and operating status to obtain a priority sequence.

[0034] Specifically, the software system of the airborne mission computer can be exemplarily divided into an airborne management module, an obstacle avoidance module, an image processing module, a data service module, and an intelligent algorithm module based on function. The airborne management module coordinates various tasks and resources of the UAV, sends corresponding instruction information to other software modules according to different received commands, drives functions, receives task information and instruction information from the flight control computer, and transmits the UAV's heartbeat information (i.e., operational status) to the ground control system. The obstacle avoidance module monitors the surrounding environment in real time during UAV flight using binocular cameras or lidar to determine if there are obstacles in the flight path, ensuring flight safety. The image processing module acquires image information from the airborne camera (or pod) and processes and analyzes it to obtain useful information. The data service module is mainly responsible for the storage, transmission, and management of image data, operational data, and mission data, ensuring data accuracy and timeliness. The intelligent algorithm module is used to call algorithms such as route planning, allocation, and formation, and converts various received data into commands for UAV control.

[0035] Those skilled in the art should understand that the above-described division of the airborne mission computer's software system into five software modules is merely one embodiment of this application and is not intended to limit the scope of protection of this application.

[0036] Furthermore, priorities are set based on the functions and operational status of each software module. For example, the priority of each software module can be determined by the product of its task and operational status; the larger the product, the higher the priority. Functionality can be understood as the number of functions a software module can perform, and the impact of these functions on the drone's mission success rate and flight safety. Specifically, software modules with more functions and a greater impact on flight safety and mission execution have higher priorities. For instance, in a complete core control system, the airborne management module has the most complex functions, including automatically judging and planning the drone's relevant actions (such as guidance, photography, video recording, hovering, etc.) based on tasks and instructions, directly affecting mission success, hence its highest priority. The obstacle avoidance module is directly related to flight safety, but its functions are lower than the airborne management module, so its priority is relatively high; while the data service module, although important, has a relatively smaller direct impact on real-time flight control, so its priority is lower. Simultaneously, the operational status of each software module must be considered; if a software module malfunctions or malfunctions, its priority will be reduced. Sorting the software modules according to priority from highest to lowest yields a priority sequence.

[0037] Based on a priority sequence, the highest-priority software module is selected as the master module. The master module has primary control over the UAV, responsible for sending commands to other software modules and the flight control computer, and coordinating them to complete tasks and operations. During normal operation, the master module issues corresponding control commands according to preset programs and logic, based on mission requirements and the flight environment, ensuring the UAV flies along the predetermined route and method, and completes the relevant tasks. Figure 2 As shown, when all software modules in the onboard mission computer are running normally, the onboard management module, which has the highest priority at this time, acts as the master module to control the UAV. The resource usage of the UAV core board at this time is as follows: Figure 3 As shown.

[0038] Step 102: Construct a communication network with the main module as the central node and the other software modules, flight control computer, and ground control system as peripheral nodes. In this embodiment, constructing the communication network includes: network communication between the main module and the other software modules and the ground control system; and serial communication between the main module and the flight control computer.

[0039] Specifically, a star-topology communication network is constructed with the master module as the central node and the other software modules, flight control computer, and ground control system as peripheral nodes. The master module, as the central node, uniformly schedules the communication requests of all peripheral nodes, avoiding network conflicts caused by direct interaction between nodes. Lightweight network communication protocols (e.g., HTTP, Hypertext Transfer Protocol) are used between the master module and the other software modules and the ground control system, employing a request-response mechanism. Serial communication is used between the master module and the flight control computer. Separating network communication from serial communication reduces latency.

[0040] In this embodiment of the application, a basic service module is also included, which is electrically connected to the main module and the other software modules respectively; wherein, the basic service module is used to store operating data and convert various received data into commands for drone control.

[0041] Specifically, based on the functions of the five software modules divided in step 101, under normal system operation, the airborne management module is the main module, the obstacle avoidance module and the image processing module are the remaining software modules, and the data service module and the intelligent algorithm module are the basic service modules.

[0042] Step 103: Through periodic communication between nodes in the communication network, the operating data of the remaining software modules is sent to the ground control system via the master module. In this embodiment, the master module, the remaining software modules, and the flight control computer periodically send heartbeat packets to each other at a set frequency based on the communication network and receive reports; based on the received reports, the master module sends the operating data of the remaining software modules to the ground control system.

[0043] Specifically, all software modules maintain regular heartbeat interactions during operation. Each software module is both a sender and receiver of heartbeats, forming a mesh-like monitoring network to avoid single-point dependencies. Heartbeat packets are transmitted with a fixed length and format to ensure real-time parsing. Furthermore, each software module and flight control computer sends heartbeat packets to the supervisor module at a set frequency (e.g., once every 50ms). These heartbeat packets contain their respective operational data. Upon receiving these heartbeat packets, the supervisor module summarizes and organizes the data, then transmits it to the ground control system via network communication. The ground control system can monitor the operational status of various parts of the UAV in real time based on the received operational data, promptly identifying potential problems. The supervisor module also reports back based on the received heartbeat packets.

[0044] For example, the heartbeat packet uses a fixed-length frame structure, including the sender's module ID, timestamp, etc. Upon receiving the heartbeat packet from the supervisor module, other software modules return a report within 10ms containing the module ID (2 bytes) and a timestamp (4 bytes, in seconds). The report returned by the flight control computer includes attitude angles (3 bytes, 0.1 degree accuracy per axis), position coordinates (8 bytes, latitude and longitude accurate to 6 decimal places), power system voltage (2 bytes, unit V), and fault code (2 bytes). The supervisor module performs CRC (Cyclic Redundancy Check) verification and field parsing on all reports, storing valid operational data in the data service module. For data reporting from the ground control system, the supervisor module encapsulates the operational data from the data service module into a ground status report frame every second and sends it to the ground control system via a TCP (Transmission Control Protocol) long connection. The heartbeat packets sent by the supervisor module to the flight control computer reuse the HEARTBEAT message from the MAVLink protocol (a lightweight, efficient, and reliable communication protocol designed for drones, robots, and other automated equipment), and add the status flag of the supervisor module. The sending frequency is consistent with the serial communication cycle (e.g., 20ms / time).

[0045] Step 104: Monitor periodic communication to determine if any communication anomalies occur. In this embodiment, if a request from the supervisor module or other software modules fails to respond or times out, it is determined that a communication anomaly has occurred in the supervisor module or other software modules; and / or, if the supervisor module or other software modules in the communication network do not receive a response within a predetermined time, it is determined that a communication anomaly has occurred in the supervisor module or other software modules.

[0046] Specifically, when determining whether a communication anomaly has occurred in the master module or other software modules, several factors can be considered. For the master module, if it does not receive a corresponding response within a predetermined time after sending a heartbeat packet to other software modules or the flight control computer—for example, if it does not receive a response within 50ms after sending a heartbeat packet to other software modules, or does not receive a response within 20ms after sending a heartbeat packet to the flight control computer—then it can be determined that a communication anomaly has occurred in the corresponding communication link.

[0047] Furthermore, the master module monitors its periodic communication links with other software modules, the flight control computer, and the ground control system in real time. The master module maintains an independent heartbeat reception counter for each peripheral node. If a peripheral node corresponding to another software module fails to receive a response three times consecutively (corresponding to 50ms × 3 = 150ms), a timeout is detected, indicating a communication link anomaly. For the peripheral node corresponding to the flight control computer, if it fails to receive a HEARTBEAT response three times consecutively (20ms × 3 = 60ms), a timeout is detected, indicating a communication link anomaly, triggering a serial port retry (reinitializing serial port parameters and sending heartbeat packets, retrying twice). For the peripheral node corresponding to the ground control system, if there is no TCP heartbeat response twice consecutively (10 seconds × 2 = 20 seconds), a timeout is detected.

[0048] The one-way delay is calculated by recording the sending and receiving timestamps of heartbeat packets and reports. The pre-defined delay time between the master module and other software modules is set to 30ms. If this time is exceeded five times consecutively, a delay occurs, indicating a communication link anomaly. The pre-defined delay time between the master module and the flight control computer is set to 10ms. If this time is exceeded three times consecutively, a delay occurs, indicating a communication link anomaly. Simultaneously, non-critical data transmission is suspended, prioritizing flight control command interaction.

[0049] The supervisor module writes the exception information (node ​​ID, exception type, timestamp, number of retries) into the local loop log and reports it to the ground control system in real time.

[0050] Meanwhile, if a node in the communication network experiences heartbeat packet loss, incomplete data frames, or transmission delays exceeding a preset time during periodic communication, and fails to recover after multiple (e.g., 3) retries, it can also be determined that a communication anomaly has occurred.

[0051] If step 104 determines that a communication anomaly has occurred, then step 105 is executed; otherwise, steps 103 to 104 are executed to continue periodic communication between the central node and peripheral nodes in the communication network and to monitor it.

[0052] Step 105: Determine if the supervisor module has failed. In this embodiment, if at least two peripheral nodes detect a communication anomaly in the supervisor module, and the communication anomaly continues for a continuous first time period, then the supervisor module is determined to have failed.

[0053] Specifically, taking two peripheral nodes as an example, if the obstacle avoidance module and the image processing module simultaneously detect a communication anomaly in the main module, the first timeout is exemplarily set to 60ms, which can be modified by those skilled in the art according to actual needs.

[0054] In addition, the failed master module releases the CPU (central processing unit) resources it occupies and triggers an update of the priority sequence; and / or, saves the data of the last normal communication of the failed master module; and / or, the flight control computer enters hover mode until the updated master module communicates with it and takes over control of the UAV.

[0055] Specifically, when the supervisor module is determined to have failed, it immediately releases the CPU resources it occupies, allowing the system to reallocate resources and enable other software modules to run more efficiently. Simultaneously, the system triggers an update to the priority sequence. Since the original supervisor module has failed, its position in the priority sequence will be removed, and the priority order of the remaining software modules will be adjusted accordingly. The new priority sequence will be recalculated and reordered based on the functionality and running status of each software module.

[0056] To facilitate subsequent fault analysis and system recovery, the system saves data from the most recent normal communication of the failed master module. This data includes communication information between the master module and other software modules, the flight control computer, and the ground control system before the failure. By analyzing this data, technicians can gain a deeper understanding of the master module's operational status before the failure and identify possible causes of the failure.

[0057] When the master module fails, the flight control computer (FNC) enters hover mode to ensure the UAV maintains stable flight and avoids danger during system malfunctions. In hover mode, the FNC ceases executing non-critical commands from the original master module, maintaining only the UAV's basic flight attitude and altitude. The FNC waits for the updated master module to establish communication and take over control of the UAV. Once communication is established, the updated master module will resend control commands based on current mission requirements and system status, allowing the UAV to continue its mission. Throughout this process, the ground control system monitors the FNC's status and system recovery progress in real time to make timely decisions and adjustments.

[0058] In one embodiment of this application, when a communication anomaly occurs and it is determined that other software modules have failed, the supervisor module can control the restart of the corresponding other software modules. The system architecture diagram at this time is as follows. Figure 8 As shown.

[0059] Specifically, when the supervisor module detects a communication anomaly in another software module and determines that it has failed, it sends a restart command to the failed module according to the communication protocol. After sending the restart command, the supervisor module enters a waiting state and starts a timer with a set waiting time, for example, 5 seconds. If, within the waiting time, the supervisor module receives a restart success signal from the corresponding other software module, it indicates a successful restart. The supervisor module then marks the other software module as being in normal operation and reintegrates it into the system's communication scheduling and task allocation system. If, after the waiting time expires, the supervisor module does not receive a restart success signal, the restart is considered a failure.

[0060] If the result of step 105 is that the supervisor module is faulty, then proceed to step 106; otherwise, proceed to steps 103 through 105.

[0061] Step 106: Update the supervisor module according to the priority sequence to take over control of the UAV. The UAV's functionality is either downgraded or restored depending on the priority of the updated supervisor module. In this embodiment, when the supervisor module is determined to have failed, the system selects a new supervisor module from the remaining software modules with a priority second only to the original supervisor module, based on the previously constructed priority sequence. For example, if the original supervisor module is the airborne management module, after its failure, the obstacle avoidance module is selected as the new supervisor module because it is second only to the airborne management module in the priority sequence.

[0062] After updating the supervisor module in step 106, steps 102 to 106 are executed based on the updated supervisor module. Specifically, the updated supervisor module will take over the responsibilities of the original supervisor module, pull data from the data service module, and take over drone control. Alternatively, the priority sequence is updated, and the software module with the highest priority in the updated priority sequence is determined as the updated supervisor module. The updated supervisor module, as the central node, updates the communication network and pulls data from the data service module to take over control of the drone.

[0063] In addition, the updated manager module also needs to reallocate resources in the system, allocating CPU resources, memory resources, etc., according to the task requirements and importance of each software module, in order to improve the overall system operating efficiency.

[0064] Furthermore, during the update of the master module, ground control personnel will monitor the status of the ground control system in real time, providing guidance and supervision for the takeover process of the updated master module. If any anomalies occur, ground control personnel can take timely intervention measures, such as manually designating a backup master module, to ensure the safe and stable operation of the UAV system.

[0065] For example, such as Figure 4 The diagram shows the core system architecture of the obstacle avoidance module taking over control of the drone after the onboard management module (shown in red) fails. When the obstacle avoidance module and image processing module detect the failure of the onboard management module via heartbeat packets, the obstacle avoidance module can obtain the latest task and command information from the data service module, take over drone control, and open basic interfaces such as the task management interface and command information interface, allowing the drone to continue executing its mission. At this point, the drone's safety is the primary consideration. The obstacle avoidance module can acquire environmental information through binocular radar or lidar, and can still avoid obstacles while ensuring safety. Figure 5 This describes the resource usage of the drone's core board after the obstacle avoidance module takes over drone control.

[0066] Figure 6 This diagram illustrates the core system architecture where the image processing module takes over control of the UAV after both the onboard management and obstacle avoidance modules fail. When these modules fail, the image processing module retrieves data from the data service module and opens the corresponding interfaces to achieve flight control of the UAV. The image processing module ensures the UAV's image transmission function, allowing ground control personnel to manually control the UAV through first-person view images, thus ensuring flight succession through human-machine collaborative control. Figure 7 Resource usage of the drone core board after the image processing module takes over drone control.

[0067] Furthermore, based on the priority of the current managing module, the function is either downgraded or restored (software modules are usually difficult to recover on their own after failure, so in most cases, the function is downgraded).

[0068] Furthermore, in this application, the control of the same function in different software modules is downgraded as their priority decreases; and / or, the software modules with lower priority contain fewer additional functions than the software modules with higher priority.

[0069] Specifically, the airborne management module's functions include flight control, mission control, module control, command control, communication control, data logging, payload control, and algorithm invocation. Flight control within the airborne management module includes position control (global position control, local position control), coordinate system switching (global coordinate system, local coordinate system, body coordinate system), attitude control, and mode switching. The obstacle avoidance module's functions include flight control, mission control, command control, ground communication, data logging, and obstacle avoidance. Flight control within the obstacle avoidance module includes position control (local position control), coordinate system switching (local coordinate system, body coordinate system), and mode switching. The image processing module's functions include flight control, command control, ground communication, data logging, and image processing. Flight control within the image processing module includes coordinate system switching (body coordinate system) and mode switching.

[0070] like Figure 9 The diagram shows the disconnection pipe flowchart for communication monitoring in this application. This application monitors the operating status of software modules in real time, enabling timely detection of software failures without requiring redundancy design for computing resources. When the onboard management module fails, CPU resources are released. Considering the possibility of bad data or infinite data points in the computational data, the UAV is only suitable for executing the current mission's flight path and is not suitable for continuing related collaborative tasks. When the obstacle avoidance module fails, considering that the UAV cannot continue automatic obstacle avoidance and that related sensors may be damaged during flight, the image processing module can activate its backup function to ensure that the UAV can be manually controlled for flight. Throughout the process, the UAV system gradually degrades from full-function operation and full resource utilization to minimum-function operation and low-resource consumption, transitioning from fully autonomous flight to manual remote control flight, thus achieving failure protection for the UAV system.

[0071] While this application provides method operation steps as shown in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in this embodiment is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the method can be executed sequentially according to this embodiment or the accompanying drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0072] like Figure 10 As shown in the illustration, this application also provides an emergency control system for unmanned aerial vehicles (UAVs) based on multi-module switching. The system includes an airborne mission computer, a flight control computer electrically connected to it, and a ground control system. The airborne mission computer includes a functionally divided and electrically connected master module, multiple alternative modules, and a basic service module. The master module periodically communicates with the multiple alternative modules and the flight control computer at a set frequency. The master module is used to: control the UAV; acquire operational data from the alternative modules through periodic communication, and send it to the basic service module and the ground control system. The multiple alternative modules are used to: monitor whether the master module has failed through periodic communication; when the master module fails, update an alternative module to become the master module, and at least when updating to become the master module, retrieve data from the basic service module to take over the master module's control of the UAV. The basic service module is used to: store operational data; and convert various received data into commands for UAV control.

[0073] In this embodiment, the multiple alternative modules include priorities determined based on their own functions and operating status. These priorities are used to determine the order in which each alternative module takes over control of the drone from the main module.

[0074] Furthermore, the alternative modules include primary functions and additional functions; when an alternative module is not updated to the primary module, it only performs its primary functions, and when an alternative module is updated to the primary module, it performs both its primary functions and additional functions.

[0075] Specifically, the primary module can be the airborne management module, and multiple alternative modules can be the obstacle avoidance module and the image processing module, with the obstacle avoidance module having higher priority than the image processing module. The basic service modules can be the intelligent algorithm module and the data service module. When the obstacle avoidance module is an alternative module and is not updated to the primary module, its primary function is to use binocular radar or lidar to acquire environmental information, implement obstacle avoidance functions, and perform flight control-related functions such as local position control, switching between local coordinate systems and body coordinate systems, and mode switching. When the obstacle avoidance module is updated to the primary module, in addition to performing the above-mentioned primary functions, it will also perform additional functions, such as taking over some of the responsibilities of the original primary module, pulling more data from the data service module for more comprehensive control of the UAV, and opening more basic interfaces such as the task management interface and command information interface, enabling the UAV to perform tasks more efficiently.

[0076] Similarly, when the image processing module is not updated to the main module, its primary functions include image processing, body coordinate system switching, mode switching, and other flight control-related functions. Once updated to the main module, in addition to its primary functions, it will perform supplementary functions, such as retrieving more data from the data service module, opening relevant interfaces to achieve more comprehensive UAV flight control, ensuring UAV image transmission capabilities, and facilitating ground control personnel to manually remotely control the UAV using first-person perspective image information.

[0077] This design allows the system to replace the primary module with a backup module based on priority when the primary module fails, ensuring functional succession and stable system operation. Furthermore, the functional design of different software modules and the distinction between primary and supplementary functions enable the UAV system to flexibly adjust its functions under varying circumstances, gradually degrading from full-function operation to the minimum required functionality to adapt to various anomalies and achieve effective failure protection. Throughout the process, the ground control system monitors the system status in real time, and ground control personnel can intervene and provide guidance as needed to ensure the safe and stable operation of the UAV system.

[0078] Some modules in the apparatus described in this application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0079] The apparatus or module described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. For ease of description, the above apparatus is described by dividing it into various modules according to their functions. When implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware. Of course, a module that implements a certain function can also be implemented by combining multiple sub-modules or sub-units.

[0080] The methods, apparatus, or modules described in this application can be implemented in a computer-readable program code manner. The controller can be implemented in any suitable manner, such as a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of a memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code manner, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included within it for implementing various functions can also be considered as structures within the hardware component. Alternatively, the device used to implement various functions can be viewed as either a software module that implements the method or a structure within a hardware component.

[0081] This application also provides an apparatus, the apparatus comprising: a processor; a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it implements the method described in this application.

[0082] This application also provides a non-volatile computer-readable storage medium storing a computer program or instructions thereon, which, when executed, enables the method described in this application embodiment to be implemented.

[0083] Furthermore, in the various embodiments of the present invention, each functional module can be integrated into a processing module, or each module can exist independently, or two or more modules can be integrated into a single module.

[0084] The aforementioned storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions.

[0085] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0086] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0087] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of this application.

Claims

1. An emergency control method for unmanned aerial vehicles (UAVs) based on multi-module switching, characterized in that, include: A priority sequence is constructed based on the functions and operating status of each software module in the airborne mission computer, and a master module is determined in each software module to control the UAV according to the priority sequence; wherein, the functions of the software module include the primary function and the additional functions, and the software module with lower priority contains fewer additional functions than the software module with higher priority. A communication network is constructed with the main module as the central node and the other software modules, flight control computer, and ground control system as peripheral nodes; wherein, the communication network also includes basic service modules that are electrically connected to the main module and the other software modules respectively; Through periodic communication between nodes in the communication network, the operating data of the remaining software modules are sent to the ground control system via the master module; The periodic communication is monitored. When a communication anomaly occurs and it is determined that the supervisor module has failed, the supervisor module is updated according to the priority sequence. At least when it is updated to be the supervisor module, data is pulled from the basic service module to take over control of the drone. The drone's functions are downgraded or restored depending on the priority of the updated supervisor module.

2. The method according to claim 1, characterized in that, The construction of a priority sequence based on the functions and operating status of each software module in the airborne mission computer includes: The airborne mission computer is divided into multiple software modules according to its function; The priority of each software module is determined and sorted based on its function and operating status, resulting in a priority sequence.

3. The method according to claim 1, characterized in that, When a communication anomaly occurs and it is determined that the supervisor module has failed, the following applies: If a request from the supervisor module or other software modules fails to respond or times out, it is determined that a communication anomaly has occurred in the supervisor module or other software modules; and / or, If the main module or other software modules in the communication network do not receive a response within a predetermined time, it is determined that the main module or other software modules have a communication abnormality. If at least two peripheral nodes detect a communication anomaly in the supervisor module, and the communication anomaly continues for an extended period of time, the supervisor module is deemed to have failed.

4. The method according to claim 1, characterized in that, When a communication anomaly occurs and it is determined that the supervisor module has failed, the following further applies: The failed supervisor module releases the CPU resources it occupies and triggers an update of the priority sequence; and / or, Save the data from the most recent normal communication of the failed supervisor module; and / or, The flight control computer enters hover mode until the updated master module communicates with it and takes over control of the drone.

5. The method according to claim 1, characterized in that, The construction of a communication network with the main module as the central node and other software modules, flight control computer, and ground control system as peripheral nodes also includes: A basic service module is electrically connected to the main module and other software modules respectively; wherein, the basic service module is used to store operational data and convert various received data into commands for UAV control.

6. The method according to claim 1, characterized in that, Also includes: When a communication failure occurs and it is determined that other software modules have failed, the supervisor module controls the restart of the corresponding other software modules.

7. The method according to claim 1, characterized in that, Also includes: Control of the same function in different software modules is downgraded as its priority decreases.

8. A multi-module switching-based UAV emergency control system for implementing the method described in any one of claims 1-7, comprising an onboard mission computer, and a flight control computer and a ground control system electrically connected thereto, characterized in that, The airborne mission computer includes a main module, multiple alternative modules, and a basic service module that are functionally divided and electrically connected to each other. The main module communicates periodically with the multiple alternative modules and the flight control computer at a set frequency. The master module is used to: control the UAV; acquire the operating data of the alternative modules through the periodic communication, and send it to the basic service module and the ground control system; The alternative modules are used to: monitor whether the supervisor module has failed through the periodic communication; when the supervisor module fails, update the alternative module to the supervisor module, and at least when updating to the supervisor module, pull data from the basic service module to take over the supervisor module to control the drone; The basic service module is used to: store operational data; and convert various types of received data into commands for drone control.

9. The system according to claim 8, characterized in that, The multiple alternative modules include priorities determined based on their own functions and operating status. These priorities are used to determine the order in which each alternative module takes over control of the drone from the main module.

10. The system according to claim 8, characterized in that, The alternative module includes its primary function and additional functions; when the alternative module is not updated to the main module, it only performs its primary function; when the alternative module is updated to the main module, it performs both its primary function and additional functions.

Images