Ground control end data management software architecture suitable for large-scale unmanned aerial vehicle cluster in large-scale block

Abstract

The invention particularly relates to a ground control end data management software architecture suitable for a large-scale block medium-large unmanned aerial vehicle cluster, the data management software architecture adopts a producer-lock-free queue-consumer modular mode to realize data decoupling, and a lock-free queue avoids time consumption of lock competition; one-to-one downlink processing and one-to-many combined one-to-one uplink processing are adopted, all component instances run in independent threads, and multi-type data concurrent processing of hundreds of medium and large unmanned aerial vehicle clusters is supported. The invention provides a high-concurrency, low-delay, high-reliability and configurable ground control end data management software architecture suitable for a large-scale block medium-large unmanned aerial vehicle cluster, solves the problems of insufficient concurrency, too high delay, rigid configuration and low reliability in the prior art, realizes high-efficiency circulation of measurement and control data of a hundred-frame-level medium-large unmanned aerial vehicle cluster, and improves the measurement and control efficiency of the hundred-frame-level medium-large unmanned aerial vehicle cluster. And the cluster real-time control requirement is met.

Description

Technical Field

[0001] This invention relates to the field of unmanned aerial vehicle (UAV) swarm measurement and control technology, and specifically to a data processing gateway software architecture suitable for medium and large-sized UAV swarms. Background Technology

[0002] In large-scale UAV swarm telemetry and control scenarios, the ground control unit needs to process massive amounts of data: downlink telemetry data includes multi-dimensional information such as flight status, mission payload, and system health, while uplink remote control data includes commands such as flight control, mission planning, and link locking. Furthermore, the data volume of a single medium-to-large UAV far exceeds that of a small UAV, placing extremely high demands on the concurrency, real-time performance, and reliability of data processing. Current technologies suffer from the following core problems: (1) Insufficient concurrent processing capability: Traditional architectures often adopt a modular approach of "single-thread / few threads + shared memory". Multiple types of telemetry / remote control data share the same processing channel, which is prone to data blocking and cannot cope with the massive concurrent input of data from hundreds of medium and large UAVs; (2) Difficulty in delay control: There is a lack of efficient decoupling mechanism in the data receiving, decoding, distribution and sending links, and multi-threaded synchronization depends on the lock mechanism (such as mutex lock). Lock contention leads to increased delay (usually more than 500 microseconds), which cannot meet the real-time control requirements of medium and large-sized UAV clusters. (3) Poor configuration flexibility: The receiving port and processing logic of telemetry / remote control data are bound to the hardware. When adding a new type of drone or adjusting the data type, the core code needs to be modified. It is impossible to quickly adapt to different cluster sizes or task scenarios through configuration. (4) Low data reliability: Lacking traffic peak shaping mechanism, when the UAV suddenly generates a large amount of telemetry data (such as fault alarm), data loss or overflow is likely to occur, resulting in the ground control terminal being unable to accurately obtain the cluster status. The aforementioned issues make it difficult for the existing ground control terminal data management architecture to support stable and real-time measurement and control of large-scale UAV clusters, thus restricting the expansion of application scenarios for medium and large-scale UAV clusters.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] This invention provides a ground control terminal data management software architecture and method suitable for large-scale UAV clusters in large-scale blocks, a computer-readable storage medium, and a computer program product, which can effectively overcome the defects existing in the prior art.

[0005] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0006] According to a first aspect of the present invention, a ground control terminal data management software architecture suitable for large-scale UAV swarms in large-scale blocks is provided, the data management software architecture comprising: The telemetry data processing module is used to queue and cache telemetry data based on the data type of the telemetry data, and encapsulate the telemetry data in the queue to obtain telemetry messages in the target format. The single-instance interface module is used to push telemetry messages to the backend application software and receive remote control commands sent by the backend application software. The remote control command processing module is used to distribute remote control commands to the target processing channel for encoding based on the command type of the remote control command, obtain remote control instructions, and send the remote control instructions to the UAV cluster through the corresponding communication port.

[0007] In some exemplary embodiments, the telemetry data processing module includes: The telemetry data receiving submodule contains multiple telemetry receivers, which are used to receive telemetry data through communication ports bound to the telemetry receivers, and use the telemetry receivers to write the telemetry data into the corresponding telemetry queue according to the data type of the telemetry data. The telemetry data buffer submodule contains multiple telemetry queues, which are used to cache telemetry data into the corresponding telemetry queue based on the data type of the telemetry data; The telemetry data decoding submodule contains multiple telemetry processors, which are used to read telemetry data from the corresponding telemetry queue, decode the telemetry data using the corresponding telemetry processor, encapsulate the decoded telemetry fields according to the target format, and generate telemetry messages.

[0008] In some exemplary embodiments, the remote control command processing module includes: The remote control command encoding submodule is used to buffer and distribute the remote control commands output by the single instance interface module, and encode the remote control commands according to the command type to generate remote control instructions that can be recognized by the UAV cluster. The remote control command sending submodule is used to send remote control commands to the drone cluster via the corresponding communication port.

[0009] In some exemplary embodiments, the remote control data encoding submodule includes: The remote control command buffer unit contains multiple command queues, which are used to cache remote control commands into the corresponding command queues based on the command type of the remote control command. The remote control command encoding unit contains multiple remote control processors, which are used to read remote control commands from the command queue, select a target remote control processor from the multiple remote control processors according to the command type of the remote control command, and encode the remote control command using the target remote control processor to obtain the remote control instruction.

[0010] In some exemplary embodiments, the remote control data transmission submodule includes: The remote control command buffer unit contains multiple command queues, which are used to cache remote control commands into the corresponding command queues based on the command type of the remote control command. The remote control command sending unit includes multiple remote control transmitters, which are used to read remote control commands from the command queue and send the remote control commands to the UAV cluster through the communication port corresponding to the remote control transmitter.

