Unmanned aerial vehicle simulation test method and system based on dual-engine coupling architecture

Abstract

The application relates to a kind of unmanned plane simulation test method and system based on double-engine coupling architecture.The method comprises: carrying out physical simulation on unmanned plane by physical simulation engine, generating physical state data and sensor data;Synchronize physical state data to visual rendering engine, and generate visual scene by visual rendering engine based on physical state data for rendering processing to the scene where unmanned plane is located;Sensor data is sent to flight control device, so that flight control device generates control instruction;Receive the control instruction generated by flight control device, and provide the control instruction to physical simulation engine, so that physical simulation engine updates the motion state of unmanned plane in visual scene.The application realizes the parallel execution of physical simulation and visual rendering through double-engine coupling architecture, and meets the needs of high-precision physical simulation and high-fidelity visual rendering, improves the running efficiency and scene fidelity of simulation test.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) system simulation and testing technology, and more specifically, to a UAV simulation and testing method and system based on a dual-engine coupled architecture. Background Technology

[0002] Drone simulation testing is a crucial step in the drone development process. By conducting flight tests in a virtual environment, development costs can be reduced, development cycles shortened, and safety improved. A simulation testing platform typically consists of core components such as a simulation engine, flight control interface, scene rendering, and sensor simulation. The physical accuracy and visual realism of the simulation engine directly impact the reliability of the test results.

[0003] Currently, there are two main types of technical solutions in the field of UAV simulation testing. One type is the open-source physics simulation solution represented by Gazebo, which provides dynamics simulation, collision detection, and sensor model calculation based on the ODE or Bullet physics engine, and supports SITL simulation connections with PX4 and ArduPilot flight controllers. The other type is the high-fidelity visual rendering solution represented by Unreal Engine, which uses a physically-based rendering pipeline to generate highly realistic visual scenes and provides dynamics simulation, sensor simulation, and flight control interface functions through the AirSim plugin. Furthermore, both PX4 and ArduPilot support software-in-the-loop and hardware-in-the-loop simulation.

[0004] However, all of the above solutions have shortcomings. Gazebo has high physical accuracy but limited visual rendering capabilities, while Unreal Engine offers strong visual realism but relatively insufficient physical accuracy. A single engine cannot meet both requirements. When Gazebo and Unreal Engine are used together, their operating frequencies differ. How to achieve low-latency data transmission while maintaining high-frequency synchronization and ensuring consistency between visual and physical data is a pressing technical challenge. Furthermore, PX4 and ArduPilot differ in communication protocol details and actuator output ranges. Existing technologies lack a unified abstraction interface layer to shield these underlying differences and also lack an automated framework to support multi-flight controller comparative testing, making it difficult to efficiently perform batch execution of standardized test cases and systematic comparative analysis. Summary of the Invention

[0005] Based on this, it is necessary to address the above problems. This invention provides a UAV simulation testing method and system based on a dual-engine coupling architecture. It achieves real-time state synchronization between the Gazebo physics simulation engine and Unreal Engine through a shared memory mechanism, and sets up a flight control adaptation module to uniformly adapt to PX4 and ArduPilot flight controllers, thereby taking into account both high-precision physical simulation and high-fidelity visual rendering, while also supporting comparative testing of multiple flight controllers.

[0006] To achieve the above objectives, according to a first aspect of the present invention, a method for simulating and testing a drone based on a dual-engine coupled architecture is provided, comprising: performing physical simulation on the drone using a physical simulation engine to generate physical state data and sensor data of the drone; synchronizing the physical state data to a visual rendering engine, wherein the visual rendering engine renders the scene in which the drone is located based on the physical state data to generate a visual scene; sending the sensor data to a flight control device, wherein the flight control device generates control commands based on the sensor data; receiving the control commands generated by the flight control device and providing the control commands to the physical simulation engine, wherein the physical simulation engine updates the motion state of the drone in the visual scene based on the control commands.

[0007] Optionally, synchronizing the physical state data to the visual rendering engine includes: through a shared memory mechanism, the physical simulation engine writes the latest physical state data into the current slot of the circular buffer in the shared memory region and updates the write pointer every preset number of physical simulation steps; the visual rendering engine reads the latest physical state data from the circular buffer at the beginning of each rendering frame.

[0008] In the above implementation process, physical state data is transmitted with low latency through a shared memory ring buffer. The physics engine writes at a preset step size and the vision engine reads at the beginning of the frame, effectively decoupling the difference in the operating frequency of the two, avoiding synchronization blocking and bus contention, and ensuring that each frame rendering is based on a complete and consistent physical state, thereby achieving vision-physics consistent joint simulation synchronization.

