Low-altitude unmanned aerial vehicle real-time trajectory cluster monitoring system and method

Abstract

The application discloses a low-altitude unmanned aerial vehicle real-time trajectory cluster monitoring system and a monitoring method, and belongs to the technical field of unmanned aerial vehicle monitoring. The system comprises a connection gateway cluster, a distributed message bus, a trajectory processing engine cluster and a distributed cache and state center. The gateway cluster receives original state data of unmanned aerial vehicles and publishes the original state data to the message bus. The trajectory processing engine consumes data and generates standard trajectory data to return to the bus. The gateway cluster combines a subscription relationship and a connection mapping of the cache center, and accurately pushes the trajectory data to a monitoring client. The application adopts a distributed cluster architecture, guarantees the sequence of data processing, the accuracy of pushing and the high availability of the system, and is suitable for real-time monitoring requirements of a large-scale unmanned aerial vehicle cluster.

Description

Technical Field

[0001] This document relates to the field of unmanned aerial vehicle (UAV) trajectory monitoring technology, and in particular to a real-time trajectory cluster monitoring system and method for low-altitude UAVs. Background Technology

[0002] With the large-scale application of drones in low-altitude economic scenarios such as logistics, inspection, surveying, and security, the need for centralized, real-time, and reliable monitoring of multiple drones is becoming increasingly urgent. Existing drone monitoring solutions mainly suffer from the following technical bottlenecks: 1. The traditional single-server direct connection mode has a limited number of concurrent connections. When the number of connected drones increases to hundreds, system resources are quickly exhausted and performance drops precipitously. 2. The status acquisition method based on HTTP short connection polling has a delay of up to seconds, which cannot meet the real-time requirement of smooth and continuous trajectory display, and the information lag is serious in emergency situations; 3. In a high-availability cluster deployment, when multiple clients subscribe to the same drone data, the existing broadcast or centralized forwarding methods are inefficient, prone to data duplication or omission, and lack accurate and consistent message routing capabilities. 4. The functions of connection management, business logic and data persistence are highly coupled, making it difficult to flexibly adapt to the needs of rapid business changes and independent module upgrades.

[0003] Therefore, there is an urgent need for a real-time cluster monitoring solution for low-altitude UAVs that supports massive access, low latency, efficient cluster synchronization, and good scalability. Summary of the Invention

[0004] This invention provides a real-time trajectory cluster monitoring system and method for low-altitude unmanned aerial vehicles (UAVs) to address the problems in existing technologies, such as the difficulty in achieving both high concurrency and low latency, the difficulty in state synchronization due to the lack of efficient cross-node message routing during cluster deployment, and the difficulty in component expansion and iteration caused by tight coupling in the system architecture.

[0005] According to an embodiment of the present invention, a real-time trajectory swarm monitoring system for low-altitude unmanned aerial vehicles (UAVs) is provided, comprising: Connects gateway clusters, distributed message buses, trajectory processing engine clusters, and distributed caches and status centers; The connection gateway cluster consists of multiple stateless gateway nodes, used to establish long-term connections with monitoring clients, receive raw status data reported by drones and publish it to the distributed message bus, and interact with the distributed cache and status center. The distributed message bus provides asynchronous communication channels for various system components, including a first topic for transmitting raw UAV state data, a second topic for transmitting processed standard trajectory data, and a third topic for transmitting control commands issued by the monitoring client. The trajectory processing engine cluster, as a consumer of the distributed message bus, is used to consume raw state data from the first topic, process it through business logic, generate standard trajectory data, and publish it to the second topic. The distributed cache and state center are at least used to store the connection mapping relationship between client sessions and gateway nodes in the connection gateway cluster. Each gateway node in the connection gateway cluster is further configured to consume standard trajectory data from the second topic and push the data to the corresponding monitoring client according to the connection mapping relationship stored in the distributed cache and the status center.

