A communication interface adaptation method based on MAVLink and uORB

Abstract

The present application relates to the technical field of unmanned aerial vehicle simulation and testing, and particularly relates to a communication interface adaptation method based on MAVLink and uORB. The present application systematically defines the internal uORB and external MAVLink communication protocols, configures the flight control system bidirectional communication mechanism, and constructs the integrated path of the ground station and the simulation model through steps S1 to S6, successfully solves the technical problems of data loss and delay caused by the fixed frequency communication in the existing in-loop simulation being unable to adapt to network fluctuations, and the key control data missing caused by the traditional message level discard strategy.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) simulation and testing technology, and in particular to a communication interface adaptation method based on MAVLink and uORB. Background Technology

[0002] In the development of unmanned aerial vehicle (UAV) systems, hardware-in-the-loop (HIL) simulation is a crucial method for verifying the safety and stability of flight control algorithms. Current HIL simulations typically employ fixed-frequency communication mechanisms, which cannot adapt to dynamic changes in network bandwidth. This leads to data loss and latency during network congestion, affecting simulation realism. Furthermore, existing bandwidth optimization methods often employ message-level drop strategies, which can easily result in the loss of critical control data, jeopardizing flight safety. In addition, communication architectures reliant on middleware (such as ROS / Redis) suffer from complex paths and high latency. Therefore, there is an urgent need for a communication interface method that can dynamically adjust transmission strategies based on network conditions and implement data filtering and completion at the field level to balance simulation real-time performance and data integrity.

[0003] Chinese patent CN117077443B discloses a drone simulation system based on Redis for internal communication, comprising: a data acquisition module for acquiring system data; a Redis replacement module for using Redis middleware to replace the UDP protocol; a containerization module for containerizing the CopterSim model service; and a system application module for applying the Redis-replaced and containerized model service to system communication. This invention uses Redis middleware to replace the UDP protocol, achieving reliable communication between system components. The containerization of the CopterSim model service allows deployment on multiple physical machines via the Redis bus. Adding hosts increases the total computing resources for running the CopterSim and PX4 clusters, thereby horizontally scaling up the supported cluster size. However, this solution still suffers from technical problems: fixed-frequency communication in loop simulation cannot adapt to data loss and latency caused by network fluctuations, and traditional message-level discarding strategies result in the loss of critical control data. Summary of the Invention

[0004] To address this, the present invention provides a communication interface adaptation method based on MAVLink and uORB, which overcomes the technical problems in existing technologies where fixed-frequency communication in loop simulation cannot adapt to data loss and delay caused by network fluctuations, and where traditional message-level discarding strategies cause the loss of critical control data.

[0005] To achieve the above objectives, this invention provides a communication interface adaptation method based on MAVLink and uORB, comprising: Step S1: Define the uORB message structure of the uORB protocol in the PX4 flight control system to obtain a custom uORB message structure. Step S2: In the PX4 flight control system, the MAVLink message structure of the MAVLink protocol is defined according to the custom uORB message structure to obtain the custom MAVLink message structure. Priority attribute tags are added to the message field definition of the custom MAVLink message structure to obtain the custom MAVLink message structure carrying priority tags. Step S3: Configure the message sending mechanism of the MAVLink protocol in the PX4 flight control system, measure the bidirectional communication delay between the PX4 flight control system and the ground station QGC system, dynamically adjust the sending frequency of the message sending stream according to the bidirectional communication delay, and when the bidirectional communication delay exceeds the delay threshold, filter the fields in the custom MAVLink message structure carrying the priority tag according to the priority attribute tag, transmit only the data of the key fields, and set the simplification flag. Step S4: Configure the message receiving mechanism of the MAVLink protocol in the PX4 flight control system and parse the simplified flag. When a simplified message is identified, use the historical data in the message completion cache structure to complete the data of non-critical fields, reconstruct the complete uORB message and publish it to the uORB bus. Step S5: Construct the MAVLink protocol transmission and reception path between the ground station QGC system and the PX4 flight control system according to the custom MAVLink message structure carrying priority markers; Step S6: Construct the simulation interaction route of the PX4 flight control system according to the custom uORB message structure and Simulink model to realize the communication adaptation between the UAV and the UAV hardware-in-the-loop simulation and testing platform.

[0006] Further, step S1, which defines the uORB message structure of the uORB protocol in the PX4 flight control system to obtain a custom uORB message structure, includes: Step S11: Obtain the target intent, which includes the data type and data content to be transmitted; Step S12: Create a uORB message text file according to the target intent. Step S13: Generate uORB code components based on the uORB message text file using a MATLAB script; Step S14: Compile the uORB code component into the PX4 flight control system in the WSL environment.

[0007] Furthermore, the priority attribute label includes: Key field markers are used to mark the necessary fields for real-time flight control in the custom MAVLink message structure carrying priority markers as key fields, including attitude angle, motor speed, and control commands; Non-critical field markers are used to mark the fields that can be delayed in transmission in the custom MAVLink message structure carrying priority markers as non-critical fields, including GPS coordinates, temperature, and system status; The step S2, which involves adding priority attribute tags to the message field definition, includes: Within the field definition tab of the MAVLink message definition file, add a priority attribute tab via extended attribute fields to set... <field type="float" name="roll" priority="Critical">Mark key fields, set <field type="float" name="temperature" priority="Non-critical">Use it to mark non-critical fields.