[0009] Optionally, the rendering process of the scene where the UAV is located by the visual rendering engine based on the physical state data includes: interpolating the physical state data between two adjacent synchronizations, wherein quaternion spherical linear interpolation is used for attitude and linear interpolation is used for position; using the simulation clock of the physical simulation engine as the master clock and the rendering clock of the visual rendering engine as the slave clock, checking the time difference before rendering each frame, if the rendering clock leads the simulation clock, pausing rendering and waiting, if the lag of the rendering clock relative to the simulation clock is within a preset threshold, then rendering is performed; otherwise, skipping frames to catch up and rendering.

[0010] In the above implementation process, by linear interpolating the position between synchronization points and spherical linear interpolation of the pose quaternion, the smooth transition between frames of the rendered image and the natural continuity of the pose rotation are ensured, avoiding visual stuttering or abrupt changes caused by discrete updates. At the same time, the physical simulation clock is used as the master clock and the rendering clock is used as the slave clock. The decision to wait for rendering or skip frames to catch up is made dynamically based on the time difference. This ensures that the visual rendering strictly follows the rhythm of the physical simulation and prevents the clock drift from causing synchronization offset. At the same time, the threshold tolerance and frame skipping mechanism take into account both the smoothness of rendering and real-time performance, thus achieving a good balance between visual smoothness and system synchronization accuracy.

[0011] Optionally, it also includes: adapting at least two different types of flight control devices, wherein the sensor data is converted into protocol format data supported by each of the flight control devices, and the control commands generated by each of the flight control devices are uniformly converted into preset normalized values; and conducting comparative testing on the at least two different types of flight control devices, wherein the same test case is executed on each of the at least two different types of flight control devices, the flight data of each flight control device when executing the test case is recorded, and the flight data is compared and analyzed.

[0012] In the above implementation process, by converting sensor data into the protocol format supported by each flight control device and normalizing the control commands generated by each flight control device into preset values, the underlying differences between different flight control devices in terms of communication protocol details and actuator output range are effectively shielded, enabling multiple flight control devices to be seamlessly connected in the same simulation environment. On this basis, by executing and recording flight data separately with the same test case for comparative analysis, a standardized automated testing framework for flight control performance evaluation is provided. This framework supports batch execution of test cases and systematic comparison, significantly improving testing efficiency and the objectivity of comparison results. It facilitates the rapid screening and evaluation of differences in control accuracy, response characteristics, and stability of different flight control devices, and has direct engineering guiding value for flight control device selection and algorithm iteration optimization.

[0013] According to a second aspect of the present invention, a drone simulation testing system based on a dual-engine coupled architecture is provided, comprising: a physical simulation module for performing physical simulation on the drone through a physical simulation engine to generate physical state data and sensor data of the drone; a state synchronization module for synchronizing the physical state data to a visual rendering engine; a visual rendering module for rendering the scene in which the drone is located based on the physical state data by the visual rendering engine to generate a visual scene; and a flight control interface module for sending the sensor data to a flight control device for the flight control device to generate control commands based on the sensor data, receiving the control commands generated by the flight control device, and providing the control commands to the physical simulation engine for the physical simulation engine to update the motion state of the drone in the visual scene based on the control commands.

[0014] Optionally, the state synchronization module is further configured to: through a shared memory mechanism, the physics simulation engine writes the latest physical state data into the current slot of the circular buffer in the shared memory region after a preset number of physics simulation steps, and updates the write pointer; the visual rendering engine reads the latest physical state data from the circular buffer at the beginning of each rendering frame.

[0015] Optionally, the state synchronization module is further configured to: interpolate the physical state data between two adjacent synchronizations, wherein quaternion spherical linear interpolation is used for attitude and linear interpolation is used for position; using the simulation clock of the physical simulation engine as the master clock and the rendering clock of the visual rendering engine as the slave clock, check the time difference before rendering each frame; if the rendering clock leads the simulation clock, pause rendering and wait; if the lag of the rendering clock relative to the simulation clock is within a preset threshold, then render; otherwise, skip frames and render after catching up.

[0016] Optionally, it also includes: a flight control adaptation module, used to adapt to at least two different types of flight control devices, wherein the sensor data is converted into protocol format data supported by each of the flight control devices, and the control commands generated by each of the flight control devices are uniformly converted into preset normalized values; a test management module, used to perform comparative testing on the at least two different types of flight control devices, wherein the same test case is executed on each of the at least two different types of flight control devices, the flight data of each flight control device when executing the test case is recorded, and the flight data is compared and analyzed.

