Control methods, equipment and storage media for drone computing boards

Abstract

This application discloses a control method, device, and storage medium for a drone computing board. The control method for the drone computing board includes: reading target odometry data and target dynamic positioning data with the same target timestamp from a shared memory data area, the target timestamp corresponding to the current fusion period; determining a weight matrix for the current fusion period based on the data confidence level corresponding to the target odometry data and the RTK state corresponding to the target dynamic positioning data; and fusing the target odometry data, the target dynamic positioning data, and the weight matrix into an extended Kalman filter to obtain the pose estimate of the drone at time n. This application can improve the positioning stability of drones in high-precision flight scenarios.

Description

Technical Field

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

[0002] Autonomous flight of unmanned aerial vehicles (UAVs) relies on SLAM (Simultaneous Localization and Mapping) perception and closed-loop flight control. It requires SLAM sensors to collect environmental and pose data, which is then processed by a computing board and transmitted to the flight control module for attitude adjustment. Multi-hardware collaborative data fusion is the core foundation for high-precision positioning and stable operation of UAVs, directly determining flight control accuracy and environmental adaptability.

[0003] Currently, the industry generally adopts a multi-module independent working mode, which unifies the data benchmark through conventional time-series calibration algorithms, and directly integrates SLAM perception data, computing board processing results and flight control data to achieve real-time positioning and flight attitude adjustment of UAVs, adapting to conventional flight operation scenarios.

[0004] However, the SLAM sensor, computing board and flight controller are independent hardware units with differences in sampling frequency, clock reference, data transmission and processing latency. The three cannot be fully synchronized in operation, resulting in inherent time misalignment, which can lead to position and pose calculation deviations and reduce the stability of high-precision flight of UAVs. Summary of the Invention

[0005] The main purpose of this application is to provide a control method, device and storage medium for a UAV computing board, which aims to solve the technical problem that the inherent time misalignment between SLAM sensors, computing board and flight controller leads to attitude calculation deviation and reduces the stability of UAV high-precision flight.

[0006] To achieve the above objectives, this application provides a control method for a drone computing board, the control method for the drone computing board comprising: Acquire the odometry data output by the SLAM sensor at time n, and acquire the dynamic positioning data output by the flight controller at time n; Covariance divergence detection is performed on the odometer data, and data confidence of the odometer data is generated based on the detection results; The odometer data, the data confidence level, and the timestamp at the nth time are associated and stored in the data area of ​​shared memory. The dynamic positioning data is associated with the timestamp of the nth time and stored in the data area of ​​the shared memory; From the data area of ​​the shared memory, read the target odometer data and target dynamic positioning data that have the same target timestamp, the target timestamp corresponding to the current fusion cycle; The weight matrix for the current fusion cycle is determined based on the data confidence level corresponding to the target odometer data and the RTK state corresponding to the target dynamic positioning data. The target odometry data, the target dynamic positioning data, and the weight matrix are fused into an extended Kalman filter to obtain the pose estimate of the UAV at time n.

[0007] In one embodiment, the step of performing covariance divergence detection on the odometer data and generating data confidence of the odometer data based on the detection results includes: The covariance matrix of the odometer data is obtained through analysis; Calculate the values ​​of the main diagonal elements of the covariance matrix; If the value of the main diagonal element exceeds a preset threshold, the odometer data is determined to be divergent, and a first confidence level flag is generated. A reset command is sent to the SLAM sensor to trigger the SLAM sensor to reinitialize.

[0008] Otherwise, generate a second confidence level flag.

[0009] In one embodiment, determining the weight matrix for the current fusion cycle based on the data confidence level corresponding to the target odometer data and the RTK state corresponding to the target dynamic positioning data includes: When the data confidence level is the second confidence level and the RTK state is a fixed solution, the target odometer data and the target dynamic positioning data are assigned equal first weights; When the data confidence level is the first confidence level and the RTK state is a fixed solution, the target odometry data is assigned a second weight lower than that of the target dynamic positioning data; When the RTK state is a floating-point solution, a third weight is assigned to the target dynamic positioning data, which is lower than the corresponding weight in the fixed solution state, and the third weight decreases as the uncertainty of the target dynamic positioning data increases.

[0010] In one embodiment, when the RTK state is a floating-point solution, the method further includes: If the data confidence level is the second confidence level, then the target odometer data is assigned a fourth weight equal to that of the target dynamic positioning data; If the data confidence level is the first confidence level, the target odometer data is assigned a fifth weight that is lower than that of the target dynamic positioning data, and the attenuation of the fifth weight is less than that of the second weight.

[0011] In one embodiment, fusing the target odometry data, the target dynamic positioning data, and the weight matrix into an extended Kalman filter to obtain the pose estimate of the UAV at time n includes: The covariance matrix at time n-1 is read from the shared memory and used as the input of the extended Kalman filter in the prediction step at time n. The observation noise covariance of the target odometer data and the target dynamic positioning data are set according to the weight matrix, respectively. The prediction and update steps of the extended Kalman filter are executed to output the pose estimate of the UAV at time n.

[0012] In one embodiment, after executing the prediction and update steps of the extended Kalman filter and outputting the pose estimate of the UAV at time n, the process includes: Calculate the covariance matrix and the innovation residual at time n; The covariance matrix at time n and the innovation residual are stored in the shared memory. The covariance matrix at time n is used as the input for the prediction step at the next time step, and the innovation residual is used to trigger the adjustment of the weight matrix.

[0013] In one embodiment, after storing the covariance matrix at time n and the innovation residual into the shared memory, the process includes: At time n+1, if the information residual of a consecutive preset number of frames exceeds a preset 3σ threshold, a sensor operating condition abnormality flag is generated. In the next fusion cycle, the weight matrix of the next fusion cycle is updated according to the anomaly flag.

[0014] In one embodiment, before updating the weight matrix of the next fusion cycle according to the anomaly flag in the next fusion cycle, the following steps are included: Obtain the processor load, memory usage, and core temperature of the computing board; When the processor load exceeds the first threshold, the memory usage exceeds the reserved water level, or the core temperature exceeds the second threshold, an anomaly flag is generated and written to the shared memory.

[0015] In addition, to achieve the above objectives, this application also provides a control device for a drone computing board, the control device for the drone computing board including: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method for the drone computing board as described above.

[0016] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program for implementing a control method for a drone computing board is stored. The program for implementing the control method for a drone computing board is executed by a processor to implement the steps of the control method for a drone computing board as described above.

[0017] This application provides a control method for a UAV computing board. First, it acquires odometry data output by a SLAM sensor at time n and dynamic positioning data output by a flight controller at time n, and stores both data in a shared memory area, associating them with the timestamp of time n. This achieves strict alignment of multi-source sensor data on a time reference, eliminating data fusion errors introduced by the inherent time misalignment between the SLAM sensor, computing board, and flight controller. Then, it performs covariance divergence detection on the odometry data and generates data confidence scores. In subsequent fusion cycles, it reads target odometry data and target dynamic positioning data with the same target timestamp from the shared memory. To ensure strict temporal synchronization between the two types of data involved in the fusion, pose estimation deviations caused by time misalignment are avoided. Next, based on the data confidence level of the target odometry data and the RTK state corresponding to the target dynamic positioning data, the weight matrix for the current fusion cycle is determined. The target odometry data, target dynamic positioning data, and weight matrix are then input into an extended Kalman filter for fusion to obtain the UAV's pose estimate at time n. This dynamic weighting mechanism can adaptively adjust the confidence levels of the two types of data in the fusion process when the SLAM data confidence level is low or the RTK state is poor, thereby effectively suppressing the interference of abnormal sensor data on the fusion results and ensuring the continuity and accuracy of pose estimation.

[0018] In summary, this application achieves strict synchronization of multi-source sensor data on a time base through a timestamp-associated storage mechanism. Combined with covariance-driven data confidence detection and dynamic weight allocation of RTK state perception, these technologies work together to perform multi-source fusion on an extended Kalman filter. This comprehensively solves the technical problem of pose calculation deviation caused by inherent time misalignment among SLAM sensors, computing boards, and flight controllers, effectively improving the positioning stability and flight safety of UAVs in high-precision flight scenarios. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0021] Figure 1 A flowchart illustrating the control method for the UAV computing board of this application (Example 1). Figure 2 This is a flowchart illustrating Embodiment 3 of the control method for the UAV computing board in this application. Figure 3 This is a schematic diagram of the hardware operating environment involved in the control equipment of the UAV computing board of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] Currently, the industry generally adopts a multi-module independent working mode, unifies the data benchmark through conventional time-series calibration algorithms, and directly integrates SLAM perception data, computing board processing results and flight control data to achieve real-time positioning and flight attitude adjustment of UAVs, adapting to conventional flight operation scenarios.

