A modeling language generation method for an unmanned aerial vehicle group-oriented application scenario

Abstract

This application relates to the field of unmanned aerial vehicle (UAV) technology and discloses a method for generating a modeling language for UAV swarm application scenarios. The method includes: constructing a task model to determine the three-level hierarchical relationship between the UAV swarm's scenario tasks, tasks, and sub-tasks, the collaborative relationships between tasks, and the collaborative relationships between sub-tasks; constructing a resource model to analyze the resources required by the task model and provide a unified resource description; constructing a constraint model to analyze the constraints of each UAV regarding resources, motion, environment, and time, and determining the constraints of the UAV swarm based on the constraints corresponding to each UAV; determining the BNF paradigm of the task model, resource model, and constraint model, and constructing syntax rules; constructing XML conforming to the BNF paradigm based on the syntax rules, and combining the results to generate a modeling language for UAV swarm application scenarios applicable to different application scenarios, providing a good underlying foundation for multi-UAV collaborative task planning.

Description

Technical Field

[0001] This application relates to the field of unmanned aerial vehicle (UAV) technology, and in particular to a method for generating modeling languages ​​for application scenarios involving UAV swarms. Background Technology

[0002] With the development of drone technology and intelligent technologies, drones have been widely used in both military and civilian fields. Intelligent drone swarms are characterized by their large number of resources, complex functions, heterogeneity, spatiotemporal constraints, and mission-driven nature. The mission scenarios of drone swarms are complex and dynamic, requiring them to address challenges such as consistent spatiotemporal consistency, consistent information expression, and consistent situational awareness to achieve autonomous and collaborative mission management. This necessitates the development of standardized descriptions of tasks, resources, and constraints under complex dynamic scenarios, modeling the capabilities and resources of drone swarms during mission execution, and adapting the computational model to the evolving capabilities of the computational scenario to ensure system safety throughout its entire lifecycle.

[0003] Unmanned aerial vehicle (UAV) swarm mission description languages ​​can be divided into individual mission description languages ​​and cluster mission description languages. Individual mission description languages ​​define the mission of a single UAV, while cluster mission description languages ​​define the collaborative mission of multiple UAVs, as well as the operations that each UAV must perform and the constraints between each operation. Traditional single-UAV missions suffer from drawbacks such as rigid mission description languages, UAVs' inability to adapt to the mission environment, and the inability to dynamically change flight paths. In swarm missions, mission description languages ​​need to focus on dynamic representation and enable the UAV swarm to respond to and handle emergencies.

[0004] With the continuous expansion and deepening of UAV swarm applications, the tasks performed by UAV swarms are becoming more complex and diverse, environmental uncertainties are increasing, and swarm resources are constantly changing. UAV swarm systems need to have stronger applicability to various application scenarios, while also facing new technological development demands. Research on swarm task description methods started later than research on individual UAV tasks, mainly because swarm tasks are more complex than individual tasks, and swarm tasks within UAV swarms have certain scenario complexity, diversity of UAVs performing the task, and diversity of task coordination constraints. Currently, the main task description methods for UAV swarms in the industry include: class-based programming methods, which provide a rich set of functions and strong expressive capabilities; declarative markup language-based methods, which have good readability, extensibility, and reusability; and graphical user interface-based methods, which are easy to use and user-friendly.

[0005] However, the inventors of this application have discovered that the above-mentioned method for describing the mission of drone swarms still has many shortcomings:

[0006] (1) The task modeling method based on class programming requires users to have certain programming skills, which makes this method unsuitable for rapid application building in dynamic scenarios.

[0007] (2) Task description methods based on declarative markup languages ​​reduce the flexibility of application domains and platforms.

[0008] (3) Task modeling methods based on graphical user interfaces are tightly bound to the applications they develop, making it difficult to migrate and use them for different application scenarios.

[0009] (4) The above task modeling methods only focus on the task level for multi-UAV collaboration, lacking consideration of resources and constraints, and mostly regard UAVs as homogeneous resources, with few restrictions on constraints.

[0010] (5) The UAV swarm task description languages ​​involved in the above methods are mostly limited to a single or a few tasks and depend on their specific application fields, such as only for search and rescue or only for logistics and transportation. They have poor versatility and cannot adapt to the needs of multiple changing scenarios. Summary of the Invention

[0011] The purpose of this application is to provide a modeling language generation method for application scenarios of drone swarms. It comprehensively considers the tasks, resources and constraints of drone swarms, and constructs a detailed scenario model of the drone swarm in the process of performing tasks. It can be applied to different application scenarios and provides a good underlying foundation for multi-drone collaborative task planning.

[0012] To address the aforementioned technical problems, embodiments of this application provide a method for generating a modeling language for application scenarios of unmanned aerial vehicle (UAV) swarms, comprising the following steps: constructing a task model, determining the three-level hierarchical relationship between the scenario task, tasks, and subtasks of the UAV swarm, the collaborative relationship between each task, and the collaborative relationship between each subtask under the same task; constructing a resource model, analyzing the resources required by the task model, classifying the resources required by the task model into tuples, and performing a unified resource description; constructing a constraint model, analyzing the constraints of each UAV regarding resources, motion, environment, and time, and determining the constraints of the UAV swarm based on the constraints corresponding to each UAV; determining the BNF paradigm of the task model, the resource model, and the constraint model, and constructing syntax rules; constructing a declarative markup language (XML) conforming to the BNF paradigm based on the syntax rules, and generating a modeling language for application scenarios of UAV swarms after combination.

[0013] Embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described modeling language generation method for application scenarios of unmanned aerial vehicle swarms.

[0014] This application provides a method for generating a modeling language for UAV swarm application scenarios. It hierarchically subdivides task types and constructs a three-level task specification tree, supporting the needs of various UAV swarm scenarios, tasks, and subtasks. This achieves the generalization of the modeling language, making it suitable for applications in different fields. By using the BNF paradigm and XML language, the syntax rules of the modeling language for UAV swarm application scenarios are standardized, providing a reasonable and effective specification for language generation and a solid foundation for multi-UAV collaborative task planning. Through the conversion of task models, resource models, and constraint models to scenario-oriented models, the reuse of various tasks, resources, and constraints is provided. Combined with the modeling method, this improves the efficiency of users in building UAV swarms. Using this UAV swarm application scenario modeling language, UAV swarm modeling can be completed simply and quickly, thereby enabling rapid application development in dynamic scenarios.

[0015] In some optional embodiments, the step of constructing a task model to determine the three-level hierarchical relationship between the scene task, tasks, and subtasks of the UAV swarm, the collaborative relationship between each task, and the collaborative relationship between each subtask under the same task includes: constructing a scene task, specifying basic scene task information, scene task attributes, and a task set. The basic scene task information includes the scene task identifier, scene task name, and scene task description. The scene task attributes are a six-tuple, including the scene task state, scene task type, scene task time, scene task coordinates, the task collaborative relationship corresponding to the task set, and the resource requirements of the scene task. The task collaborative relationship includes sequential execution, parallel execution, branch execution, and convergence execution. The step of constructing a task model includes specifying a task base. This information comprises a task set, task attributes, and a set of subtasks. The basic task information includes the task identifier, task name, and task description. The task attributes are a six-tuple, including the task's state, task type, task time, task coordinates, the task collaboration relationship corresponding to the subtask set, and the task's resource requirements. Subtasks are constructed by specifying their basic information and attributes. The basic subtask information includes the subtask identifier, subtask name, and subtask description. The subtask attributes are a six-tuple, including the subtask's state, subtask type, subtask time, subtask coordinates, subtask objective, and subtask resource requirements. The scenario task is the parent element of all the tasks, and a task is the parent element of at least one subtask.

[0016] In some optional embodiments, the construction of the resource model, the analysis of the resources required by the task model, the classification of the resources required by the task model into tuples, and the unified resource description include: constructing scenario resources, the scenario resources being formally described as a six-tuple, including basic resource information, resource status information, resource domain information, resource capability information, resource service information, and resource log information; constructing the basic resource information, including resource ID, resource name, resource type, and resource description, the attribute value of the resource type indicating whether the UAV is a fixed-wing UAV or a multi-rotor UAV; constructing the resource status information, the attribute value of the resource status information being one of idle, not fully loaded, fully loaded, under maintenance, overloaded, or invalid; constructing the resource domain information, the attribute value of the resource domain information being one of logistics, agriculture, rescue, search, or inspection; constructing the resource capability information, including mobility capability, perception capability, communication capability, load capacity, endurance capability, and task payload capability; constructing the resource service information, including the number of resources available, the service time of the resources, and the set of tasks that the resources can complete; and constructing the resource log information, including the resource historical time and resource remarks corresponding to the resource historical events.