[0006] According to an embodiment of the present invention, a method for real-time trajectory swarm monitoring of low-altitude unmanned aerial vehicles (UAVs) is provided, comprising: S1. The monitoring client establishes a WebSocket long connection with any gateway node in the connection gateway cluster, and writes the subscription relationship into the distributed cache and state center through the gateway node. The subscription relationship includes at least the correspondence between the client identifier and the subscribed drone identifier. S2. The raw status data reported by the UAV is received by the gateway node in the connected gateway cluster. The gateway node publishes the raw status data to the first topic of the distributed message bus, and at the same time updates the latest status of the UAV to the distributed cache and status center. S3. The trajectory processing engine cluster consumes raw state data from the first topic, performs business logic processing on the consumed data, generates standard trajectory data, and publishes it to the second topic of the distributed message bus. S4. The gateway node in the connection gateway cluster consumes standard trajectory data from the second topic. For each standard trajectory data consumed, the distributed cache and status center are queried to determine the monitoring client that subscribes to the data and its currently connected gateway node. The data is then pushed to the corresponding monitoring client based on the query results. S5. The control command issued by the monitoring client is received by the gateway node in the connected gateway cluster. The gateway node publishes the control command to the third topic of the distributed message bus. The gateway node in the connected gateway cluster consumes the control command from the third topic, queries the distributed cache and status center to determine the gateway node connected to the corresponding drone, and pushes the control command to the corresponding drone.

[0007] By adopting the embodiments of the present invention, a collaborative architecture connecting gateway clusters, distributed message buses, trajectory processing engine clusters, and distributed caches and state centers is used to achieve loose coupling and clustered deployment of multiple components, supporting high-concurrency access of massive drones and horizontal elastic scaling. Relying on the three-theme design of the distributed message bus, data flow and control flow are separated for transmission, and centralized state storage is combined to complete accurate message routing within the cluster, ensuring low-latency data transmission to the end. Each component has a clear responsibility and no single point of failure, making the system highly available and easy to maintain. It is suitable for the real-time monitoring needs of large-scale drone clusters and effectively solves the technical problems of limited concurrency, high latency, difficulty in cluster synchronization, and coupled architecture in traditional solutions. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in one or more embodiments of this specification or in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a schematic diagram of a low-altitude unmanned aerial vehicle (UAV) real-time trajectory cluster monitoring system according to an embodiment of the present invention; Figure 2 This is a flowchart of a low-altitude unmanned aerial vehicle (UAV) real-time trajectory cluster monitoring method according to an embodiment of the present invention. Detailed Implementation

[0010] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0011] System Implementation Examples According to embodiments of the present invention, a real-time trajectory swarm monitoring system for low-altitude unmanned aerial vehicles (UAVs) is provided. Figure 1 This is a schematic diagram of a low-altitude unmanned aerial vehicle (UAV) real-time trajectory cluster monitoring system according to an embodiment of the present invention. Figure 1 As shown, the low-altitude unmanned aerial vehicle (UAV) real-time trajectory cluster monitoring system of this invention specifically includes: Connects gateway clusters, distributed message buses, trajectory processing engine clusters, and distributed caches and status centers; The connection gateway cluster consists of multiple stateless gateway nodes, used to establish long-term connections with monitoring clients, receive raw status data reported by drones and publish it to the distributed message bus, and interact with the distributed cache and status center. The connection gateway cluster, composed of multiple stateless gateway nodes, serves as the sole entry point for communication between the system and monitoring clients and drones. It establishes long-lived connections with monitoring clients, receives raw status data reported by drones and publishes it to the distributed message bus, and interacts with the distributed cache and status center. The connection gateway cluster is front-end configured with a load balancer, employing either an ip_hash strategy or a consistent hashing strategy to ensure that consecutive connection requests from the same monitoring client or drone are always distributed to the same gateway node. This prevents session loss and data corruption caused by connection drift, guaranteeing connection stability. Each gateway node has a built-in WebSocket server, a status synchronization client, and a protocol parsing and connection management module. Each gateway node in the connection gateway cluster is configured to: establish and maintain a full-duplex WebSocket connection with the monitoring client; establish a communication connection with the drone to receive its reported raw status data; receive control commands and subscription commands issued by the monitoring client; and perform real-time data interaction with the distributed cache and status center; publish the raw status data reported by the drone and the control commands issued by the monitoring client to the corresponding topics of the distributed message bus; simultaneously consume the processed standard trajectory data and the control commands to be forwarded from the distributed message bus; and complete the accurate data push to the monitoring client and the drone based on the data stored in the distributed cache and status center.

[0012] Specifically, each gateway node in the connection gateway cluster is configured to perform the following operations: The system receives subscription instructions from monitoring clients, parses the client identifier and the set of drone identifiers to be subscribed to in the instructions, and writes the subscription relationship into the distributed cache and state center with the client identifier as the key and the set of drone identifiers to be subscribed to as the value. At the same time, it generates client connection mapping data, records the gateway node identifier and WebSocket connection handle of the client's current connection, and writes it into the distributed cache and state center synchronously.

