Unmanned aerial vehicle automatic cooperative control method and system based on Internet of Things

Abstract

The invention relates to the technical field of cooperative management, in particular to an unmanned aerial vehicle automatic cooperative control method and system based on the Internet of Things. The method comprises the following steps: acquiring unmanned aerial vehicle communication data; performing flight attitude collision avoidance control based on the unmanned aerial vehicle communication data to obtain flight attitude collision avoidance data; performing collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; performing power consumption analysis based on the collaborative flight data to obtain power consumption data; performing battery aging detection according to the power consumption data to obtain battery aging data; performing battery structure damage detection based on the battery aging data to obtain battery structure damage data; performing flight path optimization according to the battery structure damage data to obtain optimized flight path data; and reconstructing a man-machine cooperative control task based on the optimized flight path data. According to the invention, the cooperative response rate and the control stability of the multi-unmanned aerial vehicle system in a complex task scene are improved based on a cooperative management technology.

Description

Technical Field

[0001] The present invention relates to the field of collaborative management technology, and in particular to an automated collaborative control method and system for unmanned aerial vehicles based on the Internet of Things. Background Art

[0002] Traditional UAV automated collaborative control systems usually rely on fixed preset control logic and lack adaptive control capabilities for dynamic changes in mission scenarios, making it difficult to achieve efficient collaborative response of multiple UAVs in emergency situations; they focus on flight path planning and obstacle avoidance control, and do not fully consider the impact of multi-dimensional factors such as the UAV's body status, energy consumption level, and structural health status on task allocation and collaborative control, which can easily lead to overload operation, task imbalance, or flight instability of some UAVs; in addition, in the process of multi-UAV collaboration, traditional systems have insufficient adaptability to fluctuations in communication links, and lack mechanisms for abnormal data synchronization, link breakage reconstruction, and collaborative failure warnings, resulting in reduced collaborative efficiency and even system paralysis in complex environments; there is a lack of intelligent analysis and role reconstruction mechanisms for the operating status of multiple UAVs, and it cannot dynamically adjust the responsibilities and control priorities between UAVs according to current mission requirements, flight status, and battery life, affecting the overall collaborative effect and system stability. Summary of the Invention

[0003] Based on this, it is necessary for the present invention to provide an automated collaborative control method and system for drones based on the Internet of Things to solve at least one of the above technical problems.

[0004] To achieve the above objectives, an automated collaborative control method for UAVs based on the Internet of Things is provided, comprising the following steps: Step S1: Acquire UAV communication data; perform flight attitude collision avoidance control based on the UAV communication data to obtain flight attitude collision avoidance data; perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; Step S2: performing power consumption analysis based on the collaborative flight data to obtain power consumption data; performing battery aging detection based on the power consumption data to obtain battery aging data; performing battery structural damage detection based on the battery aging data to obtain battery structural damage data; Step S3: Optimizing the flight path based on the battery structure damage data to obtain optimized flight path data; reconstructing the human-machine collaborative control task based on the optimized flight path data; generating a control instruction set based on the human-machine collaborative control task; performing flight control simulation based on the control instruction set to obtain flight control data; identifying instability risks based on the flight control data to obtain flight instability data; Step S4: Perform an airframe structure looseness analysis based on the flight instability data to obtain airframe structure looseness data; perform UAV collaborative role switching based on the airframe structure looseness data to obtain UAV collaborative role switching data, and upload the data to the UAV Internet of Things management platform to execute automated collaborative role control tasks.

[0005] The present invention achieves comprehensive perception and intelligent response to the communication status, flight attitude, battery health, flight path and control stability of drones by constructing a multi-level automated collaborative control process, breaking through the technical limitations of traditional systems that rely solely on fixed control logic and ignore the differences in individual drone states. In terms of communication, flight attitude collision avoidance control and collaborative flight simulation are carried out based on real-time communication data, effectively improving the path conflict identification accuracy and dynamic collision avoidance capabilities in multi-machine collaboration, and enhancing the system's adaptability and collaborative consistency to communication link fluctuations. In terms of energy consumption management, through real-time analysis of power consumption data during collaborative flight, not only can high-precision identification of battery aging status be achieved, but it also goes further into the detection level of battery structural damage, ensuring dynamic grasp of the health status of individuals in the drone group, and providing a solid data foundation for subsequent path optimization and role allocation. At the path planning level, the flight path is optimized according to the battery structural damage results, effectively avoiding high-load areas, preventing old battery bodies from undergoing overload flight missions, and realizing the collaborative coupling of path design and body status. In addition, by reconstructing the human-machine collaborative task and generating a control instruction set for the optimized flight path, combined with flight control simulation and instability risk identification, a full-chain closed-loop control mechanism from task setting to execution monitoring has been established, which has significant stability control capabilities in the face of emergencies. In terms of structural health detection, flight instability data is used to analyze the looseness of the aircraft structure, and based on the analysis results, intelligent switching of collaborative roles is carried out to achieve state-driven dynamic reconstruction of responsibilities, breaking the traditional fixed role allocation mechanism, ensuring that each drone assumes the optimal task role within its own capabilities, and improving the overall flexibility and adaptability of the collaborative system. Finally, the collaborative role switching data is uploaded to the Internet of Things management platform, and a multi-dimensional state-driven task reconstruction and collaborative execution framework is constructed. It has the ability to continuously online and autonomously optimize, fundamentally enhancing the system's operational stability, task allocation rationality, and multi-machine collaborative efficiency in complex environments.

[0006] Preferably, this specification also provides an Internet of Things-based UAV automated collaborative control system, which is used to execute the Internet of Things-based UAV automated collaborative control method as described above. The Internet of Things-based UAV automated collaborative control system includes: The collaborative flight simulation module is used to obtain UAV communication data; perform flight attitude collision avoidance control based on the UAV communication data to obtain flight attitude collision avoidance data; perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; The battery structure damage detection module is used to analyze power consumption based on collaborative flight data to obtain power consumption data; perform battery aging detection based on power consumption data to obtain battery aging data; and perform battery structure damage detection based on battery aging data to obtain battery structure damage data; The instability risk identification module is used to optimize the flight path based on the battery structure damage data to obtain optimized flight path data; reconstruct the human-machine collaborative control task based on the optimized flight path data; generate a control instruction set based on the human-machine collaborative control task; perform flight control simulation based on the control instruction set to obtain flight control data; identify instability risks based on the flight control data to obtain flight instability data; The collaborative role switching module is used to perform body structure looseness analysis based on flight instability data to obtain body structure looseness data; based on the body structure looseness data, the UAV collaborative role switching is performed to obtain the UAV collaborative role switching data, and the data is uploaded to the UAV Internet of Things management platform to perform automated collaborative role control tasks.

[0007] The Internet of Things-based UAV automated collaborative control system of the present invention can implement any one of the Internet of Things-based UAV automated collaborative control methods of the present invention, and is used to combine the operation and signal transmission media between various modules to complete the Internet of Things-based UAV automated collaborative control method. The internal modules of the system cooperate with each other to improve the collaborative response rate and control stability of the multi-UAV system in complex mission scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Other features, objects and advantages of the present invention will become more apparent upon reading the detailed description of non-limiting embodiments thereof made with reference to the following drawings: Figure 1 This is a schematic flow chart of the steps of an automated collaborative control method for unmanned aerial vehicles based on the Internet of Things of the present invention; Figure 2 Detailed step flow diagram of step S1 in the present invention; The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0009] The following is a clear and complete description of the technical method of the present invention in conjunction with the accompanying drawings. Obviously, the embodiments described are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative work are within the scope of protection of the present invention.

[0010] In addition, the accompanying drawings are merely schematic illustrations of the present invention and are not necessarily drawn to scale. Identical reference numerals in the figures denote identical or similar parts, and thus repetitive descriptions thereof will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities that do not necessarily correspond to physically or logically separate entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor and / or microcontroller approaches.

[0011] It should be understood that although the terms "first," "second," and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used solely to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the listed associated items.

[0012] To achieve this, please refer to Figures 1 to 2 The present invention provides an automated collaborative control method for unmanned aerial vehicles based on the Internet of Things, the method comprising the following steps: Step S1: Acquire UAV communication data; perform flight attitude collision avoidance control based on the UAV communication data to obtain flight attitude collision avoidance data; perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; In this embodiment, drone communication data is acquired via a LoRa (Long Range Low Energy Communication) chip installed in the drone's communication module. The communication frequency band is set to 433 MHz, the communication range is set to within 5000 meters, and the communication refresh rate is set to 5 Hz. This chip periodically collects data including the drone's current position, velocity, acceleration, heading angle, attitude angle (pitch, roll, and yaw), and timestamp. All drones must be integrated with an IMU (Inertial Measurement Unit), consisting of a three-axis gyroscope and a three-axis accelerometer, with a data refresh rate of 100 Hz. The drones synchronously upload their attitude and positioning data to a ground control terminal via LoRa communication. The ground terminal deploys an embedded Linux platform and runs a state-space-based collision avoidance control algorithm. This algorithm sets a collision avoidance safety threshold of 3 meters based on the relative distance between drones (calculated in meters using GPS positioning data) and the trend of attitude angle changes. If two drones are predicted to enter a 2-meter radius within 3 seconds, yaw adjustments are made based on the current velocity vector and attitude angle, with an adjustment angle of 15° to 45° to avoid overlapping flight paths. The resulting flight attitude collision avoidance data was structured and stored with a 0.2-second flight time interval. This data was then fed into a multi-drone collaborative simulation system, comprised of the PX4 simulation platform and the Gazebo physics engine. The system simulated at a 200Hz frequency, with a 200m×200m×50m area as the scene. The simulated wind speed was set to 1.2m / s, with a disturbance wind direction of 30°. The system then output collaborative flight data based on the collaborative trajectory, collision avoidance behavior, and synchronization time error of each drone in the simulation. The collaborative flight data contained information such as trajectory points, collaborative status identifiers, and control variable feedback along the simulation timeline. The data was structured as a JSON data stream, annotated with frame numbers and instruction sequences.

[0013] Step S2: performing power consumption analysis based on the collaborative flight data to obtain power consumption data; performing battery aging detection based on the power consumption data to obtain battery aging data; performing battery structural damage detection based on the battery aging data to obtain battery structural damage data; In this embodiment, parameters such as each drone's speed (in meters per second), flight altitude (in meters), payload weight (in kilograms), and flight time (in seconds) are extracted from the coordinated flight data acquired in step S1. Combined with current and voltage data collected during flight, power consumption analysis for each drone is performed using the power consumption calculation formula: Power Consumption = Current × Voltage × Time (in Wh). Current and voltage data are collected at a 1Hz frequency by the drone's onboard power management module (PMU), with a threshold set to a 500mA fluctuation range to consider current stable. Power consumption data is statistically analyzed using a sliding window every five minutes and stored in a two-dimensional matrix. Battery aging for each drone is determined based on the difference between the number of flights, the percentage of charge and discharge power per flight, and the ambient temperature (collected by an onboard temperature sensor, in °C) and the actual power capacity. The aging threshold is set to: a capacity drop exceeding 20% ​​of the initial value is considered mild, 40% is considered moderate, and above 60% is considered severe. The service life assessment formula is: Degree of aging = (rated capacity − current actual capacity) / rated capacity × 100%. For battery structural damage detection, a thermal imaging camera is used to sample the battery's thermal distribution, with a resolution of 640×480 and a sampling interval of 1 second. Image analysis algorithms (such as the temperature gradient method) are used to detect localized high-temperature areas on the battery surface. If the temperature difference exceeds 6°C and lasts for more than 10 seconds, the battery is identified as at risk of thermal damage. Simultaneously, combined with battery internal resistance measurement data, if the internal resistance exceeds 150mΩ (compared to the initial 50mΩ), it is flagged as structural damage, and a battery structural damage dataset is generated, including information such as damage type, location, time, temperature difference, and resistance change.