[0011] According to a second aspect of the present invention, a ground control terminal data management method suitable for large-scale UAV swarms in large-scale blocks is provided, applied to the above-described data management software architecture, the method comprising: Based on the data type of the telemetry data, the telemetry data is queued and cached, and the telemetry data in the queue is encapsulated to obtain the telemetry message in the target format. Push telemetry messages to the backend application software and receive remote control commands sent by the backend application software; Based on the command type of the remote control command, the remote control command is distributed to the target processing channel for encoding to obtain the remote control instruction, and then sent to the UAV cluster through the corresponding communication port.

[0012] In some exemplary embodiments, the queued caching of telemetry data based on the data type of the telemetry data includes: Write the telemetry data into the corresponding telemetry queue according to the data type of the telemetry data; Telemetry data is cached using a telemetry queue.

[0013] In some exemplary embodiments, the command type based on the remote control command distributes the remote control command to the target processing channel for encoding to obtain remote control instructions, including: Based on the command type of the remote control command, the remote control command is cached in the corresponding command queue; Read the remote control commands in the command queue and select the target remote control processor from multiple remote control processors according to the command type of the remote control command; The remote control commands are encoded using the target remote control processor to obtain remote control instructions.

[0014] According to a third aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, the device where the storage medium is located controls the execution of the above-described ground control terminal data management method applicable to large-scale UAV swarms in large-scale blocks.

[0015] According to a fourth aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the above-described ground control terminal data management method applicable to large-scale UAV swarms in large-scale blocks.

[0016] According to a fifth aspect of the present invention, an electronic device is provided, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to implement the above-described ground control terminal data management method for large-scale UAV clusters in a large-scale block by executing the executable instructions.

[0017] The embodiments of this invention provide a ground control terminal data management software architecture and method suitable for large-scale UAV swarms in large-scale blocks. For the downlink telemetry link, a "multi-port access + queued buffer relay + processor decoding and encapsulation" approach is adopted. Telemetry data is received through multiple communication ports, written to the corresponding telemetry queue according to data type, and then read and decoded by the telemetry processor. The decoded fields are encapsulated according to the target format to form telemetry messages, thereby reducing the interaction interference of different types of telemetry data and improving the processing stability in scenarios with sudden data arrival. For the uplink remote control link, a "single-instance interface aggregation + dual-queue buffer distribution + independent port transmission" approach is adopted. The single-instance interface module uniformly pushes telemetry messages and receives backend remote control commands. After the remote control commands are written to the command distribution queue, the remote control processor parses and encodes them to generate remote control instructions and writes them to the instruction transmission queue. The remote control transmitter reads the instructions from the corresponding instruction queue and sends them to the UAV swarm through an independent port, thereby improving the distribution and transmission efficiency of remote control commands and reducing the blocking risk under multi-threaded / multi-channel concurrency. This invention utilizes methods such as queued buffer relay, single-instance interface aggregation, and dual-queue distribution to achieve modular decoupling and channel isolation of telemetry and remote control links. This achieves the technical effect of improving the data throughput, latency stability, and operational reliability of the system in large-scale block cluster scenarios, and facilitates expansion and deployment according to cluster-scale blocks.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0020] Figure 1 This illustration schematically shows a ground control terminal data management software architecture suitable for large-scale UAV clusters in a large-scale block according to an exemplary embodiment of the present invention; Figure 2 The diagram illustrates an exemplary embodiment of the present invention: a ground control terminal data management software architecture suitable for large-scale UAV clusters in a large-scale block. Figure 3 This schematically illustrates a flowchart of a ground control terminal data management method for large-scale UAV clusters in a large-scale block, as an exemplary embodiment of the present invention. Figure 4 The diagram illustrates the composition of an electronic device according to an exemplary embodiment of the present invention. Detailed Implementation

[0021] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0022] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0023] Existing data processing gateway software for drone swarms suffers from insufficient parallel processing capabilities, excessive latency, and rigid adaptation, failing to meet the routine monitoring and control needs of 10-30 medium to large drone swarms. This restricts the modular application of medium to large drones in scenarios such as regional emergency response and small-scale military training. Specifically: (1) M100 medium and large UAV ground station: According to its official release of the "M100 medium and large UAV ground station V2.1 technical manual" (document number: M-GS-2023-001), the solution adopts the "single processor + shared memory" design, which can only support a maximum of 10 medium and large UAVs working at the same time. After more than 10 UAVs, the data blocking rate is ≥80%, the average data processing delay is 12.5 seconds, and the core code needs to be modified and recompiled when adding a new UAV. The adaptation period is 7 days. (2) UAV Measurement and Control System X-Cluster: Its official GitHub repository (https: / / github.com / X-Cluster / UAV-Control) clearly states in the "V3.0 System Deployment Guide" that the core architecture is "single processing thread + thread synchronization lock", which can support a maximum of 5 medium and large UAVs. The system will be completely paralyzed after more than 5 UAVs, with a monthly failure rate of 15.0%. Adjusting the data type requires reconstructing the data receiving module, with an adaptation period of 5 days. (3) Y-20 small cluster ground control terminal: This control terminal adopts the "dual processor + hardware port binding" design, which can support a maximum of 8 medium and large UAVs. After more than 8 UAVs, the delay exceeds 20 seconds, the monthly failure rate is 12.0%, and new UAVs need to be re-bound to the hardware port, with an adaptation period of 6 days.

[0024] Among them, medium and large-sized drones refer to the size of the individual drone and its maximum effective payload weight. A maximum effective payload of 25kg or more is considered medium-sized, and 150kg or more is considered large-sized. Medium and large-sized drones encompass both categories. For example, the Ruiying 800A has a maximum effective payload of 150kg, making it a medium and large-sized drone.