[0017] In some optional embodiments, the construction of the constraint model, analyzing the constraints of each UAV regarding resources, motion, environment, and time, and determining the constraints of the UAV swarm based on the constraints corresponding to each UAV, includes: constructing pathpoint constraints, including constructing a set of pathpoints, constructing a unique pathpoint identifier, pathpoint longitude, pathpoint latitude, and pathpoint altitude for each pathpoint, and constructing a pathpoint connectivity matrix, wherein the pathpoints are used to characterize the path reachability of the UAVs in path planning, and each row vector of the pathpoint connectivity matrix is ​​used to characterize the connectivity between a pathpoint and other pathpoints; constructing obstacle constraints, including constructing a unique obstacle identifier, obstacle name, obstacle longitude, obstacle latitude, obstacle minimum altitude, and obstacle maximum altitude for each obstacle, wherein the obstacle is an object that the UAV cannot pass horizontally but can avoid by increasing altitude; constructing prohibition... Flight constraints include constructing no-fly zones and safety restrictions. The safety restrictions define the safe distance and altitude limits between the drone and the external environment and other drones. Constructing no-fly zones includes constructing the shape, minimum altitude, and maximum altitude of each no-fly zone. The shape of the no-fly zone is defined as a rectangle, circle, or polygon. Constructing safety restrictions includes constructing a unique identifier, name, minimum safe distance, minimum flight altitude, and maximum flight altitude for each safety restriction. Weather constraints include constructing a unique weather identifier, name, description, type, duration, temperature range, coverage area, and wind for each weather event. The weather type is defined as high temperature, low temperature, fog, thunderstorms, rain, or strong winds. The coverage area is defined as a rectangle, circle, or polygon. The wind is used to describe the wind force level and wind speed.

[0018] In some optional embodiments, determining the BNF normal form of the task model, the resource model, and the constraint model, and constructing grammar rules, includes: defining grammar rules for each element and its attribute value using the BNF normal form based on the definition of each element and its attribute value in the task model, the resource model, and the constraint model; describing the dependencies between each element and the dependencies between each attribute value; setting terminal and non-terminal symbols; and constructing nesting relationships between parent and child elements.

[0019] In some optional embodiments, for the task model, the construction syntax rules include: using <mission>The field represents the scenario task, the <mission>Divided into categories representing the basic information of the scene task<Mission_attr> Characterizing the attributes of the scene task <missionproperty>and characterizing the set of tasks <task>The<Mission_attr> Divided into identifiers representing the tasks in the aforementioned scenario<Mission_id> The name representing the scenario task<Mission_name> and a description representing the task in the scenario<Mission_describe> The <missionproperty>Divided into states representing the tasks in the scenario<Mission_state> Characterizing the type of the scenario task<Mission_type> , representing the time of the scenario task<Mission_time> The coordinates representing the scene task<Mission_Coord> Characterizing the task collaboration relationships corresponding to the task set<Mission_Relationship> and the resource requirements that characterize the scenario task<Mission_Requirements> ; using the <task>Characterizing the task, the <task>Divided into categories representing the basic information of the task<Task_attr> Characterizing the attributes of the task <taskproperty>and characterizing the set of subtasks <subtask>The<Task_attr> Divided into identifiers representing the task<Task_id> The name representing the task<Task_name> and a description characterizing the task<Task_describe> The <taskproperty>Dividing the state that represents the task<Task_state> Characterizing the type of the task<Task_type> Characterizing the time of the task<Task_time> The coordinates representing the task<Task_Coord> Characterizing the task collaboration relationships corresponding to the sub-task set<Task_Relationship> and characterize the resource requirements of the task<Task_Requirements> ; using the <subtask>Characterizing the subtask, the <subtask>Divided into subtasks representing basic information<SubTask_attr> and characterizing the attributes of the subtask <subtaskproperty>The<SubTask_attr> Divided into identifiers representing the subtasks<SubTask_id> The name representing the subtask<SubTask_name> and the description that characterizes the subtask<SubTask_describe> The <subtaskproperty>Divided into states representing the subtasks<SubTask_state> Characterizing the type of the subtask<SubTask_type> , representing the time of the subtask<SubTask_time> The coordinates representing the subtask<SubTask_Coord> Characterizing the goal of the sub-task <subtasktarget>and characterizing the resource requirements of the subtask<Task_Requirements> .

[0020] In some optional embodiments, for the resource model, the construction syntax rules include: using <resourc>Describe resources, build <stateinfo>Describe the status information of the resource, the <stateinfo>It is divided into the tag "StateInfo" and child elements.<StateInfo_value> The<StateInfo_value> The value is limited to a string and can be one of the following: idle, underloaded, fullload, maintenance, overloaded, or invalid. "idle" indicates the device is idle, "underloaded" indicates it is not at full load, "fullload" indicates it is at full load, "maintenance" indicates it is under maintenance, "overloaded" indicates it is overloaded, and "invalid" indicates it is invalid. <domaininfo>Describe the domain information of the resource, the <domaininfo>Divided into the label "DomainInfo" and several<DomainInfo_Value> Each of the above<DomainInfo_Value> Separate them with commas.<DomainInfo_Value> The value is limited to a string and can be one of Logistics, Agriculture, Rescue, Search, or HighwayPatrol. Logistics represents logistics, Agriculture represents agriculture, Rescue represents rescue, Search represents searching, and HighwayPatrol represents inspection. <functioninfo>The description of the capability information of the resource, the <functioninfo>It is divided into sub-elements representing mobility (MoveAbility), perception (SenseAbility), communication (CommunicationAbility), load (LoadAbility), endurance (CruisingAbility), and mission payload (MissionPayload); and constructed. <serviceinfo>Describe the service information of the resource, the <serviceinfo>The attributes are divided into the label "ServiceInfo" and represent the quantity of resources available. <serviceinfonumber>Attributes representing the serviceability time of the resource <serviceinfotime>and the sub-elements of the task list <servicetasklist>The <servicetasklist>Includes one or more characterizing the task <servicetask>Child elements; construction <loginfo>The log information describing the resource, the <loginfo>Includes several characterization logs <log>Sub-element, the <log>Depend on <loginfo>and< / loginfo> Surrounding, the <log>Includes characterizing the historical time of the resource <logtime>and the resource notes that characterize the historical events of the resources. <lognote>.

[0021] In some optional embodiments, for the constraint model, the construction syntax rules include: using <constraint>Describe constraints, using <waypoints>Represents the set of path points, the <waypoints>Divided into "WayPoints" labels and representations of the path points. <waypoint>The <waypoint>Divided into "WayPoint" labels and<WayPoint_attr> The<WayPoint_attr> The unique identifier of the waypoint, the longitude of the waypoint, the latitude of the waypoint, and the altitude of the waypoint are defined, and used...<Coord_attr> The path point connectivity matrix represents the path points connected by the path.<Coord_attr> Divided into "Connectivity" tag and<Connectivity_values> The<Connectivity_values> Composed of several<Connectivity_value> Connected, the<Connectivity_value> The value is limited to either the character 0 or the character 1; use <obstacle>The obstacle is referred to as the obstacle. <obstacle>Divided into the tag "Obstacle"<Obstacle_attr> Characterizing the minimum height of the obstacle <minaltitude>and characterizing the highest height of the obstacle <maxaltitude>The<Obstacle_attr> Classified into unique identifiers representing the obstacles<Obstacle_id> , characterizing the name of the obstacle<Obstacle_name> Characterizing the longitude of the obstacle<Obstacle_longitude> and characterizing the latitude of the obstacle<Obstacle_latitude> ;use <noflyarea>Characterizing the no-fly zone, the <noflyarea>The area is designated as a "NoFlyArea," signifying a massive no-fly zone. <rectangle>Characterizing a circular no-fly zone <circle>and characterizing polygonal no-fly zones <polygon>The <circle>Includes sub-elements representing the coordinates of the center point. <center>and sub-elements representing the radius of the no-fly zone <radius>;use <safedistance>This indicates the security restriction, the <safedistance>Divided into the tag "safeDistance" and attributes<safeDistance_attr> Sub-elements representing the minimum safe distance <mindis>Sub-element representing the minimum flight altitude <minaltitude>and sub-elements representing the highest flight altitude <maxaltitude>The<safeDistance_attr> Including the security restriction unique identifier<safeDistance_id> and characterizing the name of the security restriction<safeDistance_name> ;use <weather>The weather is described. <weather>Divided into the tag "Weather" and attributes<Weather_attr> Sub-elements representing the duration <duration>Characterizing the temperature range <temperature>Characterizing the coverage area <coveredarea>And characterizing the wind <wind>The<Weather_attr> Including the unique identifier representing the weather<Weather_id> The weather name is represented by<Weather_name> Characterizing the weather description<Weather_describe> and characterizing the weather type<Weather_type> The <wind>Including those characterizing the wind force level <windlevel>and characterizing the wind speed <windspeed>.

