Unmanned aerial vehicle parameter management method based on template management

Abstract

The invention relates to the technical field of unmanned aerial vehicle control and management systems, in particular to an unmanned aerial vehicle parameter management method based on template management, and the method comprises the steps: building multi-device concurrent connection with an unmanned aerial vehicle flight control system through a communication abstraction layer, integrating a protocol adaptation module, a port automatic detection engine and a multi-device connection pool, and achieving a unified device access interface; parameters are structured and managed through the core processing module, a dynamic parameter tree, a batch operation engine and a template management system are constructed, verification operation is monitored through the safety control module, and an auditing system, a version control engine and a parameter verification module are integrated. According to the invention, by constructing a modular architecture of a communication abstraction layer, a core processing layer and a security control layer, adopting a dynamic parameter tree, a difference comparison algorithm and a template management system, and combining an operation auditing and atomic transaction writing technology, low resource occupation and high-concurrency batch operation are realized, the production line efficiency is improved, and the production cost is reduced. And parameter consistency, safety and traceability are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) control and management system technology, and in particular to a UAV parameter management method based on template management. Background Technology

[0002] Unmanned Aerial Vehicles (UAVs) are integrated platforms combining sensing, communication, automatic control, and data processing technologies. In recent years, their development has been extremely rapid, with applications expanding from early military reconnaissance and aerial photography to agricultural plant protection, logistics transportation, power line inspection, geographic surveying, and urban emergency management. The flight control system is the core of a UAV, its performance directly determining flight stability, safety, and mission execution capabilities. The operation of the flight control system relies on the precise configuration of numerous internal parameters, involving multiple levels such as sensor calibration, attitude control gain, navigation logic, and fault protection strategies, often numbering in the hundreds or even thousands. Therefore, establishing an efficient, reliable, and standardized parameter management mechanism is of great significance for the research, development, production, and maintenance of UAVs.

[0003] Currently, open-source flight control systems, such as PX4, typically manage parameters through ground station software (GCS). Among these, QGroundControl (QGC) is the most commonly used tool. This software communicates with the flight control system via the MAVLink protocol, provides a graphical interface, and supports reading, modifying, saving, and loading parameters. This design greatly simplifies the operation process during the research and development and debugging phases, meets the needs of personalized prototype development and flight optimization, and promotes the popularization of open-source UAV technology.

[0004] However, as the drone industry shifts towards industrialized production and commercial applications, the limitations of traditional ground station tools in terms of efficiency, reliability, and standardization are becoming increasingly apparent. Systems such as QGroundControl have numerous functions, integrating modules such as maps, videos, mission planning, and firmware upgrades. They consume a lot of CPU and memory resources during operation, making them unsuitable for production terminals or embedded devices with limited hardware and a strong emphasis on cost control. Their parameter retrieval and loading often use a linear traversal method, which can cause significant delays when the number of parameters is large. They also lack the ability to manage multiple devices in parallel, requiring each device to be connected and configured individually on the production line, thus limiting operational efficiency.

[0005] A more prominent problem is that industrial production has extremely high requirements for consistency, traceability, and security, while existing solutions are clearly insufficient in these aspects. They lack standardized parameter templates, and the configuration of different batches or models relies heavily on manual operation and file import, which is prone to errors. They lack version control and operation records, and parameter modifications cannot be tracked. Once a problem occurs, it is difficult to locate the cause. They lack verification of the logical relationship between parameters and verification of the safety range, and they cannot perform operation rollback. Once erroneous parameters are written, they may cause abnormal aircraft control and are difficult to recover.

[0006] Therefore, how to break free from the design constraints of traditional R&D and debugging tools, and design a lightweight UAV parameter management method that is low in resource consumption, can support high-concurrency batch operations, and deeply integrates advanced functions such as parameter template management, version control, security verification, and operation auditing for industrial production scenarios, in order to systematically solve the deep-seated contradictions of existing technologies in terms of production efficiency, deployment cost, process control, and security, has become a key challenge and an urgent technical problem for those skilled in the art. Summary of the Invention

[0007] The purpose of this invention is to provide a template-based method for managing drone parameters, in order to solve the technical problems of existing drone parameter management tools in industrial production scenarios, such as high resource consumption, low operational efficiency, lack of batch processing capabilities, insufficient management standardization, and lack of security mechanisms.

[0008] To achieve the above-mentioned objectives, this invention provides a template-based method for managing UAV parameters, comprising the following steps:

[0009] A multi-device concurrent communication connection is established, which is implemented through a communication abstraction layer. The communication abstraction layer integrates a protocol adaptation module, a connection port automatic detection engine, and a multi-device connection pool.

[0010] Once the communication abstraction layer establishes a communication link with at least one UAV flight control system, a core processing module performs structured management and efficient operation of the internal parameters of the UAV flight control system. The core processing module internally constructs a dynamic parameter tree data structure, a batch operation engine, and a parameter template management system.

[0011] All parameter operations are monitored and verified through a security control module, which integrates an operation audit system, a version control engine, and a parameter verification module to ensure the security, traceability, and consistency of parameter modifications.