[0025] To address the shortcomings and deficiencies of existing technologies, this example implementation provides a ground control terminal data management software architecture suitable for large-scale UAV swarms in large-scale blocks. (Reference) Figure 1 As shown, it can specifically include: The telemetry data processing module 10 is used to queue and cache telemetry data based on the data type of the telemetry data, and encapsulate the telemetry data in the queue to obtain a telemetry message in the target format. The single-instance interface module 12 is used to push telemetry messages to the backend application software and receive remote control commands sent by the backend application software. The remote control command processing module 14 is used to distribute the remote control command to the target processing channel for encoding based on the command type of the remote control command, obtain the remote control instruction, and send the remote control instruction to the UAV cluster through the corresponding communication port.

[0026] Based on embodiments of the present invention, a ground control terminal data management software architecture and method suitable for large-scale UAV swarms in large-scale blocks are provided. For the downlink telemetry link, a method of "multi-port access + queued buffer relay + processor decoding and encapsulation" is adopted to reduce the interactive interference of different types of telemetry data and improve the processing stability in scenarios with sudden data arrival. For the uplink remote control link, a method of "single-instance interface aggregation + dual-queue buffer distribution + independent port transmission" is adopted to improve the distribution and transmission efficiency of remote control commands and reduce the blocking risk under multi-threaded / multi-channel concurrency.

[0027] The following will describe in more detail the various modules of a ground control terminal data management software architecture suitable for large-scale UAV clusters in this exemplary embodiment, with reference to the accompanying drawings and embodiments.

[0028] For example, the telemetry data processing module 10 includes: The telemetry data receiving submodule 101 includes multiple telemetry receivers, which are used to receive telemetry data through communication ports bound to the telemetry receivers, and use the telemetry receivers to write the telemetry data into the corresponding telemetry queue according to the data type of the telemetry data. The data type of the aforementioned telemetry data is used to characterize the service category to which the telemetry data sent by the UAV swarm belongs, indicating the source payload or data content category corresponding to the telemetry data, as well as the message structure or set of fields used by the telemetry data. The data type can be determined by the mapping relationship between the type field and / or message identifier (MsgID) in the data packet header of the telemetry data and the port number.

[0029] Optionally, the data types of telemetry data include, but are not limited to: flight status telemetry (such as attitude angle, speed, altitude), navigation and positioning telemetry (such as latitude and longitude, heading, timestamp), payload mission telemetry (such as mission payload working status, sensor measurements), health monitoring telemetry (such as battery level, temperature, motor / servo status), and / or link status telemetry (such as signal strength, packet loss rate, latency information), etc.; wherein, telemetry data of different data types are written into their corresponding data type queues so that they can be read and decoded by the corresponding telemetry processors.

[0030] The telemetry data buffer submodule 102 contains multiple telemetry queues, which are used to cache telemetry data into the corresponding telemetry queue based on the data type of the telemetry data. The aforementioned telemetry queues are used to characterize queued cache channels corresponding to different telemetry data types. Each telemetry queue corresponds to a type of telemetry data, stores multiple data units of that type of telemetry data, and serves as the source queue for subsequent telemetry processors to read and process that type of telemetry data.

[0031] For example, flight status telemetry queues, navigation and positioning telemetry queues, payload mission telemetry queues, health monitoring telemetry queues, and / or link status telemetry queues can be set up. When telemetry data of the corresponding type is received, it is written to the corresponding telemetry queue, and then the telemetry processor corresponding to that telemetry queue reads it from the queue and decodes and encapsulates it.

[0032] The telemetry data decoding submodule 103 contains multiple telemetry processors, which are used to read telemetry data from the corresponding telemetry queue, decode the telemetry data using the corresponding telemetry processor, encapsulate the decoded telemetry fields according to the target format, and generate telemetry messages.

[0033] The aforementioned target format characterizes the output data structure / field organization specifications of telemetry messages. It defines the field set, field order, data type, unit, and encoding method of telemetry fields, ensuring that telemetry data from different sources and of different types can be output in a unified or preset message structure after decoding and recognized and processed by backend application software. Furthermore, the target format can be defined by a preset protocol module board, message definition file, and / or data dictionary.

[0034] For example, the target format can be JSON, XML, Protocol Buffers (protobuf), or a custom TLV (Type-Length-Value) structured message format. In one example, the telemetry message may include a message header (including message identifier, timestamp, and data type identifier) ​​and a message body (including telemetry fields such as attitude angle, velocity, altitude, latitude and longitude, and battery level), and be encapsulated according to the field order and encoding rules corresponding to the target format before being output.

[0035] Specifically, the telemetry data receiving submodule 101 includes multiple telemetry receivers, each of which is bound to a corresponding communication port to receive telemetry data sent by the UAV cluster via its bound communication port. After receiving the telemetry data, the telemetry receiver obtains the data type information of the telemetry data and writes the telemetry data into the corresponding telemetry queue in the telemetry data buffer submodule 102 according to the data type.

[0036] Specifically, the telemetry data buffer submodule 102 includes multiple telemetry queues for caching telemetry data written by the telemetry data receiving submodule 101. Each telemetry queue is associated with a specific data type, and each telemetry queue instance uniquely corresponds to one telemetry receiver and one telemetry processor, serving as a data transfer channel between the receiver and processor. When a telemetry receiver receives telemetry data of a specific data type, it writes the data to the telemetry queue that corresponds to and is uniquely bound to that data type. When the telemetry processor uniquely bound to that queue performs a read operation, it reads the telemetry data to be processed from the queue and enters the decoding process.

[0037] In an optional implementation, the telemetry queue is a lock-free safe queue to support concurrent writes and reads in multi-threaded scenarios.

[0038] Specifically, the telemetry data decoding submodule 103 includes multiple telemetry processors, each of which establishes a unique correspondence with a telemetry queue in the telemetry data buffer submodule 102. Each telemetry processor is used to read telemetry data from its uniquely corresponding telemetry queue and decode the read telemetry data. After decoding, the decoded telemetry fields are encapsulated according to the target format to generate a telemetry message for subsequent modules to push or distribute.