[0022] In some optional embodiments, constructing a declarative markup language XML conforming to the BNF paradigm based on the syntax rules includes: constructing the XML of the task model, comprising three parts: the scenario task, the task, and the subtasks, so that the... <mission>The definition in the text contains several of the above. <task>And one of the aforementioned <missionproperty>, so that the <task>The definition in the text contains several of the above. <subtask>And one of the aforementioned <taskproperty>, so that the <subtask>The definition in contains the above. <subtaskproperty>; Construct the XML of the resource model, so that the <resourc>The definition in contains the above. <basicinfo>The above <stateinfo>The above <domaininfo>The above <functioninfo>The above <serviceinfo>Japanese <loginfo>; Construct the XML of the constraint model, so that the <constraint>The definition in contains the above. <waypoints>The above <obstacle>The above <noflyarea>The above <safedistance>Japanese <weather>The XML of the task model, the XML of the resource model, and the XML of the constraint model are integrated into a single XML, which serves as a modeling language for application scenarios involving UAV swarms. Attached Figure Description

[0023] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0024] Figure 1 This is a flowchart of a modeling language generation method for application scenarios of unmanned aerial vehicle (UAV) swarms, provided by an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the hierarchical structure of the task model provided in one embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0027] One embodiment of this application relates to a modeling language generation method for application scenarios of unmanned aerial vehicle (UAV) swarms. The implementation details of this method are described below. The following implementation details are provided for ease of understanding and are not necessary for implementing this solution.

[0028] The specific process of the modeling language generation method for UAV swarm application scenarios provided in this embodiment can be as follows: Figure 1 As shown, it includes:

[0029] Step 101: Construct a task model to determine the scenario tasks of the drone swarm, the three-level hierarchical relationship between tasks and sub-tasks, the collaborative relationship between tasks, and the collaborative relationship between sub-tasks under the same task.

[0030] Understandably, a drone swarm scenario refers to the description of the tasks, resources, and constraints of a drone swarm in a specific context (such as highway inspection). Here, "task" refers to one or more specific tasks that the drone swarm needs to complete. "Resources" refers to the payload and other resources available to the drones during the task execution. "Constraints" refers to environmental, spatiotemporal, and resource constraints encountered by the drones during the task execution. The scenario model is a triple, including a task model (Mission), a resource model (Resource), and a constraint model (Constraint), which can be represented as: Scenario =<Mission,Resource,Constraint> .

[0031] In the specific implementation, a task model is constructed, which involves determining the scenario task of the UAV swarm, the three-level hierarchical relationship between tasks and subtasks, the collaborative relationship between each task, and the collaborative relationship between subtasks under the same task. This includes three parts: constructing the scenario task, constructing each task under the scenario task, and constructing each subtask under each task.

[0032] Construct a scenario task, establish a Mission as the scenario task, and specify the basic information of the scenario task (MissionAttr), scenario task attributes (MissionProperty), and task set (Task). The basic information of the scenario task (MissionAttr) includes the scenario task identifier (Mission ID), scenario task name (Mission Name), and scenario task description (Mission Describe). The scenario task attribute (MissionProperty) is a six-tuple, including the scenario task state (Mission State), scenario task type (Mission Type), scenario task time (Mission Time), scenario task coordinates (Mission Coord), the task coordination relationship corresponding to the task set (Mission Relationship), and the scenario task resource requirements (Mission Requirements). The task coordination relationship includes sequential execution (Sequence), parallel execution (CoBegin), branch execution (Fork), and convergence execution (Join). The six-tuple of Mission Property can be specifically represented as: MissionProperty = {MissionState, MissionType, MissionTime, MissionCoord, MissionRelationship, MissionRequirements}.

[0033] Construct a task, using `Task` as the task name, specifying basic task information (`Task Attr`), task properties (`TaskProperty`), and a set of subtasks (`SubTask`). The `Task Attr` includes the task identifier (`Task ID`), task name (`Task Name`), and task description (`Task Describe`). The `Task Property` is a six-tuple containing the task's state (`Task State`), task type (`Task Type`), task time (`Task Time`), task coordinates (`TaskCoord`), the task relationship (`Task Relationship`) for the subtask set, and the task's resource requirements (`TaskRequirements`). Subtask relationships include sequential execution (`Sequence`), parallel execution (`CoBegin`), branch execution (`Fork`), and convergence execution (`Join`). Specifically, the six-tuple of `Task Property` can be represented as: `TaskProperty = {TaskState, TaskType, TaskTime, TaskCoord, TaskRelationship, TaskRequirements}`.

[0034] Construct a subtask, using `SubTask` as the subtask name, and specify the basic subtask information `SubTask Attr` and subtask properties `SubTask Property`. The basic subtask information `SubTask Attr` includes the subtask identifier `SubTaskID`, the subtask name `SubTask Name`, and the subtask description `SubTask Describe`. The subtask property `SubTask Property` is a six-tuple, including the subtask state `SubTask State`, the subtask type `SubTask Type`, the subtask time `SubTask Time`, the subtask coordinates `SubTask Coord`, the subtask target `SubTask Target`, and the subtask resource requirements `SubTask Requirements`.

[0035] It is worth noting that a Mission contains one or more child elements, Task, and the two are in a containment relationship. The Mission is always the parent element of the Task. A Task contains one or more child elements, SubTask, and the two are in a containment relationship. The Task is always the parent element of each SubTask under the Task.

[0036] In one example, the hierarchical structure of the task model can be as follows: Figure 2 As shown.

[0037] In one example, the scenario task is a highway inspection scenario task, which has three sub-tasks: road inspection, bridge inspection, and slope inspection. The road inspection task has three sub-tasks: guardrail inspection, crash barrier inspection, and road surface inspection. The bridge inspection task has five sub-tasks: bridge deck inspection, bearing inspection, pier inspection, expansion joint inspection, and abutment inspection. The slope inspection task has three sub-tasks: slope top inspection, slope surface inspection, and slope base inspection.

[0038] In one example, the scenario task is a search and rescue scenario task, which has two sub-tasks: a search task and a rescue task. The search task has two sub-tasks: a target location sub-task and a data acquisition sub-task. The rescue task has two sub-tasks: a real-time communication sub-task and a material transportation sub-task.

[0039] In one example, the scenario task is a material transportation scenario task, which has three sub-tasks: cargo loading, cargo transportation, and cargo unloading. The cargo loading task has a loading sub-task, the cargo transportation task has two sub-tasks: target location sub-task and multi-point flight sub-task, and the cargo unloading task has two sub-tasks: target location sub-task and unloading sub-task.

[0040] Step 102: Construct a resource model, analyze the resources required by the task model, classify the resources required by the task model into tuples, and provide a unified resource description.

[0041] In the specific implementation, a resource model is constructed, namely, a scenario resource is constructed. The scenario resource is formally described as a six-tuple, including the resource's basic information Basic Info, resource's state information State Info, resource's domain information Domain Info, resource's capability information Function Info, resource's service information Service Info, and resource's log information Log Info. This six-tuple can be specifically represented as: Resource = {BasicInfo, StateInfo, DomainInfo, FunctionInfo, ServiceInfo, LogInfo}.

[0042] Construct the Basic Info of the resource, including specifying the Resource ID, Resource Name, Resource Type, and Resource Description. The attribute values ​​of Resource ID and Resource Name are identifiers, the attribute value of Resource Type is either fixed-wing or multirotor, indicating that the UAV is a fixed-wing UAV or a multirotor UAV, and the attribute value of Resource Description can be any string.

[0043] Construct the State Info of the resource. The State Info attribute value of the resource's State Info represents the current state of the resource. Its attribute value is one of the following: idle, underloaded, full load, maintenance, overloaded, or invalid. That is, the current state of the resource includes six types: idle, underloaded, full load, maintenance, overloaded, and invalid.

[0044] Construct the domain information of the resource, which represents the specific domain defined by the resource. According to the application domain of the drone, it can be divided into logistics, agriculture, rescue, search and inspection. The attribute value of the domain information of the resource is one of Logistics, Agriculture, Rescue, Search or HighwayPatrol.

[0045] The resource's capability information (Function Info) includes the main functions that can be implemented and their corresponding parameters. This Function Info includes Move Ability, Sense Ability, Communication Ability, Load Ability, Cruise Ability, and Mission Payload. These capabilities can be flexibly combined to reflect the diversity of UAV capabilities. Furthermore, the technical parameters corresponding to each UAV's capabilities demonstrate its performance.

[0046] Construct the Service Info of the resource, including the number of available resources (Service Number), the service time of the resource (Service Time), and the set of tasks that the resource can complete (Service TaskList). The Service Time is the start time to the end time, including a time string in the format "HH:MM:SS". The Service TaskList is empty at the beginning and is entered after the resource model and task model are matched.