[0014] Step S3: Optimizing the flight path based on the battery structure damage data to obtain optimized flight path data; reconstructing the human-machine collaborative control task based on the optimized flight path data; generating a control instruction set based on the human-machine collaborative control task; performing flight control simulation based on the control instruction set to obtain flight control data; identifying instability risks based on the flight control data to obtain flight instability data; In this embodiment, the battery structure damage data obtained in step S2 is analyzed to extract the remaining battery capacity, battery internal resistance, and damaged area information. Based on this data, during the flight path optimization process, the path optimization objective function is set to minimize energy consumption, with the following constraints: a maximum climb altitude of 50m, a maximum descent angle of 30°, a flight radius not exceeding 500m, and a single-segment flight distance not exceeding the distance supported by the current remaining battery power (calculated at 0.15Wh / m). Severely damaged drone paths are removed from high-load areas, and short-distance paths are prioritized. The path node resolution is set to one path node every 10 meters, and the output after path optimization is the optimized flight path data. Subsequently, based on this path data, the human-machine collaborative control task is reconstructed according to the mission requirements (such as monitoring, filming, and delivery), and mission parameters such as the mission ID, mission execution start and end time, target coordinates, path priority, and flight attitude requirements are defined. Based on this control task parameter set, a control instruction set was generated. These included heading angle adjustment commands (with 1° accuracy), velocity adjustment commands (with a minimum unit of 0.1 m / s), flight mode switching commands (e.g., cruise / hover / turn), and power adjustment commands (in W). This control instruction set was uploaded to a simulation system (using QGroundControl + SITL) for flight control simulation. The simulation environment remained consistent, and the path was repeated five times to output a flight control data set. During flight control data analysis, flight stability indicators (such as attitude angle fluctuation amplitude, control input delay, and thrust output asymmetry) were recorded to identify flight instability risks. The instability criteria were set as follows: continuous attitude angle fluctuations exceeding 5° across all three axes for more than two seconds, thrust asymmetry exceeding 20%, and response delay exceeding one second. This constituted flight instability, and flight instability data, including the location, time, attitude angle amplitude, velocity vector, and thrust difference, were recorded.

[0015] Step S4: Perform an airframe structure looseness analysis based on the flight instability data to obtain airframe structure looseness data; perform UAV collaborative role switching based on the airframe structure looseness data to obtain UAV collaborative role switching data, and upload the data to the UAV Internet of Things management platform to execute automated collaborative role control tasks.

[0016] In this embodiment, the flight instability data identified in step S3 is analyzed to extract key indicators such as instability frequency, instability occurrence time, abnormal flight attitude angle, aircraft vibration data (using a vibration sensor, frequency 10 Hz, unit: g), and instability duration. Based on these indicators, a fast Fourier transform (FFT) is performed on the vibration data using frequency domain analysis to determine whether there are significant resonant frequency peaks (e.g., peaks in the 20-40 Hz range exceeding three times the baseline vibration). Combined with the flight attitude anomalies, looseness in the arm, propeller, or motor mounting structure is inferred and determined to be structurally loose. If the structural vibration deviation of a component exceeds ±0.05 g, it is marked as mild looseness; if it exceeds ±0.1 g, it is marked as severe looseness. The structural looseness data is recorded and organized into a structured dataset containing structural location, vibration frequency, vibration amplitude, and an associated flight instability number. Subsequently, role switching rules are set based on the UAV's original role in the collaborative mission (e.g., master control node, path guidance node, camera task node, etc.) and its detected structural status. If the master control node is severely unstable and the communication delay is greater than 0.5 seconds or the task response delay exceeds 1 second, it will automatically downgrade to a general node. At the same time, a node with high attitude stability and response delay less than 0.2 seconds will be selected from the backup nodes for replacement. The generated role switching data includes the original role, new role, switch trigger time, status parameters, and command changes. All role switching data is uploaded to the drone management platform deployed on the Alibaba Cloud IoT platform via the MQTT protocol. The data format is a JSON message with a timestamp and the identifier is DroneRoleChange. It serves as the basis for automated collaborative control task switching. The cloud sends the final control strategy instructions to each terminal to execute the drone.

[0017] Preferably, step S1 is specifically as follows: Step S11: Acquire drone communication data; In this embodiment, obtaining drone communication data requires deploying a low-power wide-area communication module based on the IEEE 802.15.4 protocol. A LoRa (Long Range Radio) communication terminal is used to connect to a ground station. Each drone is equipped with a communication control module containing a u-blox M8 series GNSS chip and an ADIS16470 inertial navigation system. Communication data is uploaded to the IoT architecture in real time via the MQTT protocol. The data format includes a timestamp (in UTC), location information (longitude, latitude, and altitude in meters), velocity information (in meters per second), heading angle (in degrees relative to true north), pitch and roll angles (in degrees), and communication signal strength (RSSI, in dBm) for each channel. When acquiring data, the sampling period is fixed at 100ms. All data is uploaded to the central processing node of the base station through an encrypted channel and written to a log file named UAVCommData_YYYYMMDD.log. The log file is automatically generated every day according to UTC time and stored in a distributed database (such as TimescaleDB) for subsequent analysis.

[0018] Step S12: determining the flight status based on the UAV communication data and obtaining flight status data; In this embodiment, flight state determination is performed based on acquired communication data. The parsed drone attitude data is converted to Euler angles using quaternions. Yaw, pitch, and roll angles are calculated using coordinate conversion formulas and fused with the GNSS velocity vector. The flight state is defined as a six-dimensional state vector S = [x, y, z, vx, vy, vz], where [x, y, z] represents the current position coordinates (latitude and longitude converted to Cartesian coordinates using the WGS84 model, with the origin at the base station), and [vx, vy, vz] represents the current velocity vector in meters per second. The flight state also includes the track deviation angle α, calculated as the angle between the current heading and the target heading, with a range of [-180° to 180°]. To ensure the integrity of the state information, the flight data time series is smoothed using a sliding window averaging method with a window size of 5 time steps and a time step length of 100ms. The final generated flight status data is stored in JSON format with the following structure: {"ID": drone number, "position":[...], "velocity":[...], "yaw": value, "pitch": value, "roll": value, "alpha": value}.

[0019] Step S13: Calculating the relative motion vector according to the flight status data; In this embodiment, relative motion vector calculation is performed based on the flight status data of two or more drones. The relative motion vector between each pair of drones is defined as R = [Δx, Δy, Δz, Δvx, Δvy, Δvz], where Δx = x² - x¹ and Δvx = vx² - vx¹, representing the relative position difference and velocity difference between the two drones, respectively. To improve accuracy, coordinate transformations must be unified to the same geographic reference frame, using the ENUA local reference coordinate system. After calculation, the relative distance D_r = sqrt(Δx² + Δy² + Δz²), and the relative velocity V_r = sqrt(Δvx² + Δvy² + Δvz²). If any D_r < 20m and V_r > 3m / s, it is marked as a high-risk relative vector. All calculation results are stored in a matrix structure: each row records the drone pair number, relative vector value, relative distance, relative velocity, and a timestamp field. This process is automatically executed by a MATLAB script, in which a loop structure is set to match all drone pair combinations at each moment, a total of N(N-1) / 2 groups.

[0020] Step S14: identifying a collision risk area based on the relative motion vector; In this embodiment, the identification of collision risk areas is performed based on the aforementioned relative vector calculation results, and a static prediction method is used for near-time domain trajectory extrapolation. Assume that the current drone position is P0, the relative speed is V_r, the prediction time T is set to 3 seconds, and the extrapolated position P1 = P0 + V_r * T. All predicted positions are plotted into the 3D spatial scene, and the safety radius R_s is set to 10m (industrial standard airspace spacing requirement). If the Euclidean distance between any two predicted points is less than 2R_s, it is defined as a potential collision risk area. The coordinates [x, y, z] of the collision area are written into the spatial grid map, each grid size is 5m×5m×5m, and the occupancy mark 1 is set. The map is stored in the form of a voxel grid, using the OctoMap format, with a resolution of 0.5m, and is used for the subsequent generation of attitude adjustment control quantities.

[0021] Step S15: Generate attitude adjustment control value according to the collision risk area to obtain flight attitude collision avoidance data; In this embodiment, the flight attitude collision avoidance control quantity is generated based on the aforementioned collision risk area and the current flight status. To ensure flight safety, the control instructions are calculated based on the force field obstacle avoidance method. First, the target position is set to P_goal and the current position is set to P_current, and the gravitational vector F_a=k_a*(P_goal-P_current) is generated. k_a is the gravitational coefficient, and its value is 1.0. Then, a repulsive force field is generated based on the risk grid point set, and the repulsive force F_r=Σ(k_r / d²)*u, where k_r is the repulsive coefficient, and its value is 5.0, d is the distance from the current position to each risk point, and u is the unit vector pointing from the risk point to the current position. The resultant force F_total = F_a + F_r. The direction of the resultant force is used to correct the attitude control angles. The pitch angle is adjusted to θ = atan²(F_total.z, sqrt(F_total.x² + F_total.y²)), and the heading angle is corrected to ψ = atan²(F_total.y, F_total.x). The control adjustments Δθ and Δψ are respectively used as inputs to the UAV flight control interface. The instructions are encapsulated in the structure format {"Delta_pitch": value, "Delta_yaw": value, "Timestamp": time} and sent to the flight control system for execution. All calculations are executed by an embedded C program on the STM32F7 platform with a cycle time of less than 30ms.

[0022] Step S16: Perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data.

[0023] In this embodiment, the collaborative flight simulation is carried out in a multi-machine environment. The simulation platform uses Gazebo 11.0 version. Six homogeneous drones (model DJI Matrice 300 RTK) are deployed in the simulation scene. The communication architecture based on ROS (Robot Operating System) is adopted to achieve data synchronization between simulation nodes. The flight attitude collision avoidance data is input as the starting condition of the simulation, including the starting position, velocity vector, heading angle and attitude adjustment control amount. The simulation time step is set to 10ms, and the total duration is 60s. During the simulation process, the wind speed field (horizontal wind speed 3m / s, height gradient 0.2m / s / m) and turbulence disturbance parameters are imported using a standard meteorological model, and the disturbance amplitude is within the range of ±0.5m / s. The flight trajectory and status of all drones are published through the ROS topics / uav_i / pose and / uav_i / state and recorded in the Bag file. After the simulation is complete, the flight status data for each drone per second is extracted from the bag file to construct a 3D collaborative flight dataset, including 3D trajectories, velocity vectors, attitude angles, collision avoidance adjustment records, and collaborative status labels. The final data is saved in HDF5 format with a fixed field structure, including timestamp, aircraft number, coordinate vector, velocity vector, attitude vector, and obstacle avoidance status. The simulation results are uploaded to the flight simulation module in the IoT management platform for subsequent mission generation and control evaluation.

