Robot operation control system and method for low-altitude economy

Abstract

The invention relates to the technical field of low-altitude economy robot control, and discloses a low-altitude economy-oriented robot operation control system and method. The system comprises a data receiving module, a task analysis and classification module, a protocol matching module, a rule generation module, an environment comparison and correction module and an instruction output module. The system analyzes task indicators and classifies the task indicators by receiving an original operation data packet of the robot; matching a control protocol library according to the classified data elements, and generating a strategy mapping table; calculating association weights among the protocols, and combining the association weights to generate an enhanced rule set; dynamically correcting the strategy mapping table by comparing the consistency of the real-time environment sensor data flow and the enhanced rule set; and finally analyzing and outputting an operation instruction of the robot. According to the method, intelligent fusion of a control protocol and online adaptive correction of a strategy are realized, and the autonomous decision-making capability and task execution efficiency of the low-altitude robot in a complex dynamic environment are improved.

Description

Technical Field

[0001] This invention relates to the field of low-altitude economic robot control technology, specifically to a robot operation control system and method for low-altitude economic use. Background Technology

[0002] Currently, robot operation control in the low-altitude economy largely relies on pre-set static rule bases or control protocols. After receiving task data, the system typically uses direct matching or simple priority scheduling to select one or a few fixed control protocols from the protocol library to generate execution instructions. This approach treats various control protocols as independent, immutable sets of instructions, lacking mechanisms for coordination and integration between protocols.

[0003] Existing technical solutions have shortcomings. Because the control protocols are static and isolated, the system struggles to handle complex, multi-objective integrated tasks. When task requirements exceed the scope of a single protocol, the system either cannot handle them effectively or requires manual orchestration by operators, resulting in limited automation and intelligence. Such systems also exhibit poor environmental adaptability. Their decision-making process is disconnected from real-time environmental awareness; typically, a lengthy replanning process is triggered only after an environmental anomaly is detected during the execution of predetermined instructions, leading to decision delays. In dynamic low-altitude environments, such delays can pose operational risks.

[0004] There is a need for a robot operation control system that can intelligently integrate multiple control protocols and quickly self-correct strategies based on real-time environmental information, in order to improve the robot's autonomous decision-making ability and task execution efficiency in complex low-altitude scenarios. Summary of the Invention

[0005] The purpose of this invention is to provide a robot operation control system and method for the low-altitude economy, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a robot operation control system for low-altitude economy, the system comprising: The data receiving module is used to receive the raw operation data packets transmitted by the robot; The task parsing and classification module is used to parse the task indicators contained in the original running data packet, and to perform preliminary classification of the original running data packet according to the type of the task indicators, forming a task-oriented data set; The protocol matching module is used to match each data element in the task-oriented data set with a pre-stored control protocol library and generate a policy mapping table corresponding to the control protocol. The rule generation module is used to traverse the multiple control protocols contained in the policy mapping table, calculate the correlation weights between the control protocols, and merge the control protocols according to the correlation weights to generate a set of reinforcement rules. The environment comparison and correction module is used to collect environmental sensor data streams in real time, compare the environmental sensor data streams with the reinforcement rule set for consistency, and correct the policy mapping table based on the comparison results. The instruction output module is used to parse the robot's action sequence based on the modified strategy mapping table and output the final running instructions.

[0007] Preferably, parsing the task indicator contained in the original runtime data packet includes: Extract the timestamp field, geolocation field, and behavior code field from the original runtime data packet; Input the timestamp field, geolocation field, and behavior code field into the task classifier to obtain the task type label output by the task classifier; Based on the task type tag, query the task knowledge graph to obtain the associated task nodes in the task knowledge graph that are connected to the task type tag; Information describing the associated task nodes is aggregated to form a task-oriented data set.

[0008] Preferably, the preliminary classification of the raw runtime data packets based on the type of the task indicator includes: Use task type tags as index keys to retrieve runtime data template libraries; Load the data segmentation template corresponding to the task type label from the runtime data template library; Apply the data segmentation template to the original runtime data packet, and split the original runtime data packet into multiple data fragments; Assign a unique partition identifier to each data segment, and store all data segments and their partition identifiers in a task-oriented data set.

[0009] Preferably, the pre-stored control protocol library includes: Read the content descriptor of a data element in a task-oriented dataset; Perform similarity matching between the content descriptor and the trigger conditions of each control protocol in the control protocol library; Control protocols with similarity exceeding a threshold are selected as candidate control protocols. Assign priority scores to candidate control protocols and sort them in descending order of priority scores to generate a policy mapping table.

[0010] Preferably, the association weights between the computation control protocols include: Select two control protocols from the policy mapping table and extract the feature vector of each control protocol; Calculate the cosine similarity between the feature vectors of the two control protocols as the initial correlation. Query the historical execution record database to obtain the frequency with which the two control protocols were called simultaneously in the past. The initial correlation degree and the frequency of simultaneous calls are weighted and averaged to obtain the correlation weight between control protocols.