[0008] Furthermore, the measurement of the bidirectional communication delay between the PX4 flight control system and the ground station QGC system includes: A network delay measurement submodule is deployed in the MAVLink module of the PX4 flight control system. The network delay measurement submodule embeds a timestamp field T_tx in the sent custom MAVLink message and listens for the loopback timestamp T_rx in the confirmation message returned by the ground station QGC system to calculate the two-way communication delay RTT=T_rx-T_tx. The sliding window averaging method is used, and the arithmetic mean of the most recent N measurements is taken as the current network latency RTT_avg, where N=10; The step of dynamically adjusting the sending frequency of the message sending stream based on the bidirectional communication delay includes: A delay threshold range [RTT_min, RTT_max] is set. The RTT_avg is compared with the delay threshold range. The sending frequency of the message stream is dynamically adjusted based on the comparison result, wherein: When RTT_avg≤RTT_min, the transmission frequency will be increased to 1.5 times the initial transmission frequency; When RTT_min < RTT_avg ≤ RTT_max, maintain the initial transmission frequency; When RTT_avg > RTT_max, the transmission frequency will be reduced to 0.5 times the initial transmission frequency.

[0009] Furthermore, when the bidirectional communication delay exceeds the delay threshold, filtering the fields in the custom MAVLink message structure carrying the priority tag according to the priority attribute label includes: When RTT_avg > RTT_max, the message priority queue is enabled; The message priority queue queries the priority attribute tags, extracts only the field data marked as critical field, packages and transmits it, and temporarily stores the field data marked as non-critical field in a local circular buffer.

[0010] 6. The communication interface adaptation method based on MAVLink and uORB according to claim 5, characterized in that setting the simplification flag includes: Set the Trimmed_Flag flag in the message header of the custom MAVLink message, where: When transmitting the complete message, set Trimmed_Flag=0; Set Trimmed_Flag=1 when only key fields are transmitted.

[0011] Furthermore, the step of using historical data in the message completion cache structure to complete the data of non-critical fields includes: In the MAVLink message receiving module of the PX4 flight control system, a message completion cache structure is declared. The message completion cache structure is used to store non-critical field data from the most recently received complete message. When a new message is received, the key field data is extracted, and the corresponding non-key field data is extracted from the message completion cache structure, and then the field-level merging and reconstruction are performed.

[0012] Furthermore, parsing the simplified flag bit, when a simplified message is identified, includes: In the implementation file of the MAVLink message receiving module, the message header of the received MAVLink message is parsed, and the Trimmed_Flag flag is read, where: When Trimmed_Flag=1, the current message is determined to be a simplified message. Historical non-critical field data is extracted from the message completion cache structure and merged with the current critical field to generate a complete uORB message. When Trimmed_Flag=0, the current message is determined to be a complete message. All fields are directly parsed and the non-critical field data in the message completion cache structure is updated.

[0013] Further, step S5 constructs the MAVLink protocol transmission and reception path between the ground station QGC system and the PX4 flight control system based on the custom MAVLink message structure carrying the priority flag. Specifically, this includes: step S51, integrating the custom MAVLink message structure carrying the priority flag into the ground station QGC system and adding a message checksum corresponding to the custom MAVLink message structure to the MAVLink library directory; step S52, implementing the sending function of the custom MAVLink message in the ground station QGC system; and step S53, implementing the receiving and parsing function of the custom MAVLink message in the ground station QGC system, wherein the parsing function includes identifying the simplified flag bit and feeding back an acknowledgment message. Further, step S6 constructs the simulation interaction route of the PX4 flight control system based on the custom uORB message structure and the Simulink model to achieve communication adaptation between the UAV and the UAV hardware-in-the-loop simulation and testing platform. Specifically, it includes: step S61, configuring the uORB message reading function in the Simulink model; step S62, configuring the uORB message writing function in the Simulink model; step S63, generating simulation interaction route code based on the uORB message reading function and the uORB message writing function; and step S64, burning the simulation interaction route code into the PX4 flight control system.

[0014] Compared with existing technologies, the beneficial effects of this invention are as follows: the method optimizes bandwidth while ensuring flight control real-time performance through field-level priority marking and network adaptive mechanisms, and ensures data integrity through historical completion, thereby improving the reliability of HIL simulation. The method creates a custom uORB message structure in step S1, defining an efficient and dedicated internal data exchange format for specific simulation test tasks. This enables simulation data to be transmitted between modules within the PX4 flight control system in an optimized form, providing a structural basis for subsequent protocol conversion and external communication. The method also further optimizes the MAVLink message structure in step S2. The segment definition is extended with priority attribute tags, establishing a field-level differentiated transmission identification system. This enables semantic distinction between key and non-key fields within the message, providing a structured basis for subsequent dynamic filtering and avoiding computational overhead from runtime dynamic judgment. The method also constructs a network latency awareness and frequency adaptive adjustment mechanism in step S3, dynamically adjusting the message transmission frequency based on bidirectional communication latency. This allows the PX4 flight control system to proactively adapt to changes in network conditions, increasing data refresh density to enhance simulation fidelity when the network is smooth and proactively reducing frequency and load when the network is congested. To avoid data storms and achieve adaptive matching between communication rate and network bandwidth, the method further filters fields in custom MAVLink messages carrying priority tags according to the priority attribute label in step S3 when the bidirectional communication delay exceeds the delay threshold. Only data of key fields is transmitted and a simplification flag is set, so that critical control data can still be transmitted with priority even when the network is congested, while non-critical data is delayed and retransmitted. This overcomes the limitations of traditional message-level discarding and significantly improves the arrival rate of control commands and flight safety. The method also utilizes historical data in the message completion cache structure in step S4 when a simplification message is identified. By supplementing the data of non-critical fields and reconstructing the complete uORB message, it is published to the uORB bus. This allows the upper-layer flight control algorithm to receive the uORB message with a complete data structure without needing to detect network fluctuations, ensuring the continuity and stability of the control loop. At the same time, the integrity of the data record is guaranteed through the historical data supplementation mechanism. The method also establishes an interactive connection between the Simulink model and the PX4 flight control system through step S6, enabling researchers to quickly design and verify algorithms in Simulink and seamlessly deploy them to real hardware for hard-in-the-loop testing, thereby improving the efficiency and fidelity of flight control algorithm development. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the communication interface adaptation method based on MAVLink and uORB in this embodiment. Detailed Implementation