[0039] Based on the telemetry data processing module 10, the telemetry data processing process includes: the telemetry receiver receiving telemetry data → writing it into a unique corresponding telemetry queue according to the data type → the corresponding telemetry processor reading the telemetry data from the telemetry queue → decoding → encapsulating it into a telemetry message according to the target format.

[0040] For example, the single-instance interface module 12 is a singleton object of the backend interface class, which is a globally unique instance used for bidirectional data interaction with the backend application software.

[0041] Specifically, the single-instance interface module 12 is used to perform the following processing procedures: 1) Telemetry message push: Receive telemetry messages output from the telemetry data buffer processing module, and send / push the telemetry messages to the backend application software through the communication interface established with the backend application software; 2) Remote command reception: Receive remote commands sent by the backend application software and output the remote commands as input data of the uplink processing link to the remote command buffer processing module, so that the single instance interface module 12 constitutes the entry point of the uplink remote command data stream.

[0042] Since the singleton object of the backend interface class corresponding to the singleton interface module 12 is a globally unique instance, during system operation, all telemetry messages pushed to the backend application software and the backend application software issued remote control commands are completed through this single instance, so as to achieve unified management of backend interactive connections and data channels.

[0043] For example, the remote control command processing module 14 includes: The remote control command encoding submodule 141 is used to buffer and distribute the remote control commands output by the single instance interface module, and encode the remote control commands according to the command type to generate remote control instructions that can be recognized by the UAV cluster. The command type of the aforementioned remote control command is used to characterize the control category to which the remote control command belongs, indicating the controlled object and control content corresponding to the remote control command, as well as the parameter set and encoding rules adopted by the remote control command. The command type can be determined by the command word, command identifier (CmdID), and / or command header field of the remote control command, and is used to distribute the remote control command to the matching remote control processor for parsing and encoding.

[0044] For example, the types of remote control commands include, but are not limited to: flight control commands (such as takeoff, landing, heading / speed / altitude control), route mission commands (such as uploading waypoints, starting / pausing / ending missions), payload control commands (such as camera on / off, zoom, gimbal rotation, sensor working module settings), communication link commands (such as link switching, frequency / power configuration), and system management commands (such as parameter configuration, time synchronization, restart / reset). After being buffered and distributed, remote control commands of different types are encoded by the corresponding remote control processor to generate remote control instructions that can be recognized by the UAV swarm.

[0045] The remote control command sending submodule 142 is used to send remote control commands to the UAV cluster via the corresponding communication port.

[0046] Specifically, the remote control command encoding submodule 141 writes the remote control command into the corresponding command queue according to the command type of the remote control command, and the remote control processor reads the remote control command from the corresponding command queue for parsing and encoding to generate remote control instructions that can be recognized by the UAV cluster.

[0047] Specifically, the remote control command sending submodule 142 reads remote control commands from the command queue and sends the remote control commands to the UAV cluster via the communication port corresponding to the command type, thereby realizing the issuance of remote control commands to the UAV cluster.

[0048] For example, the remote control data encoding submodule 141 includes: The remote control command buffer unit 201 contains multiple command queues, which are used to cache remote control commands into the corresponding command queues based on the command type of the remote control command. The remote control command encoding unit 202 includes multiple remote control processors, which are used to read remote control commands in the command queue, select a target remote control processor from the multiple remote control processors according to the command type of the remote control command, and encode the remote control command using the target remote control processor to obtain a remote control instruction.

[0049] Specifically, the command queue includes at least one command distribution queue, which is a single queue shared by multiple remote controllers, and is used to cache remote control commands to be encoded. Upon receiving a remote control command, the command is written to the command queue corresponding to that command type, based on the command type of the remote control command. When a command distribution queue is used, the remote control command is written to that command distribution queue for subsequent reading and processing by the remote controllers.

[0050] Specifically, the remote control processor reads remote control commands from the command queue and, based on the command type, selects a target remote control processor from among multiple remote control processors that matches the command type. The target remote control processor then parses and encodes the remote control commands to obtain remote control instructions that the UAV can recognize. Thus, the remote control processor simultaneously functions as a "command consumer" (reading and parsing remote control commands) and an "instruction producer" (outputting the encoded remote control instructions) during the processing.

[0051] Furthermore, the multiple remote control processors are multiple instances of the same remote control processing class. Each instance is used to parse a specific type of remote control command and encode it to generate a remote control instruction that the UAV can recognize. After generating the remote control instruction, the remote control processor writes the remote control instruction into the corresponding instruction sending queue in the remote control instruction buffer unit, and then the remote control transmitter corresponding to the instruction sending queue completes the transmission.

[0052] For example, the remote control data transmission submodule 142 includes: The remote control command buffer unit 301 includes multiple command queues, which are used to cache remote control commands into the corresponding command queues based on the command type of the remote control command. The remote control command sending unit 302 includes multiple remote control transmitters, which are used to read remote control commands from the command queue and send the remote control commands to the UAV cluster through the communication port corresponding to the remote control transmitter.

[0053] Specifically, the instruction queue includes at least multiple instruction sending queues, wherein each instruction sending queue is associated with a remote control processor and a UDP transmitter, thereby serving as an instruction transmission channel between the remote control processor and the UDP transmitter.

[0054] In one embodiment, after the remote control processor completes the encoding of the remote control command, it writes the obtained remote control instruction into the instruction sending queue corresponding to the remote control processor; the remote control instruction buffer unit 301 can also classify the remote control instruction based on the instruction type of the remote control instruction and cache the remote control instruction into the instruction queue corresponding to the instruction type.

[0055] Specifically, the remote control command sending unit 302 includes multiple remote control transmitters, each bound to an independent communication port and running on an independent thread. These transmitters read remote control commands from their corresponding command queue and send the commands to the UAV cluster via the communication port corresponding to their respective transmitter. Thus, the remote control transmitter acts as a consumer of remote control commands, enabling the network transmission and distribution of these commands.