[0012] Specifically, the communication abstraction layer is responsible for the underlying physical communication and protocol parsing, providing a unified, stable, and concurrent device access interface for upper-layer applications. The protocol adaptation module has built-in complete encoding and decoding logic for a standardized micro-aircraft communication protocol. The communication protocol specifies the binary data frame format of a series of messages such as parameter requests, parameter settings, heartbeat signals, and acknowledgment responses. The protocol adaptation module abstracts the raw byte stream of physical communication ports (including Universal Asynchronous Receiver / Transmitter interfaces, Universal Serial Bus interfaces, and network sockets based on User Datagram Protocol) into a unified, object-oriented device communication interface, thereby enabling the core processing module to interact with the UAV flight control system in a way that is independent of the physical medium.

[0013] Furthermore, the automatic connection port detection engine is used to automatically identify and configure the correct communication parameters when a physical connection is established, and the engine adopts a sequential detection strategy.

[0014] Intelligent matching verification: When a suspected response data packet is received, the engine will perform strict structural verification and cyclic redundancy check (CRC) calculation on the data packet according to the frame structure of the communication protocol (including start byte, payload length, sequence number, system ID, component ID and checksum). Only after receiving at least three valid data frames with complete structure and passing verification can the current communication baud rate be finally confirmed and this configuration be fixed to complete the connection establishment.

[0015] As one embodiment of the present invention, the multi-device connection pool is used to manage concurrent communication sessions with multiple UAV flight control systems. The connection pool internally maintains a dynamic array or linked list structure, where each element is a connection object. The connection object encapsulates all the status information required to communicate with a single device, including a device unique identifier (UUID), physical port descriptor, negotiated communication rate, message sending and receiving queue, recent activity timestamp, and connection status flags (e.g., connected, connected, idle, disconnected).

[0016] The connection pool employs a scheduling strategy based on the Least Recently Used (LRU) algorithm to manage limited connection resources. For example, when the number of concurrent connections reaches a preset limit (e.g., 16) and a new connection request arrives, the connection pool will automatically select the idle connection with the oldest recent activity timestamp and release it, thereby freeing up resources for the new connection. This mechanism ensures that the system can efficiently serve active devices while automatically cleaning up zombie connections, guaranteeing system stability and responsiveness in high-concurrency scenarios.

[0017] The core processing module is the core of achieving efficient parameter management and operation. The dynamic parameter tree data structure is designed to solve the problem of low retrieval efficiency caused by linear traversal of parameter lists in existing technologies. This data structure is composed of a hash table and a multi-way tree at the bottom layer. The hash table uses the string name of the parameter as the key and the pointer to the corresponding parameter node in the multi-way tree as the value, thereby realizing direct access to any single parameter with constant time complexity (O(1)). The multi-way tree is logically structured according to the functional attributes of the parameters. The root node of the tree is a virtual root, and its next-level nodes represent the highest level functional domain, such as "attitude controller", "position controller", and "sensor calibration". The system includes functional domains such as "Attitude Controller" and "Power Management," each of which can be further subdivided into sub-functional nodes. For example, "Attitude Controller" can contain sub-nodes such as "Roll Ring," "Pitch Ring," and "Yaw Ring." The leaf nodes of the tree are specific parameter objects. Each parameter object is a structure that not only contains the current value of the parameter but also stores its complete metadata, including the parameter name, data type (e.g., 32-bit floating-point, 32-bit integer, Boolean), value range (minimum and maximum values), unit, description information, and a "reboot effective" flag. Through this composite structure, the system can achieve millisecond-level precise lookup through a hash table and provide a collapsible grouped view that conforms to human engineering logic by traversing a multi-branch tree.

[0018] Furthermore, the batch operation engine is specifically designed for batch comparison, synchronization, and modification of UAV parameters. The core of this engine is an incremental difference comparison algorithm based on parameter ID hash indexing. The parameter ID is a unique string identifier for each parameter, used as the key in the hash table. When performing a comparison operation, the engine receives two parameter sets as input: a source parameter set (e.g., from a standard parameter template) and a target parameter set (e.g., the current parameter configuration read from the UAV in real time). The engine first iterates through each parameter in the source parameter set, utilizing the dynamic parameter tree constructed with parameter ID as the key... The hash table directly locates parameter objects with the same parameter ID in the target parameter set within an average time complexity of O(1), and performs precise comparison logic based on the parameter data type: strict equality comparison is performed for integer or Boolean parameters, and fuzzy comparison with tolerance is performed for floating-point parameters, that is, it judges whether the absolute value of the difference between two floating-point values ​​is less than a preset minimum threshold (e.g., 1.0E-6). If it is less, it is considered equal, so as to eliminate false differences caused by differences in floating-point representation between platforms. After the comparison is completed, the engine generates a difference report, which only includes parameter items that differ between the source and target parameter sets, and marks their different values. When performing synchronization operations, the engine generates an incremental update set containing only the parameters to be modified based on the above difference comparison results, and submits the update set to the atomic transaction processing unit to perform write operations, thereby avoiding unnecessary repeated writing of all parameters and significantly improving the batch configuration efficiency of the production line.