[0011] Preferably, the association weight merging control protocol includes: Set an association weight threshold and mark control protocols with association weights higher than the threshold as highly associated protocol pairs; For each highly correlated protocol pair, extract the control rule clauses from the protocol pair; Merge duplicate or conflicting parts of the control rule clauses to generate new composite rules; All new composite rules are packaged together with the unmerged control protocols to form an enhanced rule set.

[0012] Preferably, the consistency comparison between the environmental sensor data stream and the enhanced rule set includes: Decode the environmental sensor data stream to obtain the current environmental status parameters; Extract one rule from the set of enhanced rules and analyze the scope of environmental conditions to which the rule applies. Determine whether the current environmental state parameters are within the range of environmental conditions to which the rule applies; If the rules fall within the specified range, they are marked as consistent; otherwise, they are marked as inconsistent. The number of rules marked as inconsistent in the statistical reinforcement rule set is counted.

[0013] Preferably, the step of correcting the strategy mapping table based on the comparison results includes: Calculate the ratio of the number of rules marked as inconsistent to the total number of rules in the reinforcement rule set; If the ratio exceeds the preset tolerance limit, the policy mapping table correction process is triggered. The correction process includes: re-matching the control protocol from the control protocol library based on the current environment status parameters, and updating the contents of the policy mapping table.

[0014] Preferably, the action sequence of the parsing robot includes: Read the revised policy mapping table and extract the action codes corresponding to the control protocols listed in the table; Based on the execution dependencies of the action codes, the action codes are topologically sorted to form a preliminary action sequence; Check for resource conflicts in the initial action sequence; If resource conflicts exist, the execution order of the action code is adjusted until the conflict is resolved, and the final action sequence is generated.

[0015] Preferably, the present invention also includes a robot operation control method for low-altitude economy, the method comprising all the modules and method flow of the robot operation control system for low-altitude economy as described above.

[0016] Compared with the prior art, the beneficial effects of the present invention are: After parsing the task and matching multiple control protocols, the system calculates the correlation weights between the protocols and merges them according to these weights to generate a reinforced rule set. This transforms the originally isolated and static protocols into a dynamically integrated, internally interconnected organic whole. The generated rule set can cover more complex task scenarios, and the synergistic effect between the rules enhances the system's ability to handle comprehensive tasks. The intelligence and adaptability of the decision output surpass the effect of simply stacking protocols.

[0017] The system acquires environmental sensor data streams in real time and compares them with the generated reinforcement rule set for consistency. Based on the comparison results, it directly corrects the policy mapping table. This mechanism establishes a high-speed feedback loop before the final output of the command. The system can make millisecond-level policy adjustments to environmental changes. The correction occurs at the policy level rather than at the level of a single command, making the robot's behavior response more proactive and smooth, and reducing the risk of execution interruption or failure due to sudden environmental changes.

[0018] By combining dynamic protocol integration with real-time environmental comparison and correction, a self-optimizing control closed loop is constructed. The system no longer merely executes pre-programmed instructions but can dynamically evolve and optimize its control strategy based on the inherent requirements of the task and external environmental constraints. This design enables the robot to exhibit stronger robustness and autonomy when performing long-cycle, variable low-altitude tasks, improving the overall system's operational efficiency and reliability. Attached Figure Description

[0019] Figure 1 This is a schematic diagram illustrating the working principle of the robot operation control system for low-altitude economy described in this invention. Figure 2 A flowchart for parsing task indicators; Figure 3 The flowchart is for matching the control protocol library; Figure 4 A diagram showing the correlation weights of control protocols; Figure 5 This is a timeline diagram for environmental consistency analysis. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please see Figure 1 This invention provides a robot operation control system for the low-altitude economy. The system includes: a data receiving module responsible for receiving raw operation data packets transmitted by the robot and forwarding the data packets to a task parsing and classification module. The task parsing and classification module parses the task indicators contained in the raw operation data packets, performs preliminary classification of the raw operation data packets according to the type of the task indicators, and forms a task-oriented data set. A protocol matching module matches each data element in the task-oriented data set with a pre-stored control protocol library to generate a policy mapping table corresponding to the control protocol. A rule generation module traverses multiple control protocols contained in the policy mapping table, calculates the correlation weights between control protocols, and merges control protocols according to the correlation weights to generate a reinforcement rule set. An environment comparison and correction module collects environmental sensor data streams in real time, performs consistency comparison between the environmental sensor data streams and the reinforcement rule set, and corrects the policy mapping table according to the comparison results. An instruction output module parses the robot's action sequence based on the corrected policy mapping table and outputs the final operation instruction.

[0022] Example 1: See Figure 2 In practical implementation, the task parsing and classification module's parsing operation of the original running data packet begins with the extraction of specific fields within the data packet. The original running data packet is forwarded by the data receiving module, and its structure contains multiple data segments with predefined formats. The module first calls the field parser to sequentially scan from the beginning of the original running data packet, identifying and separating the timestamp field, geographic location field, and behavior encoding field. The timestamp field records the absolute time information of the data packet's generation, the geographic location field contains the latitude and longitude coordinates and altitude of the robot when sending the data packet, and the behavior encoding field is a set of predefined codes used to characterize the robot's current or upcoming action intention. Inputting the timestamp field, geographic location field, and behavior encoding field into the task classifier is a crucial step. The task classifier is a pre-trained machine learning model that internally stores feature patterns of various task types. The task classifier receives the values ​​of the three fields as input vectors, performs calculations through its internal multi-layer neural network, and finally generates a probability distribution at the output layer. The category with the highest probability is the task type label output by the task classifier.

