Unmanned system cluster resource supply and demand dynamic sensing and monitoring system

Abstract

The invention discloses an unmanned system cluster resource supply and demand dynamic sensing and monitoring system, which adopts a distributed architecture and an intelligent algorithm lightweight monitoring and deployment scheme, realizes dynamic resource optimization and predictive maintenance of a server cluster through a performance data analysis and prediction model based on the design of a domestic operating system, and improves the service life of the server cluster. An efficient cluster management task is completed in an intelligent operation and maintenance scene, monitoring index data are transmitted to a prometheus deployed on a ground station in a grading manner, a monitoring scene specific to an unmanned system cluster is supported, a migration function of tasks on unmanned nodes with insufficient resource margin is supported, and the monitoring task is efficiently completed in a resource limited scene.

Description

Technical Field

[0001] The present invention relates to the technical field of unmanned system cluster scheduling, and in particular to an unmanned system cluster resource supply and demand dynamic perception monitoring system. Background Art

[0002] Currently, there is a public patent document for cluster monitoring, "Cluster Monitoring Method for Multiple Public Cloud Computing Platforms" (authorization announcement number CN 110912773B), and its core technology lies in resource monitoring and task scheduling in a multi-cloud environment. The method mainly includes the following steps: collecting cluster node, CPU and task status data through the cloud platform API; performing multi-dimensional analysis and processing on the collected data and storing it persistently; realizing automatic task migration based on the monitoring data to optimize resource utilization; and finally realizing hierarchical alarms and automatic repairs through the alarm subsystem. The invention also provides corresponding data processing subsystems, data collection subsystems and storage solutions. However, since it is a unified monitoring and intelligent scheduling in a multi-cloud environment, it uses cloud vendor interfaces and third-party plug-ins for data collection, resulting in the inability to efficiently complete monitoring tasks in resource-constrained scenarios.

[0003] For cluster monitoring, there is also a public patent document "Server Cluster Monitoring and Management System" (Authorization Announcement No. CN111984498B). Its core technology lies in hardware status monitoring and fault alarm based on BMC, and does not involve predictive maintenance and dynamic resource optimization based on intelligent algorithms. The method mainly includes the following steps: collecting hardware data through temperature / voltage / current sensors; storing device information through E2PROM; threshold judgment by BMC and triggering alarm lights; recording operation logs and fault information and uploading them periodically; finally, realizing power on / off, restart and firmware update control through a centralized management platform. The invention also provides corresponding sensor modules, BMC control modules and visual interfaces. However, since it is real-time monitoring and fault location at the hardware level, using sensors and BMC for hardware status collection is only applicable to server scenarios and may not be effective in drone scenarios. Summary of the Invention

[0004] The purpose of the technical solution of the present invention is to efficiently complete the task of monitoring the supply and demand of unmanned system cluster resources in a resource-constrained scenario.

[0005] In order to achieve the above-mentioned purpose, the technical solution of the present invention provides a dynamic perception and monitoring system for supply and demand of unmanned system cluster resources, comprising:

[0006] Deploy a node to each UAV as an unmanned node mission statement, assign a preset number of unmanned nodes to the same scheduler, and set up a specific field to ensure the interval between adjacent schedulers as a scheduler mission statement, which is stored in the ground station;

[0007] The ground station obtains the configuration files of all nodes in the unmanned cluster and converts them into corresponding Node objects. It then checks all nodes using the ping command. If successful, it obtains the initial location information of all nodes in the unmanned cluster based on the Node objects.

[0008] According to the scheduler task declaration and the unmanned node task declaration, combined with the initial location information, the scheduler and the unmanned node are scheduled. Each time the scheduling node is determined, an execution command is sent to the node with the corresponding IP address, so that the topology structure after scheduling satisfies the interval between adjacent schedulers. At this time, the unmanned node execution task deployment is completed;