[0019] In a preferred embodiment of the present invention, the parameter template management system is used for the standardization, versioning and distribution of parameter configuration. The parameter template is defined as a structured text file that follows the JSON Schema specification. Each template file contains 10 top-level fields: "description", "long_description", "default", "type", "min", "max", "unit", "reboot_required", "category", and "group".

[0020] "description": A brief description field for the parameter, used to describe the core function and design purpose of the parameter in a highly concise manner. This description is usually in bilingual format (Chinese and English) to facilitate quick identification of the parameter's role in cross-team and cross-regional collaboration.

[0021] "long_description": A detailed description field for the parameter, used to provide more in-depth technical background information than "description", including the parameter's functional mechanism, applicable scenarios, recommended configuration methods, and potential side effects. It is usually recorded in both Chinese and English.

[0022] "default": This field indicates the default value used by the parameter when the system is initialized or when it is not manually modified by the user, which is used to ensure that the device has a basic configuration that can run when it is in the factory or reset state;

[0023] "type": This field defines the data type of the parameter, which is used to constrain the storage format and parsing method. For example, enum (enumeration type), int32 (32-bit integer), float (floating-point number), etc. This type determines the encoding standard and value characteristics of the parameter.

[0024] "min and max": These two fields define the minimum and maximum acceptable values ​​of the parameter, respectively, to form the boundary constraints of the parameter and ensure that any written value is within the allowed safe range;

[0025] "unit": This field specifies the unit of the parameter and is used to characterize the physical quantity attribute of the parameter value, such as "V" (voltage), "A / V" (current / voltage ratio), "S" (number of cells in series), etc. If the parameter does not have a physical unit, this field is empty.

[0026] "reboot_required": This field is a boolean type and is used to indicate whether the flight control system needs to be restarted after the parameter is modified for it to take effect. If it is true, it means that this type of parameter has underlying initialization dependencies.

[0027] "category": This field is used to define the major category to which the parameter belongs, forming a first-level category in the parameter tree structure, such as "Battery", so that users can quickly locate the relevant parameter area when browsing and maintaining.

[0028] "group": This field is used to further refine the grouping information of the parameters, and to form more precise functional subgroups under the same category, such as "Battery1" or "GeneralBattery", thereby improving the structure of parameter organization and search efficiency.

[0029] The security control module provides necessary security and quality control mechanisms for the entire parameter management process. The operation audit system is responsible for persistently recording all key parameter operations, forming an immutable audit log. The system's backend uses an embedded relational database management system. With its zero-configuration, serverless, and transactional characteristics, this system is well-suited for resource-constrained industrial terminals. A table named "parameter_audit_log" is created in the database, with the following fields defined: "log_id" (auto-incrementing primary key), "timestamp" (operation time, accurate to milliseconds), "operator_id" (unique operator identifier), "device_uid" (unique identifier of the operated device), and "operation_type" (operation type, such as "READ_PARAM", "WR..."). The database engine is configured in Write-Ahead Logging (WAL) mode, which ensures that even if an unexpected power outage or system crash occurs during the operation, the integrity of the database will not be compromised, and all committed transactions can be recovered, thereby guaranteeing the absolute reliability and integrity of the audit log. The parameters include “ITE_PARAM”, “SYNC_FROM_TEMPLATE”, “LOAD_FILE”, “parameter_name” (the name of the parameter being operated on), “old_value” (the old value of the parameter before modification), “new_value” (the new value of the parameter after modification), “transaction_status” (the transaction status, “SUCCESS” or “FAILED”), and “transaction_id” (used to associate multiple records in the same batch operation).

[0030] Furthermore, the version control engine is tightly integrated with the parameter template management system, enabling refined management of the parameter configuration evolution process. When an existing parameter template is modified and saved, the system prompts the user to select the version number upgrade level (major version, minor version, or revision number) and requires a change description. All historical version template files are archived and stored, and a version list index file is created. The engine provides a version rollback function, allowing users to select any historical version and restore it to the currently active template. The engine also provides a visualization comparison function between versions, which can clearly show the addition, deletion, and modification of parameter values ​​between any two versions, providing crucial data support for troubleshooting and performance optimization analysis.