[0013] The system monitors the connection status of the client and drone in real time. When it detects that the client has actively disconnected, the network has been abnormally interrupted, or the drone is offline, it automatically deletes the subscription relationship and connection mapping relationship corresponding to the client from the distributed cache and status center, or updates the online status data of the drone, so as to release system resources in a timely manner and avoid invalid data occupation.

[0014] The system performs protocol parsing and validity verification on the raw status data reported by the UAV and the control commands issued by the monitoring client, filters out invalid messages caused by sensor failures and network jitter, publishes valid data to the corresponding topics of the distributed message bus according to type, and simultaneously updates the latest UAV status data to the distributed cache and status center.

[0015] Consume standard trajectory data processed by the distributed message bus, parse the drone identifier carried in the data, query the distributed cache and status center to determine the target client subscribing to the drone and the corresponding connected gateway node, and complete local push or cross-node routing forwarding; consume control commands from the distributed message bus, query the distributed cache and status center to determine the corresponding drone and the connected gateway node, and accurately push the control commands to the target drone.

[0016] The built-in state synchronization client establishes a low-latency state synchronization channel with other gateway nodes in the cluster. The state synchronization channel is a gRPC long connection channel or a Redis publish / subscribe channel, which enables the forwarding of cross-node routing messages and the broadcasting of cluster node states, ensuring that the states of all nodes in the cluster are consistent.

[0017] The distributed message bus is used to provide asynchronous communication channels for various components of the system, realizing decoupling of various components and efficient data flow. In this embodiment, the distributed message bus is deployed using a Kafka message queue cluster. A multi-replica mechanism is used to configure a master replica and a slave replica for each topic partition. When the master node fails, the slave node can quickly switch to the master node to ensure high availability of message transmission and no data loss. The number of nodes and partitions can be flexibly expanded according to business needs.

[0018] The distributed message bus defines at least three topics, each with a clear division of labor and data isolation, namely: The first topic (drone-status-raw-topic) is used to transmit the raw status data reported by the drone. The first topic is partitioned according to the drone identifier. All raw status data of the same drone are written to the same partition to ensure the sequential order of the time-series data of a single drone and avoid out-of-order consumption. The second topic (drone-track-processed-topic) is used to transmit standard trajectory data processed by the trajectory processing engine cluster. The second topic is available for all gateway nodes in the connection gateway cluster to subscribe to in the form of a consumer group, ensuring that each piece of standard trajectory data can be perceived by all gateway nodes, providing a foundation for subsequent accurate routing. The third topic (command-topic) is used to transmit control commands issued by the monitoring client to the drone. The third topic is partitioned according to the drone identifier. Control commands corresponding to the same drone are all written to the same partition and consumed exclusively by the gateway node connected to the drone, so as to achieve accurate forwarding of control commands. At the same time, it realizes the separation of system data flow and control flow transmission, improving the efficiency and stability of data processing.

[0019] The trajectory processing engine cluster, as a consumer of the distributed message bus, is deployed independently of the connection gateway cluster. It can flexibly expand the number of nodes according to the data processing pressure, realize the elastic scaling of business logic processing capabilities, and is completely decoupled from the communication layer. Its upgrades, optimizations or expansions will not affect the communication access and data transmission of the connection gateway cluster.

[0020] The trajectory processing engine cluster uses the drone identifier as the basis for partition allocation and consumes raw state data from the first topic of the distributed message bus, ensuring that the raw state data of the same drone is consumed by the same processing engine instance, thus maintaining the order and continuity of trajectory processing. The trajectory processing engine cluster performs a series of business logic processes on the consumed raw state data to generate standardized trajectory data. The specific processing steps include: Data cleaning: Filtering out invalid, outlier, and duplicate values ​​from the original state data, and removing dirty data caused by drone sensor malfunctions and network transmission jitter to ensure data validity; Trajectory filtering: Kalman filtering, moving average and other algorithms are used to smooth the trajectory-related data such as the position, speed and altitude of the UAV, eliminate trajectory jitter and ensure the continuity and accuracy of the UAV trajectory display; Geofence verification: The current location information of the drone is compared with the preset geofence information (including work area, no-fly zone, etc.) in real time to determine whether the drone has crossed the boundary. If the boundary crossing is detected, the boundary crossing alarm information is generated and the alarm information is attached to the trajectory data. Data formatting: The cleaned, filtered, and verified raw data is converted into a unified structured standard trajectory data for the system. The standard trajectory data includes at least key fields such as UAV identifier, timestamp, latitude and longitude, altitude, speed, battery level, flight status, and alarm information to ensure the consistency of data interaction between various system components.