[0024] Preferably, step S15 is specifically as follows: Step S151: collecting relative heading angles according to the collision risk area to obtain relative heading angle data; In this embodiment, after detecting a collision risk area, the relative heading relationships between multiple drones within the area need to be analyzed. Specifically, based on the real-time heading angle data provided by each drone's inertial navigation system (INS) and global navigation satellite system (GNSS) module, a sampling period of 100 milliseconds is set. During each sampling period, heading information, including the absolute heading angle (with true north as the reference point of 0°) and the flight velocity vector, is collected. This data is broadcast synchronously via IoT communication nodes (such as LoRa or UWB wireless communication modules) in the 2.4 GHz frequency band. The flight controller calculates the difference between the three-dimensional coordinate point position difference and the heading angle, using the vector cosine method formula (cos(θ) = (A·B) / (|A||B|)) to calculate the current heading angle θ between the two drones, which is the relative heading angle. To ensure data accuracy, the heading angle is calibrated using a six-axis gyroscope and magnetometer, with an upper limit of ±1.5° for heading angle measurement error. Finally, a relative heading angle data table in a structured format is generated in the local flight control node. The fields include the participating drone ID, timestamp, heading angle difference (in degrees), and spatial relative distance (in meters).

[0025] Step S152: Calculating the minimum collision avoidance deflection angle based on the relative heading angle data; In this embodiment, after obtaining the relative heading angle data, the minimum deflection angle is calculated based on the collision avoidance algorithm to avoid the risk of collision. In specific implementation, the collision avoidance activation threshold is set to the relative distance between the two drones being less than 20 meters and the heading angle θ being less than 15° (indicating that the two drones are tending to fly in the same direction). At this time, the collision avoidance logic is activated. It is based on a rule set approach and does not adopt a neural network model. A collision prediction time window of 3 seconds is used. Based on the flight speed (obtained by the GPS module with an accuracy better than 0.3m / s) and direction of the two drones, trigonometric functions are used to predict the future position difference ΔP. To ensure the feasibility of the minimum deflection angle, the maximum deflection angle Δθ_max is limited to no more than 45°. Using the principle of geometric vector offset, the deflection angle is gradually evaluated in units of 1° from 15° to the left of the current heading to 15° to the right. The minimum angle that can make the predicted position difference ΔP greater than 10 meters is selected as the minimum collision avoidance deflection angle Δθ_min. Finally, a minimum deflection angle data record table is formed, which contains information such as the reference drone ID, the referenced drone ID, the current heading, the recommended deflection angle, and the timestamp.

[0026] Step S153: Decomposing the flight attitude control amount according to the minimum collision avoidance deflection angle; In this embodiment, converting the minimum collision avoidance deflection angle Δθ_min into specific flight attitude adjustment commands requires decomposing the control variables for the aircraft's three attitude axes: roll, pitch, and yaw. During implementation, the current attitude is calculated using the attitude calculation module embedded in the flight control system (using quaternions or the direction cosine matrix (DCM) method), with an initial control period of 50ms. While maintaining constant altitude and speed, only the yaw angle is adjusted to achieve heading adjustment, with the yaw angle response rate limited to a maximum of 10° per second. Specifically, a PID controller sets the yaw angle control target to the current yaw angle plus Δθ_min, with the error being the difference between the target angle and the current angle. The yaw angle adjustment is calculated using the proportional coefficient Kp = 1.8, the integral coefficient Ki = 0.04, and the differential coefficient Kd = 0.3. This adjustment is encoded in the flight control system as a rudder deflection command or a brushless motor speed difference control signal, which is used to drive the aircraft's heading adjustment, thus completing the specific decomposition of the control variables.

[0027] Step S154: generating a flight control instruction based on the flight attitude control value; In this embodiment, after obtaining the control variable, corresponding low-level flight control instructions are generated to perform aircraft attitude adjustments. In implementation, the flight control system uses a flight control main unit based on the STM32F7 series chip, with control tasks scheduled via a real-time operating system (RTOS). Flight control instructions are encoded in a 32-bit data packet format. Each instruction contains the control surface control channel number (e.g., yaw channel number 03), the control target value (PWM pulse width in microseconds, ranging from 1000-2000 μs), a valid flag, and a timestamp. Yaw adjustment instructions are linearly mapped to the PWM control range based on the PID control calculation results. The base value is set to 1500 μs, corresponding to the neutral point, and the control increment ΔPWM = Δθ × 10 (i.e., 1° corresponds to a 10 μs adjustment). However, the control margin is set to no more than ±300 μs to prevent flight instability caused by excessive control. Control instructions are refreshed every 20 ms and sent to the servo driver module or motor electronic control module to control steering. The command data is also recorded in the EEPROM for subsequent traceability.

[0028] Step S155: Perform real-time control of the attitude collision avoidance angle based on the flight control instruction to obtain flight attitude collision avoidance data.

[0029] In this embodiment, after control command generation is complete, the real-time attitude control task is initiated in the flight control system. The IMU module (which includes an accelerometer, gyroscope, and magnetometer) updates the attitude solution every 5 ms and subtracts it from the target heading angle to obtain the heading error e_ψ. The control system adjusts the yaw angle using the real-time control variable output by the PID controller. The yaw value is then fed back to the system status via the servo or electronic speed controller. During the control process, a maximum adjustment window of 2 seconds is set. During this window, the current attitude, velocity, acceleration, heading angle, and their rate of change are collected every 100 ms to form an attitude collision avoidance control data structure. Each data record contains: a timestamp, the current yaw angle, an attitude stability index (calculated from the standard deviation of the roll and pitch angles), a heading change rate (in degrees per second), the target heading angle, and the current predicted distance to the collision zone (in meters). This data is transmitted to the upper-level decision-making system via the CAN bus and simultaneously saved to a local SD card for subsequent collaborative flight analysis. Ultimately, a complete flight attitude collision avoidance data sequence is generated, enabling full-process recording and control feedback of the aircraft's collision avoidance status.

[0030] Preferably, the power consumption analysis in step S2 is specifically as follows: Extract spatial location information based on collaborative flight data; In this embodiment, in the collaborative flight system, position information is obtained by installing a high-precision RTK-GNSS module on each drone. The module uses the ZED-F9P type and the sampling frequency is set to 10Hz, that is, 10 sets of three-dimensional spatial coordinate data are collected per second. Each drone is bound to a unique device number and has a built-in LoRa wireless communication module for sending data to the control center in real time. The data collected by the GNSS module includes fields such as longitude, latitude, elevation, acquisition time, and signal accuracy level. All data is uniformly connected to the edge computing node through a gateway device, pre-processed, and written to the database. In this process, the timestamp requirements of the data are strictly controlled to ensure that the master node clock synchronization error is less than 50 milliseconds. Data that exceeds the error range is directly marked as invalid and eliminated from the subsequent processing flow to ensure the timeliness and accuracy of the spatial position information.

[0031] Performing time synchronization processing based on the spatial position information to obtain time-synchronized spatial position information; In this embodiment, after the collected spatial position information enters the processing system, it is first time-aligned according to the unified time standard provided by the master control node. The data of all drones are converted to the UTC time format, and the original timestamps of different source devices are uniformly corrected to the system standard time. If a drone is missing data at a certain moment, the processing system will automatically calculate the estimated position information of the missing time point from the data of adjacent time points and write a repair mark. The maximum allowable time difference is set to 10 milliseconds during the processing process, and all data exceeding this threshold will trigger a resynchronization instruction. The synchronized data is centered on the time axis, and the spatial coordinates of all drones at each time point are integrated into a unified data table to facilitate subsequent trajectory reconstruction operations.

[0032] Sorting trajectory points based on time-synchronized spatial position information to obtain the UAV flight trajectory; In this embodiment, all time point data of each drone are arranged in chronological order through the processed time-synchronized spatial data to form a continuous trajectory data set. The sorting method uses a stable comparison algorithm to ensure that the timestamp of each record is strictly increasing. The sorted results are stored in a structured text format, and each record includes the device number, standard timestamp, longitude, latitude, and elevation three-dimensional coordinates. Any data segment where the distance between any two points exceeds a reasonable range is marked as an anomaly (for example, the speed corresponding to the distance between the two points is much higher than the maximum flight capability of the aircraft), and the jump point is marked in the trajectory sequence for subsequent analysis. The generated trajectory files will be archived separately according to the drone number and form a time series structure at intervals of 10Hz.

[0033] Calculate the flight speed according to the UAV flight trajectory and obtain the flight speed data; In this embodiment, after obtaining the trajectory data, the processing system will calculate the flight speed of the time period based on the spatial position changes between two adjacent time points. Since the trajectory data sampling interval is 0.1 seconds, the speed of movement in the time period can be directly derived by the spatial change between consecutive sampling points. To ensure the validity of the data, the system sets a speed jump detection threshold, which is set by default to no more than 10 meters per second. If the flight speed suddenly increases and exceeds the threshold within a certain time period, it is judged as an abnormality and a mark is triggered. All speed data is stored in an independent speed data table with each time point as the recording unit. Each record contains the device number, timestamp and corresponding speed value. To enhance data integrity, the speed sequence is smoothed every ten seconds to remove mutation points.

[0034] Calculate the flight altitude according to the UAV flight trajectory and obtain the flight altitude data; In this embodiment, flight altitude data is extracted from the elevation field in the trajectory. GNSS altitudes are ellipsoidal heights and need to be converted to geodetic heights using ground-referenced elevation data in a geographic information system (GIS). During this conversion, the local DEM (digital elevation model) of the deployment area is used as a reference, and the ground-referenced elevation is subtracted from the GNSS altitude to obtain the true flight altitude. For example, if the drone's original altitude at a certain location is 123 meters and the ground reference at that point is 16 meters, the actual flight altitude is 107 meters. This processing is performed in batch mode within the system, with each batch processed at a 1-second interval. After processing, a flight altitude time series file is generated. Each record in this file contains the standard time, the drone ID, and the converted true flight altitude. Records with an altitude change rate exceeding a reasonable value (e.g., an altitude change exceeding 15 meters per second) are automatically identified and recorded as abnormal.