[0031] As a core security mechanism of the present invention, the parameter verification module performs a final security check before the parameters are written to the drone. The verification logic of this module comes from two aspects: first, the inherent constraints defined in the parameter metadata, such as data type and value range; second, the complex logical dependencies defined in the "dependencies" field of the parameter template. When a write operation (whether it's a single parameter modification or batch synchronization) is triggered, the atomic transaction processing unit first submits the set of parameter changes to be written to the parameter verification module. The verification module checks each change item one by one: first, it verifies whether the value conforms to the parameter's own data type and preset value range; then, it queries the dependency rule base to check whether this change will cause logical conflicts with other existing parameter values. For example, if the rule defines "when the flight mode control parameter 'MPC_POS_MODE' is set to 4 (i.e., autonomous mission mode), the geofence enabling parameter 'GF_ACTION' must not be 0 (i.e., disabled)," then when attempting to set 'GF_ACTION' to 0, if the current value of 'MPC_POS_MODE' is 4, the verification will fail. Only when all parameters in the change set pass the verification will the write operation be allowed to continue; otherwise, the entire operation will be aborted, and a specific error message will be returned to the user, indicating which rule for which parameter failed the verification.

[0032] To ensure the atomicity of the parameter writing process and prevent the drone from being in an unstable state due to unexpected situations such as communication interruptions, this invention also introduces an atomic transaction writing mechanism. This mechanism simulates the logic of a two-phase commit protocol. When a verified "incremental update set" is ready to be written to the device, the system first enters the "preparation phase," creating a rollback log in local memory. This log accurately records the original values ​​of all parameters in the update set before the write operation. Then, in the "execution phase," the system sends instruction messages for setting parameters to the drone one by one through the communication abstraction layer. The system sets a timeout timer for each message and waits for the device's confirmation response. During execution, if all parameter setting instructions receive a successful confirmation response, the system enters the "commit phase," the transaction is marked as successful, and the rollback log in memory is cleared. If any instruction fails to be sent, times out without receiving a response, or receives a negative response during execution, the system will immediately suspend subsequent write operations and enter the "rollback phase." In the rollback phase, the system sends a series of parameter setting instructions to the drone based on the previously created rollback log, restoring all modified parameters to their original values. Through this mechanism, a batch parameter update operation either succeeds completely or fails completely and returns to the initial state, fundamentally eliminating the risk of inconsistent parameter configurations.

[0033] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following:

[0034] This invention constructs a layered modular architecture consisting of a communication abstraction layer, a core processing layer, and a security control layer. It innovatively introduces key technologies such as a dynamic parameter tree data structure, an incremental difference comparison algorithm, a JSONSchema-based template management system, a comprehensive operation auditing mechanism, and atomic transaction writing. This systematically solves many problems faced by existing technologies in the industrial production and deployment of drones. It not only reduces the resource consumption of parameter management to a level that allows for smooth operation on low-cost embedded platforms, but also significantly improves production line efficiency by supporting high-concurrency connections and efficient batch operations. More importantly, its built-in template management, semantic version control, strict parameter verification, and tamper-proof operation auditing functions provide comprehensive guarantees of consistency, security, and traceability for drone parameter configuration in large-scale production, powerfully promoting the industrial application of drone technology. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the system architecture of a template-based UAV parameter management method according to the present invention;

[0036] Figure 2 yes Figure 1 A schematic diagram of the module structure of the communication abstraction layer;

[0037] Figure 3 yes Figure 1 A schematic diagram of the module structure of the core processing module;

[0038] Figure 4 yes Figure 1 A schematic diagram of the module structure of the central security control module;

[0039] Figure 5 This is a flowchart illustrating a template-based drone parameter management method according to the present invention. Detailed Implementation

[0040] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0041] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0042] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0043] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0044] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0045] Reference Figures 1 to 5 This invention discloses a template-based method for managing drone parameters. This method systematically solves the problems of efficiency, standardization, and security in drone parameter management in industrial production scenarios through a carefully designed layered software architecture.

[0046] Reference Figure 1 The overall architecture of this method mainly consists of three core modules:

[0047] A communication abstraction layer responsible for underlying device access and protocol abstraction;

[0048] A core processing module responsible for the structured organization and efficient processing of parameter data;

[0049] And a security control module responsible for ensuring operational compliance and data integrity;

[0050] The three modules work together to provide a stable, efficient, and secure drone parameter management service for upper-layer applications.

[0051] Specifically, the communication abstraction layer, as the cornerstone of the entire system, has the core responsibility of shielding the complexity of the underlying physical communication interface and specific communication protocols, and providing the core processing module with a unified, stable communication interface that supports concurrent access from multiple devices.

[0052] Reference Figure 2 The communication abstraction layer is further divided into three cooperating sub-modules: a protocol adaptation module, a connection port auto-detection engine, and a multi-device connection pool.

[0053] The protocol adaptation module is the core of communication protocol parsing and encapsulation. In a specific embodiment, this module has a built-in complete implementation of a standardized micro-aircraft communication protocol that is widely used in the industry.

[0054] This protocol defines a complete binary data frame format for exchanging information between ground control stations and UAV flight control systems. Each data frame follows a strict structural definition and typically includes a start synchronization byte (e.g., "0xFE"), a payload length byte, a sequence number to prevent message replay, a system ID and component ID to identify the sender and receiver, a message ID to identify the message type, the payload that actually carries the data, and a 16-bit cyclic redundancy check (CRC-16 / X-25) code to verify data integrity.

[0055] The protocol adaptation module internally implements a complete encoder and decoder for the protocol. When it is necessary to send a command to the drone, such as requesting to read a parameter, the core processing module only needs to construct a high-level command object, and the encoder of the protocol adaptation module will automatically serialize it into a binary byte stream that conforms to the protocol specification.

[0056] Conversely, when the raw byte stream is received from the physical communication port, the decoder continuously scans the byte stream to find the starting synchronization byte. Once the frame header is located, the decoder reads the complete potential data frame based on the length information and immediately calculates its CRC checksum.

[0057] A data frame is considered valid only when the calculated checksum exactly matches the checksum carried at the end of the frame. The decoder then deserializes the payload portion into a structured message object that can be understood by the upper-layer application, such as a parameter value message or an acknowledgment message.