[0021] The trajectory processing engine cluster publishes the processed standard trajectory data to the second topic of the distributed message bus in real time. At the same time, it can persist key information in the standard trajectory data to the business database according to business needs, for historical query, statistical analysis and tracing of UAV flight trajectories.

[0022] The distributed cache and state center are used to store at least the connection mapping relationship between client sessions and gateway nodes in the connection gateway cluster; the distributed cache and state center are deployed in Redis Sentinel mode or Redis cluster mode, and store the following data: The latest status data of the drone is set with the drone identifier as the key and structured status information including position, speed, altitude, and battery level as the value, and a lifespan is also set. Client subscription relationship data is stored using a Redis Set data structure, with the client identifier as the key and the set of drone identifiers subscribed to by that client as the value. Client connection mapping data uses the client identifier as the key and the gateway node identifier and connection handle currently connected to by the client as the value.

[0023] Each gateway node in the connection gateway cluster is further configured to consume standard trajectory data from the second topic and push the data to the corresponding monitoring client according to the connection mapping relationship stored in the distributed cache and the status center.

[0024] Each gateway node in the connection gateway cluster pushes data based on the distributed cache and state center, specifically including: In response to obtaining standard trajectory data from the second topic, the drone identifier carried in the standard trajectory data is parsed; Based on the drone identifier, query the client subscription relationship stored in the distributed cache and the state center to determine the list of target client identifiers that have subscribed to the drone; For each client identifier in the target client identifier list, query the connection mapping relationship between the distributed cache and the state center to determine the target gateway node identifier that the client is currently connected to; If the current gateway node identifier is the same as the target gateway node identifier, the standard trajectory data is pushed directly through the WebSocket long connection with the target client; If the current gateway node identifier is different from the target gateway node identifier, the standard trajectory data is encapsulated into a routing message and forwarded to the target gateway node through the state synchronization channel between gateway nodes. The target gateway node then pushes the data through a WebSocket long connection between itself and the target client.

[0025] In this system embodiment, all components are deployed in a clustered manner, eliminating single points of failure. The system can seamlessly switch over when a single node fails: when the connection gateway node fails, the load balancer distributes requests to other normal nodes; when the Kafka node fails, the multi-replica mechanism ensures uninterrupted message transmission; when the Redis master node fails, the sentinel mode quickly switches to the slave node; when the trajectory processing engine node fails, the consumer group redistributes partitions to other normal nodes, ensuring high availability of the entire system and providing continuous and stable monitoring services.

[0026] By employing the embodiments of the present invention, the following beneficial effects are achieved: First, it achieves high-concurrency access and elastic scaling. Both the connection gateway and trajectory processing engine can be horizontally scaled. Adding nodes linearly increases the number of drones supported and the data processing capacity, adapting to the needs of large-scale drone cluster monitoring. Second, it achieves end-to-end low-latency transmission. WebSocket full-duplex long connections replace traditional HTTP short-connection polling. Combined with Kafka's high-throughput message bus and Redis's low-latency read / write characteristics, end-to-end data transmission latency is controlled at the millisecond level, meeting the real-time requirements for smooth and continuous drone trajectory display. Third, it solves the challenges of state synchronization and accurate routing in cluster deployments. Through centralized Redis storage of session mappings, subscription relationships, and other core states, any gateway node can quickly query and calculate data routing targets, ensuring accurate and consistent data push to all subscribed clients, avoiding data duplication or omission. Fourth, it achieves high system decoupling with clear responsibilities for each component. Loosely coupled communication is achieved through Kafka, with the communication layer, business processing layer, and data layer independent of each other. Upgrading, optimizing, or expanding a single module will not affect the overall system stability, improving system flexibility and maintainability. Fifth, it achieves intelligent state management through Redis. The system's lifespan mechanism and gateway node connection detection function automatically complete the offline marking of drones and the cleanup of invalid client states, avoiding invalid data from occupying system resources and improving system operating efficiency.