[0017] In the above implementation process, the UAV simulation test system based on a dual-engine coupling architecture provided by this invention, through the collaborative operation of the physical simulation module and the visual rendering module, takes into account the dual requirements of high-fidelity physical simulation and realistic visual presentation. The state synchronization module adopts a shared memory ring buffer combined with interpolation and clock synchronization strategies to solve the synchronization problem caused by the frequency difference of heterogeneous engines in a low-latency and high-smooth manner, ensuring strict consistency between the visual scene and the physical state in terms of timing. The flight control interface module realizes the protocol conversion of sensor data and the normalization processing of control commands, opening up the data closed loop between the simulation environment and the real flight control device, enabling seamless access to both software-in-the-loop and hardware-in-the-loop simulations. On this basis, the flight control adaptation module and the test management module further provide the ability to shield the underlying differences of different flight control devices and standardize comparative testing capabilities, supporting batch execution of the same test cases and automatic recording of flight data for analysis, thus forming a complete and scalable UAV simulation test platform. This effectively reduces the engineering complexity of multi-flight control comparative testing, significantly improves test efficiency and the comparability of results, and has important engineering practical value for the research, verification and selection evaluation of flight control algorithms.

[0018] According to a third aspect of the present invention, an electronic device is provided, the electronic device including a memory and a processor, the memory storing program instructions, and the processor, when reading and running the program instructions, performing the steps in any of the above implementations.

[0019] The UAV simulation testing method based on a dual-engine coupled architecture provided by this invention achieves a balance between high-fidelity physical simulation and realistic visual presentation. This is achieved through the collaborative operation of the physical simulation engine and the visual rendering engine, a bidirectional synchronization mechanism using a shared memory ring buffer combined with interpolation and clock synchronization strategies, and an automated framework that supports multi-flight control protocol adaptation and standardized comparative testing. It solves the synchronization problem caused by the frequency difference of heterogeneous engines and the compatibility problem caused by the underlying differences of different flight control devices. It realizes a closed-loop simulation of the entire process from sensor data generation and flight control command interaction to visual-physical consistent rendering. This effectively reduces the engineering complexity of multi-flight control comparative testing, improves testing efficiency and result comparability, and provides a reliable basic platform for the research, verification, and selection evaluation of flight control algorithms. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the conventional technology, the drawings used in the description of the embodiments or the conventional technology will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating the overall process of a drone simulation testing method based on a dual-engine coupling architecture, provided for an embodiment of the present invention. Figure 2 A flowchart of physical state data synchronization provided for embodiments of the present invention; Figure 3 A schematic diagram of the flight control adaptation process provided in the embodiments of the present invention; Figure 4 This is a schematic diagram of the multi-flight control comparison test process provided for an embodiment of the present invention; Figure 5 A structural diagram of a drone simulation test system based on a dual-engine coupling architecture, provided for an embodiment of the present invention. Detailed Implementation

[0022] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention.

[0023] Currently, the field of UAV simulation testing generally adopts a single simulation engine architecture, which makes it difficult to simultaneously meet the requirements of high-precision physical simulation and high-fidelity visual rendering. To address this technical problem, this implementation provides a dual-engine coupled architecture that combines the Gazebo physical simulation engine and the Unreal Engine. In this implementation, Gazebo handles high-precision physical simulation calculations, while the Unreal Engine handles visual scene rendering and visual sensor image generation. The two engines achieve real-time state synchronization through a shared memory mechanism, ensuring strict consistency between physical simulation and visual rendering in time and space. Simultaneously, this implementation also provides a flight control adaptation module for unified adaptation to PX4 and ArduPilot flight control systems, and a test management module for comparative testing of the two flight control systems under identical conditions. The specific architecture and workflow of this implementation are described in detail below with reference to the accompanying drawings.

[0024] Reference Figure 1 , Figure 1 The overall flowchart of the UAV simulation testing method based on a dual-engine coupled architecture provided for embodiments of the present invention is shown below. Figure 1 As shown, it includes the following steps: Step S100: Perform physical simulation. Specifically, a physical simulation engine is used to perform a physical simulation of the UAV, generating physical state data and sensor data for the UAV. The physical simulation engine uses the Gazebo simulation engine, which is responsible for performing dynamic simulation, aerodynamic simulation, collision detection, and sensor physical model calculation for the UAV. In this embodiment, the physical state data includes the UAV's position, attitude, linear velocity, and angular velocity; the sensor data includes IMU data, GPS data, barometer data, and magnetometer data.

[0025] The Gazebo simulation engine performs the following core functions: multi-rotor dynamics simulation, based on quaternion rigid body dynamics models and motor-propeller-ESC joint models, supporting the mapping of pulse width modulation (PWM) signals to thrust / torque and aerodynamic effect simulation; battery discharge model, supporting the impact of voltage drop on the maximum output of the motor; wind field model, supporting wind disturbance simulation of constant wind, gusts, and turbulent wind; sensor physical models, including IMU models (including zero bias, noise, temperature drift, and scale factor errors of accelerometers and gyroscopes), GPS models (including position drift, multipath effects, and signal loss simulation), barometer models (including barometric pressure noise and temperature compensation errors), magnetometer models (including hard iron / soft iron calibration errors and magnetic interference), and lidar models (including ranging error, angular resolution, and point cloud open dynamics collision detection engine, supporting rigid body-rigid body and rigid body-soft body collisions, as well as collision force calculation and damage assessment).