[0023] In some embodiments, the process of querying a task knowledge graph based on task type tags involves interaction with a graph database. The task knowledge graph is a large semantic network where nodes represent different task concepts or entities, and edges represent relationships between nodes. The system uses task type tags as query keywords to send a request to the task knowledge graph's query interface. Upon receiving the request, the query interface locates the node in the graph that perfectly matches the task type tag, then traverses all outgoing edges of that node to obtain all directly connected associated task nodes. In a specific implementation, aggregating the information described by associated task nodes to form a task-oriented data set is a data integration operation. Each associated task node contains a series of attributes describing the data dimensions, parameter requirements, and constraints required for that type of task. The system creates an empty task-oriented data set, then sequentially reads the attribute content of each associated task node, converts these attribute contents into standardized data descriptors, and adds all data descriptors sequentially to the task-oriented data set.

[0024] In practice, the process of initially classifying the raw runtime data packet according to the type of task indicator is driven by data templates. The task type label serves as the index key, and its value is used to retrieve the runtime data template library. The runtime data template library is a database stored in a local or network storage system. Each record contains a unique task type label and a corresponding data segmentation template. The system performs a database query operation, using the task type label as the query condition, to retrieve and load the corresponding data segmentation template from the runtime data template library. It can be understood that applying the data segmentation template to the raw runtime data packet is a data segmentation process. The data segmentation template is a set of rules defining how to divide the raw runtime data packet. The rules specify the starting offset, ending offset, and expected data type of each data segment. Following the rules in the data segmentation template, the system extracts corresponding byte segments from the binary stream of the raw runtime data packet. Each extracted byte segment constitutes an independent data fragment.

[0025] Optionally, assigning a unique partition identifier to each data segment is an identifier generation process. After successfully creating a data segment, the system immediately calls a partition identifier generator. This generator generates a globally unique string code based on the current system time, machine serial number, and a random number. This string code serves as the unique partition identifier for that data segment. In practice, storing all data segments and their partition identifiers into a task-oriented data set is the final step in the classification operation. The system creates a structured data storage object containing multiple storage units. Each storage unit stores a data segment and its associated partition identifier. The system iterates through all generated data segments, writing the data segment's content and its corresponding partition identifier as a record pair into the storage units of the data storage object. Once all data segments have been processed, this data storage object, containing all partition identifiers and data segment content, is marked as the final task-oriented data set and output to the subsequent protocol matching module.

[0026] In some embodiments, the training and updating of the task classifier is a continuous process. The task classifier is not static; its model parameters need to be fine-tuned periodically using new task execution data to maintain classification accuracy. The system records the task classifier's prediction results for task type labels each time, as well as the feedback from subsequent modules on these prediction results. This data is collected to form a training dataset, which is periodically used to retrain the task classifier model, enabling it to adapt to constantly changing low-altitude economic task scenarios. The construction and maintenance of the task knowledge graph is also a dynamic activity. The nodes and relationships in the task knowledge graph are not static but updated as domain knowledge develops. System administrators or domain experts can add new task nodes, delete outdated nodes, or modify the relationships between nodes through a dedicated knowledge management interface, ensuring that the task knowledge graph covers the latest low-altitude robot application modes. This dynamic update mechanism guarantees that the task parsing and classification modules can make decisions based on the latest knowledge.

[0027] Optionally, the customized design of the data segmentation template allows for fine-grained data preprocessing for different task types. For complex task types, the corresponding data segmentation template may contain a large number of segmentation rules, thereby dividing the original running data packet into numerous fine-grained data fragments. For simple task types, the data segmentation template may contain only a few rules, generating a smaller number of data fragments. This flexibility enables the system to allocate appropriate computing resources for data processing according to the complexity of the task, avoiding resource waste.

[0028] Example 2: See Figure 3In practical implementation, when the protocol matching module starts operating, it receives a task-oriented data set from the task parsing and classification module. The task-oriented data set contains multiple data elements, each with a content descriptor. The content descriptor is an abstract representation of the content of a data fragment, usually encoding the key attributes of the data in the form of a feature vector. For example, for a low-altitude logistics robot, the content descriptor of a data element may contain numerical features such as cargo weight, delivery destination coordinates, and urgency level indicators. The protocol matching module first traverses the task-oriented data set, processing each data element one by one. Reading the content descriptor of a data element in the task-oriented data set is done by calling a descriptor parser. The descriptor parser accesses the storage structure of the task-oriented data set, locates the specific entry based on the partition identifier of the data element, and then extracts the predefined content descriptor field from the entry. The content descriptor field is usually a multi-dimensional vector, with each dimension of the vector corresponding to a data feature. These feature values ​​have been standardized during the task parsing and classification stage. The vector dimension of the content descriptor is fixed to ensure consistency with the dimension of the trigger condition vector in the control protocol library, thereby facilitating subsequent similarity calculation. The protocol matching module temporarily stores the read content descriptor in a memory buffer to prepare for the next matching operation.