[0035] Estimate energy consumption per unit time based on flight speed data and flight altitude data; In this embodiment, based on speed and altitude data, the system calculates power consumption at each time point using a table lookup method. This table is based on a preset flight power consumption data table, derived from actual flight experiments. This table lists energy consumption values ​​for different speed ranges (e.g., 0-5 m / s, 5-10 m / s, 10-15 m / s) and altitude ranges (e.g., 50-100 m, 100-150 m, and 150-200 m). For example, when the drone is at a speed of 12 m / s and an altitude of 130 m, the system searches the table for the corresponding power level and returns the energy consumption per unit time for this combination of conditions. The unit energy consumption value (in watt-seconds) at each time point is recorded in a database table named "unit_energy_profile." Each entry includes a timestamp, drone ID, speed value, altitude value, and the corresponding power consumption value for that state. This table is pre-populated by the flight control test platform and is not dynamically generated.

[0036] The cumulative power consumption of the entire flight trajectory is calculated based on the energy consumption per unit time to obtain the power consumption data.

[0037] In this embodiment, after obtaining the unit energy consumption data at all time points, the system accumulates all the power consumption data one by one in chronological order to obtain the power consumption results of the entire flight process. This operation is performed on the edge server, and the batch processing window is set to 10 seconds. The energy consumption in each time period is accumulated and the current power consumption value of the drone is updated. All cumulative values ​​are uniformly converted into watt-hour units and stored in the "cumulative_energy_profile" database table. Each record contains the device number, the start and end time of the statistical time period, the cumulative energy consumption of the period, and the corresponding cumulative total power value. The cumulative power calculation does not use any model, but is implemented by a value-by-value superposition method supported by hardware test data. The final power consumption file is used to generate energy consumption trend curves, endurance estimation, and mission planning.

[0038] Preferably, the battery aging detection in step S2 is specifically as follows: screening high power consumption batteries according to the power consumption data, and performing a pulse load response test on the high power consumption batteries to obtain pulse load response data; In this embodiment, based on cumulative energy calculations, the system calculates the total energy consumption of each drone during its mission cycle and compares this value with the standard energy consumption range for drones in the same batch. This standard range is determined by averaging 100 flight records of the same battery model under the same mission environment and setting upper and lower limits. If the energy consumption during a single mission exceeds the standard upper limit by 20%, the corresponding battery is marked as a high-energy-consumption battery. For example, the standard energy consumption of a certain drone model at an altitude of 200 meters and a speed of 12 m / s is 420 Wh, with an upper limit set at 504 Wh. If the single-mission consumption is 520 Wh, the battery is marked as a high-energy-consumption battery. For these marked batteries, the control system removes them from normal use after charging to 80% SOC and connects them to a pulse load tester via the BMS (battery management system). The pulse load test uses a fixed current load module (Chroma 6310A) with a test current pulse of 10 A, a pulse width of 2 seconds, and an interval of 5 seconds, for a total of 10 pulses. During the test, the instantaneous voltage value, voltage stability value, current change and timestamp before and after each pulse loading are recorded. All data are collected at 10ms intervals through the CAN interface and saved in CSV format. Each line of record contains the pulse number, initial voltage value, final voltage value, current value and load duration.

[0039] Extracting voltage drop characteristics based on pulse load response data to obtain voltage drop data; In this embodiment, after obtaining the complete pulse response data, the processing system extracts the voltage difference at the initial moment of each group of pulse current loading as the voltage drop feature. The extraction method is to take the difference between the voltage average value in the last 10ms before loading and the voltage average value in the first 20ms after loading from each group of data to avoid instantaneous fluctuation errors caused by sampling jitter. If jitter or obvious abnormal fluctuations (i.e., the standard deviation is greater than 0.05V) appear after loading in a group of pulse responses, then this group of data will be eliminated and not included in subsequent processing. Finally, each battery generates a set of voltage drop data sets, including the drop amplitude (in volts), drop time point (accurate to milliseconds), current value and other information under each pulse. It is recorded in the database in a tabular form, and the structure includes fields such as battery number, pulse number, voltage drop amplitude, current intensity, and loading time. This voltage drop data set is used for subsequent internal resistance calculations without fitting or modeling.

[0040] Calculate the internal resistance change rate based on voltage drop data; In this embodiment, the voltage drop data under each pulse load condition is directly divided by the known load current to obtain the equivalent battery internal resistance value (in ohms) at that point in time. For example, if the drop voltage is 0.25V and the load current is 10A, the equivalent internal resistance is 0.025Ω. The internal resistance values ​​from 10 sets of tests are averaged to obtain the current average equivalent internal resistance of the battery. To calculate the internal resistance change rate, this value is compared with the standard internal resistance of a new battery of the same model under the same pulse conditions. The standard value is the average internal resistance of 10 manufacturer's sample batteries under the same test process. For example, if the standard for a new battery is 0.018Ω and the average value of the current battery is 0.025Ω, the internal resistance change rate is calculated as (0.025-0.018) / 0.018 = 0.388, which means an increase of 38.8%. All change rate data is recorded in the "battery_impedance_profile" table, with fields including battery number, test date, average internal resistance, standard internal resistance, and change rate.

[0041] Determine the degree of degradation of battery electrode activity based on the internal resistance change rate; In this embodiment, the degree of degradation is divided by the grading threshold value based on the internal resistance change rate data, and the specific threshold values ​​are set as follows: when the internal resistance change rate is less than 10%, it is defined as no degradation, 10%-30% is mild degradation, 30%-60% is moderate degradation, and greater than 60% is defined as severe degradation. This threshold is determined based on the laboratory's actual measurement statistics of 300 lithium batteries with different usage cycles, and is obtained by physical disassembly to verify the internal resistance change rate corresponding to the electrode state. The system directly matches the corresponding gear according to the internal resistance change rate value of each battery, and generates a field "active status". The value of this field is: 0 for no degradation, 1 for mild, 2 for moderate, and 3 for severe. All matching results are added to the battery performance diagnostic table, recording the battery number, active state, test time, original internal resistance value, change rate and reference standard value for subsequent use.

[0042] Evaluate the integrity of the electrode interface connection based on the degree of degradation of the battery electrode activity; In this embodiment, after clarifying the level of the electrode activity state, the system further determines the level of electrode interface connection integrity based on the empirical correspondence table. The reference values ​​are set as follows: when the activity state is 0 or 1, the interface integrity is "complete", when it is 2, it is "slightly desorbed", and when it is 3, it is "severely desorbed". This correspondence is derived from the systematic comparison of the adhesion change between the electrode and the current collector and the interface desorption phenomenon in the battery disassembly experiment. The evaluation results are written into a database table named "electrode_interface_profile", and the fields include battery number, activity level, connection integrity (complete / slightly desorbed / severely desorbed), and test date. The system does not perform any judgmental reasoning, but only directly corresponds to the evaluation according to the table lookup results. All evaluations can be traced back to the original internal resistance change rate and interface observation records.

[0043] Conduct electrode peeling detection based on the integrity of the electrode interface connection to obtain electrode peeling data; In this example, for batteries whose interface integrity was assessed as "severe desorption," an additional vibration test was performed to confirm whether actual physical delamination of the electrode occurred. The test was performed using a standard vibration device (model IMV J260) set to a sinusoidal sweep with a frequency range of 20Hz-2kHz. The test lasted 30 minutes, with the temperature maintained at 25°C, and the battery placed in a triaxial fixture. After the vibration test, a pulse load test was performed again to observe whether there was a significant voltage jump or increased jitter. If the instantaneous voltage drop in a single pulse increased by more than 15% compared to the initial test, the electrode was considered to have delaminated. This judgment standard was developed through laboratory validation and relies on the repeated stability of the difference in pulse response data before and after vibration exceeding a specific threshold. The electrode delamination judgment results are recorded in the "electrode_delamination_data" table. The fields include the battery number, the maximum voltage drop difference before and after the vibration test, the number of voltage jumps, and whether it was determined to be delamination (1 / 0).

[0044] The battery aging is determined based on the electrode stripping data to obtain the battery aging data.

[0045] In this embodiment, in the "electrode_delamination_data" table, all batteries marked as being in the stripped state are automatically identified as entering the deep aging stage. The system combines additional indicators such as the battery's flight usage cycle (accumulated discharge times greater than 200 times) and the voltage platform drop (the average platform of the last five charge and discharge cycles is more than 5% lower than the nominal value) to determine whether to enter the elimination process. Batteries that meet all of the above conditions are written to the "battery_aging_status" table and marked as aging level 3 (severe aging); if only some conditions are met (such as no stripping but an activity level of 3 and a cumulative usage cycle of more than 300 times), they are marked as level 2; those with no obvious signs of aging but a usage cycle of more than 200 times are marked as level 1. The table structure includes fields such as battery number, aging level, total number of cycles, voltage platform average value, maximum voltage jump, stripping determination result, activity level, etc., which serve as the basis for maintenance and replacement of the battery management system.

[0046] Preferably, the battery structure damage detection in step S2 is specifically as follows: Calculate the volume of the electrode material based on the battery aging data to obtain the volume data of the electrode material; In this embodiment, detailed operational data is collected from the battery aging process. This data includes the number of battery cycles, the voltage-current curve during each charge and discharge process, the capacity retention rate, and the changes in the open-circuit voltage plateau at different stages of the cycle. This data is recorded by a multi-channel, high-precision voltage and current acquisition module deployed in the battery pack. The data sampling frequency is set to 1Hz to ensure that every cycle is fully recorded. After acquisition, this aging data is combined with the battery physical structure analysis process. An industrial-grade blue-light 3D scanning system, model ATOS Core 135, is used to perform non-contact 3D scanning of the battery casing and internal structure. The scanning system is set to a resolution of 20 microns, and the scan data is exported as a point cloud format. The point cloud data is then reconstructed using a voxelized grid reconstruction algorithm implemented in the scanning device control software. Initial structural contour parameters of the positive and negative electrodes are imported based on the original battery design drawings. The drawings contain precise data for the thickness of the positive electrode sheet of 120 microns and the negative electrode sheet of 80 microns. During the point cloud voxelization process, the parameters of the boundary extraction algorithm are set as the boundary grayscale gradient threshold of 15 and the boundary minimum closed contour area threshold of 1 square millimeter to ensure accurate extraction of the electrode material boundary area. After calculating the height difference of all point cloud data within the boundary, combined with the point spacing and the scanning area range, a layer-by-layer stacking method is used to directly generate the actual three-dimensional structure model of the electrode area without introducing an analytical formula. The original structural parameters are compared with the current volume reconstruction structure, and the local electrode thickness change at each location is obtained by point-to-point difference, thereby accumulating the actual volume data of the electrode material. All generated data are stored in a structured manner in a temporary cache area of ​​the local server, and then uploaded to the database deployed in the IoT edge computing node in CSV format. The database fields include scanning time, electrode type, volume data number, point coordinate range and volume change value for continuous access in subsequent working condition evaluation steps.