[0027] Method Implementation Examples According to an embodiment of the present invention, a method for real-time trajectory swarm monitoring of low-altitude unmanned aerial vehicles (UAVs) is provided. Figure 2 This is a flowchart of a real-time trajectory cluster monitoring method for low-altitude unmanned aerial vehicles according to an embodiment of the present invention. Figure 2 As shown, the low-altitude UAV real-time trajectory cluster monitoring method of this invention specifically includes: S1. The monitoring client establishes a WebSocket long connection with any gateway node in the connection gateway cluster, and writes the subscription relationship into the distributed cache and state center through the gateway node. The subscription relationship includes at least the correspondence between the client identifier and the subscribed drone identifier. S1 specifically includes: The monitoring client initiates a WebSocket connection request to the load balancer at the front end of the connection gateway cluster. The load balancer uses the ip_hash strategy or the consistent hash strategy to distribute the connection request to a gateway node in the connection gateway cluster. The monitoring client establishes and maintains a WebSocket full-duplex connection with the gateway node. The monitoring client sends a subscription request to the connected gateway node. The subscription request carries a unique client identifier and a list of drone identifiers to be subscribed to, and supports subscription methods for single, multiple, or all drones. The gateway node parses the subscription request and generates a subscription relationship record, which uses the client identifier as the key and the drone identifier set as the value; at the same time, it generates a client connection mapping record, which uses the client identifier as the key and the current gateway node identifier and WebSocket connection handle as the value; The gateway node writes the subscription relationship record into the distributed cache and state center, using a Redis Set data structure for storage; at the same time, it synchronously writes the client connection mapping record into the distributed cache and state center. The gateway node initiates real-time status monitoring of the WebSocket connection. When the monitoring client actively cancels its subscription, disconnects due to network anomalies, or has no interaction for an extended period, the connected gateway node detects the connection interruption event, immediately deletes the client's subscription relationship record and connection mapping record from the distributed cache and state center, and releases the corresponding connection resources.

[0028] S2. The raw status data reported by the drone is received by the gateway node in the connected gateway cluster. The gateway node publishes the raw status data to the first topic of the distributed message bus, and simultaneously updates the latest status of the drone to the distributed cache and status center; S2 specifically includes: The drone collects sensor data such as its position, speed, altitude, battery level, and flight status, encapsulates it into raw status data messages that conform to the system communication protocol, and reports them to the connection gateway cluster at a preset frequency. The load balancer distributes the drone's connection requests to a fixed gateway node. This gateway node performs protocol parsing and validity verification on the received raw status data packets, filtering out invalid and abnormal packets and extracting valid data. The gateway node will write the parsed valid raw state data into the corresponding partition of the first topic of the distributed message bus according to the UAV identifier, so as to ensure the time sequence of the raw state data of the same UAV. While publishing the original status data, the gateway node synchronously updates the latest parsed drone status data to the distributed cache and status center, overwriting the original status data corresponding to the drone identifier, refreshing the data's lifetime, and marking the drone as online.

[0029] S3, the trajectory processing engine cluster consumes raw state data from the first topic, performs business logic processing on the consumed data, generates standard trajectory data, and publishes it to the second topic of the distributed message bus; S3 specifically includes: The trajectory processing engine cluster uses the drone identifier as the basis for partition allocation and consumes the original state data of the corresponding partition from the first topic of the distributed message bus to ensure that all original state data of the same drone are consumed by the same processing engine instance, thus avoiding out-of-order data processing. The processing engine instance sequentially performs business logic processing on the raw state data it consumes, including data cleaning, trajectory filtering, geofence verification, and data formatting. It removes dirty data, smooths trajectory data, verifies out-of-bounds states, and converts the data into system-unified structured standard trajectory data. The standard trajectory data includes at least key fields such as UAV identifier, timestamp, latitude and longitude, altitude, speed, battery level, flight status, and alarm information. The trajectory processing engine cluster publishes the processed standard trajectory data to the second topic of the distributed message bus in real time, which is then consumed by all gateway nodes in the connection gateway cluster. According to business needs, key information in standard trajectory data (such as historical trajectory points, boundary crossing alarm records, etc.) can be persisted to the business database for historical query, statistical analysis and tracing of drone flight trajectories.