[0056] The data management software architecture provided in this embodiment of the invention is based on... Figure 2 As shown. Figure 2 The diagram clearly illustrates the connection relationships and data flow paths of the modules in this invention, intuitively demonstrating the core design of "producer-lockless queue-consumer".

[0057] Specifically, the diagram includes a large and medium-sized UAV cluster, a telemetry data receiving submodule, a telemetry data buffering submodule, a telemetry data decoding submodule, a single-instance interface module, backend application software, a remote control command encoding submodule, and a remote control command sending submodule. The telemetry data receiving submodule consists of a UDP receiver cluster, including telemetry UDP receiver 1 to telemetry UDP receiver n; the telemetry data buffering submodule consists of a telemetry data queue group, including telemetry CAS security queue 1 to telemetry CAS security queue n; the telemetry data decoding submodule consists of a telemetry processor cluster, including telemetry processor 1 to telemetry processor n; the single-instance interface module is a singleton object of the backend interface class; the remote control command encoding submodule includes a remote control command buffer unit and a remote control command encoding unit; and the remote control command sending submodule includes a remote control command buffer unit and a remote control command sending unit.

[0058] The remote control command buffer unit consists of a remote control lockless queue group, including command distribution CAS secure queue 1 to command distribution CAS secure queue n; the remote control command encoding unit consists of a remote control processor cluster, including remote control processor 1 to remote control processor n; the remote control instruction buffer unit consists of a remote control lockless queue group, including instruction transmission CAS secure queue 1 to instruction transmission CAS secure queue n; and the remote control instruction transmission unit consists of a UDP receiver cluster, including remote control UDP transmitter 1 to remote control UDP transmitter n.

[0059] Furthermore, the downlink telemetry data processing process is as follows: large and medium-sized UAV cluster → UDP receiver cluster → telemetry lockless queue group → telemetry processor cluster → backend interface class singleton object → backend application software. Uplink remote control command processing: Backend application software → Backend interface class singleton object → Remote control lock-free queue group (command distribution queue) → Remote control processor cluster → Remote control lock-free queue group (instruction sending queue) → UDP transmitter cluster → Large and medium-sized UAV cluster.

[0060] This example implementation provides a ground control data management method suitable for large-scale UAV swarms in large-scale blocks, applied to the data management software architecture described above. (Reference) Figure 3 As shown, it can specifically include: Step S30: Based on the data type of the telemetry data, the telemetry data is queued and cached, and the telemetry data in the queue is encapsulated to obtain a telemetry message in the target format. In step S30, the target format telemetry message is used to define the output structure of the telemetry message. The target format includes at least a message header and a message body. The message header carries general identification information of the message, and the message body carries the telemetry fields obtained from the decoded telemetry data. The message header may include at least some of the following fields: msg_id: Message identifier used to distinguish different message types; data_type: Data type identifier, used to identify the category to which the telemetry message belongs; uav_id: Drone identifier, used to identify the drone from which the message originated; timestamp: A timestamp used to represent the time corresponding to telemetry data; seq: Sequence number, used to identify the message sequence number; len: Length field, used to represent the length of the message body or the entire frame; crc / checksum: Validation field used to represent the validation value (optional).

[0061] The message body can use different sets of fields depending on the data_type. For example: When data_type = flight status, the message body can include: roll, pitch, yaw, airspeed / groundspeed, altitude, etc. When data_type=navigation positioning, the message body may include: lat, lon, heading, position_valid, etc.; When data_type = health status, the message body can include: battery_percent, temperature, fault_code, etc.

[0062] The data type, unit, and precision of each field can be specified by a preset data dictionary or message definition file.

[0063] Step S32: Push the telemetry message to the backend application software and receive the remote control command sent by the backend application software. Step S34: Based on the command type of the remote control command, the remote control command is distributed to the target processing channel for encoding to obtain the remote control instruction, and then sent to the UAV cluster through the corresponding communication port.

[0064] Based on steps S30 to S34 above, for the downlink telemetry link, a method of "multi-port access + queued buffer relay + processor decoding and encapsulation" is adopted to reduce the interaction interference of different types of telemetry data and improve the processing stability in scenarios with sudden data arrival. For the uplink remote control link, a method of "single-instance interface aggregation + dual-queue buffer distribution + independent port transmission" is adopted to improve the distribution and transmission efficiency of remote control commands and reduce the blocking risk under multi-thread / multi-channel concurrency.

[0065] For example, in step S30, the queued caching of telemetry data based on the data type of the telemetry data includes: Step S301: Write the telemetry data into the corresponding telemetry queue according to the data type of the telemetry data; Step S302: Cache the telemetry data using the telemetry queue.

[0066] Specifically, upon system startup, multiple telemetry processing channels are generated based on configuration files or preset parameters. Each channel includes at least one telemetry UDP receiver, one telemetry lockless queue, and one telemetry processor, establishing a one-to-one correspondence so that the telemetry lockless queue serves as the data transmission channel between the telemetry UDP receiver and the telemetry processor. The telemetry UDP receiver listens for and receives telemetry data sent by the UAV cluster on its bound communication port. After receiving the telemetry data, the receiver obtains information characterizing the telemetry data type; the telemetry data type can be determined by the port-to-type mapping relationship or by the type field / message identifier in the telemetry data packet header.

[0067] The receiver writes the received telemetry data into the corresponding lockless telemetry queue based on the telemetry data type. If the system is configured as "one channel per type," telemetry data of the same type is continuously written to the same telemetry queue; if the system is configured as "multiple channels for the same type," it can be further written to the corresponding queue according to the UAV identifier / fragmentation rules. The telemetry processor, corresponding one-to-one with the telemetry queue, reads the telemetry data from the telemetry queue, decodes the telemetry data, and obtains a set of telemetry fields; the set of telemetry fields includes at least the field items corresponding to the type of telemetry data and their values ​​(e.g., timestamp, UAV number, attitude, speed, etc.).