[0026] However, the SLAM sensor, computing board and flight controller are independent hardware units with differences in sampling frequency, clock reference, data transmission and processing latency. The three cannot be fully synchronized in operation, resulting in inherent time misalignment, which can lead to position and pose calculation deviations and reduce the stability of high-precision flight of UAVs.

[0027] The main solution of this application is as follows: Obtain the odometry data output by the SLAM sensor at time n, and obtain the dynamic positioning data output by the flight controller at time n; perform covariance divergence detection on the odometry data, and generate a data confidence score for the odometry data based on the detection result; associate and store the odometry data, the data confidence score, and the timestamp at time n in a shared memory data area; associate and store the dynamic positioning data with the timestamp at time n in the shared memory data area; read target odometry data and target dynamic positioning data with the same target timestamp from the shared memory data area, the target timestamp corresponding to the current fusion period; determine the weight matrix of the current fusion period based on the data confidence score corresponding to the target odometry data and the RTK (Real-Time Kinematic) state corresponding to the target dynamic positioning data; input the target odometry data, the target dynamic positioning data, and the weight matrix into an extended Kalman filter for fusion to obtain the pose estimate of the UAV at time n.

[0028] This application achieves strict synchronization of multi-source sensor data on a time base through a timestamp-associated storage mechanism. It combines covariance-driven data confidence detection and dynamic weight allocation of RTK state perception to work together on an extended Kalman filter for multi-source fusion. This comprehensively solves the technical problem of pose calculation deviation caused by the inherent time misalignment among SLAM sensors, computing boards, and flight controllers, effectively improving the positioning stability and flight safety of UAVs in high-precision flight scenarios.

[0029] It should be noted that the execution subject in this embodiment can be the control system of the UAV computing board, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a UAV computing board capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses the UAV computing board as the execution subject as an example to describe this embodiment and the following embodiments.

[0030] Based on this, Embodiment 1 of this application proposes a control method for a UAV computing board. Please refer to... Figure 1 The control method for the UAV computing board includes steps S10 to S70: Step S10: Obtain the odometry data output by the SLAM sensor at time n, and obtain the dynamic positioning data output by the flight controller at time n.

[0031] In this embodiment, the SLAM sensor refers to a multi-source sensing module equipped with a simultaneous localization and mapping algorithm, whose output odometry data includes at least position, velocity, attitude quaternions and corresponding covariance matrices; the dynamic positioning data refers to the real-time dynamic differential positioning (RTK) data output by the flight controller through the MAVLink (Micro Air Vehicle Link) protocol, which includes at least global latitude and longitude, altitude, ground speed, RTK solution status and positioning uncertainty.

[0032] As an optional implementation, the computing board receives odometry data packets from SLAM sensors in real time via the MAVLink protocol, and simultaneously receives RTK data frames broadcast by the flight controller via the same MAVLink link. When acquiring each data frame, the receiving process appends a monotonically increasing hardware timestamp to that frame using the local system time generated by the Precision Time Protocol (PTP). This timestamp has a precision in the microsecond range, ensuring accurate identification of the same moment in the subsequent fusion stage. For odometry data, the receiving process parses the position vector, velocity vector, quaternion attitude, and a 9×9 or 15×15 covariance matrix from the data packet; for dynamic positioning data, the receiving process extracts latitude and longitude coordinates, altitude, north and east velocity components, RTK fixed or floating-point solution status flags, and horizontal position uncertainty.

[0033] As an alternative implementation, the computing board receives SLAM odometry data and RTK data through two independent UART (Universal Asynchronous Receiver / Transmitter) serial channels. Each channel is equipped with a DMA (Direct Memory Access) controller to reduce CPU interrupt load. Upon data arrival, the receiving process uses a built-in hardware timer to capture the precise arrival time as a timestamp for that data frame and stores it in a circular buffer. This method preserves the original arrival times even when sensor output frequencies are asynchronous, providing higher time resolution for subsequent timestamp matching and avoiding time misalignment caused by serial port transmission delay differences.

[0034] Step S20: Perform covariance divergence detection on the odometer data, and generate the data confidence score of the odometer data based on the detection results.

[0035] In this embodiment, covariance divergence detection refers to the quantification process of evaluating the confidence of the SLAM algorithm in its own pose estimation by analyzing the covariance matrix attached to the odometer data; data confidence is a binary or hierarchical flag characterizing whether the odometer data of a frame can be used for fusion.

[0036] As an optional implementation, the receiving process extracts a 3×3 submatrix corresponding to the position component from the covariance matrix parsed in step S10, and calculates the sum or maximum value of the main diagonal elements of the submatrix. This value is then compared in real-time with a preset covariance divergence threshold. If the value is greater than or equal to the threshold, the current frame's odometry data is determined to be in a divergent state, and a first confidence flag is generated, indicating that the data is unreliable; otherwise, a second confidence flag is generated, indicating that the data is reliable. Simultaneously, after generating the first confidence flag, the receiving process sends a reset signal to the SLAM sensor via MAVLink instructions, triggering its re-initialization positioning process in order to restore stability in subsequent frames. After generating the second confidence flag, the receiving process continues to transmit the frame data normally.

[0037] As an alternative implementation, the receiving process does not calculate the sum of the main diagonal elements of the position submatrix. Instead, it calculates the determinant or trace of the entire covariance matrix and maps this value to a continuous confidence score between 0 and 1. The mean and variance of the confidence scores for the most recent frames are statistically analyzed using a dynamic sliding window. If the score of the current frame is lower than the mean minus twice the standard deviation, it is determined to be divergent, and a first confidence flag is generated. This method can adaptively adjust the difference detection sensitivity, avoiding false resets in environments where SLAM normally degrades but does not diverge, thereby reducing unnecessary re-initializations.

[0038] Step S30: The odometer data, the data confidence level, and the timestamp at the nth time are associated and stored in the data area of ​​the shared memory.

[0039] In this embodiment, shared memory is a physical memory area on the computing board that can be accessed simultaneously by multiple processes, and its data area is used to store the original observation data and fusion results.

[0040] As an optional implementation, the receiving process combines the hardware timestamp added in step S10, the complete odometer data packet parsed in step S20, and the data confidence flag generated in step S20 into a fixed-length data structure. This structure is written to the circular buffer of the shared memory data area according to a predefined memory layout. The write operation uses lock-free atomic operations to avoid read / write conflicts with the fusion process. Each storage slot in the data area contains a timestamp field to ensure that subsequent reading processes can accurately index the corresponding data frame using the timestamp.

[0041] As an alternative implementation, the shared memory data area uses a key-value pair storage method, with the integer value of the timestamp as the key and the serialized binary block containing odometer data and confidence flags as the value. During writing, the receiving process first obtains the current write position using an atomically incrementing sequence number generator, then copies the data, and finally updates the write completion flag. This allows the fusion process to identify valid data based on the completion flag during reading, avoiding the reading of partially updated, dirty data.

[0042] Step S40: Associate the dynamic positioning data with the timestamp at the nth time and store it in the data area of ​​the shared memory.

[0043] In this embodiment, the dynamic positioning data is stored in the same way as the odometer data, and a unified timestamp index is used to support subsequent time synchronization reading.

[0044] As an optional implementation, the receiving process combines the dynamic positioning data packet obtained in step S10 with the same hardware timestamp and writes it into a separate RTK data circular buffer in the shared memory data area. This buffer is physically adjacent to the odometer data buffer but logically isolated, and both use the same slot size and timestamp alignment strategy, enabling the fusion process to concurrently access both types of data through the same timestamp offset.

[0045] As an alternative implementation, the receiving process does not store the dynamic positioning data separately. Instead, it appends the dynamic positioning data to an extended field of the odometer data structure and writes it to the same storage slot. This method saves shared memory space but requires odometer data and dynamic positioning data to arrive in pairs. When the RTK data update frequency is lower than that of the odometer data, the receiving process repeatedly fills subsequent odometer slots with the latest received RTK data until new RTK data arrives.

[0046] Step S50: Read target odometer data and target dynamic positioning data with the same target timestamp from the data area of ​​the shared memory, wherein the target timestamp corresponds to the current fusion cycle.

[0047] In this embodiment, the current fusion period refers to the fixed execution interval of the extended Kalman filter, and the target timestamp is the sensor sampling time corresponding to this period.

[0048] As an optional implementation, the fusion process is periodically woken up at a fixed frequency, such as 50Hz. At the beginning of each cycle, the fusion process calculates a target timestamp based on the current system time and a preset fusion delay budget. This target timestamp is taken as the integer millisecond value closest to and less than the current fusion moment. Subsequently, the fusion process searches for data entries with the target timestamp in the odometer buffer and RTK buffer of the shared memory data area, respectively. If both types of data exist and their respective confidence flags are valid, they are read and temporarily stored in the local cache; if one type of data is missing, linear interpolation is used to estimate the equivalent data at that moment from the preceding and following frames to ensure that the fusion cycle is not interrupted.