[0058] In this way, the protocol adaptation module abstracts various heterogeneous physical communication links, including Universal Asynchronous Receiver / Transmitter (UART) interfaces, Universal Serial Bus (USB) virtual serial ports, and User Datagram Protocol (UDP)-based network sockets, into a unified, object-oriented device communication interface, greatly simplifying the development of upper-layer business logic.

[0059] As one of the key technologies supporting industrialized batch operations in this invention, the multi-device connection pool is responsible for efficiently managing concurrent communication sessions with multiple UAV flight control systems. In a production line environment, operators typically need to connect to and configure multiple devices simultaneously, and the multi-device connection pool 13 provides underlying support for this scenario.

[0060] Internally, the connection pool maintains a dynamic data structure, such as a linked list or dynamic array, to store all active connection objects. Each connection object is a structure that encapsulates all the state information required to communicate with a single device. Key fields include: a unique device identifier (UUID) generated by the flight control system hardware serial number, a port descriptor for physical communication (such as "COM3" or "dev / ttyUSB0"), a communication baud rate negotiated by the automatic detection engine 12, independent send and receive message queues, an activity timestamp recording the time of the most recent successful communication, and a flag indicating the current connection state (e.g., enumeration types: "CONNECTING", "CONNECTED", "IDLE", "DISCONNECTED").

[0061] To serve as many devices as possible despite limited system resources, the connection pool employs an intelligent scheduling strategy based on the Least Recently Used (LRU) algorithm. The system can preset a maximum concurrent connection limit, such as 16. When the pool reaches this limit and a new device connection request arrives, the connection pool automatically scans all connection objects, finding the connection in the "IDLE" state (i.e., currently without active tasks) with the oldest "last_activity_timestamp." This connection is considered the "least active" and is safely closed and released by the connection pool, freeing up resources for new connection requests. This ensures the system prioritizes serving currently active devices and automatically and gracefully cleans up "zombie connections" that may have failed to close properly due to physical disconnection. In high-concurrency, high-turnover production line environments, this guarantees the stability, responsiveness, and resource utilization of the entire system.

[0062] After the communication abstraction layer provides a stable and reliable underlying connection, the core processing module begins to play its core role, realizing the structured management and efficient operation of UAV parameters.

[0063] Reference Figure 3 This module consists of a dynamic parameter tree data structure, a batch operation engine, and a parameter template management system.

[0064] In order to fundamentally solve the problem of low retrieval efficiency (time complexity of O(n)) caused by the use of linear lists to store parameters in traditional parameter management tools.

[0065] This invention designs a dynamic parameter tree data structure, which is composed of a hash table and a multi-way tree at the bottom layer. The two work together to meet the needs of fast random access and logical grouping display. Specifically, the hash table of this data structure uses the unique string name of the parameter (e.g., "MC_PITCHRATE_P") as the key and a pointer or reference that directly points to the corresponding parameter node in the multi-way tree as the value.

[0066] Due to the characteristics of hash tables, the average time complexity of querying the corresponding node by parameter name is constant, i.e., O(1). This allows access to any single parameter to be completed in milliseconds. Meanwhile, the multi-branch tree is responsible for logically structuring hundreds of parameters according to their functional attributes.

[0067] The root node of the tree is a virtual system root node. Its next-level child nodes represent the highest-level functional domains, such as "Attitude Controller," "Position Controller," "Task Planner," "Sensor Calibration," and "Power Management." Each functional domain node can be further subdivided into more specific sub-functional nodes. For example, the "Attitude Controller" node can contain sub-nodes such as "Roll Controller," "Pitch Controller," and "Yaw Controller." The leaf nodes of the tree are the final, concrete parameter objects. Each parameter object is no longer a simple key-value pair, but a structure containing rich metadata.

[0068] This structure defines in detail the various attributes of the parameter, such as the parameter's current value, its data type (e.g., "float32", "int32", "bool"), its valid value range (minimum and maximum values), its physical unit (e.g., "deg / s"), a detailed description for user reference, and a very crucial "restart to take effect" flag, which informs the user whether a restart of the flight controller is required for the changes to take effect after modifying this parameter.

[0069] By using this composite data structure of hash table and multi-way tree, the system can provide the background algorithm with ultimate search performance through hash table, and provide the user interface with a grouped view that conforms to human engineering logic and can be arbitrarily collapsed and expanded by traversing the hierarchical structure of multi-way tree, which greatly improves the user experience of parameter browsing and editing.

[0070] Furthermore, in order to meet the need for standardized configuration of a large number of devices on the production line,

[0071] This invention designs a dedicated batch operation engine. The core of this engine is an incremental difference comparison algorithm based on the high-speed search capability provided by the aforementioned dynamic parameter tree data structure.

[0072] When a user triggers a batch comparison operation, the engine receives two parameter sets as input: a source parameter set as a baseline (usually derived from a standard parameter template file) and one or more target parameter sets as comparison objects (e.g., the current parameter configuration read concurrently from multiple drones in real time). For each target parameter set, the engine iterates through all parameters in the source parameter set. For each parameter in the source parameter set, the engine uses the hash table inside the target parameter set to directly locate the parameter object with the same name in O(1) time.