[0068] The telemetry processor encapsulates the decoded telemetry fields according to a preset target format to generate a telemetry message. The target format can be a structured message format that can be directly parsed by the backend application software. The encapsulation process may include: generating a message header (such as message identifier, data type, timestamp, drone identifier, etc.) and generating a message body (writing the corresponding telemetry fields according to field order / field definition), thereby forming a telemetry message in the target format, which is then output to subsequent modules (such as a single-instance interface module) for push.

[0069] For example, the system presets three types of telemetry data: flight status telemetry, navigation and positioning telemetry, and payload status telemetry, and configures three telemetry channels for each: Channel A: Port P1 (Flight State) → Receiver A → Queue A → Processor A Channel B: Port P2 (Navigation and Positioning) → Receiver B → Queue B → Processor B Channel C: Port P3 (load status) → Receiver C → Queue C → Processor C When the drone swarm sends telemetry data: 1) UAV #12 sends a frame of flight status telemetry data (including timestamp, UAV number, attitude angle, speed, altitude, etc.) to port P1. Receiver A receives this frame of data at port P1, determines its data type as flight status telemetry, and writes the frame of data to queue A. Processor A reads the frame of data from queue A and decodes it to obtain the various flight status fields; then, processor A encapsulates the fields according to the target format to generate a "flight status telemetry message".

[0070] 2) UAV #07 sends a frame of navigation and positioning telemetry data (including timestamp, UAV number, latitude and longitude, heading, etc.) to port P2. After receiving the data, receiver B determines that the type is navigation and positioning telemetry and writes the data into queue B; processor B reads and decodes the navigation and positioning fields from queue B, and then encapsulates them according to the target format to generate a "navigation and positioning telemetry message".

[0071] 3) UAV #03 sends a frame of payload status telemetry data (including timestamp, UAV number, payload working module type, key status quantities, etc.) to port P3. Receiver C receives the data and writes it to queue C; processor C reads and decodes the payload fields from queue C, encapsulates them according to the target format, and generates a "payload status telemetry message".

[0072] As can be seen from the above example, the data process of telemetry data is as follows: receiving → identifying type → writing to the corresponding queue → processor reading → decoding → encapsulating the output according to the target format.

[0073] For example, in step S32, after the system starts, the single-instance interface module initializes the communication interface with the backend application software and establishes an interactive channel for sending messages and receiving commands; the single-instance interface module is a globally unique instance used to uniformly manage the interactive connection with the backend application software.

[0074] Specifically, the single-instance interface module receives telemetry messages generated by the telemetry data processing module and sends them to the backend application software according to preset push rules. These push rules may include the destination address / port, message subject / channel identifier, sending frequency, or triggering conditions. After completing the sending, the single-instance interface module can update the sending sequence number or record the sending timestamp.

[0075] Specifically, the single-instance interface module listens to the remote control command input channel from the backend application software. After receiving the remote control command sent by the backend application software, it performs basic reception processing on the remote control command. Basic reception processing may include: reading the command payload, extracting the command identifier / command type field, and verifying the integrity of the command.

[0076] Specifically, the single-instance interface module outputs the received remote control commands to the remote control command processing module (e.g., writes them to the command distribution queue or provides them to the command buffer unit) to enter the subsequent command buffer distribution and encoding transmission process.

[0077] For example, the telemetry processor generates a "flight status telemetry message" (containing fields such as uav_id, timestamp, attitude angle, velocity, and altitude) and outputs it to the single-instance interface module. The single-instance interface module then sends this telemetry message to the backend application software; the backend application software receives it and uses it for interface display, storage, or alarm judgment, etc.

[0078] The backend application software generates a remote control command (e.g., "UAV_12 set heading=90°, altitude=1200m") according to the task requirements and sends the remote control command to the command receiving channel of the single-instance interface module. After receiving the remote control command, the single-instance interface module extracts the command type and target UAV identifier, and outputs the remote control command to the command buffer entry of the remote control command processing module, so that it can enter the subsequent encoding and transmission process.

[0079] For example, in step S33, the remote control command type is used to distribute the remote control command to the target processing channel for encoding to obtain remote control instructions, including: Step S331: Based on the command type of the remote control command, cache the remote control command to the corresponding command queue; Step S332: Read the remote control commands in the command queue, and select the target remote control processor from multiple remote control processors according to the command type of the remote control command; Step S333: Encode the remote control command using the target remote control processor to obtain the remote control instruction.

[0080] Specifically, after receiving a remote control command from the backend application software, the single-instance interface module writes the remote control command into the command distribution queue in the remote lockless queue group as the input queue for subsequent encoding processing. The remote control command encoding submodule reads the remote control command from the command distribution queue, parses it to obtain the command type of the remote control command; based on the command type, it selects a target remote control processor that matches the command type from multiple remote control processors, and distributes the remote control command to the processing channel corresponding to the target remote control processor.

[0081] Specifically, the target remote control processor parses and encodes the remote control command to generate remote control instructions recognizable by the UAV swarm; the encoded remote control instructions are written into the instruction sending queue in the remote control unlocked queue group. The remote control instruction sending submodule reads the remote control instructions from the instruction sending queue corresponding to the target remote control processor, and the UDP transmitter corresponding to each instruction sending queue sends the remote control instructions to the target UAV through its bound communication port, thereby realizing the distribution of remote control instructions to the UAV swarm.

[0082] For example, the system is configured with two types of remote control commands: Track / mission type commands (CmdType=A) are encoded by remote control processor A; corresponding to command sending queue A and UDP transmitter A (port 60001). The load control commands (CmdType=B) are encoded by the remote control processor B; the corresponding command sending queue B and UDP transmitter B (port 60002) are also involved.