[0029] In practical implementation, a core computational process involves matching the content descriptor with the trigger conditions of each control protocol in the control protocol library based on similarity. The control protocol library is a database or collection of files that stores numerous predefined control protocols. Each control protocol contains a trigger condition, which is also represented as a feature vector with the same dimensions as the content descriptor vector. For example, a control protocol related to obstacle avoidance might have a trigger condition vector containing dimensions such as obstacle distance, relative speed, and environmental visibility. The protocol matching module iterates through all control protocols in the control protocol library. For each control protocol, it extracts its trigger condition vector and then calculates the similarity between the trigger condition vector and the content descriptor vector. The similarity calculation uses an algorithm based on a vector space model, and its mathematical expression is as follows: in: Indicates the similarity score. Represents a content descriptor vector. This represents the trigger condition vector for the control protocol. Represents the dimension of a vector. This represents the value of the content descriptor vector in the i-th dimension. This represents the value of the trigger condition vector in the i-th dimension. This formula calculates the complement of the normalized Manhattan distance, making the similarity value range between [0,1]. The larger the value, the more similar the similarity.

[0030] In some embodiments, filtering control protocols with similarity scores exceeding a threshold as candidate control protocols is a decision-making step. The protocol matching module presets a similarity threshold, which is a configurable parameter, typically set based on historical data or domain knowledge. For example, the threshold might be set to 0.7, meaning only control protocols with similarity scores higher than 0.7 are considered relevant. The module scans all similarity scores recorded in a temporary list, filtering out control protocols with scores below the threshold and retaining only those with scores above the threshold. These retained control protocols are marked as candidate control protocols. The number of candidate control protocols may be zero or one or more, depending on the actual matching situation. The module collects information on all these candidate control protocols, including protocol identifiers and similarity scores, into a new data structure, such as a list or array, for subsequent processing. Optionally, the dynamic adjustment mechanism of the similarity threshold can adaptively change based on changes in the system's operating environment. For example, in complex and changeable low-altitude environments, the system can automatically lower the threshold to capture more possible protocols, improving the system's robustness.

[0031] In practice, the final output stage of the protocol matching module is to assign priority scores to candidate control protocols and generate a policy mapping table by sorting them in descending order of priority scores. The priority score is a quantitative assessment of the importance of candidate control protocols; it is based not only on similarity scores but may also consider other factors, such as the protocol's historical execution success rate, execution cost, or how new the protocol is. The protocol matching module calculates a comprehensive priority score for each candidate control protocol. One way to calculate the priority score is using a weighted summation model, where the similarity score is used as a primary weight, and the contributions of other factors, such as the priority score, are added. It can be calculated as follows: in: It is a similarity score. It is the historical success rate of the agreement. It is the freshness coefficient of the timestamp of the most recent use of the protocol. , , These are predefined weighting coefficients that satisfy... After calculating the priority score for each candidate control protocol, the protocol matching module sorts all candidate control protocols from high to low according to their priority scores. The sorted results are organized into a table-like structure, namely the policy mapping table. Each row of the policy mapping table corresponds to a candidate control protocol, and the columns include at least the protocol identifier, similarity score, priority score, and a brief index of the protocol content.

[0032] Example 3: In specific implementation, the rule generation module receives a policy mapping table from the protocol matching module. The policy mapping table is an ordered list containing multiple candidate control protocols and their priority scores. The rule generation module needs to traverse the multiple control protocols contained in the policy mapping table and calculate the association weights between the control protocols. The first step in calculating the association weights is to select two control protocols from the policy mapping table. The selection operation is usually completed in a nested loop. The outer loop traverses each control protocol in the policy mapping table as the current protocol, and the inner loop traverses all control protocols after the current protocol as comparison protocols, thereby ensuring that each pair of control protocols is only calculated once for association weights. For each pair of selected control protocols, the rule generation module needs to extract the feature vector of each control protocol. The feature vector of the control protocol is a numerical representation of the content of the control protocol. The dimension of the feature vector is predefined, and each dimension corresponds to a key attribute of the control protocol. For example, for the flight control protocol of a low-altitude robot, the dimension of its feature vector may include quantitative indicators such as the applicable speed range of the protocol, the required safe distance of the protocol, and the energy consumption level of the protocol execution. The feature vector is usually pre-calculated and stored by the system administrator or automated tools when the control protocol is entered into the database.

[0033] In practical implementation, calculating the cosine similarity between the feature vectors of two control protocols as the initial correlation is a core step. Cosine similarity measures the similarity between two feature vectors by measuring the difference in their directions, ignoring their magnitude. The calculation process involves the dot product and magnitude calculation of the vectors, and its mathematical expression is as follows: in: This represents the calculated cosine similarity value, i.e., the initial correlation. This represents the feature vector of the first control protocol. This represents the feature vector of the second control protocol. A fixed dimension representing the feature vector. Representing vectors The component value in the m-th dimension, Representing vectors The initial correlation degree is calculated based on the component values ​​of the m-th dimension. The value range is between [-1, 1]. The closer the value is to 1, the more similar the feature vectors of the two control protocols are.