[0030] S4. The gateway nodes in the connection gateway cluster consume standard trajectory data from the second topic. For each standard trajectory data point consumed, the distributed cache and status center are queried to determine the monitoring clients subscribed to the data and their currently connected gateway nodes. Based on the query results, the data is pushed to the corresponding monitoring clients. S4 specifically includes: After any gateway node in the connection gateway cluster consumes standard trajectory data from the second topic of the distributed message bus, it parses the drone identifier carried in the data. Based on the drone's identifier, a query is initiated to the distributed cache and state center to obtain a list of all client identifiers that have subscribed to the drone; Iterate through the client identifier list. For each client identifier, query the distributed cache and state center to obtain the identifier of the gateway node currently connected to the client. Determine whether the current gateway node identifier matches the queried gateway node identifier: if they match, push the standard trajectory data to the target client directly through the established WebSocket long connection between the gateway node and the target client; if they do not match, encapsulate the standard trajectory data into a routing message and forward the routing message to the target gateway node through the pre-established communication channel between gateway nodes, and the target gateway node will then push the data through its WebSocket long connection with the target client.

[0031] The pre-established communication channel between the gateway nodes is either a gRPC long-connection channel or a Redis publish / subscribe channel. When forwarding routing messages through the gRPC long-connection channel, the following fault tolerance processing is also performed to avoid data loss due to message transmission failure: Each gateway node establishes a gRPC connection pool with all other nodes in the cluster in advance, maintains a bidirectional communication channel between the gateway nodes, avoids delays caused by temporary connection establishment, and improves the efficiency of routing message transmission. When sending a routing message, a preset timeout period is set. If no acknowledgment response is received from the target gateway node within the timeout period, a retry mechanism is triggered, with a maximum of a preset number of retries. If the retry count is exhausted and the transmission still fails, the routing message is written to the local failure queue to avoid data loss, and is asynchronously reported to the monitoring and alarm system to remind the operation and maintenance personnel to investigate the problem in time. After receiving the routing message, the target gateway node parses out the standard trajectory data and the target client identifier, looks up the corresponding connection handle through the locally maintained WebSocket connection mapping, completes the data push, and returns a push confirmation receipt to the source gateway node. The source gateway node updates the message sending status based on the receipt, making the push process traceable.

[0032] S5. The control command issued by the monitoring client is received by the gateway node in the connected gateway cluster. The gateway node publishes the control command to the third topic of the distributed message bus. The gateway node in the connected gateway cluster consumes the control command from the third topic, queries the distributed cache and status center to determine the gateway node connected to the corresponding drone, and pushes the control command to the corresponding drone.

[0033] S5 specifically includes: The monitoring client sends control commands through a WebSocket long connection with the connected gateway node. The control commands carry the drone identifier, command type and command parameters. The commands include hovering, returning to home, adjusting flight altitude / speed, starting and stopping operations, etc. After parsing the control command, the gateway node encapsulates it into a standard control command message that conforms to the system specifications and writes it into the corresponding partition of the third topic of the distributed message bus according to the UAV identifier. Each gateway node in the connected gateway cluster consumes standard control command messages from the third topic in the form of a consumer group. After any gateway node consumes a control command message, it parses the drone identifier carried in it. The gateway node initiates a query to the distributed cache and status center based on the drone identifier to obtain the identifier of the target gateway node currently connected to the drone; Determine whether the current gateway node identifier matches the target gateway node identifier obtained from the query: if they match, the control command is directly pushed to the target drone through the communication connection between the gateway node and the drone; if they do not match, the control command is encapsulated into a routing command message and forwarded to the target gateway node through the status synchronization channel between gateway nodes, and the target gateway node completes the control command push through its communication connection with the drone.

[0034] The monitoring method of this invention further includes auxiliary mechanisms such as load balancing, data ordering guarantee, and UAV offline status management, which work in conjunction with the core steps to improve the overall performance and reliability of the method. Specifically: Load balancing mechanism: A load balancer is set up in front of the connection gateway cluster, using the ip_hash strategy or the consistent hash strategy to distribute all connection requests from the same monitoring client or the same drone to the same gateway node, ensuring connection stability and session continuity, and avoiding business anomalies caused by connection drift. Data ordering guarantee mechanism: The first and third topics of the distributed message bus are partitioned according to the UAV identifier. The original state data and corresponding control commands of the same UAV are written to the same partition. The trajectory processing engine cluster uses the UAV identifier as the partition allocation basis to ensure that the original state data of the same UAV is consumed by the same processing engine instance, thus maintaining the order of trajectory processing and command issuance. Drone offline status management mechanism: The latest drone status data stored in the distributed cache and status center is set with a lifespan. When a drone fails to report data for a preset time, the status data will be automatically cleared. After the connection gateway cluster detects the status change, it marks the drone as offline and encapsulates the offline information as additional information for trajectory data, which is then pushed to all monitoring clients that have subscribed to the drone. When the drone comes back online and reports data, the system automatically updates its online status and pushes the online information to the corresponding monitoring client, realizing real-time perception and display of drone status.