[0049] As an alternative implementation, the fusion process employs a synchronous read lock mechanism, retrieving the latest odometer and RTK data write completion flags from the data area status field at the beginning of each cycle. The fusion process only reads the two types of data as paired data when the difference between their latest timestamps is less than a preset synchronization tolerance threshold, such as 2 milliseconds. If the timestamp difference exceeds the limit, the fusion process waits for the next cycle and discards the earlier-arriving frame of data to avoid using asynchronous observations in subsequent EKF (Extended Kalman Filter) updates, thereby eliminating observation noise introduced by time misalignment.

[0050] Step S60: Determine the weight matrix of the current fusion cycle based on the data confidence level corresponding to the target odometer data and the RTK state corresponding to the target dynamic positioning data.

[0051] In this embodiment, the weight matrix is ​​a diagonal matrix, and its diagonal elements correspond to the noise covariance scaling factors of the odometer observations and RTK observations in the extended Kalman filter, respectively; the RTK state includes at least three levels: fixed solution, floating-point solution, and invalid solution.

[0052] As an optional implementation, after reading the target data, the fusion process first checks the odometer confidence flag and the RTK solution status flag. If the odometer confidence is at the second confidence level and the RTK status is a fixed solution, the diagonal elements of the weight matrix are all set to 1.0, meaning that the odometer observations and RTK observations use the same noise covariance baseline value in the EKF update. If the odometer confidence is at the first confidence level and the RTK status is a fixed solution, the weight elements corresponding to the odometer observations are reduced to 0.1, while the weight elements corresponding to the RTK observations remain at 1.0, thereby significantly reducing the impact of divergent SLAM data on the fusion result. If the RTK status is a floating-point solution, the horizontal position uncertainty value in the dynamic positioning data of that frame is first obtained. This uncertainty is compared with the standard uncertainty under the fixed solution to calculate a scaling factor, and the weight elements of the RTK observations are set to the reciprocal of this scaling factor. At the same time, the weight elements of the odometer observations maintain the same strategy as the fixed solution, thus automatically weakening their fusion contribution as the RTK accuracy decreases.

[0053] As an alternative implementation, the elements of the weight matrix are not fixed discrete values, but are calculated using a smoothing function. This function takes the odometry covariance trace and the RTK horizontal position uncertainty as inputs, and outputs continuous weight coefficients between 0 and 1. As the odometry covariance trace increases linearly, the weight coefficients decrease continuously; as the RTK uncertainty increases exponentially, the corresponding weight coefficients also decrease according to an exponential decay law. The fusion process calculates this function in real time during each cycle, and the resulting weight matrix is ​​then normalized to ensure that the sum of the two types of weights is always equal to 2. This continuous adjustment method avoids pose estimation jitter caused by discrete jumps and improves the smoothness of fusion in scenarios with gradual changes in sensor performance.

[0054] Step S70: The target odometry data, the target dynamic positioning data, and the weight matrix are input into the extended Kalman filter and fused to obtain the pose estimate of the UAV at time n.

[0055] In this embodiment, the extended Kalman filter is a state recursive estimator based on a nonlinear motion model and an observation model, and its state vector includes the position, velocity, and attitude angle of the UAV; the fusion process includes a prediction step and an update step.

[0056] As an optional implementation, the fusion process reads the covariance matrix of the previous time step (time n-1) from the shared memory state area, using it as the prior covariance for the current time step prediction. Subsequently, the odometry observation noise covariance matrix and the RTK observation noise covariance matrix are scaled according to the weight matrix determined in step S60. Specifically, the odometry default noise covariance matrix is ​​multiplied by the odometry weight coefficient, and the RTK default noise covariance matrix is ​​multiplied by the RTK weight coefficient to form the actual observation noise matrix for the current period. Then, the EKF prediction step is executed, using the UAV motion model to deduce the predicted state value at time n from the state estimate at time n-1. Next, an update step is executed, substituting the scaled observation noise matrix into the Kalman gain calculation, fusing the target odometry data and target dynamic positioning data, and finally outputting the optimal state estimate at time n as the pose estimate, including three-dimensional position, three-dimensional velocity, and attitude angle.

[0057] As an alternative implementation, before the update step, the fusion process first determines whether the confidence flag of the target odometry data is at the first confidence level. If so, the odometry observation update step is skipped, and only the RTK data is used for EKF update, i.e., only the global position is updated without updating the relative motion increment. If the RTK state is an invalid solution, only the odometry data is used for prediction update, without observation update. If both fail, the fusion process directly outputs the pose estimate of the previous moment and sets the failure flag. This hierarchical processing strategy ensures that the system can still output a non-jumping pose result under extreme conditions, providing continuous navigation reference for flight control.

[0058] For example, suppose a drone equipped with a visual-inertial SLAM module and a dual-antenna RTK receiver flies over an open urban area. The computing board receives SLAM odometry at 100Hz and RTK data at 20Hz. At a certain millisecond, the computing board obtains a position covariance trace of 0.05 square meters from the SLAM output, far below the preset threshold of 0.1 square meters, thus generating a high confidence flag; simultaneously, the received RTK data indicates a fixed solution state. The receiving process appends the same hardware timestamp to both data frames and stores them in shared memory. The fusion process starts with a 50Hz cycle, selecting the current timestamp as the target timestamp, reads paired data from the data area, checks for high confidence and fixed RTK, and therefore sets the weight matrix to a unit diagonal matrix. The EKF uses the covariance matrix saved from the previous moment to complete the prediction, then performs an update using the unscaled observation noise covariance, calculates the precise pose estimate for that moment, and outputs it to the transmitting process. The entire process, from data acquisition to fusion output, takes approximately 5 milliseconds, fully meeting the requirements for real-time control.

[0059] This embodiment eliminates time misalignment between sensors and flight control by storing SLAM odometry data and RTK dynamic positioning data in shared memory with a unified timestamp, and performs paired readings based on the same target timestamp. This ensures the consistency of the timescale of the input data to the fusion filter. Simultaneously, the introduction of covariance divergence detection to dynamically generate data confidence, combined with the real-time decision weight matrix of the RTK solution state, enables the extended Kalman filter to adaptively adjust observation noise parameters when any sensor degrades, effectively suppressing the contamination of state estimation by abnormal observations. Therefore, this embodiment guarantees fusion accuracy under normal operating conditions and provides a smooth, fault-tolerant transition when sensors degrade or fail, significantly improving the positioning continuity and flight stability of the UAV in highly dynamic and complex environments.

[0060] Based on any of the above embodiments, in Embodiment 2 of this application, covariance divergence detection is performed on the odometer data, and data confidence of the odometer data is generated based on the detection results, including: The covariance matrix of the odometer data is obtained through analysis; Calculate the values ​​of the main diagonal elements of the covariance matrix; If the value of the main diagonal element exceeds a preset threshold, the odometer data is determined to be divergent, and a first confidence level flag is generated. A reset command is sent to the SLAM sensor to trigger the SLAM sensor to reinitialize.

[0061] Otherwise, generate a second confidence level flag.

[0062] In this embodiment, covariance divergence detection refers to the quantification process of evaluating the reliability of the SLAM algorithm's pose estimation by analyzing the covariance matrix attached to the odometer data; the first confidence flag indicates that the odometer data frame is unreliable, and the second confidence flag indicates that the odometer data frame is reliable.

[0063] As an optional implementation, the receiving process extracts the covariance matrix from the odometer data packet parsed in step S10. This matrix is ​​a 9×9 or 15×15 symmetric positive definite matrix, and its main diagonal elements represent the variances of the SLAM algorithm's estimates of position, velocity, and attitude degrees of freedom, respectively. The receiving process extracts the three main diagonal elements corresponding to the position component, namely the eastward position variance, the northward position variance, and the altitude variance, and compares them one by one with preset thresholds. If the variance in any direction exceeds the preset threshold for that direction, the current frame's odometer data is determined to be divergent, a first confidence flag is generated, and a reset signal is immediately sent to the SLAM sensor via MAVLink command to trigger its visual relocalization or inertial alignment process. If the variances in all three directions do not exceed their respective thresholds, a second confidence flag is generated. This method, through independent threshold comparisons for each direction, can promptly trigger a reset when a single degree of freedom diverges while the other directions remain normal, avoiding continuous contamination of the fusion filter by partially degraded states.