[0026] Step S101: Synchronize physical state data to the visual rendering engine. Specifically, the physical state data generated in step S100 is synchronized to the visual rendering engine. The visual rendering engine uses Unreal Engine. In this embodiment, the Gazebo simulation engine and Unreal Engine achieve real-time state data synchronization through a shared memory mechanism, ensuring strict consistency between physical simulation and visual rendering in time and space. The specific implementation of the synchronization mechanism will be discussed later. Figure 2 Detailed description is provided.

[0027] Step S102: Send sensor data to the flight control device. Specifically, the sensor data generated in step S100 is sent to the flight control device so that the flight control device can generate control commands based on the sensor data. The flight control device can be a PX4 flight control or an ArduPilot flight control. In this embodiment, the sensor data is sent to the flight control device through the flight control interface module. The flight control adaptation module is used to adapt to at least two different types of flight control devices, unifying the communication interfaces of different flight control devices into a standardized interface to ensure compatibility with software-in-the-loop simulation and hardware-in-the-loop simulation connections supporting PX4 and ArduPilot flight control. The flight control adaptation module converts the sensor data into protocol format data supported by each flight control device and unifies the control commands generated by each flight control device into preset normalized values. The specific implementation of the above-mentioned flight control adaptation module will be discussed later. Figure 3 Detailed description is provided.

[0028] Step S103: Render the visual scene. Specifically, Unreal Engine renders the scene where the drone is located based on the physical state data obtained synchronously in step S101 to generate the visual scene. Unreal Engine undertakes the following core functions: high-fidelity scene rendering, with a PBR-based material system supporting metallicity / roughness workflows, a Lumen global illumination system for dynamic indirect lighting, Nanite virtual geometry for ultra-high precision model rendering, a volumetric cloud / volumetric fog system for realistic sky and atmospheric effects, and a water surface rendering system supporting ripple, reflection, and refraction effects; visual sensor image generation, including RGB cameras generating realistic images that conform to PBR physical laws, depth cameras generating depth maps consistent with scene geometry, semantic segmentation cameras generating pixel-level semantic label maps, infrared cameras simulating thermal imaging effects, and post-processing effects such as motion blur, lens distortion, high dynamic range, and chromatic aberration; environmental effects system, including weather systems such as rain, snow, fog, and dust storms, lighting changes brought about by time systems such as morning, noon, afternoon, and night, and vegetation and terrain changes brought about by seasonal systems of spring, summer, autumn, and winter.

[0029] In step S104, the flight control device generates control commands. Specifically, after receiving the sensor data sent in step S102, the flight control device generates control commands based on the sensor data. In software-in-the-loop simulation mode, the sensor data generated by the physical simulation module is processed by the flight control adapter module and sent to the flight control's software-in-the-loop simulation process via UDP or TCP protocol; in hardware-in-the-loop simulation mode, the sensor data generated by the physical simulation module is sent to the flight control hardware via the flight control interface module through a serial port or USB interface. The flight control device calculates and generates actuator control commands based on the received sensor data.

[0030] Step S105: Receive control commands and provide them to the physics simulation engine. Specifically, receive control commands generated by the flight controller and provide them to the Gazebo simulation engine. The control commands returned by the flight controller are processed by the flight controller adaptation module and then returned to the physics simulation module. The flight controller adaptation module adopts an adapter model and internally includes an abstract flight controller interface, a PX4 adapter, an ArduPilot adapter, a protocol converter, and a connection manager. Different flight controllers differ in communication protocol details and actuator output ranges. The flight controller adaptation module adapts the MAVLink protocol of the PX4 flight controller to the standardized interface and the MAVLink protocol of the ArduPilot flight controller to the standardized interface. It also uses the protocol converter to handle the differences between the two flight controllers in message type, actuator output range, motor number mapping, and flight mode enumeration.

[0031] Step S106: Update the UAV's motion state. Specifically, the Gazebo simulation engine drives the UAV model to move according to the control commands output by the flight controller received in step S105, updating the UAV's motion state in the visual scene. The Gazebo simulation engine drives the UAV model to move according to the control commands output by the flight controller interface module, updating the UAV's pose in the visual scene accordingly, forming a simulation closed loop. Then, it returns to step S100 to continue the next round of simulation iterations until the simulation test ends.