[0035] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A real-time trajectory cluster monitoring system for low-altitude unmanned aerial vehicles (UAVs), characterized in that... include: Connects gateway clusters, distributed message buses, trajectory processing engine clusters, and distributed caches and status centers; The connection gateway cluster consists of multiple stateless gateway nodes, used to establish long-term connections with monitoring clients, receive raw status data reported by drones and publish it to the distributed message bus, and interact with the distributed cache and status center. The distributed message bus is used to provide asynchronous communication channels for various components of the system, including a first topic for transmitting raw UAV state data, a second topic for transmitting processed standard trajectory data, and a third topic for transmitting control commands issued by the monitoring client. The trajectory processing engine cluster is used to consume raw state data from the first topic, process it with business logic to generate standard trajectory data, and publish it to the second topic. The distributed cache and state center are used to store the connection mapping relationship between client sessions and gateway nodes in the connection gateway cluster, as well as the client's subscription relationship with the drone; Each gateway node in the connection gateway cluster is further configured to: consume standard trajectory data from the second theme, push the data to the corresponding monitoring client according to the connection mapping relationship stored in the distributed cache and the status center, and consume control commands from the third theme, push the control commands to the corresponding drone according to the drone connection mapping relationship stored in the distributed cache and the status center.

2. The system according to claim 1, characterized in that, Each gateway node in the connection gateway cluster is configured as follows: The system receives a subscription instruction sent by the monitoring client, parses the client identifier and the set of drone identifiers to be subscribed to in the instruction, and writes the subscription relationship into the distributed cache and state center. The subscription relationship is stored with the client identifier as the key and the set of drone identifiers to be subscribed to as the value. The system monitors the connection status of clients. When a client disconnects, it automatically removes the client's subscription and connection mapping from the distributed cache and state center. The system detects the drone's connectivity status and automatically updates the drone's online status data from the distributed cache and status center when the drone is detected to be offline.

3. The system according to claim 1, characterized in that, Each gateway node in the connection gateway cluster pushes data based on the distributed cache and state center, specifically including: In response to obtaining standard trajectory data from the second topic, the drone identifier carried in the standard trajectory data is parsed; Based on the drone identifier, query the client subscription relationship stored in the distributed cache and the state center to determine the list of target client identifiers that have subscribed to the drone; For each client identifier in the target client identifier list, query the connection mapping relationship between the distributed cache and the state center to determine the target gateway node identifier that the client is currently connected to; If the current gateway node identifier is the same as the target gateway node identifier, the standard trajectory data is pushed directly through the WebSocket long connection with the target client; If the current gateway node identifier is different from the target gateway node identifier, the standard trajectory data is encapsulated into a routing message and forwarded to the target gateway node through the state synchronization channel between gateway nodes. The target gateway node then pushes the data through a WebSocket long connection between itself and the target client.

4. The system according to claim 1, characterized in that, The distributed message bus uses a Kafka message queue cluster. Both the first and third topics are partitioned according to the drone identifier. The original status data and corresponding control commands of the same drone are written to the same partition to ensure the order of data and commands. The second topic is available for all gateway nodes in the connection gateway cluster to subscribe to in the form of a consumer group.

5. The system according to claim 1, characterized in that, The distributed cache and state center are deployed using a Redis Sentinel cluster or a Redis cluster mode, and store the following data: The latest status data of the drone is set with the drone identifier as the key and structured status information including position, speed, altitude, and battery level as the value, and a lifespan is also set. Client subscription relationship data is stored using a Redis Set data structure, with the client identifier as the key and the set of drone identifiers subscribed to by that client as the value. Client connection mapping data uses the client identifier as the key and the gateway node identifier and connection handle currently connected to by the client as the value. The drone connection mapping data uses the drone identifier as the key and the gateway node identifier and connection handle currently connected to the drone as the value.