[0047] Log Info is constructed for the resource. During the use of the drone resource, corresponding time, status information, and remarks are recorded. The resource's Log Info includes the resource's historical time (LogInfo Time) and the resource's corresponding remarks (LogInfo Note). The value of LogInfo Time is a time string, using the ISO 8601 date and time representation method, in the format "YYYY-MM-DDTHH:MM:SS". The value of LogInfo Note is a string.

[0048] Step 103: Construct a constraint model, analyze the constraints of each UAV regarding resources, motion, environment, and time, and determine the constraints of the UAV swarm based on the constraints corresponding to each UAV.

[0049] In practical implementation, constructing a constraint model requires establishing pathpoint constraints, obstacle constraints, no-fly zones, and weather constraints. The constraints of the drone swarm are determined by analyzing the constraints of each drone regarding resources, motion, environment, and time.

[0050] The process involves constructing waypoint constraints, including building a set of waypoints (WayPoints), a unique identifier (WayPoint ID), a longitude (WayPoint Longitude), a latitude (WayPoint Latitude), and an altitude (WayPoint Altitude) for each WayPoint, and a connectivity matrix (Connectivity). Waypoints characterize the reachability of the UAV in path planning. Each row vector in the Connectivity matrix represents the connectivity between a waypoint and other waypoints. The values ​​of each row vector in Connectivity are in the form of an array {0, 1, 0, 1, ..., 0}, where 1 indicates connectivity and 0 indicates disconnection. Connectivity is bidirectional. The array index corresponds to the WayPoint ID of the waypoint, and the array length is the total number of waypoints.

[0051] Construct obstacle constraints, including constructing a unique obstacle identifier (ObstacleID), obstacle name (Obstacle Name), obstacle longitude (Obstacle Longitude), obstacle latitude (Obstacle Latitude), obstacle minimum altitude (Obstacle minAltitude), and obstacle maximum altitude (Obstacle maxAltitude) for each obstacle. The units for Obstacle minAltitude and Obstacle maxAltitude are meters.

[0052] Constructing no-fly constraints includes establishing NoFly Areas (NoFly Areas) and SafeDistances (Safe Distances) to restrict airspace. Safe Distances define the safe distance and altitude restrictions between the drone and the external environment and other drones. Constructing NoFly Areas involves defining their shape, minimum altitude (NoFly Area minAlt), and maximum altitude (NoFly Area maxAlt). The shape attribute can be a rectangle, a circle, or a polygon. Constructing SafeDistances includes defining their unique identifier (Safe Distance ID), name (Safe Distance Name), minimum safe distance (Safe Distance minDis), minimum flight altitude (Safe Distance minAltitude), and maximum flight altitude (Safe Distance maxAltitude).

[0053] The weather constraints are constructed, including a unique weather identifier (Weather ID), weather name, weather description, weather type, duration, temperature range, covered area, and wind for each weather element. The weather type attribute is a string value, specifically one of the following: heat, snow, fog, thunder, rain, or windstorm. The temperature range is in the form "a~b". The covered area attribute is a rectangle, circle, or polygon. The wind attribute describes the wind force level and wind speed, with wind force levels ranging from 0 to 12 and wind speeds from 0 to 36.9 m / s.

[0054] Step 104: Determine the BNF paradigm for the task model, resource model, and constraint model, and construct the syntax rules.

[0055] In the specific implementation, after constructing the task model, resource model, and constraint model, it is necessary to define the syntax rules for each element and its attribute value using BNF normal form based on the definition of each element and its attribute value in the task model, resource model, and constraint model, and describe the dependency relationships between each element and the dependency relationships between each attribute value. At the same time, terminal and non-terminal symbols are set, and "::=" is used for connection, and the nesting relationship between parent elements and child elements is constructed.

[0056] For task models, when constructing grammar rules, it is necessary to construct the grammar rules for the scenario task, the grammar rules for the task, and the grammar rules for the subtask in sequence.

[0057] Syntax rules for constructing scene tasks:

[0058] use <mission>Fields represent the scenario and task. <mission>Fields can be divided into<Mission_attr> , <missionproperty>and <task>Describe,<Mission_attr> Further divided into<Mission_id> ,<Mission_name> and<Mission_describe> ,<Mission_id> The value of is defined as an identifier.<Mission_name> and<Mission_describe> The values ​​for each element are defined as strings. <missionproperty>Further divided into<Mission_state> ,<Mission_type> ,<Mission_time> ,<Mission_Coord> ,<Mission_Relationship> and<Mission_Requirements> The following are respectively<Mission_state> ,<Mission_type> ,<Mission_time> ,<Mission_Coord> ,<Mission_Relationship> and<Mission_Requirements> Define the syntax rules.

[0059] <Mission_state> Further divided into<Mission_state_value> ,<Mission_state_value> When combined with "MissionState", it represents the state label of the scene task.<Mission_state_value> The value of is defined as a string and is restricted to one of "Allocated", "Unallocated" or "PartiallyAllocated", specifically: MissionState = {Allocated, Unallocated, PartiallyAllocated}.

[0060] <Mission_type> Further divided into<Mission_type_value> It is closed using the angle bracket rules in XML.<Mission_type_value> The value is defined as a string and is restricted to one of "Logistics", "Agriculture", "Rescue" and "HighwayPatrol", specifically: MissionType = {Logistics, Agriculture, Rescue, HighwayPatrol}.

[0061] <Mission_time> Further divided into <starttime> 、 <endtime>and <estimatedtime> ， <starttime>and <endtime>The value is determined by the DateTime field. The DateTime field uses... <datetime>It means that by <date>The letter "T" and <time>Combined, in the format YYYY-MM-DDTHH:MM:SS. <estimatedtime>The value is determined by <time>The decision is in the format HH:MM:SS. EndTime <datetime>The value must be greater than or equal to StartTime. <datetime>The value is EstimatedTime. <datetime>The value is less than or equal to the range between EndTime and StartTime. <datetime>Difference. StartTime <datetime>The default value is the current time, and the value must be greater than or equal to the current time.

[0062] <Mission_Coord> Further divided into <enterpoint>and <leavepoint> 。 <enterpoint>Defined as an attribute by<Coord_attr> Self-closing XML tags.<Coord_attr> It is further defined as<Longitude_attr> ,<Latitude_attr> and<Altitude_attr> The values ​​for these three attributes follow the XML attribute format. The left side shows the attribute name, and the value is... <string>,like<Longitude_attr> The attribute name is "longitude". The right side shows the specific value, which takes the value of "longitude". <string>The paths are connected by "=". The path points are coordinate arrays (longitude, latitude, altitude), specifically represented as Coord = (Longitude, Latitude, Altitude).

[0063] <Mission_Relationship> Further divided into<Relationship_elem> ,<Relationship_elem> There can be one or more.<Relationship_elem> Values <sequence> 、 <cobegin> 、 <fork>and <join>One of them. <sequence>and <cobegin>Each contains one<Task_attr> The value selection rules follow the XML attribute format. The left side shows the attribute name, and the value is... <string>,like<Task_attr> The attribute name is "Tasks". The right side shows the specific values, which can be...<Task_val> The two characters are connected by "=".<Task_val> By one or more <identifier>Combinations are formed, separated by commas. <fork>It is an XML self-closing tag with the element name Fork, enclosed by the start tag "<Fork" and the end tag " / >", including the attributes PreTask and NextTask, and the value rules are identifier and <ForkNextTask_attr> respectively. <join>It is an XML self-closing tag named Join, enclosed by the start tag "<Join" and the end tag " / >", including the attributes PreTask and NextTask, and the value rules are <JoinPreTask_attr> and <identifier>.<ForkNextTask_attr> and<JoinPreTask_attr> A string consisting of two or more strings separated by commas.

[0064] <Mission_Requirements> Contains one or more <resourcetype>Child elements, each <resourcetype>Represents a resource type, whose value is determined by...<ResourceType_value> specified.<ResourceType_value> It can be any string, of type 1 <string>The value of MissionRequirements is equal to the sum of the resource types in the TaskRequirements of each Task; that is, MissionRequirements includes all child elements of TaskRequirements.

[0065] Syntax rules for building tasks:

[0066] use <task>Representation task, <task>Further divided into<Task_attr> , <taskproperty>and <subtask>,<Task_attr> Divided into<Task_id> ,<Task_name> and<Task_describe> , <taskproperty>Divided into<Task_state> Characterizing the type of the task<Task_type> ,<Task_time> ,<Task_Coord> ,<Task_Relationship> and<Task_Requirements> The following are respectively<Task_type> ,<Task_time> ,<Task_Coord> ,<Task_Relationship> and<Task_Requirements> Define the syntax rules.