[0064] As an alternative implementation, instead of using the independent variances of the position components in each direction as the criterion, the receiving process calculates the trace of the 3×3 submatrix of the position in the covariance matrix, i.e., the sum of the three main diagonal elements, and compares this trace with a comprehensive threshold. If the trace exceeds the comprehensive threshold, divergence is determined and a first confidence flag is generated; otherwise, a second confidence flag is generated. This method reduces the complexity of multi-threshold parameter tuning. Furthermore, the receiving process employs a hysteresis comparison strategy, i.e., a reset command is triggered only when the traces of three consecutive frames exceed the comprehensive threshold, preventing frequent resets due to accidental fluctuations in a single frame and avoiding repeated initialization of the SLAM sensor under normal degradation scenarios, thus preventing loss of positioning capability.

[0065] For example, after the computing board receives the SLAM odometry data packet at time n, the receiving process parses the position covariance submatrix from the data packet. The main diagonal elements of this submatrix are: eastward variance 0.08 square meters, northward variance 0.12 square meters, and altitude variance 0.03 square meters. The preset northward variance threshold is 0.10 square meters. The receiving process compares the data and finds that the northward variance of 0.12 square meters exceeds the threshold. Therefore, it determines that the SLAM data in this frame is divergent, generates a first confidence flag, and triggers the SLAM sensor to perform reinitialization via a MAVLink instruction. The data in this frame with the first confidence flag is then stored in the shared memory data area. When the fusion process reads this frame of data, it performs subsequent weighting processing based on the first confidence flag, thereby preventing the divergent data from adversely affecting the EKF fusion results.

[0066] This embodiment achieves a quantitative assessment of SLAM positioning quality by analyzing the covariance matrix of the odometer data and calculating its main diagonal elements. By comparing the main diagonal elements with a preset threshold, it can detect data divergence in real time when SLAM positioning accuracy deteriorates, and effectively isolate unreliable data through a first confidence flag to prevent it from entering the fusion filter. Simultaneously, upon detecting divergence, a reset command is sent to the SLAM sensor, triggering its re-initialization, enabling the system to actively recover and preventing SLAM from failing to converge on its own for an extended period after divergence. Therefore, this embodiment ensures that only odometer data with acceptable confidence participates in subsequent fusion, guaranteeing the input quality and overall robustness of the fusion positioning system from the data source end.

[0067] Based on any of the above embodiments, in Embodiment 3 of this application, referring to Figure 2 Based on the data confidence level corresponding to the target odometer data and the RTK state corresponding to the target dynamic positioning data, the weight matrix for the current fusion cycle is determined, including: S61, when the data confidence level is the second confidence level and the RTK state is a fixed solution, assign equal first weights to the target odometer data and the target dynamic positioning data; S62, when the data confidence level is the first confidence level and the RTK state is a fixed solution, assign a second weight to the target odometry data that is lower than that to the target dynamic positioning data; S63, when the RTK state is a floating-point solution, a third weight is assigned to the target dynamic positioning data that is lower than the corresponding weight in the fixed solution state, and the third weight decreases as the uncertainty of the target dynamic positioning data increases.

[0068] In this embodiment, a fixed solution refers to the RTK carrier phase differential reaching a state of fixed integer ambiguity, at which point the positioning accuracy is at the centimeter level; a floating-point solution refers to the integer ambiguity only obtaining a floating-point estimate, with a positioning accuracy at the decimeter to meter level; uncertainty refers to the horizontal position error estimate or standard deviation carried in the RTK data, used to quantify the dispersion of the current positioning solution.

[0069] As an optional implementation, after reading the target odometry data and target dynamic positioning data, the fusion process first checks the odometry confidence flag and the RTK solution status flag. If the odometry confidence flag is at the second confidence level and the RTK status is a fixed solution, the fusion process sets the weight coefficients corresponding to both the odometry observations and the RTK observations to 1.0, achieving equal-weighted fusion. If the odometry confidence flag is at the first confidence level and the RTK status is a fixed solution, the fusion process sets the weight coefficient corresponding to the odometry observations to 0.1 and keeps the weight coefficient corresponding to the RTK observations at 1.0, so that the fusion result prioritizes the use of RTK data and suppresses the contamination of pose estimation by divergent SLAM data. If the RTK state is a floating-point solution, the fusion process first reads the horizontal position uncertainty value from the target dynamic positioning data. This uncertainty is in meters. Then, with the reference uncertainty in the fixed solution state as a reference, the uncertainty ratio is calculated. The reciprocal of this ratio is used as the weighting coefficient of the RTK observation. At the same time, the weighting coefficient of the odometer observation is set to 1.0 or 0.1 according to its confidence flag. This makes the RTK observations given a smaller fusion weight when the floating-point solution accuracy is low, and the weight decreases monotonically with the increase of uncertainty until it approaches zero.

[0070] As an alternative implementation, the fusion process does not employ discrete weight coefficient settings. Instead, it maps both the odometer confidence and RTK uncertainty into a two-dimensional continuous weight function. This function takes the trace of the odometer covariance and the RTK horizontal position uncertainty as inputs, and outputs the weight values ​​for the odometer and RTK observations. Specifically, the weight value for the odometer observation is calculated from the trace of the odometer covariance using a sigmoid function; as the trace increases from zero to a threshold, the weight value smoothly decreases from 1.0 to 0.1. The weight value for the RTK observation is calculated from the RTK uncertainty using an exponential decay function; as the uncertainty increases from a baseline value to three times the baseline value, the weight value smoothly decreases from 1.0 to 0.2. The fusion process independently calculates both types of weight values ​​in each cycle, and then normalizes them to keep the trace of the weight matrix constant. This approach avoids the jumps in fusion results caused by discrete weight switching in scenarios with gradual changes in sensor performance, allowing the observation noise covariance of the EKF to adjust smoothly during transitions in operating conditions, thereby maintaining the temporal continuity of pose estimation.

[0071] For example, in the current fusion cycle, the fusion process reads target odometry data and target dynamic positioning data from the shared memory data area. The target odometry data carries a confidence flag of first confidence, indicating that the SLAM data in this frame has diverged; the RTK state of the target dynamic positioning data is a fixed solution with a horizontal position uncertainty of 0.02 meters. Following the decision logic of this step, the fusion process sets the weight coefficient of the odometry observations to 0.1 and the weight coefficient of the RTK observations to 1.0. Subsequently, the fusion process uses this weight matrix as the basis for observation noise scaling in the EKF update phase, significantly reducing the contribution of SLAM observations to the fusion result, so that the pose estimation of the EKF output is mainly determined by the RTK data, thereby maintaining positioning accuracy during SLAM divergence. In a subsequent frame, if the RTK signal of the same UAV is downgraded to a floating-point solution due to flying over a building obstruction area, and the uncertainty rises to 0.5 meters, the fusion process will adjust the weight coefficient of the RTK observation to 0.2, while restoring the weight coefficient of the odometry observation to 1.0. This allows EKF to rely mainly on odometry data when the RTK accuracy is insufficient, thus maintaining a smooth and effective positioning output.

[0072] This embodiment dynamically determines the weight matrix based on two-dimensional information: odometry data confidence and RTK solution state. This enables the fusion strategy to adaptively adjust to sensor operating conditions. In the optimal operating condition where odometry confidence is high and the RTK solution is fixed, equal-weighted fusion is employed to fully leverage the accuracy advantages of dual-source observations. When odometry diverges, its weight is proactively reduced to prevent abnormal data from contaminating the fusion results. When the RTK solution is downgraded to a floating-point solution, the RTK weight is continuously reduced based on uncertainty to prevent low-precision absolute positioning from dominating the fusion and introducing biases. The differentiated weight allocation under these three operating conditions works synergistically, enabling the UAV to obtain optimal pose estimation in various environments, including changes in GNSS signal quality and SLAM degradation, significantly improving the robustness and availability of the fusion positioning system across all operating conditions.

[0073] Based on any of the above embodiments, in Embodiment 4 of this application, when the RTK state is a floating-point solution, the method further includes: S631, if the data confidence level is the second confidence level, assign a fourth weight equal to that of the target odometer data to the target dynamic positioning data; S632, if the data confidence level is the first confidence level, assign a fifth weight to the target odometer data that is lower than that to the target dynamic positioning data, and the attenuation magnitude of the fifth weight is less than that of the second weight.

[0074] In this embodiment, the fourth weight is the same weight value used for odometer observation and RTK observation when the RTK state is in a floating-point solution and the odometer data is reliable; the fifth weight is a lower weight value assigned to odometer observation than RTK observation when the RTK state is in a floating-point solution and the odometer data is divergent; the attenuation magnitude refers to the reduction ratio or difference of the odometer observation weight relative to the RTK observation weight under the same RTK state conditions; the second weight is a lower weight value assigned to odometer observation than RTK observation when the RTK state is a fixed solution and the odometer data is divergent.