[0009] All schedulers obtain the position sequence of all Node objects, calculate the distance based on the position relationship between themselves and other nodes, and sort them to obtain a distance table between the scheduler and the unmanned nodes. The scheduler defines the unmanned node management domain based on the distance table and sets the acceptable threshold of the node to schedule a preset number of unmanned nodes.

[0010] The ground station obtains the desired unmanned node based on the lowest threshold between the distance table and the acceptable threshold. For unmanned nodes selected by only one scheduler, the ground station writes the corresponding entry in the "server-agent management table". For unmanned nodes that appear multiple times, the ground station writes the entry of the scheduler with the least number of currently managed unmanned nodes. The "server-agent management table" is determined and pushed to the scheduler. For unmanned nodes that are not selected, the ground station increases its own threshold to the specified value to obtain the corresponding desired unmanned node and writes it into the "server-agent management table".

[0011] The ground station schedules the unmanned nodes and scheduler according to the "server-agent management table", the scheduler task declaration and the unmanned node task declaration, so that the scheduler obtains all monitoring data information from the unmanned nodes and judges the network load within the domain. If the comprehensive network load is within a specific range, the frequency of the unmanned node pushing monitoring data to the scheduler is dynamically adapted to the load of the cluster, so that the monitoring system itself will not affect the normal operation of non-system tasks.

[0012] Preferably, the configuration file includes configurations such as the node name, static IP, and the corresponding topic for publishing location coordinates.

[0013] Preferably, the scheduling steps are as follows:

[0014] According to the task list and initial position information of the scheduler, a two-dimensional position pair is selected for traversal. The number of nodes managed by each scheduler is calculated based on the number of all nodes n and the number of servers m. It is defined that each positive integer m has a corresponding whole root p. The topological partitioning form obtained is m=p*(p+1)+q and m=p*p+q. In this partitioned area, a scheduling node is selected from each sub-area as the scheduler.

[0015] The technical solution of the present invention proposes a dynamic perception and monitoring system for resource supply and demand of unmanned system clusters, which adopts a distributed architecture and intelligent algorithm lightweight monitoring and deployment solution, is designed based on a domestically produced operating system, realizes dynamic resource optimization and predictive maintenance of server clusters through performance data analysis and prediction models, completes efficient cluster management tasks in intelligent operation and maintenance scenarios, and transmits monitoring indicator data in a hierarchical manner to Prometheus deployed at the ground station, supports monitoring scenarios specific to unmanned system clusters, supports the migration function of tasks on unmanned nodes with insufficient resource margins, and efficiently completes monitoring tasks in resource-constrained scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A schematic diagram of the overall structure of an unmanned system cluster resource supply and demand dynamic perception and monitoring system provided by an embodiment of the present invention;

[0017] Figure 2 A schematic diagram of area division provided in an embodiment of the present invention;

[0018] Figure 3 A schematic diagram of a cluster topology provided in an embodiment of the present invention;

[0019] Figure 4 This is a schematic diagram of the final topology result provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0020] Below in conjunction with specific embodiment, further set forth the present invention.Should be understood that these embodiments are only used to illustrate the present invention and are not used in limiting the scope of the present invention.In addition, should be understood that after reading the content taught by the present invention, those skilled in the art can make various changes or modifications to the present invention, and these equivalent forms fall equally within the scope limited by the appended claims of the application.

[0021] The scheduler server manages all unmanned node agents within a domain. The unmanned node agent is used to describe the nodes corresponding to all drones in the cluster that provide monitoring information.

[0022] like Figure 1 As shown, an embodiment of the present invention provides an unmanned system cluster resource supply and demand dynamic perception monitoring system, including:

[0023] When the cluster is running, the unmanned node agent manages its corresponding scheduler server configuration and pushes the collected indicator data to it.

[0024] The scheduler (server) manages a certain number of agents in a specific domain, monitors the status of the agents, and based on the current status of the agents, modifies the status field of the corresponding Node object, adds a specific label, and synchronizes with the ground station.