[0067] <Task_state> Further divided into<Task_state_value> When combined with "TaskState", it represents the status label of a task.<Task_state_value> The value of is defined as <string>And it is limited to one of "Allocated", "Unallocated" or "PartiallyAllocated".<Task_state_value> The value of depends on the value of SubTaskState. When all SubTaskState values ​​are already allocated,<Task_state_value> The value "Allocated" is used when all SubTaskStates are unallocated.<Task_state_value> The option "Unallocated" is used when SubTaskState is partially allocated.<Task_state_value> Use "PartiallyAllocated".

[0068] <Task_type> Further divided into<Task_type_value> And it is closed using the angle bracket rules in XML.<Task_type_value> Value type is <string>The `TaskType` needs to be determined based on the value of its parent element, `MissionType`. For example, when `MissionType` is set to `Scene Task 1`, the range of task types is limited to `Task 1-1` to `Task 1-N`. `MissionType` can be viewed as the key of a dictionary (or mapping), and the corresponding set of `TaskType` values ​​as the values, forming key-value pairs. The corresponding `TaskType` value set is found using `MissionType`. The range of `TaskType` values ​​is determined based on the different values ​​of `MissionType`.

[0069] <Task_time> Further divided into <starttime> 、 <endtime>and <estimatedtime>The StartTime of TaskTime must be greater than or equal to the MissionTime in Mission, and the EndTime of TaskTime must be less than or equal to the MissionTime in Mission. The default value of the StartTime of TaskTime is the current time, and it cannot be earlier than the current time.

[0070] <Task_Coord> Indicates further division into <enterpoint>and <leavepoint>The definitions of the MissionCoord field are the same for the remaining rules.

[0071] <Task_Relationship> Further divided into<Relationship_elem> .<Relationship_elem> There can be one or more.<Relationship_elem> The value is <sequence> 、 <cobegin> 、 <fork>and <join>one of the. <sequence>and <cobegin>Each contains one<SubTask_attr> The value selection rules follow the XML attribute format. The left side shows the attribute name, and the value is... <string>,like<SubTask_attr> The attribute name is "SubTasks". The right side shows the specific values, which can be...<SubTask_val> The value is limited to the string "SubTask" and the integer INT, and can be combined by concatenation with commas and connected by "=".<SubTask_val> By one or more <subtaskidentifier>The combinations are separated by commas, and are in the form of "SubTask1", ​​"SubTask2", "SubTask3, SubTask4". <subfork>It is an XML self-closing tag with the element name Fork, enclosed by the start tag "<Fork" and the end tag " / >", including the attributes PreSubTask and NextSubTask, and the value rules are respectively <subtaskidentifier>and<ForkNextTask_attr> . <subjoin>It is an XML self-closing tag named Join, enclosed by the start tag "<Join" and the end tag " / >", including the attributes PreSubTask and NextSubTask, with the value rules being <ForkNextSubTask_attr> and <subtaskidentifier>.<ForkNextTask_attr> and<JoinPreTask_attr> Two or more <subtaskidentifier>Combinations are formed, separated by commas. <subtaskidentifier>Represents a unique identifier.

[0072] <Task_Requirements> Contains one or more <resourcetype>Child elements. Each <resourcetype>Represents a resource type, whose value is determined by...<ResourceType_value> specified.<ResourceType_value> It can be any string, of type 1 <string>The value of TaskRequirements is equal to the sum of the resource types in SubTaskRequirements of each SubTask, meaning TaskRequirements includes all child elements of SubTaskRequirements.

[0073] Syntax rules for constructing subtasks:

[0074] use <subtask>Characterization subtasks <subtask>Further divided into<SubTask_attr> and <subtaskproperty>,<SubTask_attr> Further divided into<SubTask_id> ,<SubTask_name> and<SubTask_describe> , <subtaskproperty>Further divided into<SubTask_state> ,<SubTask_type> ,<SubTask_time> ,<SubTask_Coord> , <subtasktarget>and<Task_Requirements> The following are respectively<SubTask_state> ,<SubTask_type> ,<SubTask_time> ,<SubTask_Coord> , <subtasktarget>and<Task_Requirements> Define the syntax rules.

[0075] <SubTask_state> Further divided into<Task_state_value> ,<Task_state_value> When combined with "SubTaskState", it represents the status label of a subtask.<Task_state_value> Values <string>And it is limited to one of "Allocated" and "Unallocated".

[0076] <SubTask_type> Definition rules are the same<Task_type> The type is determined by the parent element's TaskType.<Task_type_value> When it is "RoadTask",<SubTask_type_value> It can be "RoadBarrier", "RoadGuardarail", or "RoadSurface". When<Task_type_value> When it is "BridgeTask",<SubTask_type_value> Can be "BridgeDeck", "BridgeBearing", "BridgePier", "Bridge Joint", "BridgeAbutment".

[0077] <SubTask_time> Further divided into <starttime> 、 <endtime>and <estimatedtime>The rest of the rules are the same as<Task_time> same.

[0078] <SubTask_Coord> Further divided into <enterpoint>and <leavepoint>The rest of the rules are the same as<Task_Coord> same.

[0079] <subtasktarget>Further divided into tags "SubTaskTarget",<SubTaskTarget_attr> , <targetlocation> 、 <targetshape> 、 <targetevent>and <targetsize>, the tuple representation of SubTask is: SubTaskTarget={id, name, TargetLocation, TargetShape, (TargetSize), (TargetCoords)}, TargetSize={length, height, width}(shap e=cube), TargetSize={center, height, radius} (shape=cylinder), TargetSize=TargetCoords={TargetCood}, TargetCoord={TargetStart, TargetEnd}.

[0080] <Task_Requirements> Contains one or more <resourcetype>Child elements. Each <resourcetype>Represents a resource type, whose value is determined by...<ResourceType_value> specified.<ResourceType_value> The value can be any string, and the type is <string>.

[0081] For the resource model, use <resourc>Describe the resources and build them separately. <resourc>Below <stateinfo> 、 <domaininfo> 、 <functioninfo> 、 <serviceinfo>and <loginfo> 。

[0082] <stateinfo>Further divided into the tag "StateInfo" and child elements.<StateInfo_value> .<StateInfo_value> The value can be a string and can be one of "idle", "underloaded", "fullload", "maintenance", "overloaded", or "invalid".

[0083] <domaininfo>Further divided into the tag "DomainInfo" and one or more <domaininfovalue>multiple <domaininfovalue>Separate them with commas. <domaininfovalue>The value type is restricted to a string, and must be one of "Logistics", "Agriculture", "Rescue" or "HighwayPatrol".

[0084] <functioninfo>It is further divided into sub-elements MoveAbility, SenseAbility, CommunicationAbility, LoadAbility, CruisingAbility, and MissionPayload. Each sub-element can be selected once or multiple times.

[0085] <serviceinfo>Further divided into the tag "ServiceInfo" and attributes <serviceinfonumber> 、 <serviceinfotime>and child elements <servicetasklist> 。 <servicetasklist>Includes one or more <servicetask>Sub-elements.

[0086] <loginfo>Includes one or more <log>Child elements, defined by the tag " <loginfo> "and"< / loginfo> "Surrounded." <log>It contains the attributes "Time" and "Note". <loginfotime>It consists of the attribute "Time=" and a <loginfotime>Composition of elements, representing time.

[0087] For constrained models, use <constraint>Describe the constraints and construct them respectively. <constraint>Below <waypoints> 、 <obstacle> 、 <noflyarea> 、 <safedistance>and <weather> 。

[0088] <waypoints>Represents the set of path points. <waypoints>Further divided into "WayPoints" labels and <waypoint> ， <waypoint>This represents a waypoint that appears one or more times. <waypoint>Further divided into "WayPoint" tags and attributes<WayPoint_attr> and child elements <connectivity>.<WayPoint_attr> The path point attributes (id, longitude, latitude, and altitude) are defined, including<WayPoint_id> and<Coord_attr> Define "id" as having the value <identifier>,<Coord_attr> The rules are the same as the task definition. <connectivity>Indicating connectivity, it is further broken down into the "Connectivity" label and<Connectivity_values> The latter contains the values ​​of the connectivity array, which can have one or more.<Connectivity_value> Connected, separated by a comma.<Connectivity_value> The value type is restricted to the character 0 or 1.

[0089] <obstacle>Further divided into the label "Obstacle",<Obstacle_attr> , <minaltitude>and <maxaltitude>.<Obstacle_attr> include<Obstacle_id> ,<Obstacle_name> ,<Obstacle_longitude> and<Obstacle_latitude> The value of "id" is... <identifier>The three values ​​"name", "longitude", and "latitude" are... <string> 。 <minaltitude>and <maxaltitude>The value is restricted to strings, and the type is [type]. <string> 。