[0075] As an optional implementation, after detecting that the current RTK state is a floating-point solution, the fusion process first reads the confidence flag of the target odometer data. If the flag indicates a second confidence level, the fusion process sets the weight coefficients of the odometer observations and the RTK observations to the same value, i.e., the fourth weight. This fourth weight is less than the weight value of equal-weighted fusion under the fixed solution state, but maintains the balance between the odometer and RTK, ensuring that the system still utilizes both observation sources in a balanced manner when the RTK accuracy is insufficient, avoiding system bias caused by a single observation source dominating. If the confidence flag indicates a first confidence level, the fusion process sets the weight coefficient of the odometer observations as the fifth weight and the weight coefficient of the RTK observations as the third weight. The third weight is determined by the floating-point solution uncertainty reduction rule. The fifth weight is numerically lower than the third weight, but its reduction relative to the third weight is less than the reduction of the second weight relative to the RTK observation weight of 1.0 under the fixed solution state. Specifically, if the second weight is 0.1, meaning the odometer weight has decreased by 0.9 from the equal weight state, then the decrease in the fifth weight relative to the third weight is set to 0.5. That is, the odometer weight is the third weight minus 0.5 times the difference between the third weight and the minimum weight, so that the degree of weight reduction of the odometer in the floating-point solution is less than the degree of weight reduction in the fixed solution.

[0076] As an alternative implementation, the fusion process employs a relative proportional constraint to achieve differentiated control of the attenuation magnitude. When the RTK state is a floating-point solution and the odometer confidence level is the first confidence level, the fusion process first calculates the baseline weight value of the RTK observation based on the floating-point solution uncertainty in step S60. Subsequently, the weight value of the odometer observation is set to the baseline weight value multiplied by a fixed proportional coefficient, which is greater than the proportional coefficient used when the solution is fixed and the odometer diverges. For example, if the ratio of the odometer weight to the RTK weight is 0.1 when the solution is fixed and the odometer diverges, then this ratio is set to 0.5 when the solution is floating and the odometer diverges, so that the odometer obtains a relatively higher retention weight in the floating-point solution condition. This proportional constraint method ensures that the attenuation magnitude of the fifth weight relative to the third weight is mathematically strictly less than the attenuation magnitude of the second weight relative to the fixed solution RTK weight of 1.0, thereby forming a consistent weight reduction gradient between different RTK states.

[0077] For example, after the drone flies over a building-obstructed area, the RTK signal recovers, but the satellite geometry is poor, and the receiver outputs a floating-point solution with a horizontal position uncertainty of 0.3 meters. The fusion process reads that the odometry confidence flag for the current frame is at the second confidence level, indicating that the SLAM data is reliable. Therefore, both the odometry and RTK observation weights are set to the fourth weight of 0.8, achieving equal-weight fusion under the floating-point solution condition. A few seconds later, SLAM degrades due to insufficient visual features, increasing the output covariance, and the confidence flag switches to the first confidence level. At this point, the fusion process, while maintaining the RTK observation weight at the third weight of 0.4, sets the odometry observation weight to the fifth weight of 0.2, meaning the odometry attenuation relative to RTK is 0.5. In contrast, in the same scenario, if the RTK state is a fixed solution, the second weight when the odometry diverges is only 0.1, with an attenuation of 0.9. In this embodiment, the attenuation amplitude of 0.5 under the floating-point solution is significantly smaller than the attenuation amplitude of 0.9 under the fixed solution. This allows SLAM to retain a moderate fusion contribution even when the RTK accuracy is insufficient, avoiding the introduction of bias due to excessive weighting causing the fusion result to rely entirely on low-precision RTK.

[0078] This embodiment achieves reasonable utilization of odometer data under floating-point solution conditions by differentiating odometer confidence levels and allocating weights accordingly. When the odometer is reliable, equal-weighted fusion is used, fully utilizing the relatively smooth information of SLAM even with limited RTK accuracy. When the odometer diverges, its weight is reduced, but the attenuation is less than that under fixed-solution conditions. This avoids over-reliance on the low-precision absolute positioning source when the RTK itself is already in a degraded state, effectively balancing the fusion contribution of dual-source observations under non-ideal conditions, and improving the system's positioning robustness and accuracy maintenance capability in scenarios with partial GNSS signal obstruction.

[0079] Based on any of the above embodiments, in Embodiment 5 of this application, the target odometry data, the target dynamic positioning data, and the weight matrix are input into an extended Kalman filter to obtain the pose estimate of the UAV at time n, including: S71, read the covariance matrix at time n-1 from the shared memory and use it as the input of the extended Kalman filter in the prediction step at time n.

[0080] In this embodiment, the covariance matrix at time n-1 is the state covariance matrix output by the extended Kalman filter after the update step of the previous fusion cycle. Its dimension is consistent with the dimension of the state vector and is used to quantify the uncertainty of the pose estimation at the previous time. The prediction step refers to the process of using the system motion model to recursively derive the state estimate and covariance matrix at the previous time to the current time. This process outputs the prior state estimate and prior covariance matrix at the current time.

[0081] As an optional implementation, after the fusion process starts in the current fusion cycle, it first reads the covariance matrix at time n-1 from the state area of ​​shared memory. This covariance matrix is ​​the complete matrix data written to the state area by the extended Kalman filter in the previous cycle, and uses the same atomic access mechanism as the shared memory data area to ensure read consistency. The fusion process loads this covariance matrix into local memory as input for the current prediction step, and simultaneously reads the state estimation vector at time n-1 from the state area. Subsequently, the fusion process calls a preset system motion model function, which contains the UAV's uniform motion model or uniform acceleration motion model and its corresponding Jacobian matrix. Using the state estimation and covariance matrix at time n-1, it calculates the prior state estimate and prior covariance matrix at time n, completing the recursive calculation of the prediction step.

[0082] As an alternative implementation, the fusion process does not directly read the complete covariance matrix from shared memory. Instead, it reads the square root factor matrix of the covariance matrix, i.e., the covariance representation in square root form. This method is superior to directly transmitting the covariance matrix in terms of numerical stability and can effectively avoid the loss of symmetric positive definiteness of the covariance matrix due to numerical rounding errors. After reading the square root factor matrix, the fusion process recovers the complete covariance matrix by multiplying its transpose by the original matrix and uses it in the prediction step calculation. Alternatively, it can directly participate in the calculation in the square root factor form in the prediction and update steps. After the update step is completed, the new square root factor matrix is ​​written back to shared memory for reading in the next cycle.

[0083] S72, set the observation noise covariance of the target odometer data and the target dynamic positioning data according to the weight matrix.

[0084] In this embodiment, the observation noise covariance matrix is ​​a matrix used in the extended Kalman filter update step to characterize the measurement noise amplitude of each observation source. The larger the value, the lower the reliability of the observation source. The weight matrix is ​​the weight coefficient matrix of the current fusion period determined in step S60, which is used to scale the default observation noise covariance.

[0085] As an optional implementation, after completing the prediction step in step S71, the fusion process reads the target odometer data and target dynamic positioning data from the shared memory data area, and reads the weight matrix calculated in step S60 from the local cache or state area. This weight matrix is ​​a diagonal matrix, with its diagonal elements corresponding to the weight coefficients of the odometer observations and RTK observations, respectively. The fusion process calls the preset default odometer observation noise covariance matrix and the default RTK observation noise covariance matrix, multiplying them by the corresponding weight coefficients in the weight matrix to obtain the actual odometer observation noise covariance matrix and the RTK observation noise covariance matrix used in the current period. If the odometer weight coefficient is 1.0 and the RTK weight coefficient is 1.0, the actual observation noise covariance is equal to the default value, achieving equal-weighted fusion; if the odometer weight coefficient is 0.1 and the RTK weight coefficient is 1.0, the odometer observation noise covariance is amplified tenfold, significantly reducing its information contribution in the EKF update step, while the RTK observation maintains its original contribution.

[0086] As an alternative implementation, the fusion process does not directly multiply the weight matrix by the complete observation noise covariance matrix. Instead, it multiplies the square root of the weight coefficients by the square root factor of the observation noise covariance matrix, i.e., the Cholesky decomposition factor of the observation noise covariance. Since the observation noise covariance matrix is ​​usually a diagonal or block diagonal matrix, this square root factor is still a diagonal matrix and is computationally simple. The fusion process uses the scaled square root factor for the Kalman gain calculation in the update step. This method is numerically equivalent to scaling the original observation noise covariance matrix, but avoids the complete matrix multiplication operation, reducing the computational load of the fusion process and improving numerical stability.

[0087] S73, execute the prediction and update steps of the extended Kalman filter, and output the pose estimate of the UAV at time n.