[0016] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0017] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0018] It should be noted that in the description of this invention, the terms "upper," "lower," "left," "right," "inner," "outer," etc., indicating directions or positional relationships are based on the directions or positional relationships shown in the accompanying drawings. This is merely for ease of description and does not indicate or imply that the device or element must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of this invention.

[0019] Furthermore, it should be noted that, in the description of this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0020] Please see Figure 1 The diagram shown is a flowchart illustrating the communication interface adaptation method based on MAVLink and uORB in this embodiment. The method includes: Step S1: Define the uORB message structure of the uORB protocol in the PX4 flight control system to obtain a custom uORB message structure. Step S2: In the PX4 flight control system, the MAVLink message structure of the MAVLink protocol is defined according to the custom uORB message structure to obtain the custom MAVLink message structure. Priority attribute tags are added to the message field definition of the custom MAVLink message structure to obtain the custom MAVLink message structure carrying priority tags. Step S3: Configure the message sending mechanism of the MAVLink protocol in the PX4 flight control system, measure the bidirectional communication delay between the PX4 flight control system and the ground station QGC system, dynamically adjust the sending frequency of the message sending stream according to the bidirectional communication delay, and when the bidirectional communication delay exceeds the delay threshold, filter the fields in the custom MAVLink message structure carrying the priority tag according to the priority attribute tag, transmit only the data of the key fields, and set the simplification flag. Step S4: Configure the message receiving mechanism of the MAVLink protocol in the PX4 flight control system and parse the simplified flag. When a simplified message is identified, use the historical data in the message completion cache structure to complete the data of non-critical fields, reconstruct the complete uORB message and publish it to the uORB bus. Step S5: Construct the MAVLink protocol transmission and reception path between the ground station QGC system and the PX4 flight control system according to the custom MAVLink message structure carrying priority markers; Step S6: Construct the simulation interaction route of the PX4 flight control system according to the custom uORB message structure and Simulink model to realize the communication adaptation between the UAV and the UAV hardware-in-the-loop simulation and testing platform.

[0021] Specifically, the communication interface adaptation method based on MAVLink and uORB is applied in a UAV hardware-in-the-loop simulation and testing platform. This method optimizes bandwidth while ensuring flight control real-time performance through field-level priority marking and network adaptive mechanisms, and ensures data integrity through historical completion, thereby improving the reliability of HIL simulation. Specifically, step S1 creates a custom uORB message structure, defining an efficient and dedicated internal data exchange format for specific simulation test tasks. This allows simulation data to be transmitted in an optimized form between modules within the PX4 flight control system, providing a structure for subsequent protocol conversion and external communication. Furthermore, the method further extends the MAVLink message field definition by adding priority attribute tags in step S2, establishing a field-level differentiated transmission identification system. This enables semantic distinction between key and non-key fields within the message, providing a structured basis for subsequent dynamic filtering and avoiding computational overhead caused by dynamic judgment at runtime. The method also constructs a network latency awareness and frequency adaptive adjustment mechanism in step S3, dynamically adjusting the message transmission frequency based on bidirectional communication latency. This allows the PX4 flight control system to proactively adapt to changes in network conditions, increasing data refresh density to enhance simulation performance when the network is readily available. To enhance fidelity, the method proactively reduces frequency and load during network congestion to avoid data storms, achieving adaptive matching between communication rate and network bandwidth. Furthermore, in step S3, when the bidirectional communication delay exceeds a delay threshold, the method filters fields in the custom MAVLink message carrying priority tags based on the priority attribute label, transmitting only data from key fields and setting a simplification flag. This ensures that critical control data is prioritized for transmission even during network congestion, while non-critical data is delayed and retransmitted, overcoming the limitations of traditional message-level discarding and significantly improving the arrival rate of control commands and flight safety. In step S4, when a simplification message is identified, the method utilizes message completion buffering... The method completes the data of non-critical fields in the stored structure by supplementing the historical data, reconstructs the complete uORB message, and publishes it to the uORB bus. This allows the upper-layer flight control algorithm to receive the uORB message with a complete data structure without needing to detect network fluctuations, ensuring the continuity and stability of the control loop. At the same time, the historical data completion mechanism ensures the integrity of the data record. The method also establishes an interactive connection between the Simulink model and the PX4 flight control system through step S6, enabling researchers to quickly design and verify algorithms in Simulink and seamlessly deploy them to real hardware for hard-in-the-loop testing, thereby improving the efficiency and fidelity of flight control algorithm development.