[0032] The aforementioned UAV simulation testing method based on a dual-engine coupled architecture decouples and synchronizes the physical simulation engine with the visual rendering engine in real time. This allows physical simulation and visual rendering to execute in parallel without blocking each other, avoiding the performance bottleneck caused by serial processing of a single engine and improving the efficiency of simulation testing. Simultaneously, the physical simulation engine and visual rendering engine each perform their respective functions: the physical simulation engine focuses on high-precision dynamics calculations and sensor physical model simulation, while the visual rendering engine focuses on high-fidelity scene rendering. Their collaborative work balances physical accuracy and visual realism, enhancing the overall realism of the simulation environment. Furthermore, the flight controller adaptation module unifies the communication protocols of different flight controllers into a standardized interface, enabling seamless integration of PX4 and ArduPilot flight controllers into the same simulation platform without requiring the reconstruction of simulation environments for different flight controllers, thus reducing the complexity of multi-flight controller testing. The simulation process forms a continuously iterative closed-loop structure, with physical simulation, sensor data transmission, control command generation, and motion state updates executed cyclically, achieving continuous autonomous flight testing of the UAV in a virtual environment.

[0033] Figure 2 A flowchart illustrating the physical state data synchronization process for embodiments of the present invention. Figure 2 right Figure 1The specific implementation method of "synchronizing physical state data to the visual rendering engine" in step S101 is described in detail. Figure 2 As shown, it includes the following steps.

[0034] Step S200: Advance the physical simulation. Specifically, the physical simulation engine (Gazebo) advances the physical simulation with a fixed physical step size, generating the latest physical state data of the UAV. The Gazebo simulation engine runs with a fixed physical step size of 1ms, and at the end of each physical step, it generates physical state data including the UAV's position, attitude, linear velocity, angular velocity, etc.

[0035] The physical state data constitutes the synchronization data packet, which includes the following fields: timestamp (microsecond precision), vehicle unique identifier, position coordinates (x, y, z, in meters), attitude quaternions (qx, qy, qz, qw), linear velocity (vx, vy, vz, in meters per second), angular velocity (wx, wy, wz, in radians per second), speed of each motor (revolutions per minute), collision marker, and ground contact marker.

[0036] Step S201: Write to the shared memory circular buffer. Specifically, the Gazebo simulation engine, acting as the writer of the shared memory, writes the latest physical state data to the current slot in the circular buffer of the shared memory region after a preset number of physical steps, and updates the write pointer. The shared memory region adopts a circular buffer structure, containing multiple synchronization data slots. Gazebo runs with a 1ms physical step size, writing to the shared memory every 10 steps (i.e., every 10ms), with a write frequency of no less than 100Hz. This scheme avoids data copy overhead, achieving zero-copy data transmission with an end-to-end latency of less than 5ms.

[0037] Step S202: Read the shared memory circular buffer. Specifically, the visual rendering engine (Unreal Engine) acts as the reader of the shared memory, reading the latest physical state data from the shared memory circular buffer at the beginning of each rendering frame. The Unreal Engine's rendering frame rate is 60fps. By separating the write pointer and the read pointer, it is ensured that the physical simulation write and the visual rendering read do not block each other.

[0038] Step S203: Master-Slave Clock Synchronization Check. Specifically, a master-slave clock synchronization strategy is adopted, with the simulation clock of the Gazebo simulation engine as the master clock and the rendering clock of the Unreal Engine as the slave clock. Before rendering each frame, the Unreal Engine checks the time difference: if the rendering clock leads the simulation clock, rendering is paused and waited; if the lag between the rendering clock and the simulation clock is within a preset threshold, rendering proceeds; if the lag exceeds the preset threshold, frames are skipped to catch up before rendering. This mechanism ensures that the simulation times of the two engines are strictly consistent, avoiding visual and physical time-axis drift.

[0039] Step S204: Interpolate physical state data. Specifically, after clock synchronization determines that the frame is renderable, Unreal Engine interpolates the physical state data between two adjacent synchronization timestamps based on the current rendering timestamp. Quaternion spherical linear interpolation (SLERP) is used for pose data to ensure smooth rotation; linear interpolation is used for position data to ensure natural position transitions. This interpolation process eliminates visual jitter, making the drone's movement in the visual scene smoother and more fluid.

[0040] Step S205: Perform rendering. Specifically, after clock synchronization confirmation and interpolation processing, Unreal Engine performs rendering based on the interpolated physical state data to generate the visual scene. It then returns to step S200 to continue the next round of synchronization and rendering iterations until the simulation test ends.

[0041] Figure 3 This is a schematic diagram of the flight control adaptation process provided for an embodiment of the present invention. For example... Figure 3 As shown, the flight controller adaptation process includes the following steps: Step S300: Acquire sensor data. Specifically, acquire sensor data from the Gazebo simulation engine. Sensor data includes IMU data, GPS data, barometer data, magnetometer data, and lidar data.

[0042] Step S301: Sensor Data Protocol Conversion. Specifically, the flight controller adapter module converts sensor data into protocol format data supported by each flight controller device. The flight controller adapter module adopts an adapter mode and internally includes an abstract flight controller interface, a PX4 adapter, an ArduPilot adapter, a protocol converter, and a connection manager.