[0047] Determine electrode material bulging based on electrode material volume data to obtain electrode material bulging data; In this embodiment, based on the electrode material volume data generated above, a method for identifying abnormal regional volume changes is used to detect bulges. The volume growth threshold for the positive electrode material is set at 8% of the initial volume, and for the negative electrode at 10%. That is, when the volume change in the detection area exceeds this threshold, it is marked as a bulge area. The threshold selection is based on the statistical analysis results of 500 battery accelerated aging experiments conducted in the laboratory. Principal component analysis (PCA) is used to project and analyze the volume change distribution data of the electrode material to identify local abnormal volume offset points. During implementation, a two-dimensional grid is used to partition the battery plan, with each 10mm² area serving as the basic detection unit. The volume change of each unit is statistically determined. Once the volume of a local area exceeds the corresponding electrode threshold, its coordinate position is numbered and output to the "bulge area index table." Information such as the position coordinates, volume change percentage, and offset relative to the original value of each area is recorded in JSON format to form the electrode material bulge data.

[0048] Calculate the bulging deformation of the electrode material based on the bulging data of the electrode material; In this embodiment, after obtaining the electrode material bulge data, a refined local height scan of each bulge area is required to obtain its actual bulge deformation. Specifically, a high-precision laser interferometer, model Zygo NewView 9000, is used to measure the height of the identified bulge area point by point. The interferometer has a scanning resolution of 1 micron, and the scanning area is delineated based on the bulge coordinate data generated by the bulge detection in the previous stage. Before measurement, the design parameter document provided by the battery manufacturing stage must be imported. The document clearly lists the initial thickness values ​​of each electrode layer. Here, the total initial thickness of the positive and negative electrodes is used as a benchmark. During the measurement process, the acquisition instrument records a current height value at each bulge point. The current height value of each point is then directly calculated by numerically differencing the standard design thickness of the corresponding point. The difference is the bulge deformation. The deformation data of each point is mapped to its original two-dimensional coordinate position information by number, forming a two-dimensional deformation matrix containing the deformation values ​​of all bulge areas. This matrix is ​​constructed in the form of a two-dimensional array, with each element representing the local deformation corresponding to that position, and the unit is uniformly set to microns. To ensure data timeliness and subsequent tracking and analysis, the two-dimensional array is immediately accompanied by a collection timestamp after the record is generated, and is transmitted to the data master platform deployed in the UAV collaborative control system via the edge collection node. At the same time, the data is associated with the current battery module number and inspection batch number to achieve preprocessing preparation for subsequent deformation trend prediction and regional crack identification analysis.

[0049] The high deformation area is calibrated according to the bulging deformation of the electrode material; In this embodiment, a high deformation threshold is set based on the bulging deformation matrix. According to the battery safety standards and empirical data, the high deformation threshold of the positive electrode is set to 50µm and that of the negative electrode is set to 65µm. All deformation units in the two-dimensional array are classified and calibrated based on this standard. A region growing algorithm based on a connected domain is used to merge and identify multiple adjacent detection units that exceed the threshold, forming a block annotation of high deformation areas. The k-means clustering method is used to classify these areas according to the deformation level (for example, divided into three levels of 50–70µm, 70–100µm, and >100µm). The output format is an image heat map and a GeoJSON geographic annotation file, which annotates the boundary coordinates, maximum deformation value, average value, electrode type, and other data of each high deformation block to provide positioning indexes and target area constraints for crack detection.

[0050] Conduct electrode particle crack detection based on high deformation areas to obtain electrode particle crack data; In this embodiment, the electrode particles in the calibrated high deformation area are taken as the target, and microscopic imaging is performed on the electrode particles in the area. A scanning electron microscope (SEM) is used to scan the internal microstructure of the area layer by layer, with the magnification set to 2000 times and the resolution to 0.5µm. The crack boundary features are extracted by an image processing algorithm (based on Canny edge detection + morphological operation). The minimum width threshold for crack identification is set to 1µm and the minimum length is set to 3µm. If this condition is met, it is determined to be a valid crack. All crack location information, length, direction angle and area number are output as XML structured data. The crack density (number of cracks per unit area) is recorded in the database as a quantitative indicator for subsequent dendrite tracking analysis. At the same time, the crack image and numerical data are synchronously uploaded to the drone control system for the inspection equipment calibration database, and encrypted storage and remote call are performed through the Internet of Things platform.

[0051] Identify dendrite microchannels based on electrode particle crack data and obtain dendrite growth data; In this embodiment, based on the acquired crack data, it is identified whether there are penetrating microchannels to confirm the dendrite growth path. The crack boundary image spectrum is analyzed by Fourier transform to extract the crack branching structure characteristics. An analysis method based on fractal dimension is adopted, and the dimension threshold is set to 1.5. When the crack structure dimension is higher than this value and the boundary has a bifurcation feature, it is determined to have dendrite growth potential. Further combined with X-ray tomography (resolution 5µm), it is checked whether there is a high conductivity area in the crack. If the reflection characteristic intensity of metallic lithium is detected to be more than 3 times higher than the background noise (the reference intensity threshold is 240Gray), the presence of a dendrite structure is confirmed. The final output dendrite growth data includes the dendrite starting coordinates, length, direction, number of bifurcations, and number of penetration paths. The data is saved in a two-dimensional matrix and visual vector diagram format.

[0052] The degree of battery structure damage is determined based on the dendrite growth data to obtain battery structure damage data.

[0053] In this embodiment, based on the dendrite data, it is evaluated whether it has caused damage to the battery structure. First, the battery structure drawing information and the dendrite growth path data are combined to analyze whether it penetrates the diaphragm or the positive and negative electrode interfaces. If the dendrite end position is within the diaphragm thickness range (for example, the thickness is 30µm), and the dendrite length exceeds 25µm, it is judged to be a structural penetrating dendrite. At the same time, scanning acoustic microscopy (SAM) is used to analyze whether there are voids or layered structural changes in the dendrite growth area. If the reflection time difference exceeds 20ns, combined with the sound speed calculation, the void size exceeds 10µm, then the structure is judged to be damaged. All structural damage areas are numbered, and an association table is established for their location information, damage type, damage size, and corresponding dendrite number. Finally, a structural damage data table is formed, and a unique ID number is established on the Internet of Things platform for the drone to perform automatic battery replacement task scheduling and call.

[0054] Preferably, step S3 is specifically as follows: Step S31: Identify high-risk flight nodes based on battery structure damage data; In this embodiment, after obtaining the battery structure damage data, combined with the flight node information in the UAV mission track, the damage level data of the battery corresponding time period is matched node by node with the mission timestamp and location coordinates (latitude and longitude + altitude) as indexes. After the battery structure damage data is processed by the previous step, it is recorded at a time resolution of 0.1 seconds. Each time point corresponds to a damage index value, and the unit is a dimensionless score (for example, 0.0~1.0). The high-risk threshold is set to 0.7. When the damage index of a flight node corresponding to the time period is greater than the threshold, the node is determined to be a high-risk node. After the identification is completed, the spatial coordinate information of all high-risk nodes and their corresponding damage indexes are integrated to generate a high-risk node list, and written into a CSV format file, which is uploaded to the task scheduling control center by the Internet of Things gateway.

[0055] Step S32: identifying avoidable paths based on high-risk flight nodes; optimizing the flight path based on the avoidable paths to obtain optimized flight path data; In this embodiment, the list of high-risk nodes generated in step S31 is imported into the flight path avoidance module, and the dynamic path planning algorithm is called to perform obstacle avoidance reconstruction. This process relies on the constructed 3D track map, in which each flight cell is a spatial grid of 5m×5m×5m. In the process of planning the path, all grids where high-risk nodes are located are marked as inaccessible areas, and then the shortest feasible path is generated for the remaining areas. In the definition of path weight, the flight altitude change penalty (0.2 weight is increased for every increase of 1 meter), the steering angle penalty (0.3 weight is increased for each time it exceeds 45 degrees), and the distance cost function are considered. After the path calculation is completed, the optimized path data set containing the coordinates of the heading point, speed setting, and target altitude is output, stored in a structured JSON format, and synchronized to the drone flight control main control unit for use by the subsequent control simulation module.

[0056] Step S33: performing flight control simulation according to the control instruction set to obtain flight control data; In this embodiment, the optimized flight path data is imported into an embedded flight control simulation module, which has a complete six-degree-of-freedom dynamic control system simulation framework embedded in it. Based on each flight point in the optimized path, a control instruction set (such as target speed, pitch angle, yaw angle, and altitude) is extracted as an input signal, and the corresponding thrust adjustment instructions and attitude adjustment parameters are calculated through the control law. The PID controller parameters used in the control law are: the proportional gain is set to 1.2, the integral gain is 0.01, and the differential gain is 0.5. During the simulation process, the control signal is iterated with a time step of 10ms. Each iteration records key control data such as flight speed, displacement vector, attitude angle, and motor speed, and summarizes them to form a flight control data set. All of them are stored in floating-point form in the data cache module for subsequent processing.

[0057] Step S34: calculating the attitude change rate based on the flight control data; determining the gyroscope change trend according to the attitude change rate to obtain gyroscope change trend data; evaluating the attitude stability according to the gyroscope change trend data to obtain attitude stability data; In this embodiment, a continuous time series of pitch, roll, and yaw angles is extracted from the flight control data set. The angular change between two adjacent time steps is calculated and divided by the time interval to obtain the attitude change rate (in degrees per second). The attitude change rate series is used as input and compared with the actual internal gyroscope output (collected by the MPU-9250 gyroscope module at a 1kHz frequency). The mean and fluctuation amplitude are calculated using a sliding window width of 200ms. A change trend threshold is set: when the maximum fluctuation amplitude of a certain attitude change rate exceeds 15 degrees per second in 10 consecutive windows, the gyroscope change trend is determined to be unstable at that stage. This method outputs the time series gyroscope change trend data. In attitude stability analysis, the degree of attitude angle deviation is further evaluated. When the attitude angle exhibits irregular rotation or oscillation exceeding ±8 degrees per unit time, it is considered unstable. The corresponding moment is recorded as an attitude instability node, and an attitude stability data table (containing timestamps, coordinates, and instability type identifiers) is generated.

[0058] Step S35: Acquire wind speed data; perform gravity center offset evaluation on the attitude stability data based on the wind speed data to obtain gravity center offset data; perform flight control hysteresis detection based on the gravity center offset data to obtain flight control hysteresis data; In this embodiment, during flight, a wind speed sensor module (using an Ultrasonic Anemometer model Gill WindSonic) deployed on the lower portion of the drone acquires real-time wind speed data in the flight environment. The sampling frequency is set to 10 Hz, and each wind speed data point contains three components: X-direction wind speed, Y-direction wind speed, and vertical wind speed. The wind speed data is time-synchronized with attitude stability data. Using the flight platform's center of gravity parameters (statically calculated from a structural CAD model, with the center of gravity coordinates set 2 cm forward and 1.5 cm below the aircraft's central axis) as a reference, a weighted calculation is performed on the attitude angle mutation caused by wind speed disturbances to derive the center of gravity offset per unit wind speed. An empirical coefficient matrix (using regression fitting of experimental data, with wind speed offset influence coefficients set to 0.8 for horizontal, 0.5 for vertical, and 0.2 for vertical) is used to quantify the contribution of wind speed to the center of gravity offset, resulting in center of gravity offset data. Combined with the delay between the flight control command and the actual attitude change response (analyzed from the flight control response data, in milliseconds), when the time difference between the control command issuance and the attitude change exceeds 100ms, it is recorded as a flight control hysteresis point. This hysteresis information is combined with the center of gravity offset data to generate a flight control hysteresis dataset.