[0022] Specifically, step S1, which defines the uORB message structure of the uORB protocol in the PX4 flight control system to obtain a custom uORB message structure, includes: Step S11: Obtain the target intent, which includes the data type and data content to be transmitted; Step S12: Create a uORB message text file according to the target intent. Step S13: Generate uORB code components based on the uORB message text file using a MATLAB script; Step S14: Compile the uORB code component into the PX4 flight control system in the WSL environment.

[0023] Specifically, the PX4 flight control software refers to an open-source flight control software. The target intent refers to the data type and content to be transmitted as set by the developers. This embodiment does not limit the method of obtaining the target intent; those skilled in the art can set it according to actual conditions, such as having it input in advance by developers. The developers refer to designers who design custom communication interfaces based on MAVLink and uORB. In this embodiment, when creating the uORB message text file according to the target intent, the system first navigates to the " / msg" folder in the firmware source code directory of the PX4 flight control system, for example, the path of the " / msg" folder is "~ / PX4 / Firmware / msg / ". Then, a uORB topic text file with a name that describes the purpose of the message is created in the " / msg" folder, for example, the name of the uORB topic text file is set to "hcsim_data.msg". The number of characters in the uORB topic text file is defined according to the uORB syntax rules. Based on the fields, the uORB message text file is obtained. In this embodiment, when generating the uORB code component based on the uORB message text file using a MATLAB script, the "init_control.m" script is first run using a MATLAB script to call the PX4 flight control system's build system toolchain, triggering the "px4_generate_uorb_topic_headers" code generation task in the build system toolchain. The "px4_generate_uorb_topic_headers" code generation task generates the code corresponding to the uORB message text file based on the uORB message text file, and outputs the code corresponding to the uORB message text file as the uORB code component. The specific implementation method of compiling the uORB code component into the PX4 flight control system in the WSL environment is as follows: In the WSL environment, the PX4 flight control system's compilation command "make" is executed. "px4_fmu-v3_default" compiles the uORB code component into the PX4 flight control system. The full English name of WSL is Windows Subsystem for Linux, which is a feature in modern Windows operating systems. It refers to a highly compatible Linux environment running inside the Windows system.

[0024] Specifically, the priority attribute tags include: Key field markers are used to mark the necessary fields for real-time flight control in the custom MAVLink message structure carrying priority markers as key fields, including attitude angle, motor speed, and control commands; Non-critical field markers are used to mark the fields that can be delayed in transmission in the custom MAVLink message structure carrying priority markers as non-critical fields, including GPS coordinates, temperature, and system status; The step S2, which involves adding priority attribute tags to the message field definition, includes: Within the field definition tab of the MAVLink message definition file, add a priority attribute tab via extended attribute fields to set... <field type="float" name="roll" priority="Critical">Mark key fields, set <field type="float" name="temperature" priority="Non-critical">Use it to mark non-critical fields.

[0025] Specifically, the "real-time control essential fields" refer to data fields that directly affect the real-time calculation of the flight control algorithm and the maintenance of the aircraft's attitude stability during hardware-in-the-loop simulation. Transmission delays or loss of these fields will lead to control loop instability or simulation interruption. The "attitude angles" refer to the angular position states of the aircraft's body coordinate system relative to the ground coordinate system, including pitch, roll, and yaw angles, typically expressed as quaternions or Euler angles, used for attitude calculation and stability control of the flight control system. The "motor speeds" refer to the rotational speeds of the rotor motors of the multi-rotor UAV, typically expressed as revolutions per minute (RPM) or normalized duty cycle (range 0-1), and are crucial for the flight control system to perform attitude and altitude control. The core execution feedback includes control commands, which are actuator drive signals generated by the flight control system based on the control algorithm. These signals include motor ESC control quantities, servo deflection angles, throttle openings, etc., used to directly drive the aircraft actuators to respond. Delayable transmission fields refer to data fields that, during hardware-in-the-loop simulation, have no direct impact on the real-time control loop, allowing for a certain transmission delay or temporary absence during network congestion, and can be retransmitted after network recovery without affecting flight safety. GPS coordinates refer to geographical location information provided by the Global Positioning System, including longitude, latitude, altitude, and positioning accuracy factor, used for navigation and position holding. The full English name of GPS is Global Positioning System. Temperature refers to the temperature monitoring values ​​of sensors, batteries, and motors within the flight control system, used for system health monitoring and over-temperature protection. Its rate of change is much lower than the control cycle, allowing for second-level delays. System status refers to non-critical operating status information of the flight control system, including battery remaining percentage, flight mode, unlock status, and sensor calibration status flags, used for ground station display and log recording, and is a necessary input for non-real-time control closed loops.