[0043] The abstract flight controller interface defines standardized APIs, including connection management APIs (connect: connect to a specified type of flight controller, disconnect(): disconnect the flight controller connection, is_connected(): check the connection status, get_fc_type(): get the type of the currently connected flight controller), sensor data APIs (send_imu_data: send IMU data, send_gps_data: send GPS data, send_baro_data: send barometer data, send_mag_data: send magnetometer data, send_distance_sensor_data: send distance sensor data), control command receiving APIs (receive_actuator_controls(): receive actuator control output, receive_motor_commands(): receive motor speed commands), and status acquisition APIs (get_vehicle_state(): get the internal state of the flight controller, get_mission_status(): get the mission execution status).

[0044] The protocol converter is used to handle the differences between the two flight controllers in terms of message type, actuator output range, motor number mapping, flight mode enumeration, and parameter protocol, as shown in Table 1 below: Table 1 The connection manager is used to manage the startup, connection, disconnection, and reconnection of the flight control process. The flight control adapter module supports automatic detection of the PX4 source code path, compilation, and startup of the PX4 software-in-the-loop simulation process. Startup parameters include aircraft selection (iris, plane, vtol, etc.), simulation speed factor, and logging options. It also supports automatic startup of the ArduPilot software-in-the-loop simulation process via the ArduPilot sim_vehicle.py script, supporting multiple aircraft selections (copter, plane, rover, etc.).

[0045] Step S302: Send to the target flight controller. Specifically, the protocol-converted sensor data is sent to the target flight controller via the flight controller interface module. In software-in-the-loop simulation mode, the sensor data is sent to the flight controller's software-in-the-loop simulation process via the MAVLink protocol; in hardware-in-the-loop simulation mode, the sensor data is sent to the flight controller hardware via a serial port or USB interface.

[0046] The PX4 adapter communicates with the PX4 software-in-the-loop simulation process via the UDP MAVLink protocol. The data flow is as follows: the Gazebo sensor plugin collects analog sensor data, which is then standardized by the flight controller adapter module and transmitted to the PX4 adapter. The PX4 adapter converts the standardized data into PX4 MAVLink message format (HIL_SENSOR, HIL_GPS, etc.) and sends it to the PX4 software-in-the-loop simulation process via the UDP port.

[0047] The ArduPilot adapter communicates with the ArduPilot software-in-the-loop simulation process via the TCP / UDP MAVLink protocol. The data flow is as follows: the Gazebo sensor plugin collects simulated sensor data, which is then standardized by the flight controller adapter module and transmitted to the ArduPilot adapter. The ArduPilot adapter converts the standardized data into the ArduPilot MAVLink message format and sends it to the ArduPilot software-in-the-loop simulation process via the TCP / UDP connection.

[0048] Step S303: The flight control device generates control commands. Specifically, the flight control device calculates and generates actuator control commands based on the received sensor data.

[0049] Step S304: Control command normalization processing. Specifically, the flight control adaptation module converts the control commands generated by each flight control device into preset normalized values.

[0050] Step S305: Output control commands to the physics simulation engine. Specifically, the flight control interface module receives control commands generated by the flight control device and provides them to the Gazebo simulation engine. The data flow is as follows: The PX4 software-in-the-loop simulation process outputs actuator control commands. After receiving the MAVLink message, the flight control interface module sends it to the PX4 adapter for parsing. After normalization by the flight control adapter module, the data is then sent to the Gazebo simulation engine. Similarly, the ArduPilot software-in-the-loop simulation process outputs motor control commands. After receiving the MAVLink message, the flight control interface module sends it to the ArduPilot adapter for parsing. After normalization by the flight control adapter module, the data is then sent to the Gazebo simulation engine.

[0051] Figure 4 This is a schematic diagram of a multi-flight controller comparison test process provided for an embodiment of the present invention. Figure 4 As shown, the multi-flight controller comparison test process includes the following steps: Step S400: Obtain the test scenario. Specifically, the test management module obtains the simulation scenario used for comparative testing. The simulation scenario includes Gazebo world files and Unreal Engine level files. The same Gazebo world file and Unreal Engine scenario can be reused by both flight controllers to ensure the consistency of the test environment. The test management module is connected to the physics simulation module, visual rendering module, state synchronization module, and flight controller interface module respectively, for comparative testing of the PX4 flight controller and the ArduPilot flight controller under the same simulation conditions.

[0052] Step S401: Load test cases. Specifically, the test management module loads standardized test cases. Test cases are defined in JSON format and include the following fields: test identifier, test name, Gazebo world file path, Unreal Engine scene level name, vehicle dynamics model, weather preset configuration, waypoint list, evaluation index list, and target flight control list.

[0053] The test management module supports the automatic generation of test cases based on orthogonal experimental design, generating a set of test cases with optimal coverage from the parameter space; it also supports regression testing after flight control code updates, automatically executing all or selected historical test cases and comparing the test results of the new version with the old version.