[0090] <noflyarea>This indicates further division into the tag "NoFlyArea" and its sub-elements. <rectangle> 、 <circle>and <polygon>There can be one or more rectangular areas. A rectangular area is represented by the `Rectangle` element, which includes the attributes `id`, `name`, `minAlt`, and `maxAlt`. `id` is a unique identifier for the area, `name` represents the area's name, `minAlt` represents the area's minimum altitude, and `maxAlt` represents the area's maximum altitude. `center` represents the area's center, including the attributes `longitude`, `latitude`, and `altitude`, representing longitude, latitude, and altitude respectively (rounded to four decimal places, approximately 1 meter precision). `NE` represents the northeast corner's longitude and latitude, `NW` represents the northwest corner's longitude and latitude, `SW` represents the southwest corner's longitude and latitude, and `SE` represents the southeast corner's longitude and latitude, all including the attributes `longitude` and `latitude`, representing the corresponding longitude and latitude respectively. A circular area is represented by the element... <circle>This indicates that the region includes the attributes id, name, minAlt, and maxAlt. id is a unique identifier for this region, name represents the name of the region, minAlt represents the minimum height of the region, and maxAlt represents the maximum height of the region. <circle>The child elements include <center>and <radius>, representing the coordinates of the center point and the corresponding radius, respectively. The polygonal region is defined using elements. <polygon>This indicates that the region includes the attributes id, name, minAlt, and maxAlt. id is a unique identifier for this region, name represents the name of the region, minAlt represents the minimum height of the region, and maxAlt represents the maximum height of the region. <polygon>The child elements of a coordinate system consist of three or more coordinates, denoted by Coord, to define a closed polygonal region.

[0091] <safedistance>Further divided into the tag "safeDistance" and attributes<safeDistance_attr> sub-elements <mindis> 、 <minaltitude>and <maxaltitude>.<safeDistance_attr> include<safeDistance_id> and<safeDistance_name> Define id and name respectively, with the value type being <identifier>and <string> 。 <mindis>The value inside the tag is <positivefloat> ， <minaltitude>and <maxaltitude>The values ​​within the tag are all <string> 。

[0092] <weather>This indicates further subdivision into the tag "Weather" and attributes.<Weather_attr> sub-elements <duration> 、 <temperature> 、 <coveredarea>as well as <wind>.<Weather_attr> include<Weather_id> ,<Weather_name> ,<Weather_describe> and<Weather_type> ,<Weather_id> and<Weather_name> The value types are respectively <identifier>and <string> 。 <duration>Values <datetime>The combination with "~". <temperature>This represents the weather temperature, and its value is a combination of two floating-point numbers and "~", with the unit being degrees Celsius. <coveredarea>Indicates the covered area, including three area types. <rectangle> , <circle>and <polygon> 。 <wind>Wind is indicated by wind force rating and wind speed, respectively. <windlevel>and <windspeed>express.

[0093] Step 105: Construct XML conforming to the BNF paradigm based on syntax rules, and generate a modeling language for application scenarios of drone swarms after combination.

[0094] In the specific implementation, the XML for constructing the task model includes three parts: scenario task, task, and subtask. <mission>The definition in contains one or more child elements. <task>And one <missionproperty>,make <missionproperty>Include <missionstate> 、 <missiontype> 、 <missiontime> 、 <missioncoord> 、 <missionrelationship>and <mssionrequirments>,make <task>The definition in contains one or more child elements. <subtask>And one <taskproperty>,make <taskproperty>Include <taskstate> 、 <tasktype> 、 <tasktime> 、 <taskcoord> 、 <taskrelationship>and <taskrequirements>,make <subtask>The definition in contains <subtaskproperty>,make <subtaskproperty>Include <subtaskstate> 、 <subtasktype> 、 <subtasktime> 、 <subtaskcoord> 、 <subtasktarget>and <subtaskrequirements>.

[0095] XML for building resource models enables <resourc>The definition in contains <basicinfo> 、 <stateinfo> 、 <domaininfo> 、 <functioninfo> 、 <serviceinfo>and <loginfo>make <functioninfo>Include <moveability> 、 <senseability> 、 <communicationability> 、 <loadability> 、 <cruisingability>and <missionpayload>,make <serviceinfo>Include <tasklist>.

[0096] The XML for constructing the constraint model enables <constraint>The definition in contains <waypoints> 、 <obstacle> 、 <noflyarea> 、 <safedistance>and <weather>,make <waypoints>Include <waypoint>,make <obstacle>Include <minaltitude>and <maxaltitude>,make <noflyare>Include <rectangle> 、 <circle>and <polygon>,make <safedistance>Include <mindis> 、 <minaltitude>and <maxaltitude>,make <weather>Include <duration> 、 <temperature>and <coveredarea>.

[0097] Finally, the XML of the task model, the XML of the resource model, and the XML of the constraint model are integrated into a single XML, which serves as the modeling language for application scenarios of UAV swarms.

[0098] This embodiment hierarchically subdivides task types, constructing a three-level task specification tree. This supports the needs of various scenarios, tasks, and subtasks within a drone swarm, achieving a universal modeling language applicable to different fields. Through BNF paradigm and XML, the syntax rules of the modeling language for drone swarm application scenarios are standardized, providing a reasonable and effective specification for language generation and a solid foundation for multi-drone collaborative task planning. By converting task models, resource models, and constraint models to scenario-oriented models, the reuse of various tasks, resources, and constraints is provided. Combined with modeling methods, this improves the efficiency of drone swarm construction. Using this drone swarm application scenario modeling language, drone swarm modeling can be completed simply and quickly, enabling rapid application development in dynamic scenarios.

[0099] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0100] Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.

[0101] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.< / coveredarea> < / temperature> < / duration> < / weather> < / maxaltitude> < / minaltitude> < / mindis> < / safedistance> < / polygon> < / circle> < / rectangle> < / noflyare> < / maxaltitude> < / minaltitude> < / obstacle> < / waypoint> < / waypoints> < / weather> < / safedistance> < / noflyarea> < / obstacle> < / waypoints> < / constraint> < / tasklist> < / serviceinfo> < / missionpayload> < / cruisingability> < / loadability> < / communicationability> < / senseability> < / moveability> < / functioninfo> < / loginfo> < / serviceinfo> < / functioninfo> < / domaininfo> < / stateinfo> < / basicinfo> < / resourc> < / subtaskrequirements> < / subtasktarget> < / subtaskcoord> < / subtasktime> < / subtasktype> < / subtaskstate> < / subtaskproperty> < / subtaskproperty> < / subtask> < / taskrequirements> < / taskrelationship> < / taskcoord> < / tasktime> < / tasktype> < / taskstate> < / taskproperty> < / taskproperty> < / subtask> < / task> < / mssionrequirments> < / missionrelationship> < / missioncoord> < / missiontime> < / missiontype> < / missionstate> < / missionproperty> < / missionproperty> < / task> < / mission> < / windspeed> < / windlevel> < / wind> < / polygon> < / circle> < / rectangle> < / coveredarea> < / temperature> < / datetime> < / duration> < / string> < / identifier> < / wind> < / coveredarea> < / temperature> < / duration> < / weather> < / string> < / maxaltitude> < / minaltitude> < / positivefloat> < / mindis> < / string> < / identifier> < / maxaltitude> < / minaltitude> < / mindis> < / safedistance> < / polygon> < / polygon> < / radius> < / center> < / circle> < / circle> < / polygon> < / circle> < / rectangle> < / noflyarea> < / string> < / maxaltitude> < / minaltitude> < / string> < / identifier> < / maxaltitude> < / minaltitude> < / obstacle> < / connectivity> < / identifier> < / connectivity> < / waypoint> < / waypoint> < / waypoint> < / waypoints> < / waypoints> < / weather> < / safedistance> < / noflyarea> < / obstacle> < / waypoints> < / constraint> < / constraint> < / loginfotime> < / loginfotime> < / log> < / log> < / loginfo> < / servicetask> < / servicetasklist> < / servicetasklist> < / serviceinfotime> < / serviceinfonumber> < / serviceinfo> < / functioninfo> < / domaininfovalue> < / domaininfovalue> < / domaininfovalue> < / domaininfo> < / stateinfo> < / loginfo> < / serviceinfo> < / functioninfo> < / domaininfo> < / stateinfo> < / resourc> < / resourc> < / string> < / resourcetype> < / resourcetype> < / targetsize> < / targetevent> < / targetshape> < / targetlocation> < / subtasktarget> < / leavepoint> < / enterpoint> < / estimatedtime> < / endtime> < / starttime> < / string> < / subtasktarget> < / subtasktarget> < / subtaskproperty> < / subtaskproperty> < / subtask> < / subtask> < / string> < / resourcetype> < / resourcetype> < / subtaskidentifier> < / subtaskidentifier> < / subtaskidentifier> < / subjoin> < / subtaskidentifier> < / subfork> < / subtaskidentifier> < / string> < / cobegin> < / sequence> < / join> < / fork> < / cobegin> < / sequence> < / leavepoint> < / enterpoint> < / estimatedtime> < / endtime> < / starttime> < / string> < / string> < / taskproperty> < / subtask> < / taskproperty> < / task> < / task> < / string> < / resourcetype> < / resourcetype> < / identifier> < / join> < / fork> < / identifier> < / string> < / cobegin> < / sequence> < / join> < / fork> < / cobegin> < / sequence> < / string> < / string> < / enterpoint> < / leavepoint> < / enterpoint> < / datetime> < / datetime> < / datetime> < / datetime> < / datetime> < / time> < / estimatedtime> < / time> < / date> < / datetime> < / endtime> < / starttime> < / estimatedtime> < / endtime> < / starttime> < / missionproperty> < / task> < / missionproperty> < / mission> < / mission> < / weather> < / safedistance> < / noflyarea> < / obstacle> < / waypoints> < / constraint> < / loginfo> < / serviceinfo> < / functioninfo> < / domaininfo> < / stateinfo> < / basicinfo> < / resourc> < / subtaskproperty> < / subtask> < / taskproperty> < / subtask> < / task> < / missionproperty> < / task> < / mission> < / windspeed> < / windlevel> < / wind> < / wind> < / coveredarea> < / temperature> < / duration> < / weather> < / weather> < / maxaltitude> < / minaltitude> < / mindis> < / safedistance> < / safedistance> < / radius> < / center> < / circle> < / polygon> < / circle> < / rectangle> < / noflyarea> < / noflyarea> < / maxaltitude> < / minaltitude> < / obstacle> < / obstacle> < / waypoint> < / waypoint> < / waypoints> < / waypoints> < / constraint> < / lognote> < / logtime> < / log> < / log> < / log> < / loginfo> < / loginfo> < / servicetask> < / servicetasklist> < / servicetasklist> < / serviceinfotime> < / serviceinfonumber> < / serviceinfo> < / serviceinfo> < / functioninfo> < / functioninfo> < / domaininfo> < / domaininfo> < / stateinfo> < / stateinfo> < / resourc> < / subtasktarget> < / subtaskproperty> < / subtaskproperty> < / subtask> < / subtask> < / taskproperty> < / subtask> < / taskproperty> < / task> < / task> < / missionproperty> < / task> < / missionproperty> < / mission> < / mission>