[0034] In practical implementation, querying the historical execution record database to obtain the frequency of simultaneous invocation of two control protocols in the past is another important input for calculating the association weight. The historical execution record database is a database that records the combination of control protocols actually invoked each time a task is executed during the system's past operation, along with their timestamps. The rule generation module sends a query request to the historical execution record database. The query condition is the identifiers of two specific control protocols, and the query goal is to count the number of times these two control protocols were simultaneously invoked within the same time window in all historical records. This number is the simultaneous invocation frequency, which reflects the probability of the two control protocols co-occurring in historical practice. It can be understood that obtaining the association weight between control protocols by weighted averaging the initial association degree and the simultaneous invocation frequency is a data fusion process. The calculation of the weighted average requires assigning appropriate weight coefficients to the initial association degree and the simultaneous invocation frequency, such as the association weight. It can be calculated as follows: in: It is the initial correlation. This is the normalized frequency of simultaneous calls. and It is a weighting coefficient, and satisfies The rule generation module calculates an association weight for each pair of control protocols in the policy mapping table. These weight values ​​are then stored in an associated weight matrix.

[0035] In some embodiments, the process of merging control protocols based on association weights begins by setting an association weight threshold, which is a preset threshold used to determine whether the association strength between two control protocols is sufficient for merging. The rule generation module then assigns each association weight in the association weight matrix to the relevant data. Compared with an association weight threshold, control protocol pairs with association weights exceeding the threshold are marked as highly associated protocol pairs, and all highly associated protocol pairs are collected into a pending list. In practice, extracting the control rule clauses from each highly associated protocol pair is a meticulous parsing task. Each control protocol consists of several control rule clauses, which define the specific behavioral logic of the protocol in structured text or code form, such as "flight speed must not exceed 10 meters / second" or "maintain a distance of at least 5 meters from obstacles." The rule generation module needs to parse the complete content of the two control protocols in the highly associated protocol pair, identify all independent control rule clauses, and extract these clauses into a temporary workspace. Optionally, merging duplicate or conflicting control rule clauses to generate new composite rules is crucial for rule synthesis. The rule generation module compares each control rule clause extracted from the two protocols. For clauses with completely duplicated content, only one is retained; for conflicting clauses, they are handled according to predefined conflict resolution strategies. These strategies might include choosing a more conservative value (10m / s), a more aggressive value (15m / s), or taking the average. The resulting set of clauses constitutes the new composite rule. The final output of the rule generation module is to package all the new composite rules with the unmerged control protocols to form a reinforcement rule set. Unmerged control protocols refer to individual control protocols in the policy mapping table that do not form highly correlated protocol pairs with any other protocols, as well as protocols in protocol pairs whose correlation weights do not exceed a threshold. The rule generation module creates a new rule set data structure, adding all the generated new composite rules and these unmerged control protocols to it. This complete set is the reinforcement rule set, which is then passed to the environment comparison and correction module.

[0036] See Figure 4This paper presents the results of the association weight matrix analysis between control protocols in the rule generation module. A heatmap visually illustrates the similarity of different control protocols in the feature space and their collaborative relationships during historical execution. The color depth of each cell in the graph represents the association strength between two control protocols in the corresponding row and column; a darker color indicates a higher association weight, meaning that the two protocols are more similar in functional characteristics and are frequently invoked simultaneously in historical execution. This association analysis provides an important basis for subsequent protocol merging and reinforcement rule set generation, helping to optimize the combination efficiency of control strategies. Elements on the diagonal, representing self-associations of the same protocol, are generally not considered in the analysis. By observing the overall pattern of the heatmap, the natural grouping of control protocols can be identified, providing data support for the system's intelligent decision-making. In the process of calculating association weights, the system comprehensively considers the similarity of the feature vectors of the control protocols and the frequency of simultaneous invocation during historical execution. The feature vectors include quantitative indicators of multiple dimensions such as speed range, safety distance, and energy consumption level, and the functional similarity between protocols is measured using a cosine similarity algorithm. The frequency of simultaneous invocation reflects the collaborative mode of the protocols in actual operation. The weighted fusion of these two factors forms the final association weight matrix. This multi-dimensional analysis method ensures the accuracy and practicality of the correlation weights.

[0037] Example 4: In specific implementation, when the environment comparison and correction module is started, it receives the enhanced rule set from the rule generation module and simultaneously accesses the environmental sensor data stream. The environmental sensor data stream consists of real-time readings from multiple sensors on the robot body and the surrounding environment, usually continuously input in the form of binary data packets or structured data frames. The primary task of the environment comparison and correction module is to decode the environmental sensor data stream to obtain the current environmental state parameters. The decoding process is executed by a dedicated data stream parser. The data stream parser disassembles the original data stream according to a predefined communication protocol and extracts the values ​​of each sensor channel. After calibration and unit conversion, these values ​​are mapped to a set of standardized environmental state parameters, such as current wind speed and direction, ambient light intensity, precipitation, and distance to surrounding obstacles. These parameters together constitute a current environmental state parameter vector that can describe the robot's real-time operating environment.