[0088] In this embodiment, the prediction step has been completed by step S71. The update step refers to the process of correcting the prior estimate using the observation data and observation noise covariance matrix at the current time to obtain the posterior state estimate. The pose estimation includes at least the three-dimensional position, three-dimensional velocity and attitude angle of the UAV at time n.

[0089] As an optional implementation, after completing the observation noise covariance setting in step S72, the fusion process calls the update step function of the extended Kalman filter. This function takes the state prior estimate and prior covariance matrix output in step S71, the target odometry data and target dynamic positioning data read in step S70, and the scaled observation noise covariance matrix from step S72 as inputs, and sequentially calculates the Kalman gain matrix, the state posterior estimate, and the posterior covariance matrix. The calculation of the Kalman gain considers both the prior covariance and the scaled observation noise covariance, enabling the weight matrix to control the fusion result. After the update step is completed, the fusion process extracts the three-dimensional position, three-dimensional velocity, and attitude angle from the state posterior estimate vector as the pose estimate at time n, and stores this result in the shared memory data area for the sending process to read. Simultaneously, the fusion process stores the posterior covariance matrix as the covariance matrix at time n in the shared memory state area for step S71 to read in the next fusion cycle, thus forming a recursive closed loop of the covariance matrix on the time axis.

[0090] As an alternative implementation, the fusion process verifies the validity of the observation data before executing the update step. Specifically, the fusion process compares the position increment in the target odometry data and the absolute position in the target dynamic positioning data with the state prior estimate output in step S71, and calculates their Mahalanobis distance. If the Mahalanobis distance of a certain type of observation data exceeds a preset threshold, it indicates that the observation deviates too much from the predicted value. The fusion process then multiplies the observation noise covariance matrix corresponding to this type of observation by a larger scaling factor on top of the scaling in step S72, which is equivalent to further reducing the contribution of this anomalous observation in this update. This method provides an additional layer of anomaly isolation protection under the condition that the weight matrix is ​​already determined, preventing observation outliers caused by sensor transient jumps from contaminating the fusion results and enhancing the system's resistance to sensor output glitches.

[0091] For example, after the fusion process starts in the current fusion cycle, it first reads the covariance matrix at time n-1 from the shared memory state area. This matrix is ​​the joint covariance matrix of the nine-dimensional state (position, velocity, attitude) output after the EKF update in the previous cycle. The fusion process uses the UAV's uniform motion model to recursively derive this covariance matrix to time n, obtaining the prior covariance matrix. Subsequently, the fusion process reads the weight matrix calculated in step S60, in which the odometry weight is 0.1 and the RTK weight is 1.0. Therefore, the odometry default observation noise covariance matrix is ​​multiplied by the reciprocal of 0.1, i.e., magnified tenfold, while the RTK default observation noise covariance matrix is ​​kept unchanged. Next, the fusion process calls the EKF update function, using the target odometry data and target dynamic positioning data of the current frame, as well as the scaled observation noise covariance matrix, to correct the prior estimate and obtain the posterior state estimate. The fusion process extracts three-dimensional position, three-dimensional velocity, and three attitude angles (roll, pitch, and yaw) from the posterior estimate and writes them into the shared memory data area as the pose estimate at time n. Simultaneously, the posterior covariance matrix is ​​written into the state area for use at time n+1. The entire process from reading the covariance to outputting the pose is completed within 5 milliseconds, meeting the requirements of real-time UAV control.

[0092] This embodiment achieves a recursive closed-loop extended Kalman filter (EKF) on the time axis by reading the covariance matrix from shared memory as the input to the current prediction step. This ensures the continuous transmission of covariance information across different fusion cycles, enabling the filter to continuously track its own estimation uncertainties. Simultaneously, by setting the observation noise covariances of odometry and RTK according to the weight matrix, the weight decision results are transformed into mathematical parameters that the EKF can directly execute, establishing a complete link between the weight matrix and the fusion results. The coordinated execution of the prediction and update steps ensures the recursive updating of the state estimate, while the closed-loop storage of the covariance matrix provides necessary prior information for the next cycle. The organic combination of these three elements guarantees the stability, accuracy, and self-consistency of the fusion positioning system during continuous operation.

[0093] Based on any of the above embodiments, in Embodiment Six of this application, after executing the prediction and update steps of the extended Kalman filter and outputting the pose estimate of the UAV at time n, the process includes: Calculate the covariance matrix and the innovation residual at time n; The covariance matrix at time n and the innovation residual are stored in the shared memory. The covariance matrix at time n is used as the input for the prediction step at the next time step, and the innovation residual is used to trigger the adjustment of the weight matrix.

[0094] In this embodiment, the covariance matrix at time n refers to the posterior state covariance matrix output by the extended Kalman filter after the update step at time n, which is used to quantify the uncertainty of the current pose estimation; the innovation residual refers to the difference vector between the actual observation and the observation predicted based on the prior estimation in the update step of the extended Kalman filter, and its magnitude reflects the degree of consistency between the current observation data and the filter prediction.

[0095] As an optional implementation, in the extended Kalman filter update step of step S73, the fusion process simultaneously calculates the Kalman gain, posterior state estimate, and posterior covariance matrix. After the update step is completed, the fusion process extracts the observation vector at the current time, i.e., the observation value composed of target odometry data and target dynamic positioning data, and maps it to the predicted observation value obtained by mapping the prior estimate output from the prediction step through the observation model. The difference vector between the two is calculated as the innovation residual. The dimension of this innovation residual is equal to the total dimension of the observation vector, i.e., the sum of the odometry observation dimension and the RTK observation dimension. The fusion process then writes the posterior covariance matrix calculated in step S73 and the innovation residual vector at the current time into the covariance storage field and residual storage field of the state area in shared memory, respectively. The posterior covariance matrix is ​​stored in a complete matrix format for reading in step S71 of the next fusion cycle and as input to the prediction step; the innovation residual vector is appended and stored in the circular buffer of the state area in a time-series manner for independent monitoring processes or the fusion process itself to read at the beginning of the next cycle to determine whether the weight matrix of subsequent fusion cycles needs to be adjusted.

[0096] As an alternative implementation, the fusion process does not store the complete posterior covariance matrix. Instead, it calculates and stores the square root factor of its inverse matrix, i.e., the information matrix, to reduce storage space usage and improve numerical stability during the next cycle read. Simultaneously, after calculating the innovation residual, the fusion process further calculates the Mahalanobis distance of the innovation residual. This is achieved by multiplying the transpose of the innovation residual by the inverse of the innovation covariance matrix, then multiplying by the innovation residual again, resulting in a scalar value used as the residual normalization index. This scalar value, rather than the complete residual vector, is stored in the shared memory state area. This normalization index directly reflects the degree of statistical deviation between observed and predicted values, simplifying the threshold determination logic. Downstream monitoring processes do not need to calculate the inverse covariance matrix themselves; they can directly perform subsequent anomaly determinations based on this scalar value, reducing the overall computational load of the system.

[0097] For example, after completing the EKF update step at time n, the fusion process obtains the posterior covariance matrix and the current time-innovation residual vector. The residual value corresponding to the RTK observation component in the innovation residual vector is 0.05 m, which is less than the preset 3σ threshold, indicating that the current RTK observation is consistent with the filter prediction. The fusion process stores the posterior covariance matrix in complete matrix form in the covariance field of the shared memory state area, and appends the innovation residual vector to the end of the residual circular buffer in the state area. At the beginning of the subsequent (n+1)th fusion cycle, step S71 reads the covariance matrix at time n from the state area as the prediction input to realize the continuous recursion of covariance information; at the same time, the monitoring process reads the innovation residual sequence in the state area in the background at regular intervals. If the residual of multiple consecutive frames exceeds the threshold, an adjustment request is sent to the weight decision logic in step S60 to trigger the recalculation of the weight matrix, thereby forming a complete feedback loop from fusion output to weight adjustment.

[0098] This embodiment achieves dual-path feedback of the fusion result to the next time-time prediction step and weight decision step by synchronously calculating and storing the posterior covariance matrix and innovation residual after the EKF update step. The storage of the posterior covariance matrix ensures the recursive continuity of the extended Kalman filter along the time axis, allowing the estimation uncertainty at each time step to be fully utilized by the prediction step at the next time step. The storage of the innovation residual provides the system with a data foundation for real-time monitoring of sensor observation consistency, enabling subsequent fusion cycles to dynamically adjust the weight matrix based on the historical performance of the residual, thus forming an adaptive closed-loop adjustment mechanism from the fusion output to the weight decision. Together, these two elements constitute a complete information loop in the time dimension of the fusion positioning system, enabling the system to continuously perceive its own estimation quality and proactively respond to changes in sensor operating conditions.