Claims

1. A method for generating modeling language for application scenarios of unmanned aerial vehicle (UAV) swarms, characterized in that, include: Construct a task model to determine the three-level hierarchical relationship between the scene task, task and sub-task of the UAV swarm, the collaborative relationship of each task, and the collaborative relationship of each sub-task under the same task; Construct a resource model, analyze the resources required by the task model, classify the resources required by the task model into tuples, and provide a unified resource description; A constraint model is constructed to analyze the constraints of each UAV regarding resources, motion, environment, and time. Based on the constraints corresponding to each UAV, the constraints of the UAV swarm are determined. Determine the BNF paradigm of the task model, the resource model, and the constraint model, and construct the syntax rules; Based on the grammar rules, a declarative markup language XML conforming to the BNF paradigm is constructed, which is then combined to generate a modeling language for application scenarios of drone swarms.

2. The method for generating a modeling language for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 1, characterized in that, The construction of the task model, which determines the three-level hierarchical relationship between the scene task, task, and sub-task of the UAV swarm, the collaborative relationship between each task, and the collaborative relationship between each sub-task under the same task, includes: Construct a scenario task, specifying the scenario task's basic information, scenario task attributes, and task set. The scenario task's basic information includes the scenario task's identifier, scenario task's name, and scenario task's description. The scenario task attributes are a six-tuple, including the scenario task's state, scenario task's type, scenario task's time, scenario task's coordinates, the task collaboration relationship corresponding to the task set, and the scenario task's resource requirements. The task collaboration relationship includes sequential execution, parallel execution, branch execution, and convergence execution. Construct a task by specifying basic task information, task attributes, and a set of subtasks. The basic task information includes the task identifier, task name, and task description. The task attributes are a six-tuple that includes the task status, task type, task time, task coordinates, the task collaboration relationship corresponding to the set of subtasks, and the task's resource requirements. Construct a subtask, specifying its basic information and attributes. The basic information includes the subtask's identifier, name, and description. The subtask attributes are a six-tuple, including the subtask's status, type, time, coordinates, objective, and resource requirements. In this context, the scenario task is the parent element of each of the tasks, and a task is the parent element of at least one child task.

3. The modeling language generation method for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 2, characterized in that, The process of constructing a resource model involves analyzing the resources required by the task model, classifying the resources required by the task model into tuples, and providing a unified resource description, including: Construct scene resources, which are formally described as a six-tuple, including basic information of the resource, state information of the resource, domain information of the resource, capability information of the resource, service information of the resource, and log information of the resource; Construct the basic information of the resource, including resource ID, resource name, resource type and resource description, wherein the attribute value of the resource type indicates whether the UAV is a fixed-wing UAV or a multi-rotor UAV; Construct the status information of the resource, wherein the attribute value of the status information of the resource is one of idle, not fully loaded, fully loaded, under maintenance, overloaded or invalid; Construct the domain information of the resource, wherein the attribute value of the domain information of the resource is one of logistics, agriculture, rescue, search or inspection; The capability information for constructing the resource includes mobility, sensing, communication, load capacity, battery life, and task payload capacity. Construct the service information of the resource, including the number of resources available, the service time of the resource, and the set of tasks that the resource can complete; Construct log information for the resource, including the resource's historical time and resource notes corresponding to the historical time.

4. The modeling language generation method for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 3, characterized in that, The construction of the constraint model analyzes the constraints of each UAV regarding resources, motion, environment, and time, and determines the constraints of the UAV swarm based on the constraints corresponding to each UAV, including: Constructing path point constraints includes constructing a set of path points, constructing a unique path point identifier, path point longitude, path point latitude, and path point altitude for each path point, and constructing a path point connectivity matrix. The path points are used to characterize the path reachability of the UAV in path planning, and each row vector of the path point connectivity matrix is ​​used to characterize the connectivity between a path point and other path points. Constructing obstacle constraints includes constructing a unique obstacle identifier, obstacle name, obstacle longitude, obstacle latitude, obstacle minimum height, and obstacle maximum height for each obstacle. The obstacles are objects that the drone cannot pass through in the horizontal direction but can avoid by increasing its altitude. Constructing no-fly constraints includes constructing no-fly zones and safety restrictions. The safety restrictions are used to define the safe distance and altitude limits between the drone and the external environment and other drones. Constructing no-fly zones includes constructing the shape of each no-fly zone, the minimum altitude of the no-fly zone, and the maximum altitude of the no-fly zone. The attribute value of the shape of the no-fly zone is one of rectangle, circle, or polygon. Constructing safety restrictions includes constructing the unique identifier of each safety restriction, the name of the safety restriction, the minimum safe distance, the minimum flight altitude, and the maximum flight altitude. The weather constraints are constructed, including the construction of a unique weather identifier, weather name, weather description, weather type, duration, temperature range, coverage area, and wind for each weather event. The weather type attribute value is one of high temperature, low temperature, fog, thunderstorm, rain, or strong wind. The coverage area attribute value is one of rectangle, circle, or polygon. The wind is used to describe the wind force level and wind speed.

5. The modeling language generation method for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 4, characterized in that, The process of determining the BNF paradigm of the task model, the resource model, and the constraint model, and constructing grammar rules, includes: Based on the definition of each element and its attribute value in the task model, resource model, and constraint model, the BNF normal form is used to define syntax rules for each element and its attribute value, describe the dependencies between the elements and the dependencies between the attribute values, set terminal and non-terminal symbols, and construct the nesting relationship between parent and child elements.