[0038] In practice, extracting a rule from the enhanced rule set and parsing the applicable environmental conditions range of the rule is an iterative process. The enhanced rule set contains multiple rules. The environment comparison and correction module creates a loop to process each rule in turn. For the rule being processed, the module needs to parse its internal structure. Each rule contains an environmental condition range clause, which defines the environmental parameter boundaries required for the rule to take effect. For example, the environmental condition range of a rule may be expressed as "wind speed less than 5 m / s" and "visibility greater than 1 km". The module uses a rule condition parser to interpret these clauses and convert the condition logic in text or code form into a computable range interval. For example, "wind speed less than 5 m / s" is converted into the wind speed parameter range [0, 5). It's understandable that determining whether the current environmental state parameters fall within the applicable environmental conditions range of the rule is a logical comparison operation. The module compares the corresponding parameter values ​​in the current environmental state parameter vector with the environmental condition range parsed by the rule. For example, it checks whether the current wind speed value falls within the [0,5) interval and whether the current visibility value is greater than 1000. If all condition comparison results are true, the current environmental state parameters are determined to be within the applicable environmental conditions range of the rule, and the rule is marked as consistent. If any condition comparison result is false, the rule is marked as inconsistent. The module maintains a consistency status flag for each rule. Counting the number of rules marked as inconsistent in the reinforcement rule set is a simple counting operation. After all rules have been processed, the module iterates through the consistency status flags of all rules, referring to Table 1, and accumulates the count of rules marked as "inconsistent" to obtain the number of inconsistent rules.

[0039] Table 1: Comparison Table of Environmental Parameters and Regulatory Conditions In practice, the process of revising the strategy mapping table based on the comparison results is controlled by a decision logic. The ratio of the number of rules marked as inconsistent to the total number of rules in the reinforcement rule set is the basis for triggering the revision judgment. The formula for calculating this ratio (denoted as the inconsistency ratio) is as follows: in: Indicates the proportion of inconsistencies. This indicates the number of rules marked as inconsistent. This indicates the total number of rules contained in the enhanced rule set.

[0040] The module will calculate the inconsistency ratio This is compared to a preset tolerance limit, which is a system configuration parameter, for example, set to 0.3, meaning the system allows a maximum of 30% of rules to be inconsistent with the current environment. If the inconsistency percentage... If the preset tolerance limit is exceeded, the policy mapping table correction process is triggered. The core operation of this process is to re-match control protocols from the control protocol library based on the current environment state parameters. The environment comparison and correction module treats the current environment state parameter vector as a new, comprehensive "content descriptor," and then calls logic similar to that of the protocol matching module to perform similarity matching between the current environment state parameter vector and the trigger conditions of each control protocol in the control protocol library. This filters out candidate control protocols highly relevant to the current environment, regenerates priority scores, and finally uses this newly generated policy mapping table to overwrite the old one, thus completing the update. Optionally, if the inconsistency ratio... If the preset tolerance limit is not exceeded, the system considers the current policy mapping table to be still valid, and there is no need to trigger the correction process. The module will directly use the existing policy mapping table for subsequent operations.

[0041] In some embodiments, the preset tolerance upper limit can be dynamically adjusted according to the criticality level of the task. For robots performing critical tasks, the system can adopt a lower preset tolerance upper limit to make the control system more sensitive to environmental changes; any slight environmental mismatch may trigger a strategy re-evaluation. For robots performing routine tasks, a higher preset tolerance upper limit can be used to reduce computational overhead and maintain behavioral stability. It is understood that the sampling frequency of the environmental sensor data stream and the frequency of consistency comparison need to be coordinated to avoid system oscillation caused by overly frequent correction operations. The consistency comparison operation is not performed immediately on every incoming data packet, but is triggered at a fixed time interval or when a significant jump in a critical environmental parameter is detected. Optionally, historical inconsistencies can be recorded to analyze the robustness of the system and the completeness of the control protocol, providing data support for the optimization of the control protocol library.

[0042] See Figure 5This paper presents the consistency analysis results between environmental sensor data and the enhanced rule set in the environmental comparison and correction module. The charts show the changing trend of the rule inconsistency ratio during system operation in time series form, while also overlaying real-time values ​​of key environmental parameters. The red line represents the rule inconsistency ratio, reflecting the proportion of rules that cannot meet all rule conditions under the current environmental state. The blue dashed line shows the changes in wind speed parameters, and the green dotted line represents the time-series changes in visibility parameters. The red horizontal dashed line in the chart indicates the system's preset tolerance upper limit threshold. When the inconsistency ratio exceeds this threshold, the system will trigger the correction process of the strategy mapping table. During system operation, the environmental comparison and correction module continuously monitors the environmental sensor data stream and matches it with each rule in the enhanced rule set. For each rule, the system checks whether the current environmental parameters are within the applicable conditions of the rule, counts the number of inconsistent rules, and calculates the inconsistency ratio. When the inconsistency ratio exceeds the tolerance upper limit, it indicates that the current environmental state has changed significantly, and the existing control strategy needs to be re-evaluated and adjusted. The system re-matches the most suitable control protocol from the control protocol library based on the current environmental state parameters, updating the policy mapping table to ensure the robot's adaptability and safety. This dynamic correction mechanism guarantees the system's robustness and reliability in complex and variable low-altitude environments. The correction trigger points marked in the graph show situations where the system detects a severe mismatch between environmental conditions and the rule set at specific times. These points typically correspond to drastic changes in environmental parameters or the occurrence of extreme weather conditions. By analyzing the temporal distribution and frequency of these correction events, the system's sensitivity to environmental changes and response efficiency can be assessed, providing important reference for subsequent optimization of the control protocol library and adjustment of the rule set.