[0099] Based on any of the above embodiments, in Embodiment 7 of this application, after storing the covariance matrix at time n and the innovation residual into the shared memory, the process includes: At time n+1, if the information residual of a consecutive preset number of frames exceeds a preset 3σ threshold, a sensor operating condition abnormality flag is generated. In the next fusion cycle, the weight matrix of the next fusion cycle is updated according to the anomaly flag.

[0100] In this embodiment, the innovation residual refers to the difference vector between the actual observed value and the predicted observed value in the update step of the extended Kalman filter; the 3σ threshold refers to a threshold set based on three times the standard deviation of the statistical covariance of the innovation residual, used to determine whether the current observation is significantly inconsistent with the filter prediction; the consecutive preset number of frames refers to multiple fusion cycles arranged sequentially on the time axis that all meet the same abnormal condition, and the preset number is an integer greater than or equal to 2; the sensor operating condition abnormal flag is a flag bit written into the shared memory status area, used to characterize whether the current SLAM sensor or RTK receiver is in an abnormal working state.

[0101] As an optional implementation, after the update step of each fusion cycle is completed, the fusion process or an independent monitoring process reads the historical innovation residuals of the most recent several cycles from the circular buffer of the shared memory state area. For the innovation residual vector of each cycle, the monitoring process first calculates its Mahalanobis distance, that is, multiplying the transpose of the innovation residual by the inverse of the innovation covariance matrix and then by the innovation residual to obtain a normalized scalar value. This scalar value follows a chi-square distribution, and its 3σ threshold is the critical value of the corresponding degree of freedom under the chi-square distribution. The monitoring process compares the normalized residuals of the most recent consecutive preset number of frames one by one with this critical value. If the normalized residuals of the consecutive preset number of frames are all greater than the critical value, it indicates that there is a systematic deviation between the filter prediction and the actual observations at multiple consecutive moments. At this time, the monitoring process determines that the sensor data has lost consistency and writes a sensor operating condition abnormality flag into the shared memory state area. Subsequently, when the next fusion cycle starts, the fusion process first reads the abnormal flag in the weight matrix determination logic of step S60. After identifying the abnormality, it actively performs the weight matrix update operation, such as further reducing the weight coefficients corresponding to the sensor observations that are currently in a low confidence state by a preset step size, or forcibly setting the weight coefficients corresponding to the abnormal sensors to zero.

[0102] As an alternative implementation, the determination of the innovation residual is not based on a single fusion overall residual, but rather on calculating the respective sub-residual vectors and corresponding normalized indices for odometry and RTK observations. The monitoring process independently tracks the continuous out-of-range conditions of the two types of observation sources. If the sub-residual corresponding to the odometry observation exceeds the threshold for a preset number of consecutive frames, while the sub-residual corresponding to the RTK observation is normal, a SLAM sensor anomaly flag is generated. In the next cycle, the weight matrix will unilaterally reduce the weight coefficient of the odometry observation while keeping the weight of the RTK observation unchanged. If the sub-residual corresponding to the RTK observation exceeds the threshold for a consecutive time, while the odometry observation is normal, an RTK anomaly flag is generated, and the weight of the RTK observation is unilaterally reduced in the next cycle. If the sub-residuals of both types of observations exceed the threshold for a consecutive time, a fusion system anomaly flag is generated. In this case, in the next cycle, the fusion process will skip the update step of the low-confidence observation source and only maintain the prediction state. This source-specific determination method can accurately locate the source of the anomaly and avoid misjudgment caused by the simultaneous reduction of weights for both sources due to a single source anomaly.

[0103] For example, at the start of the (n+1)th fusion cycle, the monitoring process reads the information residual sequence of the last five frames from the shared memory state area and calculates the normalized Mahalanobis distance for each frame. The normalized residuals of the first two frames are 1.2 and 1.8, respectively, both below the 3σ critical value. The normalized residual of the third frame jumps to 4.2, exceeding the 3σ critical value. The fourth frame is 3.8, and the fifth frame is 4.5, with the normalized residuals of three consecutive frames exceeding the 3σ critical value. Based on this, the monitoring process determines that the sensor data has undergone a systematic deviation and writes a SLAM anomaly flag in the state area. Subsequently, in step S60 of the (n+1)th fusion cycle, the fusion process reads this anomaly flag and further reduces the weight coefficient of the odometry observation from the current 0.1 to 0.02. Because the sub-residuals corresponding to the RTK observations remain normal, the RTK observation weight remains unchanged at 1.0, making the subsequent fusion output almost entirely dependent on the RTK data, successfully avoiding the positioning drift risk caused by the continuous deterioration of SLAM data.

[0104] This embodiment achieves reliable identification of abnormal sensor operating conditions by detecting consecutive multi-frame over-threshold values ​​of the innovation residual and combining it with a preset 3σ statistical threshold, avoiding false triggering caused by accidental fluctuations in a single frame. The generated anomaly flag serves as the trigger condition for dynamic adjustment of the fusion process weight matrix, enabling the system to proactively adjust the fusion strategy when sensor performance degrades, ensuring stable output accuracy under different sensor operating conditions. Simultaneously, this mechanism allows the fusion process to possess autonomous perception and decision-making capabilities without relying on external fault diagnosis modules, significantly improving the adaptability and reliability of the fusion positioning system in complex environments and during long-term operation.

[0105] Based on any of the above embodiments, in Embodiment 8 of this application, before updating the weight matrix of the next fusion cycle according to the anomaly flag in the next fusion cycle, the following is included: Obtain the processor load, memory usage, and core temperature of the computing board; When the processor load exceeds the first threshold, the memory usage exceeds the reserved water level, or the core temperature exceeds the second threshold, an anomaly flag is generated and written to the shared memory.

[0106] In this embodiment, processor load refers to the percentage of busy time of the central processing unit of the computing board per unit time; memory usage refers to the ratio of currently used memory capacity to total memory capacity; core temperature refers to the real-time junction temperature inside the processor chip; the reserved water level line refers to the preset memory usage warning value to ensure stable system operation, which is less than the total memory capacity; the first threshold is the safe upper limit of processor load; the second threshold is the safe upper limit of core temperature; the abnormal flag is a flag indicating that the hardware resources are in an overloaded or overheated state, which is written into the shared memory status area for the fusion process to read in subsequent weight decision-making.

[0107] As an optional implementation, a system monitoring process running on the computing board reads processor load, memory usage, and core temperature at a fixed sampling period, such as once per second. Processor load is calculated as a percentage by reading the average load value from the system file and combining it with the number of CPU cores; memory usage is calculated as a percentage by reading the used memory and total memory fields in the memory management unit; core temperature is obtained by reading the register value of the chip's built-in temperature sensor. The monitoring process compares the three collected values ​​with a preset first threshold, a reserved water level, and a second threshold, respectively. If the processor load exceeds the first threshold (continuously above 80%), or the memory usage exceeds the reserved water level (more than 90% of total memory), or the core temperature exceeds the second threshold (above 75 degrees Celsius), the monitoring process writes an anomaly flag at a predetermined offset address in the shared memory status area when any of these conditions are met. If none of the three monitored values ​​exceed their respective thresholds, the monitoring process writes a normal flag in the status area, overwriting any previously existing anomaly flags, thus achieving automatic flag clearing.

[0108] As an alternative implementation, the monitoring process does not treat processor load, memory usage, and core temperature as independent anomaly criteria. Instead, it constructs a comprehensive health score function to weight and fuse these three factors. This function assigns different weight coefficients to processor load, memory usage, and core temperature, then sums them to obtain a continuous health score. When this score exceeds a preset comprehensive threshold, the monitoring process generates an anomaly flag. Simultaneously, the monitoring process additionally records an anomaly cause code in the status area. This cause code identifies the specific item that triggered the anomaly flag in bit form, allowing the fusion process to determine whether the anomaly originated from processor load, memory usage, or temperature after reading the anomaly flag in the next cycle, thus enabling differentiated decisions during subsequent weight adjustments.

[0109] For example, during a long-duration, high-load visual SLAM and EKF fusion task, the processor load on the computing board gradually increases to 85%, the core temperature rises to 78 degrees Celsius, and memory usage remains at 70% of total memory, not exceeding the threshold. The system monitoring process samples these three indicators once per second. If it detects that the processor load exceeds the first threshold of 80% and the core temperature exceeds the second threshold of 75 degrees Celsius, and both conditions are met simultaneously, the monitoring process immediately writes an anomaly flag in the shared memory state area. At the start of the next fusion cycle, the fusion process reads this anomaly flag from the state area. During the determination of the weight matrix in step S60, the weight coefficients of both odometry and RTK observations are multiplied by a predetermined load reduction factor, such as 0.8, to synchronously reduce the contribution of both types of observations to the EKF update. This load reduction operation is equivalent to increasing the observation noise covariance matrix, allowing the filter to update the state estimate more conservatively when hardware resources are limited, preventing filter divergence due to insufficient computing power. Meanwhile, during the period when the anomaly flag is in effect, the fusion process actively skips the processing of high frame rate odometer data and only executes the fusion cycle at a lower frequency, further reducing CPU load and heat generation.