[0026] Specifically, the measurement of the bidirectional communication delay between the PX4 flight control system and the ground station QGC system includes: A network delay measurement submodule is deployed in the MAVLink module of the PX4 flight control system. The network delay measurement submodule embeds a timestamp field T_tx in the sent custom MAVLink message and listens for the loopback timestamp T_rx in the confirmation message returned by the ground station QGC system to calculate the two-way communication delay RTT=T_rx-T_tx. The sliding window averaging method is used, and the arithmetic mean of the most recent N measurements is taken as the current network latency RTT_avg, where N=10; The step of dynamically adjusting the sending frequency of the message sending stream based on the bidirectional communication delay includes: A delay threshold range [RTT_min, RTT_max] is set. The RTT_avg is compared with the delay threshold range. The sending frequency of the message stream is dynamically adjusted based on the comparison result, wherein: When RTT_avg≤RTT_min, the transmission frequency will be increased to 1.5 times the initial transmission frequency; When RTT_min < RTT_avg ≤ RTT_max, maintain the initial transmission frequency; When RTT_avg > RTT_max, the transmission frequency will be reduced to 0.5 times the initial transmission frequency.

[0027] Specifically, the network latency measurement submodule refers to an application-layer software component embedded within the MAVLink module of the PX4 flight control system, operating independently of the underlying network protocol stack. The timestamp field is a 64-bit unsigned integer field reserved in the message header or payload area of ​​the custom MAVLink message, used to record the absolute time of message transmission. Its value is obtained by reading the real-time clock of the PX4 flight control system, with an accuracy in the microsecond range. The ground station QGC system refers to the QGroundControl (QGC) open-source ground control station software, a cross-platform UAV ground station application that establishes bidirectional communication with the PX4 flight control system via the MAVLink protocol. Next, the sliding window averaging method refers to a time-domain filtering algorithm. The network delay measurement submodule maintains a circular buffer of length N, storing the RTT values ​​of the most recent N measurements. The current network delay RTT_avg is obtained by calculating the arithmetic mean of the N RTT values. The delay threshold interval refers to the delay judgment boundary preset according to the real-time requirements of HIL simulation. RTT_min is set to 20ms. The reason for this setting is that the flight control cycle in HIL simulation is usually 10ms-20ms. Setting RTT_min to 20ms ensures that when the network delay is less than one control cycle, the system judges the network condition to be excellent, which can increase the data refresh density to enhance simulation fidelity. `_max=100ms` is set because the default message timeout of the MAVLink protocol is typically 500ms-1000ms, while the control loop of the flight control system has a latency tolerance limit of approximately 100ms (exceeding this value will significantly affect control stability). Setting `RTT_max` to 100ms serves as a high latency warning threshold, ensuring proactive frequency reduction and load alleviation before control performance deteriorates. The initial transmission frequency refers to the baseline transmission rate of the message transmission stream during system initialization or when network conditions are normal. It is set by the developers in the stream configuration code segment of the MAVLink main task source file using the `configure_stream_local()` function. In this embodiment, it is set... The initial transmission frequency is set to 5.0f (i.e., 5Hz), which matches the typical control cycle (200ms) of HIL simulation, ensuring that the basic data throughput meets the requirements for flight control algorithm updates. The message transmission stream refers to a software entity in the MAVLink module of the PX4 flight control system, which is a derived class instance inheriting from the MavlinkStream base class. This entity is responsible for converting specific topic data on the uORB bus into MAVLink protocol format at a set frequency and sending it externally. Each message transmission stream corresponds to a specific message ID and has independent transmission cycle control and data packaging logic. This is defined in the MAVLink message stream management source file (mavlink_messages).Registered and managed in the list of flow objects in the .cpp file, the HIL simulation refers to Hardware-In-the-Loop (HIL) simulation, a semi-physical simulation technology that embeds real flight control hardware (such as the PX4 flight control system) into the simulation loop. Through the simulation interface, it interacts with virtual aircraft dynamics models, sensor models, and environmental models in real time to form a closed-loop control system, used for ground verification of the correctness and stability of the flight control algorithm and hardware / software interfaces.

[0028] Specifically, when the bidirectional communication delay exceeds the delay threshold, filtering the fields in the custom MAVLink message structure carrying the priority tag according to the priority attribute label includes: When RTT_avg > RTT_max, the message priority queue is enabled; The message priority queue queries the priority attribute tags, extracts only the field data marked as critical field, packages and transmits it, and temporarily stores the field data marked as non-critical field in a local circular buffer.

[0029] Specifically, the message priority queue refers to a software data filtering unit deployed within the MAVLink module of the PX4 flight control system. It takes the custom MAVLink message carrying priority tags as input, and by parsing the priority attribute tags in the message definition, it traverses, identifies, and extracts each field in the message payload. When a field marked as a critical field is identified, it is extracted to the transmission buffer for packaging and encapsulation. When a field marked as a non-critical field is identified, it is routed to the local circular buffer for temporary storage, thereby achieving differentiated transmission control at the field level within the message. This refers to a circular storage area opened in the memory space of the PX4 flight control system, which adopts a first-in-first-out data management strategy and is used to temporarily store field data marked as non-critical fields that have been filtered out due to network congestion. The local circular buffer has a fixed storage depth (in this embodiment, it is set to store non-critical field data for the most recent 5 periods). When the network condition recovers to RTT_avg≤RTT_max, the MAVLink module extracts historical non-critical field data from the local circular buffer and sends it to the ground station QGC system through an independent retransmission message stream or by appending it to the next complete message to ensure the integrity of the data record.

[0030] Specifically, setting the simplification flag includes: Set the Trimmed_Flag flag in the message header of the custom MAVLink message, where: When transmitting the complete message, set Trimmed_Flag=0; Set Trimmed_Flag=1 when only key fields are transmitted.