[0073] The engine performs precise comparison logic based on the data type of the parameters. For integer or Boolean parameters, it performs strict bitwise equality comparison. For floating-point parameters, considering the slight differences in binary representation that may occur between different computing platforms or compilers, the engine adopts a fuzzy comparison strategy with tolerance. Specifically, it calculates the absolute value of the difference between two floating-point values ​​and determines whether the absolute value is less than a preset, extremely small positive threshold (e.g., "1.0E-6"). Only when the absolute value of the difference is less than this threshold is the two floating-point numbers considered equal. This effectively eliminates meaningless "spurious differences" caused by floating-point precision issues.

[0074] After comparing all parameters, the engine generates a difference report for each target parameter set. This report does not simply list all parameters, but only includes those parameters whose values ​​differ between the source and target parameter sets. It clearly indicates the standard value of the parameter in the source template and its current value on the target device. When a user initiates a batch synchronization operation based on the difference report, the batch operation engine will execute the above difference comparison process to generate an "incremental update set" for each device to be synchronized, containing only the parameters to be modified.

[0075] The update set is essentially a list of key-value pairs, where the key is the parameter name and the value is the new value to which the parameter should be modified. The engine submits this highly streamlined incremental update set to an atomic transaction processing unit to perform the final write operation. Compared to the traditional tool that performs a full write operation on all parameters in the template regardless of whether they are the same, this greatly reduces unnecessary communication overhead and the write load on the flight control main control chip, significantly improving the efficiency and reliability of batch configuration on the production line.

[0076] As a preferred embodiment of the present invention, the parameter template management system provides a solid foundation for the standardization, versioning, and distribution of UAV parameter configuration.

[0077] In this invention, a parameter template is strictly defined as a structured text file conforming to the JSON Schema specification. This ensures the template file is both highly readable and easily parsed and validated by the program. Each template file contains 10 top-level JSON fields: "description": A brief description of the parameter, usually including both Chinese and English, for quick understanding of the parameter's function. "long_description": A detailed description of the parameter, providing more in-depth information, including the parameter's specific purpose, working principle, recommended values, etc., also including both Chinese and English. "default": The default value of the parameter, used when the user does not manually set it. "type": The data type of the parameter, determining its value range and storage method, such as `enum` (enumeration), `int32` (32-bit integer), `float` (floating-point number), etc. "min and max": Represent the minimum and maximum allowed values ​​of the parameter, respectively, used to limit the valid range of the parameter. "unit": The unit of the parameter, such as `V` (voltage), `A / V` (current / voltage ratio), `S` (number of cells in series), etc. Some unitless parameters are left blank. "reboot_required": A boolean value indicating whether a system restart is required for the changes to take effect. "category": The general category to which the parameter belongs, such as "Battery", used to organize and categorize the parameter. "group": The specific group to which the parameter belongs, such as "Battery1" or "GeneralBattery", further specifying the application scenario of the parameter.

[0078] To ensure the safety, reliability, and traceability of the entire parameter management process, this invention features a meticulously designed safety control module.

[0079] Reference Figure 4 This module consists of an operation auditing system, a version control engine, and a parameter validation module.

[0080] The operation auditing system is responsible for persistently and immutably recording all critical parameter operations, forming a complete audit log. In a specific embodiment, the backend of this system uses a lightweight embedded relational database management system, such as SQLite. This type of database is chosen because of its zero-configuration, serverless, and transactional characteristics, making it very suitable for deployment on resource-constrained industrial terminals or portable devices. The core table in the database is "parameter_audit_log," whose table structure is carefully designed to capture all necessary operation information. This table defines the following key fields: "log_id" (an auto-incrementing integer primary key), "timestamp" (the time the operation occurred, with precision configured to milliseconds), "operator_id" (the unique employee ID or username of the worker performing the operation), and "device_uid" (the user ID of the device being operated on). The system includes the following parameters: a unique hardware serial number for the UAV flight control system, "operation_type" (the type of operation, represented by an enumeration string such as "READ_PARAM", "WRITE_PARAM", "SYNC_FROM_TEMPLATE", "LOAD_FILE", etc.), "parameter_name" (the name of the parameter when the operation targets a single parameter), "old_value" (the old value of the parameter before modification for write operations), "new_value" (the new value of the parameter after modification), "transaction_status" (the final status of the operation, such as "SUCCESS" or "FAILED"), and "transaction_id" (a unique identifier used to associate multiple parameter modification records involved in the same batch operation).

[0081] To ensure the absolute integrity of log data, the database engine is configured in Write-Ahead Logging (WAL) mode. In this mode, any modifications to the database are first written to a separate WAL file and then synchronized to the main database file at the appropriate time. Even if an unexpected system crash or power outage occurs during the transaction commit process, the database can be restored to a consistent state through the WAL file after the system restarts, thereby ensuring the absolute reliability and non-repudiation of the audit log.