[0054] Step S402: Parallel execution of the two flight controllers. Specifically, under the same simulation conditions, the same test case is executed using both the PX4 and ArduPilot flight controllers. The two flight controllers run separately within the same Gazebo world file and Unreal Engine scene to ensure consistency of the test environment. The test management module uniformly schedules the startup, operation, and shutdown of both flight controllers.

[0055] Step S403: Record flight data. Specifically, record the flight data for each of the two flight controller execution test cases. Flight data includes: flight trajectory (time series of position, attitude, and velocity), control outputs (motor commands, control surface deflections), sensor data, and internal flight controller states (flight mode, navigation status, fault indicators). The recorded data will be used for subsequent comparative analysis.

[0056] Step S404: Comparative Analysis. Specifically, the test management module performs a comparative analysis of the flight data of the two flight controllers under the same test case. The comparative analysis includes the following three aspects: (1) Trajectory Comparison Analysis: Quantitatively assess the degree of trajectory deviation when two flight controllers perform the same flight mission. Define the Mean Absolute Trajectory Deviation (MATE) to reflect the overall deviation level of the flight trajectory: in, For flight control FC at all times The actual location, As a reference trajectory, the expected position at the same time. The total number of sampling points. This represents the Euclidean norm.

[0057] Define the maximum trajectory deviation (MTE) to reflect the trajectory deviation under worst-case conditions: Define the root mean square trajectory deviation (RMSTE), a trajectory quality metric that is more sensitive to larger deviations: Define dual-control trajectory cross-deviation (CFCD) to directly measure the difference between the PX4 and ArduPilot trajectories: Define heading angle tracking deviation and assess the degree of consistency between the aircraft's nose pointing and the desired heading during flight: The heading angle difference is taken as the minimum circular distance to ensure .

[0058] (2) Performance index comparison and analysis: The evaluation is conducted from three dimensions: flight efficiency, energy consumption efficiency, and attitude control quality. The flight time deviation rate is defined as: in, , These represent the total flight time for the two flight control systems to complete the same task. .