[0031] Specifically, the step of using historical data in the message completion cache structure to complete the data of non-critical fields includes: In the MAVLink message receiving module of the PX4 flight control system, a message completion cache structure is declared. The message completion cache structure is used to store non-critical field data from the most recently received complete message. When a new message is received, the key field data is extracted, and the corresponding non-key field data is extracted from the message completion cache structure, and then the field-level merging and reconstruction are performed.

[0032] Specifically, the message completion cache structure refers to a static data structure declared in the MAVLink message receiving module of the PX4 flight control system. Its data field layout is consistent with the custom uORB message structure. It is specifically used to persistently store the field values ​​marked as non-critical fields extracted from the most recently received complete message with Trimmed_Flag=0. The field-level merging and reconstruction refers to the uORB message assembly operation performed in the implementation file (mavlink_receiver.cpp) of the MAVLink message receiving module: when the Trimmed_Flag=1 of the currently received message is parsed, a new uORB message instance is created, and the field data marked as critical fields parsed from the current message payload is directly filled into the corresponding fields. At the same time, the field data marked as non-critical fields with the same name is read from the message completion cache structure and filled into the remaining fields. The complete uORB message is generated by concatenating the field-level data.

[0033] Specifically, parsing the simplified flag bit, when a simplified message is identified, includes: In the implementation file of the MAVLink message receiving module, the message header of the received MAVLink message is parsed, and the Trimmed_Flag flag is read, where: When Trimmed_Flag=1, the current message is determined to be a simplified message. Historical non-critical field data is extracted from the message completion cache structure and merged with the current critical field to generate a complete uORB message. When Trimmed_Flag=0, the current message is determined to be a complete message. All fields are directly parsed, and the non-critical field data in the message completion cache structure is updated. Specifically, the implementation file refers to the source code file corresponding to the header file of the MAVLink message receiving module. It contains the specific logic implementation of the message processing function, the instantiation definition of the uORB publishing object, and the static variable declaration of the message completion cache structure. It is a software entity responsible for parsing and converting the received MAVLink protocol data into uORB message format. The message header refers to the fixed-format header area of ​​the MAVLink protocol data frame, located before the message payload, and includes the magic number, message length, message sequence number, system ID, component ID, message ID, and the Trimmed flag. The step of extracting historical non-critical field data from the message completion cache structure and merging it with the current critical field to generate a complete uORB message refers to the message processing function performing the following operations after recognizing a simplified message with Trimmed_Flag=1: First, create a new uORB message instance according to the custom uORB message structure definition; second, parse and extract field data marked with the critical field marker (such as attitude angle, motor speed, control command) from the currently received MAVLink message payload and fill it into the corresponding field position of the uORB message instance; third, extract data from the message completion cache structure... The structure reads the field data (such as GPS coordinates, temperature, system status) marked as non-critical fields from the most recently updated storage; finally, it fills the remaining field positions of the uORB message instance with the non-critical field data, so that all fields of the uORB message instance contain valid data, forming a complete uORB message ready for publication. Parsing all fields and updating the non-critical field data in the message completion cache structure means that after recognizing a complete message with Trimmed_Flag=0, the message processing function performs the following operations: First, according to the custom MAVLink message structure definition... The process involves: first, parsing all field data in the message payload according to the field order, including fields marked as critical fields and fields marked as non-critical fields; second, filling the newly created uORB message instance with all parsed field data; third, copying the field data marked as non-critical fields from the uORB message instance to the corresponding field positions in the message completion cache structure, overwriting the original historical data; and finally, maintaining the updated message completion cache structure until the next reception process to ensure the time freshness of the cached data, so as to provide the latest non-critical field completion data when receiving a simplified message in the future.Specifically, step S5 constructs the MAVLink protocol transmission and reception path between the ground station QGC system and the PX4 flight control system based on the custom MAVLink message structure carrying priority markers. This includes: step S51, integrating the custom MAVLink message structure carrying priority markers into the ground station QGC system and adding a message checksum corresponding to the custom MAVLink message structure to the MAVLink library directory; and step S52, implementing the sending function of the custom MAVLink message in the ground station QGC system. Step S53: Implement the function of receiving and parsing the custom MAVLink message in the ground station QGC system. The parsing function includes identifying the simplified flag bit and sending back an acknowledgment message.