[0110] This embodiment acquires real-time processor load, memory usage, and core temperature data from the computing board, enabling the system to proactively perceive its operational status in the early stages of hardware resource scarcity or overheating. It then generates an anomaly flag to transmit this hardware condition information to the fusion decision-making chain. Under abnormal hardware conditions, the fusion process updates the weight matrix based on this flag, proactively reducing the fusion computing frequency or compressing the processing load of sensor data, thereby achieving system load reduction protection when hardware resources are limited. This cross-layer collaborative mechanism of hardware monitoring and weight decision-making effectively prevents sudden performance drops or even system crashes caused by computing board overload or overheating, ensuring that the UAV can maintain basic positioning capabilities even under extreme hardware resource constraints. This significantly improves the engineering reliability and environmental adaptability of the fusion positioning system in long-term continuous operation scenarios.

[0111] This application provides a drone computing board, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the control method of the drone computing board in the first embodiment described above.

[0112] The following is for reference. Figure 3 The diagram illustrates a structural schematic of a control device suitable for implementing the drone computing board in the embodiments of this application. The control device for the drone computing board in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers, and may also be a drone computing board. Figure 3 The control device for the drone computing board shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0113] like Figure 3 As shown, the control device of the UAV computing board may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in read-only memory (ROM) 1002 or programs loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the UAV computing board's control device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the control equipment of the UAV computing board to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows control equipment for a UAV computing board with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0114] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0115] The control device for the UAV computing board provided in this application, employing the control method for the UAV computing board in the above embodiments, can solve the technical problem of inherent time misalignment between the SLAM sensor, computing board, and flight controller, leading to attitude calculation deviations and reducing the stability of high-precision flight of the UAV. Compared with the prior art, the beneficial effects of the control device for the UAV computing board provided in this application are the same as those of the control device for the UAV computing board provided in the above embodiments, and other technical features in this control device for the UAV computing board are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0116] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0117] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0118] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the control method of the UAV computing board in the above embodiments.

[0119] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0120] The aforementioned computer-readable storage medium may be included in the drone computing board; or it may exist independently and not be assembled into the drone computing board.

[0121] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the UAV computing board, the UAV computing board performs the following actions: acquires odometry data output by the SLAM sensor at time n, and acquires dynamic positioning data output by the flight controller at time n; performs covariance divergence detection on the odometry data, and generates a data confidence score for the odometry data based on the detection result; associates and stores the odometry data, the data confidence score, and the timestamp at time n in a shared memory data area; associates and stores the dynamic positioning data with the timestamp at time n in the shared memory data area; reads target odometry data and target dynamic positioning data with the same target timestamp from the shared memory data area, the target timestamp corresponding to the current fusion period; determines the weight matrix for the current fusion period based on the data confidence score corresponding to the target odometry data and the RTK state corresponding to the target dynamic positioning data; and inputs the target odometry data, the target dynamic positioning data, and the weight matrix into an extended Kalman filter for fusion to obtain the pose estimate of the UAV at time n.

[0122] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0123] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation that may be implemented in systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0124] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0125] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the control method of the aforementioned UAV computing board. This solves the technical problem of inherent time misalignment between the SLAM sensor, computing board, and flight controller, leading to attitude calculation deviations and reduced stability of high-precision UAV flight. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method of the UAV computing board provided in the above embodiments, and will not be repeated here.

[0126] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the control method for the unmanned aerial vehicle (UAV) computing board described above.

[0127] The computer program product provided in this application can solve the technical problem that the inherent time misalignment between the SLAM sensor, computing board, and flight controller leads to attitude calculation deviations and reduces the stability of high-precision flight of the UAV. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the UAV computing board control method provided in the above embodiments, and will not be repeated here.

[0128] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A control method for a drone computing board, characterized in that, The control method for the UAV computing board includes: Acquire the odometry data output by the SLAM sensor at time n, and acquire the dynamic positioning data output by the flight controller at time n; The odometer data is subjected to covariance divergence detection, and the data confidence of the odometer data is generated based on the detection results; The odometer data, the data confidence level, and the timestamp at the nth time are associated and stored in the data area of ​​shared memory; The dynamic positioning data is associated with the timestamp of the nth time and stored in the data area of ​​the shared memory; From the data area of ​​the shared memory, read the target odometer data and target dynamic positioning data that have the same target timestamp, the target timestamp corresponding to the current fusion cycle; The weight matrix for the current fusion cycle is determined based on the data confidence level corresponding to the target odometer data and the RTK state corresponding to the target dynamic positioning data. The target odometry data, the target dynamic positioning data, and the weight matrix are fused into an extended Kalman filter to obtain the pose estimate of the UAV at time n.

2. The control method for the UAV computing board as described in claim 1, characterized in that, The step of performing covariance divergence detection on the odometer data and generating data confidence scores for the odometer data based on the detection results includes: The covariance matrix of the odometer data is obtained through analysis; Calculate the values ​​of the main diagonal elements of the covariance matrix; If the value of the main diagonal element exceeds a preset threshold, the odometer data is determined to be divergent, and a first confidence level flag is generated. Send a reset command to the SLAM sensor to trigger the SLAM sensor to reinitialize; Otherwise, generate a second confidence level flag.

3. The control method for the UAV computing board as described in claim 1, characterized in that, The step of determining the weight matrix for the current fusion cycle based on the data confidence level corresponding to the target odometer data and the RTK state corresponding to the target dynamic positioning data includes: When the data confidence level is the second confidence level and the RTK state is a fixed solution, the target odometer data and the target dynamic positioning data are assigned equal first weights; When the data confidence level is the first confidence level and the RTK state is a fixed solution, the target odometry data is assigned a second weight lower than that of the target dynamic positioning data; When the RTK state is a floating-point solution, a third weight is assigned to the target dynamic positioning data, which is lower than the corresponding weight in the fixed solution state, and the third weight decreases as the uncertainty of the target dynamic positioning data increases.

4. The control method for the UAV computing board as described in claim 3, characterized in that, When the RTK state is a floating-point solution, the method further includes: If the data confidence level is the second confidence level, then the target odometer data is assigned a fourth weight equal to that of the target dynamic positioning data; If the data confidence level is the first confidence level, the target odometer data is assigned a fifth weight that is lower than that of the target dynamic positioning data, and the attenuation of the fifth weight is less than that of the second weight.

5. The control method for the UAV computing board as described in claim 1, characterized in that, The step of fusing the target odometry data, the target dynamic positioning data, and the weight matrix into an extended Kalman filter to obtain the pose estimate of the UAV at time n includes: The covariance matrix at time n-1 is read from the shared memory and used as the input of the extended Kalman filter in the prediction step at time n. The observation noise covariance of the target odometer data and the target dynamic positioning data are set according to the weight matrix, respectively. The prediction and update steps of the extended Kalman filter are executed to output the pose estimate of the UAV at time n.

6. The control method for the UAV computing board as described in claim 5, characterized in that, After executing the prediction and update steps of the extended Kalman filter and outputting the pose estimate of the UAV at time n, the process includes: Calculate the covariance matrix and the innovation residual at time n; The covariance matrix at time n and the innovation residual are stored in the shared memory. The covariance matrix at time n is used as the input for the prediction step at the next time step, and the innovation residual is used to trigger the adjustment of the weight matrix.

7. The control method for the UAV computing board as described in claim 6, characterized in that, After storing the covariance matrix at time n and the innovation residual into the shared memory, the process includes: At time n+1, if the information residual of a consecutive preset number of frames exceeds a preset 3σ threshold, a sensor operating condition abnormality flag is generated. In the next fusion cycle, the weight matrix of the next fusion cycle is updated according to the anomaly flag.

8. The control method for the UAV computing board as described in claim 7, characterized in that, Before updating the weight matrix of the next fusion cycle based on the anomaly flag in the next fusion cycle, the process includes: Obtain the processor load, memory usage, and core temperature of the computing board; When the processor load exceeds the first threshold, the memory usage exceeds the reserved water level, or the core temperature exceeds the second threshold, an anomaly flag is generated and written to the shared memory.

9. A control device for a drone computing board, characterized in that, The control device of the UAV computing board includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the control method of the UAV computing board as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the control method for the UAV computing board as described in any one of claims 1 to 8.

Images