6. The modeling language generation method for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 5, characterized in that, For the task model, the construction syntax rules include: use <mission>The field represents the scenario task, the <mission>Divided into categories representing the basic information of the scene task<Mission_attr> Characterizing the attributes of the scene task <missionproperty>and characterizing the set of tasks <task>The<Mission_attr> Divided into identifiers representing the tasks in the aforementioned scenario<Mission_id> The name representing the scenario task<Mission_name> and a description representing the task in the scenario<Mission_describe> The <missionproperty> Divided into states representing the tasks in the scenario<Mission_state> Characterizing the type of the scenario task<Mission_type> , representing the time of the scenario task<Mission_time> The coordinates representing the scene task<Mission_Coord> Characterizing the task collaboration relationships corresponding to the task set<Mission_Relationship> and the resource requirements that characterize the scenario task<Mission_Requirements> ;< / missionproperty> < / task> < / missionproperty> < / mission> < / mission> Using the above <task>Characterizing the task, the <task>Divided into categories representing the basic information of the task<Task_attr> Characterizing the attributes of the task <taskproperty>and characterizing the set of subtasks <subtask>The<Task_attr> Divided into identifiers representing the task<Task_id> The name representing the task<Task_name> and a description characterizing the task<Task_describe> The <taskproperty> Divided into states that characterize the task<Task_state> Characterizing the type of the task<Task_type> Characterizing the time of the task<Task_time> The coordinates representing the task<Task_Coord> Characterizing the task collaboration relationships corresponding to the sub-task set<Task_Relationship> and characterize the resource requirements of the task<Task_Requirements> ;< / taskproperty> < / subtask> < / taskproperty> < / task> < / task> Using the above <subtask>Characterizing the subtask, the <subtask>Divided into subtasks representing basic information<SubTask_attr> and characterizing the attributes of the subtask <subtaskproperty>The<SubTask_attr> Divided into identifiers representing the subtasks<SubTask_id> The name representing the subtask<SubTask_name> and the description that characterizes the subtask<SubTask_describe> The <subtaskproperty>Divided into states representing the subtasks<SubTask_state> Characterizing the type of the subtask<SubTask_type> , representing the time of the subtask<SubTask_time> The coordinates representing the subtask<SubTask_Coord> Characterizing the goal of the sub-task <subtasktarget> and characterizing the resource requirements of the subtask<Task_Requirements> .< / subtasktarget> < / subtaskproperty> < / subtaskproperty> < / subtask> < / subtask> 7. The method for generating a modeling language for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 6, characterized in that, For the resource model, the construction syntax rules include: use <resourc>Describe resources, build <stateinfo>Describe the status information of the resource, the <stateinfo> It is divided into the tag "StateInfo" and child elements.<StateInfo_value> The<StateInfo_value> The value of is limited to a string and can be one of the following: idle, underloaded, fullload, maintenance, overloaded, or invalid. The idle value indicates that the device is idle, the underloaded value indicates that the device is not at full load, the fullload value indicates that the device is at full load, the maintenance value indicates that the device is under maintenance, the overloaded value indicates that the device is overloaded, and the invalid value indicates that the device is invalid.< / stateinfo> < / stateinfo> < / resourc> Build <domaininfo>Describe the domain information of the resource, the <domaininfo> Divided into the label "DomainInfo" and several<DomainInfo_Value> Each of the above<DomainInfo_Value> Separate them with commas.<DomainInfo_Value> The value of is limited to a string and can be one of Logistics, Agriculture, Rescue, Search, or HighwayPatrol, where Logistics represents logistics, Agriculture represents agriculture, Rescue represents rescue, Search represents search, and HighwayPatrol represents inspection.< / domaininfo> < / domaininfo> Build <functioninfo>The description of the capability information of the resource, the <functioninfo>It is divided into sub-elements representing the mobility capability, the perception capability, the communication capability, the load capability, the cruising capability, and the mission payload.< / functioninfo> < / functioninfo> Build <serviceinfo>Describe the service information of the resource, the <serviceinfo>The attributes are categorized under the label "ServiceInfo" and represent the quantity of resources available. <serviceinfonumber>Attributes representing the serviceability time of the resource <serviceinfotime>and the sub-elements of the task list <servicetasklist>The <servicetasklist>Includes one or more characterizing the task <servicetask> child elements;< / servicetask> < / servicetasklist> < / servicetasklist> < / serviceinfotime> < / serviceinfonumber> < / serviceinfo> < / serviceinfo> Build <loginfo>The log information describing the resource, the <loginfo>Includes several characterization logs <log>Sub-element, the <log>Depend on <loginfo> and< / loginfo> Surrounding, the <log>Includes characterizing the historical time of the resource <logtime> and the resource notes that characterize the historical events of the resources.<Log Note> .< / logtime> < / log> < / log> < / log> < / loginfo> < / loginfo> 8. The method for generating a modeling language for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 7, characterized in that, For the constraint model, the construction syntax rules include: use <constraint>Describe constraints, using <waypoints>Represents the set of path points, the <waypoints>Divided into "WayPoints" labels and representations of the path points. <waypoint>The <waypoint> Divided into "WayPoint" labels and<WayPoint_attr> The<WayPoint_attr> The unique identifier of the waypoint, the longitude of the waypoint, the latitude of the waypoint, and the altitude of the waypoint are defined, and used...<Coord_attr> The path point connectivity matrix represents the path points connected by the path.<Coord_attr> Divided into "Connectivity" tag and<Connectivity_values> The<Connectivity_values> Composed of several<Connectivity_value> Connected, the<Connectivity_value> The value can only be either the character 0 or the character 1;< / waypoint> < / waypoint> < / waypoints> < / waypoints> < / constraint> use <obstacle>The obstacle is referred to as the obstacle. <obstacle>Divided into the tag "Obstacle",<Obstacle_attr> Characterizing the minimum height of the obstacle <minaltitude>and characterizing the highest height of the obstacle <maxaltitude> The<Obstacle_attr> Classified into unique identifiers representing the obstacles<Obstacle_id> , characterizing the name of the obstacle<Obstacle_name> Characterizing the longitude of the obstacle<Obstacle_longitude> and characterizing the latitude of the obstacle<Obstacle_latitude> ;< / maxaltitude> < / minaltitude> < / obstacle> < / obstacle> use <noflyarea>Characterizing the no-fly zone, the <noflyarea>The area is designated as a "NoFlyArea," signifying a massive no-fly zone. <rectangle>Characterizing a circular no-fly zone <circle>and characterizing polygonal no-fly zones <polygon>The <circle>Includes sub-elements representing the coordinates of the center point. <center>and sub-elements representing the radius of the no-fly zone <radius> ；< / radius> < / center> < / circle> < / polygon> < / circle> < / rectangle> < / noflyarea> < / noflyarea> use <safedistance>This indicates the security restriction, the <safedistance>Divided into the tag "safeDistance" and attributes<safeDistance_attr> Sub-elements representing the minimum safe distance <mindis>Sub-element representing the minimum flight altitude <minaltitude>and sub-elements representing the highest flight altitude <maxaltitude> The<safeDistance_attr> Including the security restriction unique identifier<safeDistance_id> and characterizing the name of the security restriction<safeDistance_name> ;< / maxaltitude> < / minaltitude> < / mindis> < / safedistance> < / safedistance> use <weather>The weather is described. <weather>Divided into the tag "Weather" and attributes<Weather_attr> Sub-elements representing the duration <duration>Characterizing the temperature range <temperature>Characterizing the coverage area <coveredarea>And characterizing the wind <wind>The<Weather_attr> Including the unique identifier representing the weather<Weather_id> The weather name is represented by<Weather_name> Characterizing the weather description<Weather_describe> and characterizing the weather type<Weather_type> The <wind>Including those characterizing the wind force level <windlevel>and characterizing the wind speed <windspeed> 。< / windspeed> < / windlevel> < / wind> < / wind> < / coveredarea> < / temperature> < / duration> < / weather> < / weather> 9. The method for generating a modeling language for application scenarios of unmanned aerial vehicle (UAV) swarms according to claim 8, characterized in that, The construction of a declarative markup language XML conforming to the BNF paradigm based on the syntax rules includes: The XML for constructing the task model includes three parts: the scenario task, the task, and the subtasks, making the... <mission>The definition in the text contains several of the above. <task>And one of the aforementioned <missionproperty>, so that the <task>The definition in the text contains several of the above. <subtask>And one of the aforementioned <taskproperty>, so that the <subtask>The definition in contains the above. <subtaskproperty> ；< / subtaskproperty> < / subtask> < / taskproperty> < / subtask> < / task> < / missionproperty> < / task> < / mission> Construct the XML of the resource model, so that the <resourc>The definition in contains <basicinfo>The above <stateinfo>The above <domaininfo>The above <functioninfo>The above <serviceinfo>and the said <loginfo> ；< / loginfo> < / serviceinfo> < / functioninfo> < / domaininfo> < / stateinfo> < / basicinfo> < / resourc> Construct the XML of the constraint model, so that the <constraint>The definition in contains the above. <waypoints>The above <obstacle>The above <noflyarea>The above <safedistance>Japanese <weather> ；< / weather> < / safedistance> < / noflyarea> < / obstacle> < / waypoints> < / constraint> The XML of the task model, the XML of the resource model, and the XML of the constraint model are integrated into a single XML, which serves as a modeling language for application scenarios involving UAV swarms.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements a modeling language generation method for application scenarios of unmanned aerial vehicle swarms as described in any one of claims 1 to 9.

Images