[0059] Total energy consumption is defined as: in, For a moment Instantaneous total power ( , The first The current and voltage of each motor, (Number of motors) The sampling interval is denoted as .

[0060] Position control accuracy (steady-state error) is defined as: in, The sampling time is for the steady-state hovering or waypoint arrival phase. This represents the number of sampling points during the steady-state phase. The target location.

[0061] Attitude control accuracy is defined as: in, This is the roll angle deviation. This refers to the pitch angle deviation.

[0062] The control smoothness index (control output jitter) is defined as follows: in, This is the normalized total thrust control quantity or attitude angular rate command. This index reflects the smoothness of the control output; the smaller the value, the smoother the control.

[0063] (3) Timing Comparison Analysis: Focus on the differences in the triggering timing of key events when the two flight control systems perform the same mission. Key events include: takeoff, reaching cruise altitude, arrival at waypoints, commencement of landing, and touchdown. For each key event... Calculate the time deviation: in, Triggering events for flight controller FC Simulation moment.

[0064] The flight mission is divided into the takeoff phase. Cruise section and landing section Calculate the duration of each stage separately: The Timing Consistency Index (TCI) comprehensively measures the timing consistency of the two flight controllers across all critical events: in, The closer the TCI value is to 1, the more consistent the timing behavior of the two flight control systems.

[0065] Response time comparison: For dynamic disturbance events (such as sudden wind injection or obstacle appearance), compare the delay between the two flight controllers from the occurrence of the event to the control response. in Injecting moments into the disturbance. For the first time, the flight control output has exceeded the disturbance-free baseline. The timeframe within the range.

[0066] After the comparative analysis is completed, the test management module outputs the comparison results in two forms: 3D visualization and numerical reports. The 3D view renders the trajectory curves of the two flight controllers in different colors and overlays the reference flight path; the numerical reports output the quantitative results of the above indicators.

[0067] Figure 5 Figure 50 shows the module structure of a UAV simulation and testing system based on a dual-engine coupled architecture, provided for an embodiment of the present invention. Figure 5 As shown, the system includes a physical simulation module 501, a visual rendering module 502, a state synchronization module 503, a flight control interface module 504, a flight control adaptation module 505, and a test management module 506.

[0068] The physical simulation module 501 is used to perform physical simulation of the UAV through a physical simulation engine, generating physical state data and sensor data of the UAV. The visual rendering module 502 is used by the visual rendering engine to render the scene in which the UAV is located based on the physical state data, generating a visual scene. The state synchronization module 503 is used to synchronize physical state data to the visual rendering engine. The flight control interface module 504 is used to send sensor data to the flight control device, receive control commands generated by the flight control device, and provide the control commands to the physical simulation engine. The flight control adaptation module 505 is used to adapt to at least two different types of flight control devices, converting sensor data into protocol format data supported by each flight control device, and uniformly converting the control commands generated by each flight control device into preset normalized values. The test management module 506 is used to perform comparative testing on at least two different types of flight control devices, executing the same test case with at least two different types of flight control devices, recording the flight data of each flight control device when executing the test case, and comparing and analyzing the flight data.

[0069] Based on the same inventive concept, the present invention also provides an electronic device, which includes a memory and a processor. The memory stores program instructions, and when the processor reads and runs the program instructions, it executes the steps in any of the above implementation methods.

[0070] Based on the same inventive concept, embodiments of the present invention also provide a computer-readable storage medium storing computer program instructions, which, when read and executed by a processor, perform the steps in any of the above implementations.

[0071] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A simulation testing method for unmanned aerial vehicles (UAVs) based on a dual-engine coupled architecture, characterized in that, include: The drone is physically simulated using a physics simulation engine to generate physical state data and sensor data for the drone. The physical state data is synchronized to the visual rendering engine, which then renders the scene in which the drone is located based on the physical state data to generate a visual scene. The sensor data is sent to the flight control device so that the flight control device can generate control commands based on the sensor data; The system receives the control commands generated by the flight control device and provides them to the physics simulation engine so that the physics simulation engine can update the motion state of the UAV in the visual scene based on the control commands.

2. The method according to claim 1, characterized in that, The step of synchronizing the physical state data to the visual rendering engine includes: Through the shared memory mechanism, the physics simulation engine writes the latest physical state data into the current slot of the circular buffer in the shared memory region and updates the write pointer every preset number of physics simulation steps. At the beginning of each rendering frame, the visual rendering engine reads the latest physical state data from the circular buffer.

3. The method according to claim 1, characterized in that, The rendering process of the scene where the drone is located by the visual rendering engine based on the physical state data includes: Between two consecutive synchronizations, the physical state data is interpolated, with quaternion spherical linear interpolation used for attitude and linear interpolation used for position; Using the simulation clock of the physical simulation engine as the master clock and the rendering clock of the visual rendering engine as the slave clock, the time difference is checked before each frame is rendered. If the rendering clock leads the simulation clock, rendering is paused and waited. If the lag of the rendering clock relative to the simulation clock is within a preset threshold, rendering is performed. Otherwise, the rendering is performed after skipping frames to catch up.

4. The method according to claim 1, characterized in that, Also includes: Adaptation is performed for at least two different types of flight control devices, wherein the sensor data is converted into protocol format data supported by each flight control device, and the control commands generated by each flight control device are uniformly converted into preset normalized values. A comparative test is performed on the at least two different types of flight control devices, wherein the same test case is executed on each of the at least two different types of flight control devices, the flight data of each flight control device when executing the test case is recorded, and the flight data is compared and analyzed.

5. A UAV simulation and testing system based on a dual-engine coupled architecture, characterized in that, include: The physics simulation module is used to perform physical simulation of the UAV through the physics simulation engine, and generate physical state data and sensor data of the UAV. The state synchronization module is used to synchronize the physical state data to the visual rendering engine; The visual rendering module is used by the visual rendering engine to render the scene where the drone is located based on the physical state data, so as to generate a visual scene. The flight control interface module is used to send the sensor data to the flight control device, so that the flight control device can generate control commands based on the sensor data, receive the control commands generated by the flight control device, and provide the control commands to the physics simulation engine, so that the physics simulation engine can update the motion state of the UAV in the visual scene based on the control commands.

6. The system according to claim 5, characterized in that, The state synchronization module is also used for: Through the shared memory mechanism, the physics simulation engine writes the latest physical state data into the current slot of the circular buffer in the shared memory region and updates the write pointer every preset number of physics simulation steps. At the beginning of each rendering frame, the visual rendering engine reads the latest physical state data from the circular buffer.

7. The system according to claim 5, characterized in that, The state synchronization module is also used for: Between two consecutive synchronizations, the physical state data is interpolated, with quaternion spherical linear interpolation used for attitude and linear interpolation used for position; Using the simulation clock of the physical simulation engine as the master clock and the rendering clock of the visual rendering engine as the slave clock, the time difference is checked before each frame is rendered. If the rendering clock leads the simulation clock, rendering is paused and waited. If the lag of the rendering clock relative to the simulation clock is within a preset threshold, rendering is performed. Otherwise, the rendering is performed after skipping frames to catch up.

8. The system according to claim 5, characterized in that, Also includes: The flight control adaptation module is used to adapt to at least two different types of flight control devices, wherein the sensor data is converted into protocol format data supported by each of the flight control devices, and the control commands generated by each of the flight control devices are uniformly converted into preset normalized values. The test management module is used to conduct comparative tests on the at least two different types of flight control devices, wherein the same test case is executed on each of the at least two different types of flight control devices, the flight data of each flight control device when executing the test case is recorded, and the flight data is compared and analyzed.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores program instructions, and when the processor executes the program instructions, it performs the steps of the method according to any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, perform the steps of the method according to any one of claims 1-4.

Images