[0082] Furthermore, the version control engine is tightly integrated with the aforementioned parameter template management system, enabling refined and traceable management of the parameter configuration evolution process. When an engineer modifies an existing parameter template and saves it, the system does not directly overwrite the old file. Instead, a dialog box pops up, prompting the user to select the version number upgrade level (major version, minor version, or revision number) corresponding to this change. The system also requires the user to fill in a detailed description of the modification in a text box. After confirmation, the system saves the modified content as a new template file with the updated version number and archives the old version file. All historical version information is recorded in a version list index file. Based on this, the version control engine can provide powerful version management functions.

[0083] Firstly, there is a version rollback function, which allows users to browse a list of all historical versions and their change descriptions, and select any historical version to restore it as the currently active template with one click. Secondly, there is a version difference visualization and comparison function, which allows users to select any two historical versions. The system can call the difference comparison algorithm of the batch operation engine to clearly display the addition, deletion, and modification of all parameters between the two versions in a highlighted or side-by-side comparison manner. This provides crucial historical data support for diagnosing flight performance problems caused by parameter changes or for analyzing flight test data.

[0084] As the core mechanism for ensuring flight safety in this invention, the parameter verification module performs the final and most critical safety check before any parameter is actually written into the UAV. The verification logic of this module comes from two aspects: one is the inherent constraints defined in the parameter object metadata, such as the data type of the parameter and its legal value range; the other is the more complex cross-parameter logical dependency relationship defined in the "dependencies" field of the parameter template file.