[0059] Step S36: Identify the instability risk based on the flight control hysteresis data and obtain flight instability data.

[0060] In this embodiment, during the flight control lag data analysis phase, a judgment matrix is ​​constructed using a combination of lag time and center of gravity offset. The instability judgment criteria are set: when the lag time exceeds 100ms within three consecutive control cycles (each cycle is 10ms), and the center of gravity offset exceeds 5cm in any direction, it is identified as a potential instability section. The entire flight sequence is scanned, all time periods that meet the above conditions are extracted, and each instability record is bound to the flight node ID and its location information to generate a flight instability data set. The data set structure includes key fields such as flight time, flight altitude, lag time, offset direction and offset. The generated flight instability data is uploaded to the flight safety analysis module in the Internet of Things system, and is used by it for dynamic collaborative path reconstruction and control strategy correction.

[0061] It is particularly important that step S36 includes the following steps: Step S361: Calculating the flight control command response time difference based on the flight control hysteresis data; In this embodiment, flight control command logs and aircraft attitude sensor data logs transmitted via the Internet of Things are acquired. Both require synchronized sampling timestamps, with a sampling frequency set to 200Hz to ensure millisecond-level accuracy. Each control command (e.g., pitch angle adjustment command) and its corresponding flight response time point are extracted. The delay between command issuance and response onset is calculated, defined as the response time difference. The minimum recognition granularity is set to 5ms, and the continuous data acquisition cycle is 60 seconds. The response corresponding to each command is determined by the first significant change in the slope of the attitude change rate (i.e., the response inflection point). A differential algorithm is used to identify the inflection point and subtract it from the control command time point to obtain the command response time difference. Using a 10-second window, the response time differences of all commands within the window are counted to generate a sequence of time differences as flight control command response time difference data, rounded to two decimal places, in milliseconds.

[0062] Step S362: Identifying a high-frequency delay pattern based on the flight control command response time difference; In this embodiment, the time difference sequence obtained in step S361 is imported into the delay pattern extraction module. The frequency distribution statistics of the time difference sequence of each 10-second sampling window are performed, and the delay is divided into intervals such as [0-10]ms, [11-20]ms, [21-30]ms, and [31-40]ms according to a grouping interval of 5ms. Patterns that appear more than 3 times in a row and are in a delay interval of more than 30ms are identified and defined as high-frequency delay events. The ratio of the number of instruction responses with a delay of more than 30ms in each group of sampling windows to the total number of instructions in the window is calculated. If the ratio exceeds 0.3, it is marked as a high-frequency delay window. Further, all high-frequency delay windows are aggregated on the time axis, and their positions and delay intervals are recorded to form high-frequency delay pattern data. In order to avoid misidentification, a sliding window method is adopted, with a sliding step of 5 seconds each time, and overlapping detection of the same time period.

[0063] Step S363: Determine the delay mode flight attitude based on the high frequency delay mode; In this embodiment, after identifying the high-frequency delay windows, flight attitude data that completely overlaps with these window time periods is extracted. Flight attitude data includes pitch, roll, and yaw angles, with an accuracy of 0.1°. All attitude sampling points within the high-frequency delay window are used as analysis targets, and the maximum rate of change (in degrees / s) and the average deviation of the three-axis angles are calculated. If the attitude change rate is greater than 20° / s, or the pitch angle fluctuates by more than ±15° within the window, the attitude data corresponding to the window is marked as a delayed mode flight attitude. All marked data are integrated into a delayed mode flight attitude dataset, recording parameters such as time, position, attitude change rate, and angle offset, and numbered in chronological order for subsequent dynamic stability verification.

[0064] Step S364: performing a dynamic stability check based on the delayed mode flight attitude to obtain flight stability evaluation data; In this embodiment, delayed mode flight attitude data is used for stability analysis. First, within each attitude sample segment, the angular velocity rate of change curve is fitted for the pitch, roll, and yaw axes, and the maximum derivative value is calculated as the instability indicator. If the angular velocity derivative of a certain axis exceeds 50° / s² for 0.5 seconds, the attitude segment is marked as "dynamically unstable." In addition, the dynamic stability scoring parameter StabIndex is set to 100-Σ(unstable segment duration × instability intensity factor), where the instability intensity factor is divided into three levels based on angular velocity derivatives greater than 50, 75, and 100° / s², with the factors set to 1.2, 1.5, and 2.0, respectively. With a sliding analysis window length of 1 second and a step size of 0.5 seconds, the entire flight process is scored to generate the StabIndex curve, and each window period below the set threshold of 65 is recorded. The final output includes flight stability assessment data containing the StabIndex score and the timestamp of the unstable segment.

[0065] Step S365: Identify the instability risk based on the flight stability assessment data and obtain flight instability data.

[0066] In this embodiment, instability risk identification is performed based on the StabIndex curve and unstable window records generated in step S364. The instability risk identification logic is: if the StabIndex is lower than 65 in three consecutive windows, and at least one window score is lower than 50, it is marked as moderate instability; if any two windows in the consecutive windows have a score lower than 40, it is marked as severe instability. The identification result is associated with the corresponding attitude data according to the timestamp, and the location information and real-time wind speed data (collected by the onboard barometric anemometer, frequency 10Hz, accuracy 0.1m / s) are added for horizontal verification. If the wind speed does not exceed 5m / s, external interference factors are excluded, and it is finally determined to be self-instability. The above results constitute the flight instability data, including the instability level, time range, corresponding attitude anomaly, external interference information and risk labels, and are packaged as JSON format data and uploaded to the drone Internet of Things management platform for subsequent risk avoidance module calls.

[0067] Preferably, step S33 is specifically as follows: Step S331: transmitting the control instruction set to the flight control simulation system; In this embodiment, the process of transmitting the control instruction set to the flight control simulation system requires first establishing a communication protocol for the control commands via a serial communication interface (such as RS-485 or CAN bus). The control instruction set is encoded by the flight path optimization module according to the flight attitude target, turn angle, speed change instructions, and propulsion system instructions. Each instruction includes a start flag, an instruction type field (a three-bit binary field indicating hovering, path tracking, or obstacle avoidance), a value field (including throttle value, attitude angle, pitch angle, roll angle, and heading angle), and an end check bit. The flight control simulation system uses an STM32F407 processor with an integrated DMA controller to receive this data stream and verify the legitimacy of the instructions through checksum analysis. The instruction set is stored in the system's instruction cache (64KB in size) and is called into the control instruction decoding unit by an independent interrupt trigger mechanism.

[0068] Step S332: setting the flight mission type to fixed-point hovering, path tracking, and obstacle avoidance flight in the flight control simulation system; In this embodiment, within the flight control simulation system, the mission type configuration interface is first loaded. Based on the preset mission classification structure, flight missions are divided into three categories: fixed-point hovering (mission code 001), path tracking (mission code 010), and obstacle avoidance flight (mission code 011). Configuration parameters are written into the system's task scheduler via programmable registers. Before each flight control simulation, the mission type is specified using a digital DIP switch or a companion PC control terminal. For the fixed-point hovering mission, the system calls the static flight PID controller; for the path tracking mission, the Bezier curve-based trajectory approximation algorithm module is activated; and for the obstacle avoidance flight mode, both the ultrasonic ranging interference processing module and the target detour path calculation module are enabled. Mission mode parameters are written into the flight control simulation system's main control registers and participate in solving the aircraft's equations of motion.

[0069] Step S333: In the flight control simulation system, the control surface deflection angle range is set to 15°-30°, the throttle opening range is set to 30%-100%, and the attitude angle control accuracy is set to 0°-0.5°; In this embodiment, the flight control simulation system sets specific ranges for the control accuracy of the flight control surface deflection angle, throttle opening, and attitude angle. During the simulation initialization phase, the initial range of the control surface deflection angle is set to 15° to 30°. The simulation system calls the linear interpolation module to generate 16 sets of angle sample data in 1° increments. The throttle opening is set to 30%-100%, and eight throttle opening test sequences are generated in 10% increments. The attitude angle control accuracy is controlled between 0° and 0.5°, with the accuracy divided into 0.1° units. This is set as the target error threshold parameter ε in the PID attitude control module, with a specific value of ε = 0.5°. All of these control range parameters must be written into the flight control system's attitude PID parameter table, the propulsion system management module, and the input parameter registers of the servomechanism simulation model, and participate in the integral iteration of the motion equation within the main control unit.

[0070] Step S334: In the flight control simulation system, set the crosswind disturbance to 0 m / s-8 m / s, the temperature to 10°C-45°C, and the air turbulence intensity level to 1-5; In this embodiment, to create realistic flight disturbance conditions, crosswind disturbance, ambient temperature, and airborne turbulence intensity parameters are set in the environmental disturbance module of the flight control simulation system. The crosswind disturbance setting range is 0 m / s to 8 m / s, with a graded disturbance test performed in steps of 2 m / s. The disturbance direction is randomly set in a 360-degree distribution, and a Gaussian white noise function is used to simulate instantaneous wind speed changes. The temperature setting range is 10°C to 45°C, with a simulated ambient temperature setting in steps of 5°C, for a total of eight temperature settings. Air density and buoyancy changes are calculated using the simulated ambient thermal coupling module. Airborne turbulence intensity levels are defined as levels 1 to 5. Turbulence excitation signals are assigned different amplitudes (0.1 g to 0.5 g) and frequencies (1 Hz to 10 Hz) according to the ICAO turbulence classification standard. A sinusoidal excitation superposition is used to inject these signals into the flight control system's disturbance input. Once these disturbance parameters are set, they are written into the parameter storage table of the simulator's disturbance management unit for input into the disturbance signal simulation module.

[0071] Step S335: In the flight control simulation system, the feedback delay is set to 10ms-200ms, the sensor sampling frequency is set to 50Hz-500Hz, and the simulation time step is set to 10ms-100ms; In this embodiment, the feedback delay and sensor sampling frequency in the flight control simulation system must be set in conjunction with the closed-loop response characteristics of the flight control. The feedback delay parameter setting range is 10ms to 200ms, specifically calculated by superimposing the simulated ADC / DAC interface transmission delay and the task queue waiting time within the controller, and a delay simulation matrix is ​​constructed with 50ms as the median value. The sensor sampling frequency range is 50Hz to 500Hz, corresponding to a sampling period of 2ms to 20ms. Based on the STM32F4 analog collector, the system sampling timer frequency is set, and the sampling frequency is switched and set using a PLL multiplication circuit. The simulation time step range is 10ms to 100ms. The time step register in the simulator's main clock cycle control unit is set, and five levels of simulation step options are generated with a fixed step size of 10ms and an increment of 20ms each time. The simulation calculation process is discretized using the Euler integral method or the Runge-Kutta method to ensure the stability of the iterative calculation of the flight state under the simulation time step.

[0072] Step S336: Run the aircraft control response module in the flight control simulation system and output flight control data.