[0083] When the backend application software issues a remote control command: "UAV_12 uploads waypoints and starts the mission" (command type is CmdType = A), the following operations are performed: 1) The remote control command is written into the command distribution queue; 2) The encoding sub-module reads the command and identifies its command type as CmdType = A, and selects the remote control processor A as the target remote control processor; 3) The remote control processor A encodes the command, generates the corresponding remote control instruction, and writes it into the instruction sending queue A; 4) The UDP transmitter A reads the remote control instruction from the instruction sending queue A and sends the remote control instruction to the UAV cluster through port 60001, and UAV_12 will receive this remote control instruction.

[0084] When the backend application software issues a payload control command (CmdType = B), the command is distributed to the remote control processor B for encoding and sent by the UDP transmitter B through port 60002, realizing the encoding and sending of different command types in different processing channels.

[0085] In this exemplary embodiment, a ground control end data management software architecture applicable to large-scale medium and large UAV clusters is provided. Taking the basic measurement and control scenario of a 100-level medium and large UAV cluster as an example, the application process of the present invention is described as follows: Step 1: Configuration file definition Create a configuration file in XML format, and the core parameters are as follows: xml <!-- Telemetry configuration --> <telemetry> <instance id="1" port="50001" dataType="飞行状态" processor="TelemProcessor1" / > <instance id="2" port="50002" dataType="任务载荷" processor="TelemProcessor2" / > <instance id="3" port="50003" dataType="系统健康" processor="TelemProcessor3" / > < / telemetry> <!-- Remote control configuration --> <remotecontrol> <instance id="1" port="60001" cmdType="飞行控制" processor="RemoteProcessor1" / > <instance id="2" port="60002" cmdType="任务规划" processor="RemoteProcessor2" / > <instance id="3" port="60003" cmdType="链路锁定" processor="RemoteProcessor3" / > < / remotecontrol> Step 2: Architecture instantiation When the software starts, it reads the configuration file and automatically completes: (1) Generate 3 UDP receiver instances (ports 50001 - 50003), 3 telemetry lock-free queues, and 3 telemetry processor instances; (2) Generate 3 remote control processor instances, 1 command distribution queue, 3 instruction sending queues, and 3 UDP transmitter instances (ports 60001 - 60003); (3) Create independent threads for all instances, and set the thread priority to "high" (to ensure real-time performance).

[0086] Step 3: Downlink telemetry data processing (1) UAVs 1 - 100 send flight status data (such as longitude 116.3°, latitude 39.9°, speed 20 m / s) through port 50001; (2) After receiving data, telemetry UDP1 writes it to queue 1. Telemetry processor 1 reads the data from queue 1, calls Qt's QByteArray parsing function to complete the decoding, and packages it into a JSON format message: {"dataType":"Flight Status","droneId":"1","lon":116.3,"lat":39.9, "speed":20}; (3) Telemetry processor 1 calls the sendTelemMsg() function of the backend interface class singleton object to push the message to the backend application software, and the backend displays the cluster flight status in real time.

[0087] Step 4: Uplink remote control data processing (1) The backend application software sends the "UAV 1~100 mission planning command" (target coordinates 116.5°, 39.8°), and the backend interface class singleton object receives it and writes it into the command distribution queue; (2) The remote control processor 2 reads the command from the command distribution queue, parses it, and encodes it into a binary instruction (instruction format: 0x02 [droneId] [lon][lat]); (3) The remote control processor 2 writes the binary instructions into the instruction queue 2, the remote control UDP2 reads the instructions from the queue 2, and sends them to the UAVs 1~100 through port 60002 to complete the task planning and distribution.

[0088] Step 5: Performance Testing With an Intel i7-12700K CPU and 32GB of memory, the system simultaneously sends telemetry data (100 data points per second per drone) and receives remote control commands (50 data points per second) from 100 drones. Using Qt's QElapsedTimer, the average data processing latency was measured to be 68 microseconds, with no data loss, meeting the design requirements.

[0089] Furthermore, based on the aforementioned measurement and control scenarios, a fault-tolerance mechanism is added to optimize the architecture's reliability: (1) UDP receiver disconnection retry: Add the checkConnection() function to the UDP receiver class to check the port connection status every 100 milliseconds. If the connection is lost, automatically rebind the port (retry 3 times with an interval of 500 milliseconds) to avoid data interruption due to port abnormality. (2) Processor abnormal restart: The backend interface class singleton object adds an "instance monitoring thread" to detect the thread status of the telemetry / remote control processor in real time. If a thread crash is detected, the processor instance and thread are automatically regenerated by reading the configuration file. The restart time is less than 200 microseconds. (3) Data backup mechanism: Add "data backup cache" to the telemetry lockless queue and the remote control lockless queue. When the queue is full, the overflow data is automatically written to the local temporary file (the path is defined by the configuration file). When the queue is idle, the file data is reread to avoid data loss.

[0090] Tests show that this optimization enables the architecture to maintain data processing continuity even with 10% of component instances failing, and there is no data interruption after the fault is recovered, further improving the stability of large-scale block cluster monitoring and control.

[0091] This invention, through "modular design + lock-free queue decoupling + dynamic configuration," achieves the following technical effects: (1) Significantly improved concurrency capability It adopts "one-to-one" downlink processing (independent channel for each type of telemetry data) and "one-to-many + one-to-one" uplink processing (command distribution + independent instruction sending). All component instances run on independent threads, supporting concurrent processing of multiple types of data in a cluster of hundreds of medium and large UAVs, and improving data throughput by more than 3 times compared to the traditional architecture. (2) Delay control accurately meets the standards The "producer-consumer" modular approach decouples data, and the lock-free queue avoids lock contention and time consumption. The measured data processing latency is consistently below 100 microseconds, meeting the real-time control requirements of medium and large-sized UAV clusters. (3) Configuration flexibility is greatly improved By defining component instance parameters (port, data type) through configuration files, when adding a new drone type or adjusting the data channel, only the configuration file needs to be modified, without refactoring the core code, and the adaptation cycle is shortened from the traditional 3 days to 1 hour. (4) The system reliability is significantly enhanced. Lock-free queues achieve data "peak shaving and valley filling" to avoid loss or overflow caused by sudden data surges; component instances run independently, and the failure of a single instance does not affect the overall architecture, reducing the system failure rate by more than 90% compared to traditional architectures.