[0085] When a write operation (whether it's a user manually modifying a single parameter or performing batch template synchronization) is triggered, the underlying atomic transaction processing unit submits the parameter change set to be written (i.e., the "incremental update set") to the parameter validation module. The validation module iteratively checks each parameter modification item in the change set. For each item, it verifies whether its new value conforms to the data type defined by the parameter itself (e.g., a string cannot be written to a floating-point parameter) and the preset numerical range (e.g., the value of a motor idle speed parameter cannot be less than its safe lower limit). The validation module queries and traverses all dependency rule bases defined in the template to check whether this change will logically conflict with the current values ​​of other parameters on the device. Taking the aforementioned dependency relationship as an example, if the rule defines "when the flight mode control parameter "MPC_PO" When "S_MODE" is set to "4" (i.e., autonomous mission mode), the geofencing enable parameter "GF_ACTION" must not be "0" (i.e., disabled). When a change set contains a modification that attempts to set "GF_ACTION" to "0", the verification module reads the current value of the "MPC_POS_MODE" parameter on the device. If its current value is "4", the modification violates the dependency rule, and the verification fails immediately. Only when all parameter modifications in the change set successfully pass the above two types of verifications can the write operation be allowed to continue. Otherwise, the entire write operation will be aborted, and a specific and informative error message will be returned to the user, clearly indicating which parameter violates which specific verification rule, thereby preventing dangerous parameter configurations that may lead to flight accidents from being written to the device.

[0086] To ensure the atomicity of the parameter writing process and prevent the drone from being in an unstable state where parameters are partially updated due to unexpected situations such as communication interruption or sudden power failure, this invention also introduces an atomic transaction writing mechanism based on two-phase commit logic.

[0087] This mechanism ensures that a batch parameter update operation either succeeds completely or fails completely and restores the device state to its initial state before the operation. When an "incremental update set" that has passed the parameter verification module is ready to be written to the device, the system enters the "preparation phase".

[0088] During this phase, a temporary rollback log is created in the local computer's memory. This log accurately records the original values ​​of all parameters in the update set before this write operation by requesting the current values ​​of the parameters from the device. After the preparation phase is completed, the system enters the "execution phase". In this phase, the system encodes the parameter modification items in the incremental update set into parameter setting instruction messages one by one through the communication abstraction layer and sends them to the drone. The system starts an independent timer with a preset timeout (e.g., "500" milliseconds) for each sent instruction message and waits asynchronously for the device to return the corresponding acknowledgment message (ACK). If all parameter setting instructions successfully receive a positive acknowledgment response from the device before the timeout during the execution phase, the system enters the "commit phase".

[0089] At this stage, the transaction is finally marked as successful, the rollback log in memory is safely cleared, and the entire operation is declared complete. If at any time during the execution phase, any instruction fails to be sent, no response is received within the timeout period, or a negative response (NACK) is received from the device, all subsequent write operations will be immediately aborted, and the process will directly enter the "rollback phase". During the rollback phase, based on the rollback log created in the "preparation phase", a series of new parameter setting instructions will be sent to the drone to accurately restore all parameters that have been modified in this failed transaction to their original values.

[0090] This rigorous transaction mechanism fundamentally eliminates the risk of inconsistent configuration of internal parameters of the flight controller due to various unforeseen circumstances, providing the highest level of assurance for quality control in industrial production.

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

Claims

1. A method for managing UAV parameters based on template management, characterized in that, Includes the following steps: A multi-device concurrent communication connection with at least one UAV flight control system is established through a communication abstraction layer. The communication abstraction layer integrates a protocol adaptation module, a connection port automatic detection engine, and a multi-device connection pool to abstract the underlying physical communication link into a unified device access interface. Once the communication abstraction layer establishes a communication link with the UAV flight control system, a core processing module performs structured management and operation on the internal parameters of the UAV flight control system. The core processing module contains a dynamic parameter tree data structure, a batch operation engine, and a parameter template management system. All parameter operations are monitored and verified through a security control module, which integrates an operation audit system, a version control engine, and a parameter verification module.

2. The method according to claim 1, characterized in that, The connection port automatic detection engine automatically identifies and configures communication parameters through a sequential detection strategy, which includes: Intelligent matching verification: When a suspected response data packet is received, the engine performs structural verification and cyclic redundancy check code calculation on the data packet according to the frame structure of the preset communication protocol, including the start byte, payload length, sequence number, system ID, component ID, and checksum. Only after receiving at least three valid data frames with complete structure and passing verification in succession, the current communication baud rate is confirmed and the connection is established.

3. The method according to claim 1, characterized in that, The multi-device connection pool is used to manage concurrent communication sessions with multiple UAV flight control systems. Internally, the connection pool maintains a dynamic data structure consisting of multiple connection objects. Each connection object encapsulates the status information required for communication with a single device. The status information includes a unique device identifier, physical port descriptor, negotiated communication rate, message sending and receiving queue, recent activity timestamp, and connection status flag. The connection pool adopts a scheduling strategy based on the Least Recently Used algorithm. When the number of concurrent connections reaches a preset limit and a new connection request is received, the connection with the oldest recent activity timestamp that is in an idle state is automatically selected and released to provide resources for the new connection.

4. The method according to claim 1, characterized in that, The batch operation engine employs an incremental difference comparison algorithm based on the hash index of the dynamic parameter tree data structure to perform batch comparison and synchronization of UAV parameters. When performing a comparison operation, the engine receives a source parameter set and a target parameter set, iterates through each parameter in the source parameter set, uses the string name of the parameter as the key to directly locate the parameter object with the same name in the target parameter set, and then performs comparison logic according to the data type of the parameter. For floating-point parameters, a fuzzy comparison with tolerance is performed, that is, it is determined whether the absolute value of the difference between two floating-point values ​​is less than a preset minimum threshold. If it is less, they are considered equal. When performing a synchronization operation, the engine executes the difference comparison process, generates an incremental update set containing only the parameters to be modified, and submits the incremental update set to perform a write operation.

5. The method according to claim 1, characterized in that, The parameter template management system is used for the standardization, versioning, and distribution of parameter configurations. A parameter template is defined as a structured text file conforming to the JSON Schema specification, containing four top-level fields: The "description" field is used to briefly describe the function of this parameter; The "default" field contains the default value for the parameter. The "options" field allows different values ​​to represent different functions for certain parameters; The "reboot_required" field describes whether the parameter takes effect immediately or requires a reboot to take effect.

6. The method according to claim 1, characterized in that, The operation auditing system uses an embedded relational database management system to persistently record all key parameter operations, forming an audit log; A log table is established in the database management system, and its table structure defines the following fields: auto-incrementing primary key, operation timestamp accurate to milliseconds, operator unique identifier, unique identifier of the operated device, operation type, name of the operated parameter, old value of the parameter before modification, new value of the parameter after modification, transaction status, and transaction ID used to associate multiple records in the same batch operation. The database engine is configured in write-before-log mode.

7. The method according to claim 5, characterized in that, The parameter verification module performs a security check before writing parameters into the drone. The verification logic of the module comes from two aspects: These constraints originate from the inherent constraints defined in the parameter metadata, including data type and value range; Complex logical dependencies defined in the "dependencies" field of the parameter template; When a write operation is triggered, the parameter verification module checks each change item in the parameter change set to be written one by one, verifies whether its value conforms to its own data type and numerical range, and queries the dependency relationship rules to check whether this change will cause logical conflicts with other existing parameter values. Write operations are only allowed after all parameters in the change set have passed validation; otherwise, the entire operation will be aborted and a specific error message will be returned.

8. The method according to claim 1, characterized in that, The present invention also includes an atomic transaction write mechanism that simulates the logic of a two-phase commit protocol, the mechanism comprising: Preparation phase: Before the write operation begins, a rollback log is created in local memory. This log accurately records the original values ​​of the parameters to be updated before the write operation. Execution phase: The command messages with set parameters are sent to the UAV one by one through the communication abstraction layer, and a timeout timer is set for each message to wait for the device's confirmation response; Commit phase: If all instructions in the execution phase have successfully received acknowledgments, the transaction is marked as successful and the rollback log is cleared; Rollback Phase: If any instruction fails to be sent, times out without receiving a response, or receives a negative response during the execution phase, the subsequent write operation is immediately suspended, and according to the rollback log, an instruction is sent to the drone to restore all modified parameters to their original values.

9. The method according to claim 5, characterized in that, The version control engine is integrated with the parameter template management system to manage the evolution of parameter configurations. When an existing parameter template is modified and saved, the engine prompts the user to select the major version, minor version, or revision number to upgrade the version level, and forces the user to fill in a change description. All historical version template files are archived and stored. The engine provides a version rollback function, allowing users to select any historical version and restore it to the current active template. It also provides a visual comparison function between versions to show the addition, deletion, and modification of parameter values ​​between any two versions.

Images