[0073] In this embodiment, after completing the aforementioned parameter settings, the flight control simulation system runs the aircraft control response module. This module consists of three parts: a command reception module, a controller simulation module, and a flight dynamics simulation module. The command reception module periodically receives control commands by configuring an interrupt vector table. The controller simulation module loads the configured PID, LQR, or gain-scheduled controller and periodically updates it based on the configured feedback delay and sensor sampling frequency parameters. The flight dynamics simulation module uses a six-degree-of-freedom dynamics model to convert control inputs into forces and torques, and calculates velocity and attitude angles using the inertial navigation module. Output flight control data includes three-axis attitude angles (pitch, roll, and heading, with an accuracy of less than 0.1°), three-axis angular velocity (rad / s), position coordinates (longitude, latitude, and altitude), velocity vector (m / s), and control output signals (throttle percentage, control surface angle, etc.). All output data is written to the flight control data buffer (64KB) with a 10ms sampling period and exported via a USB interface for subsequent attitude analysis and stability assessment.

[0074] Preferably, step S4 is specifically as follows: Step S41: extracting flight attitude disturbance features according to the flight instability data to obtain flight attitude disturbance data; In this embodiment, after executing a simulated flight mission in a flight control simulation system, the real-time data output by the IMU (Inertial Measurement Unit) in the flight control log is read to extract the three-axis accelerations (ax, ay, az) and three-axis angular velocities (ωx, ωy, ωz). The data is formatted as a time series with a fixed sampling frequency of 200 Hz. This data is input into a cascade of a high-pass filter (with a cutoff frequency set to 1 Hz) and a Kalman filter to remove low-frequency drift and measurement noise. The processed signal is then segmented using a sliding window technique with a window length of 1 second and a 50% overlap. Within each segment, the attitude data is integrated from the raw angular velocities using the quaternion-to-Euler angle transformation formula to obtain the Euler angles (pitch, roll, and yaw). The rate of change of each Euler angle within the time window is calculated using linear differentiation, and the attitude disturbance features are then extracted using the standard deviation function. The attitude disturbance features for each segment are organized into a three-dimensional vector set, which represents the flight attitude disturbance data, expressed in degrees per second (° / s).

[0075] Step S42: Calculating the vibration amplitude of the aircraft body based on the flight attitude disturbance data; In this embodiment, the flight attitude disturbance data extracted in step S41 is combined with vibration data recorded by a triaxial accelerometer located in the center of the drone body to perform a statistical analysis of the drone's vibration amplitude. The acceleration data is acquired using a MEMS sensor with a sampling frequency of 1kHz and a dynamic range of ±16g. The time period marked as dynamic disturbance in the flight attitude disturbance data is used as the reference window, and the corresponding intercepted acceleration data is analyzed. A peak-to-peak algorithm is used to calculate the vibration amplitude. Specifically, the difference between the maximum and minimum values ​​of the triaxial acceleration in each window is calculated to obtain the vibration amplitudes Ax, Ay, and Az for each axis. The total vibration amplitude is then calculated using the triaxial synthesis formula A_total = √(Ax² + Ay² + Az²). This process is implemented using the NumPy library in Python, with a fixed window length of 2 seconds and a sliding step size of 1 second. The vibration amplitude is obtained in m / s² and serves as input data for the subsequent spectrum analysis.

[0076] Step S43: converting the vibration amplitude of the machine body into a vibration response spectrum of the machine body; In this embodiment, the vibration amplitude time series data obtained in step S42 is input into the FFT (Fast Fourier Transform) module to obtain the vibration response spectrum. Each segment of vibration data is first preprocessed using a Hamming window to suppress leakage effects, with the window function length fixed at 2048 points. A Fast Fourier Transform (FFT) operation is then performed, with a sampling frequency fixed at 1 kHz and a frequency resolution of 0.488 Hz. After the transformation, the frequency domain amplitude response from 0 to 500 Hz is obtained in units of m / s² / Hz. This is implemented using the scipy.fft module, extracting characteristic metrics such as the frequency corresponding to the main peak of the spectrum, f_peak, the spectral energy density distribution, and the energy center of gravity frequency, f_centroid. The spectral response plot is saved as a two-dimensional matrix (frequency, amplitude) for subsequent modal shift analysis. The number of all frequency points is strictly controlled to 512 to ensure frequency domain accuracy.

[0077] Step S44: identifying the degree of modal shift based on the vibration response spectrum of the machine body; In this embodiment, the main frequency peak f_peak, the secondary main frequency f_secondary and the energy center of gravity frequency f_centroid are selected from the spectrum data obtained in step S43 to construct a modal response eigenvector. This eigenvector is compared with the standard modal baseline pre-stored in the database. The standard modal baseline is obtained through static ground testing, the spectrum analysis method is consistent, and its modal frequency distribution is stable, mainly concentrated at 65Hz, 120Hz and 210Hz. By comparing the offset of f_peak and f_secondary in the current modal response with the baseline value, the degree of modal offset is judged, and the threshold is set to an offset exceeding ±10% as a significant offset, using the following formula: Δf=|f_peak-f_baseline| / f_baseline×100%. If Δf exceeds 10%, it is marked as a modal anomaly point, and the corresponding frequency band and time period are recorded in the abnormal modal log, and the modal offset degree data is output.

[0078] Step S45: calibrating the connection abnormality area according to the degree of modal deviation; judging the degree of structural connection looseness based on the connection abnormality area, and obtaining the body structure looseness data; In this embodiment, based on the modal offset frequency band identified in step S44, the offset frequency is matched against the modal response table of structural connection components in the UAV structural vibration response database. This table clearly lists the main modal frequency range of each connection point (such as the motor arm connection point, support frame joint, and sensor module mounting point) under normal conditions. For example, the modal frequency range of the motor arm connection is 115Hz-125Hz. If the identified offset frequency f_peak deviates from the motor arm connection frequency by more than 15Hz outside this range, it is determined that the connection is structurally loose. The corresponding location is marked as a connection abnormality area. Furthermore, the degree of structural connection looseness is comprehensively assessed based on the frequency offset amplitude, modal energy loss ratio (energy reduction amplitude ΔE ≥ 30%), and the degree of vibration waveform distortion (waveform mean square error RMSE ≥ 0.15). Ultimately, the structural looseness level (grade 0 to 5) for each connection component is output and a structural looseness data table is generated.

[0079] Step S46: Perform UAV collaborative role switching based on the body structure loosening data, obtain UAV collaborative role switching data, and upload it to the UAV Internet of Things management platform to execute the automated collaborative role control task.

[0080] In this embodiment, based on the structural looseness data table constructed in step S45, the current structural health status of the UAV is mapped to the collaborative control task role setting rules. If the looseness level reaches level 3 or above (i.e., the loose connection seriously affects flight safety), the current task role (such as the path leader) is switched to an auxiliary observation machine or a standby backup machine. The role switching rules are implemented according to the task scheduling table, which predefines the fault tolerance conditions and switching paths of each collaborative role. The determined collaborative role switching data is packaged into a JSON format data packet, with fields including: UAV number, current role, target role, structural status level, switching timestamp, etc. The data is transmitted to the UAV Internet of Things management platform deployed on the local area network edge computing node via the MQTT protocol. The receiving port is fixed to 1883 and the data transmission frequency is 10Hz. After receiving the data, the platform updates the UAV's task behavior mode according to the instruction rules in the collaborative control strategy file, thereby completing the execution initialization of the automated collaborative role control task.

[0081] It is particularly important that step S46 includes the following steps: Step S461: Classifying the health level of the drone based on the body structure looseness data to obtain drone health level data; In this embodiment, this step first uses the aircraft structure looseness data as input. This data includes the loosening frequency, modal shift rate, and response amplitude of each connection node, specifically represented as a triplet corresponding to the node number, for example (number A, shift rate 0.17, response amplitude 0.45g). Threshold comparison is performed on all structural connection points. Nodes with loosening frequencies greater than 0.3Hz, modal shift rates exceeding 0.12, and vibration response amplitudes exceeding 0.4g are included in the severe instability set. The health level is categorized into three levels based on the proportion of unstable nodes to the total number of connection nodes: if the proportion is less than 10%, it is defined as "Level 1 Healthy"; if it is between 10% and 30%, it is defined as "Level 2 Healthy"; and if it is greater than 30%, it is defined as "Level 3 Healthy". The classification criteria use a fixed interval partitioning method and do not involve machine learning models. Finally, the drone's unique number is paired with its health level to generate drone health level data. This data is stored in a structured table format with fields including drone ID, number of unstable nodes, total number of nodes, and health level.

[0082] Step S462: Evaluate the task fault tolerance capability based on the drone health level data to obtain task fault tolerance capability data; In this embodiment, this step sets minimum reliability requirements for different missions based on the drone's health level data and the type of mission it is currently performing (including patrol, reconnaissance, communication relay, and transport). The following mission fault tolerance standards are defined: the minimum fault tolerance health level for patrol missions is level 3, for reconnaissance missions is level 2, for communication relay missions is level 1, and for transport missions is level 1. The mission fault tolerance value is defined as the difference between the health level and the minimum required mission level. If the result is negative, the fault tolerance value is 0, indicating that the current mission cannot be properly undertaken. For example, if a drone with a health level of 3 is performing a communication relay mission, its fault tolerance value is 0; if it is performing a patrol mission, its fault tolerance value is 1. Each evaluation is performed through table lookup and simple integer calculations, without the need for probabilistic models. Ultimately, the mission fault tolerance data is generated. The data structure contains the following fields: drone ID, mission type, health level, minimum required mission level, and fault tolerance value.

[0083] Step S463: Determine the current mission status of the UAV based on the mission fault tolerance data; In this embodiment, a direct logical determination is made of the drone's current mission status based on the task tolerance data. Mission status is categorized into three categories: executable (tolerance value ≥ 1), requiring downgraded execution (tolerance value = 1 and the current task is a high-level task, such as communication relay), and unexecutable (tolerance value = 0). If the determination is "needs downgraded execution," the command issuance module replaces the mission type with a lower-level task (for example, communication relay is replaced with reconnaissance, or reconnaissance is replaced with cruise control). This replacement process is accomplished through a task adaptation rule table. Task mapping relationships are statically stored in the system, eliminating the need for dynamic reasoning. The state determination logic runs in the form of a determination function implemented in C language within an edge control node (such as an embedded controller onboard the drone). The mission status is ultimately represented by a status code: 0 indicates unexecutable, 1 indicates downgraded execution, and 2 indicates directly executable. Task status data is generated, including the status code and the recommended task type.