6. A monitoring method based on a low-altitude unmanned aerial vehicle (UAV) real-time trajectory swarm monitoring system according to any one of claims 1-5, characterized in that, include: S1. The monitoring client establishes a WebSocket long connection with any gateway node in the connection gateway cluster, and writes the subscription relationship into the distributed cache and state center through the gateway node. The subscription relationship includes at least the correspondence between the client identifier and the subscribed drone identifier. S2. The raw status data reported by the UAV is received by the gateway node in the connected gateway cluster. The gateway node publishes the raw status data to the first topic of the distributed message bus, and at the same time updates the latest status of the UAV to the distributed cache and status center. S3. The trajectory processing engine cluster consumes raw state data from the first topic, performs business logic processing on the consumed data, generates standard trajectory data, and publishes it to the second topic of the distributed message bus. S4. The gateway node in the connection gateway cluster consumes standard trajectory data from the second topic. For each standard trajectory data consumed, the distributed cache and status center are queried to determine the monitoring client that subscribes to the data and its currently connected gateway node. The data is then pushed to the corresponding monitoring client based on the query results. S5. The control command issued by the monitoring client is received by the gateway node in the connected gateway cluster. The gateway node publishes the control command to the third topic of the distributed message bus. The gateway node in the connected gateway cluster consumes the control command from the third topic, queries the distributed cache and status center to determine the gateway node connected to the corresponding drone, and pushes the control command to the corresponding drone.

7. The method according to claim 6, characterized in that, S1 specifically includes: The monitoring client sends a subscription request to the connected gateway node, the subscription request carrying the client identifier and a list of drone identifiers to be subscribed to; The gateway node parses the subscription request and generates a subscription relationship record, which uses the client identifier as the key and the drone identifier set as the value. The gateway node writes the subscription relationship records into the distributed cache and state center, and stores them using a Redis Set data structure; Simultaneously, a client connection mapping record is generated, with the client identifier as the key and the current gateway node identifier and WebSocket connection handle as the value, and written to the distributed cache and state center; When a monitoring client actively unsubscribes or disconnects abnormally, the connected gateway node detects the connection interruption event and deletes the client's subscription relationship record and connection mapping record from the distributed cache and state center.

8. The method according to claim 6, characterized in that, S4 specifically includes: After the gateway node consumes standard trajectory data from the second topic of the distributed message bus, it parses the drone identifier carried in the data. Based on the drone's identifier, a query is initiated to the distributed cache and state center to obtain a list of all client identifiers that have subscribed to the drone; Iterate through the client identifier list. For each client identifier, query the distributed cache and state center to obtain the identifier of the gateway node currently connected to the client. Determine if the current gateway node identifier matches the gateway node identifier obtained from the query: If they match, the standard trajectory data will be pushed to the target client directly through the established WebSocket long connection between the gateway node and the target client. If there is a discrepancy, the standard trajectory data is encapsulated into a routing message and forwarded to the target gateway node through a pre-established communication channel between gateway nodes. The target gateway node then pushes the data through a WebSocket long connection between itself and the target client.

9. The method according to claim 8, characterized in that, The pre-established communication channel between the gateway nodes is a gRPC long connection channel or a Redis publish / subscribe channel; and when forwarding routing messages through the gRPC long connection channel, the following fault tolerance processing is also performed: a gRPC connection pool is established between the gateway nodes, a timeout is set and a retry mechanism is triggered when sending routing messages, and when the number of retries is exhausted and the sending still fails, the routing message is written to the local failure queue and reported to the monitoring and alarm system, and the target gateway node returns an acknowledgment to the source gateway node after completing the push.

10. The method according to claim 6, characterized in that, The method further includes: A load balancer is set up in front of the connection gateway cluster, using an ip_hash strategy or a consistent hash strategy to always distribute connection requests from the same monitoring client or the same drone to the same gateway node; The first topic of the distributed message bus is partitioned according to the drone identifier, and the trajectory processing engine cluster uses the drone identifier as the basis for partition allocation to ensure that the original state data of the same drone is consumed by the same processing engine instance, so as to maintain the order of trajectory processing. The distributed cache and the latest drone status data stored in the status center are set with a lifespan. When a drone fails to report data for a preset time, the drone status data is automatically cleared and the drone is marked as offline and pushed to the monitoring client.

Images