[0043] Example 5: In a specific implementation, the instruction output module receives the corrected policy mapping table from the environment comparison and correction module. The corrected policy mapping table is an ordered list of control protocols after environmental consistency verification. The core function of the instruction output module is to parse the robot's action sequence based on this table and output the final running instructions. The module first performs the operation of reading the corrected policy mapping table. The reading process is completed by accessing the shared memory area or querying the database. The corrected policy mapping table is usually stored in the form of a table. Each row corresponds to a control protocol entry, which includes information such as protocol identifier, protocol content index, and priority score. The instruction output module uses a table parser to traverse each row of the table and process each listed control protocol in turn. Extracting the motion codes corresponding to the control protocols listed in the table is the next crucial step. Each control protocol has its own detailed definition in the control protocol library, which includes one or more sets of motion codes. Motion codes are low-level instructions that can be directly interpreted by the robot actuator, such as "set the motor speed to 1000 RPM" or "adjust the servo angle to 45 degrees". The instruction output module initiates a query request to the control protocol library based on the identifier of the control protocol, retrieves and loads all motion codes associated with that protocol, and these motion codes are temporarily stored in an motion code pool, awaiting further processing.

[0044] In practical implementation, the process of topologically sorting action codes according to their execution dependencies to form a preliminary action sequence is an application of graph theory algorithms. Execution dependencies refer to the sequential execution constraints between action codes. For example, action code A must be executed before action code B because B requires the output of A as input. The instruction output module needs to construct a dependency graph, where nodes represent action codes and directed edges represent dependencies. When constructing the dependency graph, the module analyzes the metadata of each action code, which defines a list of precondition codes. By parsing this metadata, the module can establish connections between nodes. For the dependency graph, the topological sorting algorithm linearizes the nodes, ensuring that for any edge (u, v), u always appears before v in the sequence. Topological sorting can be implemented using the Kahn algorithm or depth-first search, ultimately outputting a linear sequence of action codes that satisfies all dependencies—the preliminary action sequence. In some embodiments, to optimize the sorting result, a priority weight may be assigned to the action codes to adjust their order while satisfying dependencies. For example, the priority weight can be calculated using the following formula: in: This indicates the priority weight of action code i. and It is a pre-defined dimensionless weighting coefficient and satisfies , This represents the depth of action code i in the dependency graph. This represents the maximum depth of all nodes in the current dependency graph. This indicates the estimated execution time of action code i. This indicates the maximum estimated execution time for all action codes in the current action code pool.

[0045] In practical implementation, checking for resource conflicts in the initial action sequence is a crucial verification step. A resource conflict occurs when multiple action codes attempt to simultaneously use the same physical or logical resource, leading to contention or errors. For example, two action codes might both require controlling the same joint motor of the robot simultaneously. The instruction output module maintains a resource mapping table that defines the list of resources required by each action code. Resources can include sensor access permissions, communication channels, actuator control rights, etc. The module simulates the execution of the initial action sequence, allocating a virtual time window for each action code. It then checks if any two action codes have overlapping resource requirements and time windows. If such overlap exists, it's considered a resource conflict, and the module records all detected conflict pairs. In essence, resource conflict checking is a necessary step to ensure the safe execution of the action sequence, preventing runtime errors.

[0046] In practical implementation, adjusting the execution order of action codes until the conflict is resolved if resource conflicts exist is the core of sequence optimization. Strategies for adjusting the order include, but are not limited to: delaying the execution time of conflicting code, advancing the execution time of conflicting code, or inserting waiting code to serialize resource access, all while satisfying dependencies. The instruction output module employs a cyclic adjustment algorithm. This algorithm traverses the initial action sequence, and whenever a resource conflict is detected, it attempts to reorder the action codes involved in the conflict. Reordering must ensure that no existing execution dependencies are violated. Therefore, the adjustment operation is performed within the limits allowed by the dependency graph. For example, for two conflicting action codes A and B, if there is no path from A to B or from B to A in the dependency graph, then the positions of A and B in the sequence can be swapped. If dependencies exist, their execution time windows can only be staggered by introducing delays or advancing execution. The module repeatedly performs conflict detection and order adjustment until no resource conflicts are found in a complete traversal. The sequence generated at this point is the final action sequence. Optionally, new action code, such as resource lock acquisition and release code, may be introduced during the adjustment process to explicitly manage resource access. Finally, the action sequence is encapsulated into an instruction package and sent to the robot actuator through the communication interface to complete the task of the instruction output module.