[0084] Step S464: switching the UAV collaborative role according to the current UAV mission status, and obtaining UAV collaborative role switching data; In this embodiment, this step executes the pre-set collaborative role switch instruction allocation process based on the status code provided in the task status data. If the status code is 0, the current collaborative network queries other UAVs in the executable state (status code 2) and selects the node closest to the task target and with the lowest current task load for task replacement. The task allocation rule calculates a scoring function based on two weighted parameters: distance weighted at 0.6 and load weighted at 0.4. Distance is calculated using GPS coordinate differences, and load is calculated as the weighted sum of the current CPU load percentage and the task queue length. After task reallocation, the original UAV ID, target UAV ID, role type (e.g., "primary communication relay," "secondary reconnaissance node," etc.), and the switch timestamp are recorded. The final output data is the UAV collaborative role switch data, a data structure containing the following fields: original UAV ID, target UAV ID, role type, switch mode (replacement or downgrade), and switch time.

[0085] Step S465: Upload the drone collaborative role switching data to the drone Internet of Things management platform to execute the automated collaborative role control task.

[0086] In this embodiment, this step synchronizes the collaborative role switching data to the UAV IoT management platform through the LoRa communication module or 5G module connected to the edge computing node. The transmission adopts the MQTT protocol for information publishing, the topic path is " / uav / roleSwitch / update", and the payload content is the switching data in JSON format. The management platform server is deployed with a data receiving service endpoint, which listens to the topic and transfers the switching data to the task scheduling center module through Kafka after receiving the switching instruction. After receiving the switching instruction, the platform triggers the automatic control instruction generation module, uses the instruction template to generate the task switching control instruction of the target UAV, and sends it to the edge control terminal bound to the target UAV through an HTTP POST request. At the same time, the platform updates the task allocation diagram and collaborative status table to ensure that the role status of all UAVs is synchronized. The data upload and control instruction generation process is driven by the Python service script, and cooperates with Redis for data buffering.

[0087] Preferably, this specification also provides an Internet of Things-based UAV automated collaborative control system, which is used to execute the Internet of Things-based UAV automated collaborative control method as described above. The Internet of Things-based UAV automated collaborative control system includes: The collaborative flight simulation module is used to obtain UAV communication data; perform flight attitude collision avoidance control based on the UAV communication data to obtain flight attitude collision avoidance data; perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; The battery structure damage detection module is used to analyze power consumption based on collaborative flight data to obtain power consumption data; perform battery aging detection based on power consumption data to obtain battery aging data; and perform battery structure damage detection based on battery aging data to obtain battery structure damage data; The instability risk identification module is used to optimize the flight path based on the battery structure damage data to obtain optimized flight path data; reconstruct the human-machine collaborative control task based on the optimized flight path data; generate a control instruction set based on the human-machine collaborative control task; perform flight control simulation based on the control instruction set to obtain flight control data; identify instability risks based on the flight control data to obtain flight instability data; The collaborative role switching module is used to perform body structure looseness analysis based on flight instability data to obtain body structure looseness data; based on the body structure looseness data, the UAV collaborative role switching is performed to obtain the UAV collaborative role switching data, and the data is uploaded to the UAV Internet of Things management platform to perform automated collaborative role control tasks.

[0088] The present invention is therefore intended to be illustrative and non-restrictive in all respects, with the scope of the invention being defined by the appended claims rather than the foregoing description, and all changes that come within the meaning and range of equivalents of the application documents are intended to be embraced therein.

[0089] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is to be construed in the widest possible manner consistent with the principles and novel features disclosed herein.

Claims

1. An automated collaborative control method for drones based on the Internet of Things, characterized in that: The following steps are involved: Step S1: Acquire UAV communication data; perform flight attitude collision avoidance control based on the UAV communication data to obtain flight attitude collision avoidance data; perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; Step S2: performing power consumption analysis based on the collaborative flight data to obtain power consumption data; performing battery aging detection based on the power consumption data to obtain battery aging data; performing battery structural damage detection based on the battery aging data to obtain battery structural damage data; Step S3: Optimizing the flight path based on the battery structure damage data to obtain optimized flight path data; reconstructing the human-machine collaborative control task based on the optimized flight path data; generating a control instruction set based on the human-machine collaborative control task; performing flight control simulation based on the control instruction set to obtain flight control data; identifying instability risks based on the flight control data to obtain flight instability data; Step S4: Perform an airframe structure looseness analysis based on the flight instability data to obtain airframe structure looseness data; perform UAV collaborative role switching based on the airframe structure looseness data to obtain UAV collaborative role switching data, and upload the data to the UAV Internet of Things management platform to execute automated collaborative role control tasks.

2. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 1, characterized in that: Step S1 is specifically as follows: Step S11: Acquire drone communication data; Step S12: determining the flight status based on the UAV communication data and obtaining flight status data; Step S13: Calculating the relative motion vector according to the flight status data; Step S14: identifying a collision risk area based on the relative motion vector; Step S15: Generate attitude adjustment control value according to the collision risk area to obtain flight attitude collision avoidance data; Step S16: Perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data.

3. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 2, characterized in that: Step S15 is specifically as follows: Step S151: collecting relative heading angles according to the collision risk area to obtain relative heading angle data; Step S152: Calculating the minimum collision avoidance deflection angle based on the relative heading angle data; Step S153: Decomposing the flight attitude control amount according to the minimum collision avoidance deflection angle; Step S154: generating a flight control instruction based on the flight attitude control value; Step S155: Perform real-time control of the attitude collision avoidance angle based on the flight control instruction to obtain flight attitude collision avoidance data.

4. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 1, characterized in that: The power consumption analysis in step S2 is specifically as follows: Extract spatial location information based on collaborative flight data; Performing time synchronization processing based on the spatial position information to obtain time-synchronized spatial position information; Sorting trajectory points based on time-synchronized spatial position information to obtain the UAV flight trajectory; Calculate the flight speed according to the UAV flight trajectory and obtain the flight speed data; Calculate the flight altitude according to the UAV flight trajectory and obtain the flight altitude data; Estimate energy consumption per unit time based on flight speed data and flight altitude data; The cumulative power consumption of the entire flight trajectory is calculated based on the energy consumption per unit time to obtain the power consumption data.

5. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 1, characterized in that: The battery aging detection in step S2 is specifically as follows: screening high power consumption batteries according to the power consumption data, and performing a pulse load response test on the high power consumption batteries to obtain pulse load response data; Extracting voltage drop characteristics based on pulse load response data to obtain voltage drop data; Calculate the internal resistance change rate based on voltage drop data; Determine the degree of degradation of battery electrode activity based on the internal resistance change rate; Evaluate the integrity of the electrode interface connection based on the degree of degradation of the battery electrode activity; Conduct electrode peeling detection based on the integrity of the electrode interface connection to obtain electrode peeling data; The battery aging is determined based on the electrode stripping data to obtain the battery aging data.

6. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 1, characterized in that: The battery structure damage detection in step S2 is specifically as follows: Calculate the volume of the electrode material based on the battery aging data to obtain the volume data of the electrode material; Determine electrode material bulging based on electrode material volume data to obtain electrode material bulging data; Calculate the bulging deformation of the electrode material based on the bulging data of the electrode material; The high deformation area is calibrated according to the bulging deformation of the electrode material; Conduct electrode particle crack detection based on high deformation areas to obtain electrode particle crack data; Identify dendrite microchannels based on electrode particle crack data and obtain dendrite growth data; The degree of battery structure damage is determined based on the dendrite growth data to obtain battery structure damage data.

7. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 1, characterized in that: Step S3 is specifically as follows: Step S31: Identify high-risk flight nodes based on battery structure damage data; Step S32: identifying avoidable paths based on high-risk flight nodes; optimizing the flight path based on the avoidable paths to obtain optimized flight path data; Step S33: performing flight control simulation according to the control instruction set to obtain flight control data; Step S34: calculating the attitude change rate based on the flight control data; determining the gyroscope change trend according to the attitude change rate to obtain gyroscope change trend data; evaluating the attitude stability according to the gyroscope change trend data to obtain attitude stability data; Step S35: Acquire wind speed data; perform gravity center offset evaluation on the attitude stability data based on the wind speed data to obtain gravity center offset data; perform flight control hysteresis detection based on the gravity center offset data to obtain flight control hysteresis data; Step S36: Identify the instability risk based on the flight control hysteresis data and obtain flight instability data.

8. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 7, characterized in that: Step S33 is specifically as follows: Step S331: transmitting the control instruction set to the flight control simulation system; Step S332: setting the flight mission type to fixed-point hovering, path tracking, and obstacle avoidance flight in the flight control simulation system; Step S333: In the flight control simulation system, the control surface deflection angle range is set to 15°-30°, the throttle opening range is set to 30%-100%, and the attitude angle control accuracy is set to 0°-0.5°; Step S334: In the flight control simulation system, set the crosswind disturbance to 0 m / s-8 m / s, the temperature to 10°C-45°C, and the air turbulence intensity level to 1-5; Step S335: In the flight control simulation system, the feedback delay is set to 10ms-200ms, the sensor sampling frequency is set to 50Hz-500Hz, and the simulation time step is set to 10ms-100ms; Step S336: Run the aircraft control response module in the flight control simulation system and output flight control data.

9. The method for automated collaborative control of unmanned aerial vehicles based on the Internet of Things according to claim 1, characterized in that: Step S4 is specifically as follows: Step S41: extracting flight attitude disturbance features based on the flight instability data to obtain flight attitude disturbance data; Step S42: Calculating the vibration amplitude of the aircraft body based on the flight attitude disturbance data; Step S43: converting the vibration amplitude of the machine body into a vibration response spectrum of the machine body; Step S44: identifying the degree of modal shift based on the vibration response spectrum of the machine body; Step S45: calibrating the connection abnormality area according to the degree of modal deviation; Determine the degree of structural connection looseness based on the abnormal connection area and obtain the looseness data of the body structure; Step S46: Perform UAV collaborative role switching based on the body structure loosening data, obtain UAV collaborative role switching data, and upload it to the UAV Internet of Things management platform to execute the automated collaborative role control task.

10. An automated collaborative control system for drones based on the Internet of Things, characterized in that: The method for executing the automated collaborative control method of unmanned aerial vehicles based on the Internet of Things according to claim 1, wherein the automated collaborative control system of unmanned aerial vehicles based on the Internet of Things comprises: The collaborative flight simulation module is used to obtain UAV communication data; perform flight attitude collision avoidance control based on the UAV communication data to obtain flight attitude collision avoidance data; perform collaborative flight simulation based on the flight attitude collision avoidance data to obtain collaborative flight data; The battery structure damage detection module is used to analyze power consumption based on collaborative flight data to obtain power consumption data; perform battery aging detection based on power consumption data to obtain battery aging data; and perform battery structure damage detection based on battery aging data to obtain battery structure damage data; The instability risk identification module is used to optimize the flight path based on the battery structure damage data to obtain optimized flight path data; reconstruct the human-machine collaborative control task based on the optimized flight path data; generate a control instruction set based on the human-machine collaborative control task; perform flight control simulation based on the control instruction set to obtain flight control data; identify instability risks based on the flight control data to obtain flight instability data; The collaborative role switching module is used to perform body structure looseness analysis based on flight instability data to obtain body structure looseness data; based on the body structure looseness data, the UAV collaborative role switching is performed to obtain the UAV collaborative role switching data, and the data is uploaded to the UAV Internet of Things management platform to perform automated collaborative role control tasks.

Images