[0025] The ground station is responsible for the initialization of the cluster, scheduling and binding agent and server tasks to the unmanned node agent for execution, maintaining the cluster status when the cluster is running, and rescheduling some tasks.

[0026] The ground station module is the first module to be started when the monitoring system cluster in an unmanned system is initialized. This is because the ground station module serves as the main scheduler, deploying modules such as agents and servers that exist as cluster system components. The task declarations of agents and servers are placed in a specific directory of the ground station. During the ground station startup process, the ground station reads the configuration files of the tasks related to these system components in the directory and performs scheduling and binding operations on them, as follows:

[0027] 1. The agent task is stored in the ground station system directory in a specific configuration format, and the configuration states that each drone should deploy an agent;

[0028] 2. Server tasks (i.e., scheduler components) are stored in a specific format in the ground station system directory, and users should customize the number of servers to be enabled in the entire cluster based on the scale of the cluster (generally speaking, every 6 to 7 agents can be assigned a server for management). Specific fields in the configuration file (for the server's YAML configuration, the affinity.unitAffinity.geographySelector field can declare distance:greatEnough to ensure that adjacent schedulers are far enough apart to form a suitable topology in the cluster) ensure that the ground station scheduler uses the appropriate scheduling strategy to schedule this type of task.

[0029] 3. The ground station program is started, and the user submits the configuration files of all nodes in the unmanned cluster, including the node name, static IP, corresponding topic for publishing location coordinates, and other configurations, and converts them into Node (single node object) object format for storage.

[0030] 4. The ground station verifies the correctness of the drone swarm node configuration and checks each unmanned node using the ping command.

[0031] 5. When the check passes, the ground station obtains the initial location information of all nodes in the unmanned cluster through the topic in the Node configuration.

[0032] 6. The ground station reads the system task configuration file (agent and server configuration) in the system directory and converts it into TaskTopo and TaskUnit (objects of a single schedulable task unit).

[0033] 7. The ground station schedules all TaskUnits of the agent (there are as many TaskUnits of the agent as there are Node objects): each TaskUnit of the agent specifies the node to be scheduled through scheduleNode.

[0034] 8. The ground station schedules all TaskUnits of the server: The ground station should make the server show a reasonable topological distribution in the cluster, such as Figure 1 As shown (each server is separated by a certain distance, which indirectly ensures that the topological distribution of the servers will not have multiple servers concentrated together). Therefore, whenever the ground station scheduler finds that the field geographySelector = distance: greatEnough appears in a Task declaration, it can call the following default algorithm, that is, the node started by the ground station initialization scheduler component is the following node to initialize the scheduler topology of the entire cluster. (This algorithm is a very simple example and only implements the interfaces given in (1) and (2) below. In fact, better implementations can be directly replaced):

[0035] (1) Input: the server's TaskUnit list and the location of each Node (obtained through the topic in 5).

[0036] (2) Output: The new server list assigned to scheduleNode.

[0037] (3) Based on the (x, y, z) values given by the position topic of all nodes, only the (x, y) pairs are selected and traversed to obtain x_min, x_max, y_min, y_max.

[0038] (4) If n nodes are enabled, corresponding to m servers, each server will manage approximately n / m nodes. Furthermore, every positive integer m has a corresponding whole root p (rounded after taking the square root), and can be expressed as m = p*(p+1)+q or m = p*p+q. The above two forms (preferably the first one, if the first one fails, choose the second one) are the ways to delineate regions in the (x_min, x_max, y_min, y_max) space, and a server can be selected in each region.

[0039] (5) For example, for the form of m=p*(p+1)+q, (x_min,x_max,y_min,y_max) is divided roughly as follows: First, divide it from left to right (p+1) times to ensure that there are (p*(n / m)) drones in each divided area, and there should be (q*(n / m)) drones in the remaining areas; then divide each column into rows to ensure that there are n / m drones in each grid.

[0040] (6) Randomly select a node from each sub-area as a server and record it in the schedule field of the server's TaskUnit.

[0041] 9. Each time the ground station determines a node to schedule for a TaskUnit, it sends an execution command to the node with the corresponding IP. When the task actually starts executing on the node, it records the task in the "scheduleTasks" field of the Node object corresponding to the node.

[0042] 10. Ultimately, the ground station deploys all system tasks (including agents and servers) to the corresponding drones for execution. Furthermore, the ground station itself acts as a monitor controller, waiting for all monitor servers to start and initialize. (The ground station maintains a "server-agent management table" and three topics: "domain negotiation," "domain determination," and "domain extension," used to synchronize server management domains with the servers.)

[0043] Currently, all system tasks of the cluster have just started running but have not yet been initialized. Therefore, you first need to give all server initialization operations:

[0044] 1. Each server will synchronize all Node objects on the ground station when it starts. Therefore, all servers obtain the (x, y, z) position sequence of all Nodes.

[0045] 2. Each server calculates the distance based on its own positional relationship with other nodes (in actual use, the physical distance and the number of IP network hops can be combined for weighting, but for simplicity, the physical distance is used directly here) and sorts the distance table between the server and the agent. The server defines its own "agent management domain" based on the distance table, and defines the acceptable threshold of the node based on the distance: there is an increasing sequence ([threshold]->k) by default. For example, for a threshold of 0, the corresponding acceptable distance value should be less than or equal to k[0]*L, L=((x_max-x_min)+(y_max-y_min) / 2) / p, p is Figure 2 The specification values in .

[0046] 3. When the server starts, it obtains the agent it wants to manage based on the distance sequence with the agent and the lowest threshold, and informs the "ground station" of its own choice through the "domain negotiation" topic.

[0047] 4. The "Ground Station" obtains the lowest threshold declarations of all servers through the "Domain Negotiation" topic. For agents declared by only one server, it directly writes the corresponding entry in its own "Server-Agent Management Table". For agents that appear multiple times, it writes the entry of the server with the least number of currently managed agents. The "Server-Agent Management Table" that has been determined above is pushed to the corresponding server through the "Domain Determination" topic to actually add the agent for management.

[0048] 5. For agents that have never been declared and managed by any server, the "ground station" notifies all servers through the "domain extension" topic to expand their own thresholds to the specified value.

[0049] 6. The server obtains all new agents it wishes to manage using the new threshold, and repeats the management domain synchronization steps 3, 4, and 5 above until the server-agent management table of the ground station contains all agents.

[0050] At this point, the server has officially formed a distributed network and has a corresponding agent management domain. However, to ensure that the agent correctly interacts with the server that actually manages it, the server will synchronize with the corresponding agent every time it receives confirmation of an agent entry it manages through the "Domain Confirmation" topic from the ground station. The steps are as follows:

[0051] 1. The server sends a message to each agent, indicating that this "server" is the new manager.

[0052] 2. The "agent" receives the management signal, releases the previous writer and topic (if any, it will be released; if not, it will not be released), and creates a new writer and topic corresponding to the "server" (the DDStopic connection established between the agent and server is used to push monitoring data and health checks).

[0053] At this point, a connection is officially established between the agent and the server. The agent can push monitoring data and health check data to the server. The server can save the monitoring data to a local non-persistent database. In addition, the ground station can periodically pull data from the server's database and save it to its own large database for persistent storage.

[0054] When the cluster is running:

[0055] 1. The ground station contains a complete "server-agent management table", all scheduled TaskTopo, TaskUnit, NodeTopo.

[0056] 2. The server contains NodeTopo2 (adapted to itself, including a status field (based on monitoring data, containing real resource consumption and energy consumption information), and supports adding taints, labels, and other information). It will also include non-system TaskUnit information in the management domain (because there is no scheduling of non-system tasks, it is empty); a real-time maintained list of distances between agents, the actual managed "agent entries"; and DDS communication-related topics for interacting with agents.

[0057] 3. The agent contains information about the server that manages itself and DDS-related topics for communicating with the server.

[0058] 4. Expected overall cluster runtime topology: Servers form a reasonable "server network" across the cluster based on their configured "long distances," and each server manages its own surrounding agents to avoid network load caused by long-distance routing.

[0059] However, because cluster nodes change dynamically, the domain managed by the server is not static. An agent may leave its current server management domain and enter another server management domain. This is because the health check the agent sent to the old server failed. Therefore, the server will resend all agents it wishes to manage to the "domain negotiation" topic at the current highest threshold, excluding the agent that failed the health check. Therefore, the ground station and server will synchronize as follows:

[0060] 1. The agent management entry declared by a server in "Domain Negotiation" happens to be missing an item from the agent entry of the corresponding server in the "Server-Agent Management Table" managed by the ground station. The ground station confirms to the "server" that it has accepted the change through the "Domain Determination" topic.

[0061] 2. Because the ground station's "server-agent management table" does not include all agents, the ground station starts from the lowest threshold and informs each server through the "domain extension" topic to publish the agent entries it wants to manage to the "domain negotiation" topic according to the corresponding threshold based on the current real-time "distance table between agents".

[0062] 3. After receiving the "agent desired management entries" from all servers, the ground station will only search for the agent entries currently missing. If a corresponding entry is found, it will add the agent entry to its own "server-agent management table" and publish a confirmation message to the server via the "domain confirmation" topic. After receiving the message, the server will add the agent to its actual "agent management entries" and publish a message to the newly added agent, declaring itself the new manager.

[0063] 4. If not found, the ground station continues to increase the server's acceptance threshold through the "domain expansion" topic until the missing agent is accepted by a server.

[0064] Sometimes, the server itself can change dynamically. This is because the server's location may change, and it may not meet the "desired server spacing" configuration of the geographySelector field corresponding to the "ground station" server's Task. The ground station (unlike the server, which only stores Task information for non-system tasks) stores system-level Task information and also receives real-time location data from all nodes in the cluster. Therefore, the ground station should start a background process to check whether all system-level tasks meet the affinity configuration (such as the server's geographySelector).

[0065] The background thread of the ground station can run the following program to determine whether the topology of the nodes where certain tasks of the cluster are located meets the affinity requirements of the task configuration (this is just a simple example implementation and can be replaced with a better algorithm later as long as the corresponding interface is implemented):

[0066] 1. Input: TaskUnit sequence, affinity requirements that should be met between TaskUnits

[0067] 2. Output: A sequence of child TaskUnits (the scheduleNode field value of each TaskUnit in the sequence is different from the previous one)

[0068] 3. Check the affinity requirements. If the "task spacing is far enough" requirement of geographySelector is met, execute the following algorithm:

[0069] 4. Get the current (x_min, x_max, y_min, y_max) of the cluster and Figure 2 Division

[0070] 5. Get the value of the scheduleNode field where TaskUnit is located, and get the topology of the cluster where the node running the "server" system task is located. Take m=11 as an example, Figure 3 Possible outcomes (divided into mild and severe cases. When the cluster is running, severe cases should be ensured to occur less frequently).

[0071] 6. The ideal distribution is that in each divided area, there is only one drone performing the "server" system task. Therefore, subtracting the ideal situation from the actual situation, the final topology result is as follows Figure 4 As shown: A positive sign indicates that there are extra servers in the area, and a negative sign indicates that there are missing servers in the area.

[0072] 7. Traverse the region with the integer value k, randomly select k TaskUnits corresponding to "server" and add them to the output sub-TaskUnit sequence, indicating that these system tasks will be rescheduled.

[0073] 8. Rescheduling: Traverse the area with a value of negative 1, randomly select a Node in the area, and assign the Node information to the scheduleNode field of the output TaskUnit, changing the original old field.

[0074] The ground station gets the server (scheduler component) that should be re-bound. The re-binding is performed as follows:

[0075] 1. Input: The sub-TaskUnit sequence output by the above algorithm (the scheduleUnit field has been reassigned)

[0076] 2. The ground station maintains a new "server-agent management table" and copies the old table values into it, but leaves the fields of the server to be "rebound" in the management table empty.

[0077] 3. "Rebinding", the new and old servers are executed together: the ground station starts the system task on the corresponding node according to the scheduleNode information declared by the TaskUnit, and executes it once for all TaskUnits in the sequence.

[0078] 4. The ground station processes changes to the "server-agent management table" entries: After the new system task server on the Node is started, it declares the agent domain it wants to manage to the "domain negotiation" topic through the minimum threshold by default; the ground station accepts this content in the new "server-agent management table" (adds the fields declared by the server to it), and after receiving the "domain negotiation" information of all new servers, it deletes the conflicting items from the fields of the servers that have not been "rebound" this time (that is, the second agent item appears).

[0079] 5. The management table (entries) between the ground station and the server are synchronized through the "domain confirmation" topic: the ground station sends a confirmation message to the "domain confirmation" topic of the server where the "agent management entry" has been changed, and overwrites the field values of the old table with the field values of the new table. At this time, the newly added "management agent entry" is obtained through the server, and a new server and server management agent topology network will be established in the interaction with the agent. The ground station will synchronize real-time information (including all NodeTopo in the server management domain, Task objects of non-system-level tasks, etc.) to the corresponding new server. Even if the old server still exists, it has actually been isolated from any component (the agent no longer pushes data to it, and the old server's interaction request to the ground station is ignored because its creation timestamp is lower than the new timestamp)

[0080] 6. Terminate the execution of the old server and release the cache and memory space.

[0081] The server receives all monitoring data within the management domain and stores it in its own non-persistent database. Therefore, the server can assess the network load within the domain based on all the monitoring data it receives (especially network I / O-related data). If the server's calculated overall network load falls within a specific range, it can inform the management agent of the frequency at which monitoring data should be pushed to it, dynamically adapting to the cluster load and ensuring that the monitoring system itself does not affect the normal operation of non-system tasks.

[0082] The distributed design of the monitoring system itself running on the node in the embodiment of the present invention avoids the problem of single-node failure of Prometheus and the exponential increase in the network load of the monitoring system caused by the simultaneous deployment of multiple Prometheus. In addition, for the server running on the unmanned node, there is no need to write the monitoring data to the local disk, only non-persistent memory storage is required, which ensures the lightweight design of the monitoring components on the unmanned node; at the same time, the ground station pulls the monitoring data from each server in real time and stores it persistently, which avoids the loss of monitoring data. At the same time, the server will actively and adaptively adjust the push frequency of the agent according to the load in the domain, reducing the impact of the monitoring system on the operation of non-system tasks. In addition, the monitoring system has a clear architecture and lightweight implementation, which is easier to transplant to domestic systems than existing monitoring systems and is applied to the monitoring of unmanned systems.

[0083] An embodiment of the present invention provides a dynamic perception and monitoring system for the supply and demand of resources in an unmanned system cluster. Each server has its own management node domain, which only receives the indicator data of its own management node and stores it non-persistently in memory (such as redis). The ground station, as the main control program, can periodically access the data in the non-persistent database of each server and save it to a local large database to solve the problem that a large amount of monitoring data is stored on the unmanned node and consumes space, and the monitoring system itself does not form a distributed monitoring topology in the cluster. In the embodiment of the present invention, the distributed server used for monitoring will extract network load related information from the indicator data collected by the managed agent, and notify all agents to reduce the indicator data push frequency when the network load is large, so as to solve the problem that the original monitoring system cannot dynamically and adaptively change its own data interaction frequency, resulting in a surge in network load. The architecture is clear, with few modules and lightweight (especially only one agent needs to be deployed on the monitored end), which solves the problem that the existing monitoring system architecture is relatively complex and difficult to adapt to localization.

[0084] The unmanned system cluster resource supply and demand dynamic perception monitoring software provided by the embodiment of the present invention is designed based on the prometheus open source project, has good community support, supports distributed cluster deployment, supports deployment on domestic operating systems, and is lightweight enough (drone-exposer and cluster-exposer use less resources such as cpu and mem). When in use, the drone-exposer deployed on the drone first collects the indicator data on the local machine and submits it to the cluster monitoring component cluster-exposer distributedly deployed on the cluster (each cluster-exposer manages all drone-exposers in a certain domain). The cluster monitoring component cluster-exposer finally submits the indicator data of the drones in the domain to the prometheus deployed on the ground station at a specified time interval. If the network bandwidth is occupied and the network load of the cluster running user tasks is large, drone-exposer and cluster-exposer will adaptively update the indicator collection and submission frequency to reduce the impact of the monitoring component communication on the cluster network load, and finally visualize it on grafana.

[0085] The key technical points of the embodiments of the present invention are:

[0086] 1. Distributed server deployment solves single point of failure;

[0087] 2. The monitoring data interaction between agent-servers reflects load adaptability.

Claims

1. A dynamic perception and monitoring system for resource supply and demand of unmanned system clusters, characterized by: include: Deploy a node to each UAV as an unmanned node mission statement, assign a preset number of unmanned nodes to the same scheduler, and set up a specific field to ensure the interval between adjacent schedulers as a scheduler mission statement, which is stored in the ground station; The ground station obtains the configuration files of all nodes in the unmanned cluster and converts them into corresponding Node objects. It then checks all nodes using the ping command. If successful, it obtains the initial location information of all nodes in the unmanned cluster based on the Node objects. According to the scheduler task declaration and the unmanned node task declaration, combined with the initial location information, the scheduler and the unmanned node are scheduled. Each time the scheduling node is determined, an execution command is sent to the node with the corresponding IP address, so that the topology structure after scheduling satisfies the interval between adjacent schedulers. At this time, the unmanned node execution task deployment is completed; All schedulers obtain the position sequence of all Node objects, calculate the distance based on the position relationship between themselves and other nodes, and sort them to obtain a distance table between the scheduler and the unmanned nodes. The scheduler defines the unmanned node management domain based on the distance table and sets the acceptable threshold of the node to schedule a preset number of unmanned nodes. The ground station obtains the desired unmanned node based on the lowest threshold between the distance table and the acceptable threshold. For unmanned nodes selected by only one scheduler, the ground station writes the corresponding entry in the "server-agent management table". For unmanned nodes that appear multiple times, the ground station writes the entry of the scheduler with the least number of currently managed unmanned nodes. The "server-agent management table" is determined and pushed to the scheduler. For unmanned nodes that are not selected, the ground station increases its own threshold to the specified value to obtain the corresponding desired unmanned node and writes it to the "server-agent management table". The ground station schedules the unmanned nodes and scheduler according to the "server-agent management table", the scheduler task declaration and the unmanned node task declaration, so that the scheduler obtains all monitoring data information from the unmanned nodes and judges the network load within the domain. If the comprehensive network load is within a specific range, the frequency of the unmanned node pushing monitoring data to the scheduler is dynamically adapted to the cluster load, so that the monitoring system itself will not affect the normal operation of non-system tasks.

2. The unmanned system cluster resource supply and demand dynamic perception monitoring system according to claim 1, characterized in that: The configuration file includes the node name, static IP, corresponding topic for publishing location coordinates, and other configurations.

3. The unmanned system cluster resource supply and demand dynamic perception monitoring system according to claim 1, characterized in that: The scheduling steps are as follows: According to the task list and initial position information of the scheduler, a two-dimensional position pair is selected for traversal. The number of nodes managed by each scheduler is calculated based on the number of all nodes n and the number of servers m. It is defined that each positive integer m has a corresponding whole root p. The topological partitioning form obtained is m=p*(p+1)+q and m=p*p+q. In this partitioned area, a scheduling node is selected from each sub-area as the scheduler.

Images