[0047] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0048] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A robot operation control system for the low-altitude economy, characterized in that, The system includes: The data receiving module is used to receive the raw operation data packets transmitted by the robot; The task parsing and classification module is used to parse the task indicators contained in the original running data packet, and to perform preliminary classification of the original running data packet according to the type of the task indicators, forming a task-oriented data set; The protocol matching module is used to match each data element in the task-oriented data set with a pre-stored control protocol library and generate a policy mapping table corresponding to the control protocol. The rule generation module is used to traverse the multiple control protocols contained in the policy mapping table, calculate the correlation weights between the control protocols, and merge the control protocols according to the correlation weights to generate a set of reinforcement rules. The environment comparison and correction module is used to collect environmental sensor data streams in real time, compare the environmental sensor data streams with the reinforcement rule set for consistency, and correct the policy mapping table based on the comparison results. The instruction output module is used to parse the robot's action sequence based on the modified strategy mapping table and output the final running instructions.

2. The robot operation control system for low-altitude economy according to claim 1, characterized in that, The process of parsing the task indicator contained in the original runtime data packet includes: Extract the timestamp field, geolocation field, and behavior code field from the original runtime data packet; Input the timestamp field, geolocation field, and behavior code field into the task classifier to obtain the task type label output by the task classifier; Based on the task type tag, query the task knowledge graph to obtain the associated task nodes in the task knowledge graph that are connected to the task type tag; Information describing the associated task nodes is aggregated to form a task-oriented data set.

3. The robot operation control system for low-altitude economy according to claim 2, characterized in that, The preliminary classification of raw runtime data packets based on the type of task indicator includes: Use task type tags as index keys to retrieve runtime data template libraries; Load the data segmentation template corresponding to the task type label from the runtime data template library; Apply the data segmentation template to the original runtime data packet, and split the original runtime data packet into multiple data fragments; Assign a unique partition identifier to each data segment, and store all data segments and their partition identifiers in a task-oriented data set.

4. The robot operation control system for low-altitude economy according to claim 1, characterized in that, The pre-stored control protocol library for matching includes: Read the content descriptor of a data element in a task-oriented dataset; Perform similarity matching between the content descriptor and the trigger conditions of each control protocol in the control protocol library; Control protocols with similarity exceeding a threshold are selected as candidate control protocols. Assign priority scores to candidate control protocols and sort them in descending order of priority scores to generate a policy mapping table.

5. The robot operation control system for low-altitude economy according to claim 4, characterized in that, The association weights between the computation control protocols include: Select two control protocols from the policy mapping table and extract the feature vector of each control protocol; Calculate the cosine similarity between the feature vectors of the two control protocols as the initial correlation. Query the historical execution record database to obtain the frequency with which the two control protocols were called simultaneously in the past. The initial correlation degree and the frequency of simultaneous calls are weighted and averaged to obtain the correlation weight between control protocols.

6. The robot operation control system for low-altitude economy according to claim 5, characterized in that, The associated weight merging control protocol includes: Set an association weight threshold and mark control protocols with association weights higher than the threshold as highly associated protocol pairs; For each highly correlated protocol pair, extract the control rule clauses from the protocol pair; Merge duplicate or conflicting parts of the control rule clauses to generate new composite rules; All new composite rules are packaged together with the unmerged control protocols to form an enhanced rule set.

7. The robot operation control system for low-altitude economy according to claim 1, characterized in that, The step of performing a consistency comparison between the environmental sensor data stream and the enhanced rule set includes: Decode the environmental sensor data stream to obtain the current environmental status parameters; Extract one rule from the set of enhanced rules and analyze the scope of environmental conditions to which the rule applies. Determine whether the current environmental state parameters are within the range of environmental conditions to which the rule applies; If the rules fall within the specified range, they are marked as consistent; otherwise, they are marked as inconsistent. The number of rules marked as inconsistent in the statistical reinforcement rule set is counted.

8. The robot operation control system for low-altitude economy according to claim 7, characterized in that, The step of correcting the strategy mapping table based on the comparison results includes: Calculate the ratio of the number of rules marked as inconsistent to the total number of rules in the reinforcement rule set; If the ratio exceeds the preset tolerance limit, the policy mapping table correction process is triggered. The correction process includes: re-matching the control protocol from the control protocol library based on the current environment status parameters, and updating the contents of the policy mapping table.

9. The robot operation control system for low-altitude economy according to claim 1, characterized in that, The action sequence of the analytical robot includes: Read the revised policy mapping table and extract the action codes corresponding to the control protocols listed in the table; Based on the execution dependencies of the action codes, the action codes are topologically sorted to form a preliminary action sequence; Check for resource conflicts in the initial action sequence; If resource conflicts exist, the execution order of the action code is adjusted until the conflict is resolved, and the final action sequence is generated.

10. A robot operation control method for low-altitude economy, characterized in that, It includes all modules and method flows of the robot operation control system for low-altitude economy as described in any one of claims 1 to 9.

Images