[0034] Specifically, integrating the custom MAVLink message structure carrying priority markers into the ground station QGC system refers to completely extracting the MAVLink message definition file (common.xml) carrying priority markers defined in the PX4 flight control system, copying it to the corresponding location in the MAVLink library directory (libs / mavlink / include / mavlink / v2.0 / message_definitions / ) of the ground station QGC system, and using the mavgenerate.py tool to generate the ground station MAVLink header file corresponding to the custom MAVLink message structure carrying priority markers. Replace the ground station MAVLink header file in the MAVLink library directory (src / libs / mavlink / include / mavlink / v2.0 / ) of the ground station QGC system to ensure that the priority attribute label definition of the message field is consistent between the ground station QGC system and the PX4 flight control system. Adding the message checksum corresponding to the custom MAVLink message structure to the MAVLink library directory refers to searching for the message checksum (CRC_EXTRA) corresponding to the custom MAVLink message structure carrying the priority flag in the ground station QGC system's MAVLink library directory. The message checksum is based on the message field... The type, order, and priority attribute tags are calculated and generated to verify the consistency of message definition versions between the ground station QGC system and the PX4 flight control system, preventing parsing errors caused by message structure mismatch. Implementing the custom MAVLink message sending function in the ground station QGC system refers to writing and registering a message sending function in the vehicle communication module (Vehicle.cc) of the ground station QGC system. This message sending function constructs a custom MAVLink message instance carrying priority tags according to simulation control requirements, fills in the target data field, and calls the MAVLink library function to send the message frame to the PX4 flight control system via serial port or network link. The implementation of the custom MAVLink message reception and parsing function in the ground station QGC system refers to registering a message processor in the MAVLink message processing module of the ground station QGC system. This message processor listens for the custom MAVLink messages from the PX4 flight control system, parses the message ID in the message header to identify the message type, and reads the Trimmed_Flag flag to determine if the current message is a simplified message. Then, based on the message type, it executes the corresponding data extraction and interface display logic. The feedback confirmation message refers to the ground station QGC system receiving the custom MAVLink message carrying the timestamp field T_tx sent by the PX4 flight control system.The immediately generated response message, whose message ID is associated with the received original message ID, and whose message payload includes the loopback timestamp T_rx (directly copied from the timestamp field T_tx), is returned to the PX4 flight control system via the same MAVLink communication link. Specifically, step S6 constructs the simulation interaction route of the PX4 flight control system based on the custom uORB message structure and the Simulink model to achieve communication adaptation between the UAV and the UAV hardware-in-the-loop simulation and testing platform. This includes: step S61, configuring the uORB message reading function in the Simulink model; step S62, configuring the uORB message writing function in the Simulink model; step S63, generating simulation interaction route code based on the uORB message reading and writing functions; and step S64, burning the simulation interaction route code into the PX4 flight control system. Specifically, in this embodiment, when configuring the uORB message reading function in the Simulink model, the uORB Read module provided by the PX4 flight control system support package is located and imported in the Simulink library browser. The parameters of the uORB Read module are configured, and the topic name of the uORB Read module is set to the topic name of the custom uORB message structure defined in step S1. Similarly, when configuring the uORB message writing function in the Simulink model, the uORB Write Advanced module provided by the PX4 flight control system support package is located and imported in the Simulink library browser. The parameters of the uORB Write Advanced module are configured, and the custom uORB message structure defined in step S1 is specified through its message file selection function. Furthermore, when generating simulation interaction route code based on the uORB message reading and uORB message writing functions, if the Simulink model is equipped with both the uORB Read and uORB Write modules... After the Advanced module, configure the model's code generation options, specify the target hardware as the PX4 flight control system, and start the embedded code generation process to obtain simulation interactive route code that can be compiled and run on the PX4 flight control system. In this embodiment, when burning the simulation interactive route code into the PX4 flight control system, the simulation interactive route code is integrated as a new application module into the PX4 flight control system's firmware project, and the entire PX4 flight control system firmware is recompiled. The recompiled firmware of the entire PX4 flight control system is then burned into the PX4 flight control hardware. Thus far, the technical solution of the present invention has been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention,Those skilled in the art can make equivalent modifications or substitutions to the relevant technical features, and the resulting technical solutions will all fall within the protection scope of this invention.< / field> < / field> < / field> < / field>

Claims

1. A communication interface adaptation method based on MAVLink and uORB, characterized in that, include: Step S1: Define the uORB message structure of the uORB protocol in the PX4 flight control system to obtain a custom uORB message structure. Step S2: In the PX4 flight control system, the MAVLink message structure of the MAVLink protocol is defined according to the custom uORB message structure to obtain the custom MAVLink message structure. Priority attribute tags are added to the message field definition of the custom MAVLink message structure to obtain the custom MAVLink message structure carrying priority tags. Step S3: Configure the message sending mechanism of the MAVLink protocol in the PX4 flight control system, measure the bidirectional communication delay between the PX4 flight control system and the ground station QGC system, dynamically adjust the sending frequency of the message sending stream according to the bidirectional communication delay, and when the bidirectional communication delay exceeds the delay threshold, filter the fields in the custom MAVLink message structure carrying the priority tag according to the priority attribute tag, transmit only the data of the key fields, and set the simplification flag. Step S4: Configure the message receiving mechanism of the MAVLink protocol in the PX4 flight control system and parse the simplified flag. When a simplified message is identified, use the historical data in the message completion cache structure to complete the data of non-critical fields, reconstruct the complete uORB message and publish it to the uORB bus. Step S5: Construct the MAVLink protocol transmission and reception path between the ground station QGC system and the PX4 flight control system according to the custom MAVLink message structure carrying priority markers; Step S6: Construct the simulation interaction route of the PX4 flight control system according to the custom uORB message structure and Simulink model to realize the communication adaptation between the UAV and the UAV hardware-in-the-loop simulation and testing platform.

2. The communication interface adaptation method based on MAVLink and uORB according to claim 1, characterized in that, Step S1, which defines the uORB message structure of the uORB protocol in the PX4 flight control system to obtain a custom uORB message structure, includes: Step S11: Obtain the target intent, which includes the data type and data content to be transmitted; Step S12: Create a uORB message text file according to the target intent. Step S13: Generate uORB code components based on the uORB message text file using a MATLAB script; Step S14: Compile the uORB code component into the PX4 flight control system in the WSL environment.