[0092] In summary, this invention can stably support ground-based telemetry and control of large-scale UAV swarms of hundreds of aircraft, providing core data management support for large-scale military exercises, emergency rescue, and other scenarios involving large-scale UAV swarms.

[0093] It should be noted that the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may, for example, be executed synchronously or asynchronously in multiple modules.

[0094] It should be noted that although several modules or units of the device for performing actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0095] Figure 4 A schematic diagram of an electronic device suitable for implementing embodiments of the present invention is shown.

[0096] It should be noted that, Figure 4 The electronic device 1000 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0097] like Figure 4 As shown, the electronic device 1000 includes a Central Processing Unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1002 or programs loaded from storage section 1008 into Random Access Memory (RAM) 1003. The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An Input / Output (I / O) interface 1005 is also connected to the bus 1004. Furthermore, the electronic device 1000 also includes an FPGA device and a System-on-a-Chip (SoC) device.

[0098] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1010 as needed so that computer programs read from them can be installed into storage section 1008 as needed.

[0099] In particular, according to embodiments of the present invention, the processes described below with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs various functions defined in the system of this application.

[0100] Specifically, the aforementioned electronic devices can be airborne intelligent electronic devices.

[0101] It should be noted that the storage medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein computer-readable program code is carried. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

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

[0103] The units described in the embodiments of the present invention can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0104] It should be noted that, as another aspect, this application also provides a storage medium, which may be included in an electronic device or may exist independently without being assembled into the electronic device. The aforementioned storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to perform the methods described in the following embodiments. For example, the electronic device may perform... Figure 3 The steps of the method shown.

[0105] In one embodiment, this application provides a computer program product including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0106] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0107] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0108] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A ground control terminal data management software architecture suitable for large-scale UAV swarms in large-scale blocks, characterized in that, The data management software architecture includes: The telemetry data processing module is used to queue and cache telemetry data based on the data type of the telemetry data, and encapsulate the telemetry data in the queue to obtain telemetry messages in the target format. The single-instance interface module is used to push telemetry messages to the backend application software and receive remote control commands sent by the backend application software. The remote control command processing module is used to distribute remote control commands to the target processing channel for encoding based on the command type of the remote control command, obtain remote control instructions, and send the remote control instructions to the UAV cluster through the corresponding communication port.

2. The data management software architecture according to claim 1, characterized in that, The telemetry data processing module includes: The telemetry data receiving submodule contains multiple telemetry receivers, which are used to receive telemetry data through communication ports bound to the telemetry receivers, and use the telemetry receivers to write the telemetry data into the corresponding telemetry queue according to the data type of the telemetry data. The telemetry data buffer submodule contains multiple telemetry queues, which are used to cache telemetry data into the corresponding telemetry queue based on the data type of the telemetry data; The telemetry data decoding submodule contains multiple telemetry processors, which are used to read telemetry data from the corresponding telemetry queue, decode the telemetry data using the corresponding telemetry processor, encapsulate the decoded telemetry fields according to the target format, and generate telemetry messages.

3. The method according to claim 1, characterized in that, The remote control command processing module includes: The remote control command encoding submodule is used to buffer and distribute the remote control commands output by the single instance interface module, and encode the remote control commands according to the command type to generate remote control instructions that can be recognized by the UAV cluster. The remote control command sending submodule is used to send remote control commands to the drone cluster via the corresponding communication port.

4. The method according to claim 3, characterized in that, The remote control data encoding submodule includes: The remote control command buffer unit contains multiple command queues, which are used to cache remote control commands into the corresponding command queues based on the command type of the remote control command. The remote control command encoding unit contains multiple remote control processors, which are used to read remote control commands from the command queue, select a target remote control processor from the multiple remote control processors according to the command type of the remote control command, and encode the remote control command using the target remote control processor to obtain the remote control instruction.

5. The method according to claim 4, characterized in that, The remote control data transmission submodule includes: The remote control command buffer unit contains multiple command queues, which are used to cache remote control commands into the corresponding command queues based on the command type of the remote control command. The remote control command sending unit includes multiple remote control transmitters, which are used to read remote control commands from the command queue and send the remote control commands to the UAV cluster through the communication port corresponding to the remote control transmitter.

6. A ground control terminal data management method suitable for large-scale UAV swarms in large-scale blocks, applied to the data management software architecture of any one of claims 1 to 5, characterized in that, The method includes: Based on the data type of the telemetry data, the telemetry data is queued and cached, and the telemetry data in the queue is encapsulated to obtain the telemetry message in the target format. Push telemetry messages to the backend application software and receive remote control commands sent by the backend application software; Based on the command type of the remote control command, the remote control command is distributed to the target processing channel for encoding to obtain the remote control instruction, and then sent to the UAV cluster through the corresponding communication port.

7. The method according to claim 6, characterized in that, The method of queuing and caching telemetry data based on its data type includes: Write the telemetry data into the corresponding telemetry queue according to the data type of the telemetry data; Telemetry data is cached using a telemetry queue.

8. The method according to claim 6, characterized in that, The command type based on remote control commands distributes remote control commands to the target processing channel for encoding to obtain remote control instructions, including: Based on the command type of the remote control command, the remote control command is cached in the corresponding command queue; Read the remote control commands in the command queue and select the target remote control processor from multiple remote control processors according to the command type of the remote control command; The remote control commands are encoded using the target remote control processor to obtain remote control instructions.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method of any one of claims 6 to 8.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 6 to 8.

Images