3. The communication interface adaptation method based on MAVLink and uORB according to claim 1, characterized in that, The priority attribute tags include: Key field markers are used to mark the necessary fields for real-time flight control in the custom MAVLink message structure carrying priority markers as key fields, including attitude angle, motor speed, and control commands; Non-critical field markers are used to mark the fields that can be delayed in transmission in the custom MAVLink message structure carrying priority markers as non-critical fields, including GPS coordinates, temperature, and system status; The step S2, which involves adding priority attribute tags to the message field definition, includes: Within the field definition tab of the MAVLink message definition file, add a priority attribute tab via extended attribute fields to set... <field type="float" name="roll" priority="Critical">Mark key fields, set <field type="float" name="temperature" priority="Non-critical"> Use it to mark non-critical fields.< / field> < / field> 4. The communication interface adaptation method based on MAVLink and uORB according to claim 1, characterized in that, The measurement of the bidirectional communication delay between the PX4 flight control system and the ground station QGC system includes: A network delay measurement submodule is deployed in the MAVLink module of the PX4 flight control system. The network delay measurement submodule embeds a timestamp field T_tx in the sent custom MAVLink message and listens for the loopback timestamp T_rx in the confirmation message returned by the ground station QGC system to calculate the two-way communication delay RTT=T_rx-T_tx. The sliding window averaging method is used, and the arithmetic mean of the most recent N measurements is taken as the current network latency RTT_avg, where N=10; The step of dynamically adjusting the sending frequency of the message sending stream based on the bidirectional communication delay includes: A delay threshold range [RTT_min, RTT_max] is set. The RTT_avg is compared with the delay threshold range. The sending frequency of the message stream is dynamically adjusted based on the comparison result, wherein: When RTT_avg≤RTT_min, the transmission frequency will be increased to 1.5 times the initial transmission frequency; When RTT_min < RTT_avg ≤ RTT_max, maintain the initial transmission frequency; When RTT_avg > RTT_max, the transmission frequency will be reduced to 0.5 times the initial transmission frequency.

5. The communication interface adaptation method based on MAVLink and uORB according to claim 4, characterized in that, When the bidirectional communication delay exceeds the delay threshold, filtering the fields in the custom MAVLink message structure carrying the priority tag according to the priority attribute label includes: When RTT_avg > RTT_max, the message priority queue is enabled; The message priority queue queries the priority attribute tags, extracts only the field data marked as critical field, packages and transmits it, and temporarily stores the field data marked as non-critical field in a local circular buffer.

6. The communication interface adaptation method based on MAVLink and uORB according to claim 5, characterized in that, The setting of the simplification flag includes: Set the Trimmed_Flag flag in the message header of the custom MAVLink message, where: When transmitting the complete message, set Trimmed_Flag=0; Set Trimmed_Flag=1 when only key fields are transmitted.

7. The communication interface adaptation method based on MAVLink and uORB according to claim 1, characterized in that, The step of using message completion to complete the data of non-critical fields in the cache structure includes: In the MAVLink message receiving module of the PX4 flight control system, a message completion cache structure is declared. The message completion cache structure is used to store non-critical field data from the most recently received complete message. When a new message is received, the key field data is extracted, and the corresponding non-key field data is extracted from the message completion cache structure, and then the field-level merging and reconstruction are performed.

8. The communication interface adaptation method based on MAVLink and uORB according to claim 7, characterized in that, The parsing of the simplified flag bit, when a simplified message is identified, includes: In the implementation file of the MAVLink message receiving module, the message header of the received MAVLink message is parsed, and the Trimmed_Flag flag is read, where: When Trimmed_Flag=1, the current message is determined to be a simplified message. Historical non-critical field data is extracted from the message completion cache structure and merged with the current critical field to generate a complete uORB message. When Trimmed_Flag=0, the current message is determined to be a complete message. All fields are directly parsed and the non-critical field data in the message completion cache structure is updated.

9. The communication interface adaptation method based on MAVLink and uORB according to claim 1, characterized in that, Step S5 constructs the MAVLink protocol transmission and reception path between the ground station QGC system and the PX4 flight control system based on the custom MAVLink message structure carrying priority markers. Specifically, it includes: Step S51, integrating the custom MAVLink message structure carrying priority markers into the ground station QGC system and adding a message checksum corresponding to the custom MAVLink message structure to the MAVLink library directory; Step S52, implementing the sending function of the custom MAVLink message in the ground station QGC system; Step S53, implementing the receiving and parsing function of the custom MAVLink message in the ground station QGC system, wherein the parsing function includes identifying the simplified flag bit and feeding back an acknowledgment message.

10. The communication interface adaptation method based on MAVLink and uORB according to claim 1, characterized in that, Step S6 constructs the simulation interaction route of the PX4 flight control system based on the custom uORB message structure and the Simulink model to achieve communication adaptation between the UAV and the UAV hardware-in-the-loop simulation and testing platform. Specifically, it includes: Step S61, configuring the uORB message reading function in the Simulink model; Step S62, configuring the uORB message writing function in the Simulink model; Step S63, generating simulation interaction route code based on the uORB message reading function and the uORB message writing function; Step S64, burning the simulation interaction route code into the PX4 flight control system.

Images