Attribute-driven unmanned aerial vehicle management and control system architecture design method

Abstract

The invention discloses an unmanned aerial vehicle management and control system architecture design method based on attribute driving, and relates to the technical field of unmanned aerial vehicle system architecture design, and the technical scheme is characterized in that the method comprises the steps: extracting the attribute features of an unmanned aerial vehicle for packaging, and constructing a virtual unmanned aerial vehicle object; constructing an attribute change detection mechanism by adopting an observer mode, and pushing the state information of the unmanned aerial vehicle to an external system for broadcasting; constructing an attribute updating mechanism according to the change event of the attribute, and converting the attribute change into a control instruction for the unmanned aerial vehicle; and according to attribute updating requirements of different frequencies, actively obtaining real unmanned aerial vehicle data, and sending an unmanned aerial vehicle control interface by using a control instruction to complete attribute updating. By abstracting and packaging the attributes of the unmanned aerial vehicle, a twin system of a real unmanned aerial vehicle and a virtual unmanned aerial vehicle is constructed, the attributes of the virtual unmanned aerial vehicle are updated in real time, the unmanned aerial vehicle is driven by attribute changes to execute actions, and then the functions of flight control, load control, state monitoring, danger early warning and the like of the unmanned aerial vehicle in the physical world are achieved.

Description

Technical Field

[0001] The invention patent relates to the technical field of drone system architecture design, and specifically, to a property-driven drone control system architecture design method. Background Art

[0002] As a flying vehicle with the highest degree of freedom of movement within a certain space, drones are widely used in various fields, including information collection in various environments such as ground, air, and even underground, small or medium-sized material transportation, and even as a supplement to ground armed forces to strike dangerous targets, as well as communication relay, lighting, etc. With the expansion of application scenarios, higher and higher requirements are placed on the route planning ability, flight control ability, and payload carrying capacity of drones in different scenarios. As a link between drones and operators, drone control terminals are responsible for transmitting drone telemetry signals to operators through visual displays on the ground terminal screen, and also converting operators' control commands into drone control commands through background programs.

[0003] Currently, the communication between common drone control software and drones is generally divided into upward and downward information transmission. The downward method is to package the telemetry data and send it directly to the front-end interface, and the upward method is to use interface calls to realize the conversion of user control commands and the sending of commands. This architecture is currently commonly used by commercial software and large-scale transaction processing systems. This interface-oriented programming idea allows developers to meet changes and additions in user needs by directly changing the interface processing logic or adding new interfaces when dealing with large and complex logic processing and logic changes, and can achieve the needs at the lowest cost.

[0004] However, the current design style of drone control system architecture cannot comprehensively consider the current status of the drone to ensure the safety of the drone, and cannot guarantee the correct execution and response of instructions through the current status of the drone. The following problems still exist in actual use:

[0005] First: Low security. The command-level interface has a low-coupling design feature and is committed to the pursuit of successful command transmission, but it cannot take into account the safety design of drones. Although drones have certain safety emergency strategies and can trigger emergency landing or return commands under certain conditions, in actual flight, drones, as an aerial vehicle, have very high logical requirements for the control of various types of power, drone attitude, and the current state of action execution. It is not a single execution of a certain event. For example, when avoiding obstacles or turning, drones need to reduce speed to ensure safety. However, if there is a drone acceleration command at this time, if the drone executes the acceleration command at this time, it will cause it to hit obstacles and cause a crash.

[0006] Second: the command drive is not reliable and cannot effectively guarantee the success rate of command execution; the command trigger of the user interface is often one-time. In order to avoid the drone repeatedly executing a certain command and causing flight abnormalities, the front end generally adopts throttling to avoid sending multiple repeated events. Take the hovering command as an example. In actual flight, when the drone triggers emergency obstacle avoidance, it cannot execute the hovering command in the current state. At this time, the user's operation cannot be responded to. However, when the drone completes autonomous obstacle avoidance, it should execute hovering according to the user's requirements. At this time, the user needs to resend the command;

[0007] Third: The interface-oriented architecture design style is inefficient. Telemetry data is acquired by calling interfaces. The data such as the position, attitude and flight status of the drone are generally small and can be acquired by frequently calling interfaces. However, the route data, electronic fence data, payload images, etc. on the drone are often large. High-frequency interface calls can easily lead to excessive continuous link bandwidth occupancy. At this time, the drone generally needs to play real-time video images through the link. Such data acquisition interfaces are generally required to have the ability to respond quickly after the user clicks to acquire the data, but cannot be automatically requested at a high frequency.

[0008] Fourth: It is impossible to monitor the status of drones and report faults. As a requirement for drone mandatory certification, drone status broadcasting is a capability that every drone system must possess. It is also the basic capability of the drone system as a subsystem to provide external feedback on its own status. The current interface-oriented system architecture style often places telemetry broadcasts in the interface response for obtaining telemetry information. The acquisition of telemetry data is often high-frequency. Packaging the drone's own status according to the other party's requirements and placing the external broadcast event in the telemetry acquisition interface not only increases the complexity of the telemetry data acquisition interface and increases the code maintenance cost, but also because of the high coupling of the two events, it is easy to cause system abnormality risks. The failure of drone telemetry monitoring due to external broadcasts can cause drone flight accidents, which is not worth the loss;

[0009] In summary, the existing drone control system architecture design style cannot meet the needs of existing drone control systems in terms of safety, reliability, high performance and low risk.

[0010] Therefore, the present invention aims to provide a property-driven UAV management and control system architecture design method to solve the above problems. Summary of the invention

[0011] The purpose of the present invention is to provide a method for designing a drone management and control system architecture based on attribute-driven. The present invention constructs a twin system of real and virtual drones by abstracting and encapsulating drone attributes, which is used to update virtual drone attributes in real time, drive drone actions by attribute changes, and thus realize flight control, load control, status monitoring, and danger warning functions of drones in the physical world.

[0012] The present invention is implemented as follows: a method for designing a drone control system architecture based on attribute drive, comprising the following steps:

[0013] S1, extract the drone attribute features, encapsulate them, and build a virtual drone object;

[0014] S2. Use the observer mode to observe the changes in the attribute status of the drone, build an attribute change detection mechanism, and implement the information push interface of the external system based on the attribute change detection mechanism to push the drone status information to the external system for broadcasting;

[0015] S3, adding an attribute update method to the virtual drone object according to the attribute change event, building an attribute update mechanism, and converting the attribute change into a control instruction for the drone according to the attribute update mechanism;

[0016] S4. According to the property update requirements of different frequencies, real drone data is obtained by active acquisition, and the real drone data is used to determine whether the conditions for immediate property update are met. If the update conditions are met, the control command is sent to the drone control interface to complete the property update. Otherwise, the control command is transferred to the waiting command sending stage, and the real drone data is continued to be obtained for judgment until the update conditions are met.

[0017] Furthermore, the drone attribute features in step S1 include ground station attributes corresponding to drone control, the drone model, name, position, attitude, controller parameters, emergency parameters, maximum load, maximum flight speed, minimum flight speed, maximum climb angle, load type and load attributes. The drone attribute features are extracted and encapsulated to ensure that the real-world drone attributes are mapped to the virtual drone object, realizing attribute association analysis and attribute-driven design.

[0018] Furthermore, the construction of the virtual drone object in step S1 is to encapsulate and construct the virtual drone object using a singleton mode, and to create a corresponding virtual drone object through the unique ID of the drone to ensure the uniqueness of the global object.

[0019] Furthermore, the observer mode is used in step S2 to observe the changes in the attribute status of the drone. It adopts an object-oriented design, monitors the changes in the drone status and actively pushes the latest status and change amount to the subscribed message object, so as to realize the creation of multiple observer instances and monitor the changes.

[0020] Furthermore, the monitoring of drone status changes is achieved by adding an observer list to the drone virtual object, which is used to implement an information push interface of an external system based on the observer type added to the observer list when the drone attributes change, and complete the sending of drone information to terminal observers.

[0021] Furthermore, the observer list is used to complete the operations of adding new observers and deleting observers according to system requirements by exposing the add observer method and the delete observer method.

[0022] Furthermore, the attribute update mechanism constructed in step S3 includes an attribute update mechanism based on telemetry data and an attribute update mechanism based on the user side. The attribute update mechanism based on telemetry data is to construct multiple timers, regularly call the telemetry data acquisition interface to obtain telemetry data, and then use the telemetry data to convert it into the attribute update of the virtual drone object, thereby realizing the synchronous update of the real-world drone attributes and the virtual drone object. The attribute update mechanism based on the user side is to update the change control of the drone attributes according to user needs.

[0023] Furthermore, the attribute update method of the attribute update mechanism based on telemetry data is: by parsing the airborne telemetry data packet and completing the attribute update operation according to the virtual drone object attribute format.

[0024] Furthermore, the attribute update method based on the user-side attribute update mechanism is: according to the HTTP interface form and the attribute verification mechanism, different interface operation interfaces are exposed corresponding to the virtual drone attribute information, which are triggered by the user and mapped to different attribute update events.

[0025] Furthermore, the attribute update verification method of the attribute verification mechanism is: by obtaining the drone singleton object in real time, the real state of the current drone is obtained, and then the attribute update verification is completed using the real state of the drone.

[0026] Furthermore, the attribute update verification includes an update verification of the basic attributes of the drone and an update verification of the flight mission management attributes of the drone.

[0027] Furthermore, the construction of multiple timers includes constructing a basic telemetry data acquisition timer every 200 ms and constructing a route and electronic fence attribute information acquisition timer every 5 s.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] 1. After the front-end user modifies the drone attributes through buttons or form submission, the present invention does not directly trigger the drone command to be issued, but first calls the attribute update event of the virtual drone object. In the event, the current state information of the drone, that is, the current attribute to be modified and other attributes of the drone are retrieved, and based on the security judgment logic, it is verified whether the current attribute update will cause a drone security incident, thereby ensuring the security of the instruction sending;

[0030] 2. The present invention makes the property update effective after the property update event is judged to be safe. However, the sending of the drone command cannot guarantee that the drone can respond immediately. The system compares the current properties with the telemetry data to determine whether the command responds successfully. If not, the command event will be resent at the next telemetry data update, thereby ensuring the reliability of the user's command;

[0031] 3. The present invention adopts an asynchronous low-frequency update mechanism and uses low-frequency interface requests to obtain the route data, electronic fences, load images and other data on the aircraft, and then updates them to the current route and electronic fence attributes of the virtual drone. When the front-end user requests to obtain the data, the back-end directly returns the corresponding attributes of the virtual drone object, which can solve the route data, electronic fences and load images on the drone. The relatively simple telemetry data is large, so high-frequency interface calls are likely to cause the link bandwidth to be continuously occupied too high, and the drone generally needs to play real-time video images through the link. This type of data acquisition interface has a low update frequency and is generally triggered by the current user or other end users. The user has high real-time requirements for acquisition. The drone control system architecture design method of the present invention can meet the needs of users and solve the problem of low data acquisition efficiency, so that it not only ensures the real-time update of data and reduces the real-time bandwidth pressure, but also meets the real-time response requirements of front-end users to obtain such data;

[0032] 4. The present invention adopts the observer mode to decouple the monitoring of changes in drone attributes. The telemetry interface only updates the virtual drone attributes and does not directly trigger external status broadcasts in the interface. Virtual drone attributes will add observers. When the observer mode recognizes that the attribute is updated, it will compare its own attributes. When it recognizes that the drone's own status is asynchronously triggered to be broadcast externally, it can reduce the complexity of the telemetry data acquisition interface and reduce the code maintenance cost. At the same time, it can avoid the high coupling of the two events, which may easily lead to system abnormal risks, thereby solving the current problem of drone telemetry monitoring failures due to external broadcasts, resulting in drone flight accidents. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 It is a flow chart of a method for designing a drone management and control system architecture based on attribute drive provided in Example 1 of the present invention;

[0034] Figure 2 It is a schematic diagram of the working principle of the observer mode in the attribute-driven drone control system architecture design method provided in Example 1 of the present invention;

[0035] Figure 3 It is a flow chart of updating the hovering attributes of a drone and event-driven operation provided in Embodiment 2 of the present invention. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0037] The implementation of the present invention is described in detail below in conjunction with specific embodiments.

[0038] The same or similar numbers in the drawings of this embodiment correspond to the same or similar parts; in the description of the present invention, it should be understood that if the terms "upper", "lower", "left", "right" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the drawings, it is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific direction, be constructed and operated in a specific direction. Therefore, the terms describing the positional relationship in the drawings are only used for illustrative purposes and cannot be understood as limitations on this patent. For ordinary technicians in this field, the specific meanings of the above terms can be understood according to specific circumstances.

[0039] Reference Figure 1-3 The figure shows a preferred embodiment of the present invention.

[0040] Embodiment 1: A method for designing a drone control system architecture based on attribute drive, comprising the following steps:

[0041] S1. Construct an abstract drone object based on the drone attribute characteristics, including the ground station attributes related to drone control, the drone model, name, location, posture, controller parameters, emergency parameters, maximum load, maximum flight speed, minimum flight speed, maximum climb angle, load type and load attributes, etc., to form a virtual drone object with the same attributes as the real drone in the real world.

[0042] The extracted drone attribute features in this embodiment include basic attributes, flight control attributes, and payload attributes of the drone. The data type definition in the drone control system architecture design is shown in Table 1:

[0043] Table 1 Data type definition table of basic attributes, flight control attributes and payload attributes of drones

[0044]

[0045]

[0046] The drone attribute status mentioned in Table 1 covers the ground station attributes related to drone control, the drone model, name, position, attitude, controller parameters, emergency parameters, maximum load, maximum flight speed, minimum flight speed, maximum climbing angle, load type and load attributes; it meets the external attributes required for drone status monitoring, drone mounted load monitoring and external data requirements, so as to ensure that the real-world drone attributes can be mapped to the virtual drone object, and to realize attribute association analysis and attribute-driven design.

[0047] The construction of the virtual drone object adopts the singleton mode to encapsulate and construct the virtual drone object. The corresponding virtual drone object is created through the unique ID of the drone. The singleton maintenance is used to ensure the uniqueness of the global object. At the same time, it has rich attributes, covering drone hardware configuration, mission execution attributes, drone flight telemetry status, etc., and has a built-in object update function, which can realize its own status update according to the external interface.

[0048] S2. Use the observer pattern to observe the changes in the attribute status of the drone. According to the object-oriented design, monitor the changes in the drone status and actively push the latest status and change amount to the subscribed message object, realize the creation of multiple observer instances and monitor the changes, and build an attribute change detection mechanism. The Proxy object is introduced in this mechanism. By defining the behavior of attribute search, assignment, enumeration, function call, etc., the detection of attribute changes is completed, thereby realizing the information push interface of the external system, which is used to push the drone status information to the external system for broadcasting.

[0049] By adding an observer list to the drone virtual object, the methods of adding observers and deleting observers are exposed to complete the operations of adding observers and deleting observers according to system requirements, such as Figure 2 As shown, a new observer method is added to notify all observers (notifyAllObservers), which is used to implement the information push interface of the external system according to the observer type added to the observer list when the drone attributes change, and complete the sending of drone information to the terminal observer.

[0050] S3. Add an attribute update method to the virtual drone object based on the attribute change event, and construct an attribute update mechanism based on telemetry data and an attribute update mechanism based on the user side. The attribute update mechanism based on telemetry data is to construct multiple timers, regularly call the telemetry data acquisition interface to obtain telemetry data, and then use the telemetry data to convert it into the attribute update of the virtual drone object, thereby realizing the synchronous update of the real-world drone attributes and the virtual drone object. The attribute update mechanism based on the user side is to update the change control of the drone attributes according to user needs, and finally convert the attribute changes into control instructions for the drone according to the attribute update mechanism.

[0051] On the basis of the observer mode, a new attribute update method of the drone based on the attribute update mechanism of telemetry data is added. This method parses the airborne telemetry data packet and keeps the attributes updated according to the virtual drone object attribute format. Among them, the attribute update mechanism based on the user side belongs to the user interface operation requirement, which is mainly provided in the form of HTTP interface. Different interface operation interfaces are exposed according to the virtual drone attribute information, which are triggered by the user and mapped to different attribute update events. The exposed user operation interface corresponds to the drone attribute event one by one and includes an attribute update verification mechanism to ensure the correctness of the attribute update.

[0052] The user's update of the drone's attributes expresses the user's expectation of the drone's state change. Therefore, the drone's attribute change needs to be converted into a drone control instruction. By adding a new attribute change interface function, after verifying the drone's attribute change, it is converted into a drone control interface for sending. In this embodiment, the drone's attribute change cannot be updated directly, including the update verification of the drone's basic attributes and the update verification of the drone's flight mission management attributes. It is necessary to follow the attribute update verification rules, obtain the drone's singleton object in real time, and thus obtain the current drone's real state, and then use the drone's real state to complete the attribute update verification, so as to ensure that after the attribute is updated and converted into a drone control instruction and sent, the drone is safe. The attribute update verification rules are shown in Table 2:

[0053] Table 2 Attribute update verification rule definition table

[0054]

[0055]

[0056] When the drone attributes are updated, the attributes are automatically updated and the control instructions are sent after the update conditions are met. When the current state of the drone cannot meet the pre-requirements for the attribute update, the system will classify the attribute update events. One type is the instructions that can be executed later and will enter the attribute update waiting event, including navigation points, landing, return and other attribute update events. They can be updated when the drone meets the conditions, and the user will be notified of the current drone status and subsequent retransmissions. When the attribute update rule trigger conditions are met, the system automatically resends the drone control instructions. The other type is the rejection of the update event. At this time, the system feedbacks the front-end user that the instruction cannot be executed and ends the attribute update.

[0057] S4. According to the requirements of attribute update with different frequencies, a basic telemetry data acquisition timer with a frequency of 200ms and a route and electronic fence attribute information acquisition timer with a frequency of 5s are constructed, which are used for real-time update of the basic attributes of the drone and for updating the data with low update frequency on the drone and high response requirements on the user side. The real drone data is obtained by active acquisition, and the real drone data is used to determine whether the conditions for attribute update are met according to the attribute update verification rules. If the update conditions are met, the control command is sent to the drone control interface to complete the attribute update. Otherwise, the control command is transferred to the waiting command sending stage, and the real drone data is continued to be obtained for judgment until the update conditions are met.

[0058] in conclusion:

[0059] 1. The present invention adopts a forward fault-tolerant mechanism and performs conversion rule verification on the logical process of the drone control command that needs to be converted to the drone attribute update, thereby solving the problem of lack of verification caused by the interface-oriented design style, ensuring that each attribute change is safe, and the sending of instructions is also in line with the drone's own rules, avoiding the logical problem that the drone needs to move backward and forward at the same time, and avoiding the occurrence of drone safety incidents; it solves the problem of improving the safety of existing drone control instructions, and the instruction-level interface has a low-coupling design feature, which is committed to pursuing the successful sending of instructions, but cannot take into account the problem of drone safety design.

[0060] 2. When updating the drone attributes, the present invention establishes an effective event automatic retry mechanism. When the current state of the drone cannot meet the pre-requirements for attribute updating, the system will classify the attribute updating events. One type is the instructions that can be delayed for execution, which will enter the attribute updating waiting event and notify the user of the current drone status and subsequent retransmissions. When the event triggering conditions are met, the system automatically retransmits the drone control instructions; the other type is the update rejection event. At this time, the system feeds back to the front-end user that the instruction cannot be executed and ends the attribute update. In this way, it can avoid the user from repeatedly sending instructions to cause the drone system to be abnormal, and the attribute update event can be processed and retransmitted through the judgment mechanism to avoid users from repeating operations; it solves the problem that the existing instruction driver is unreliable and cannot effectively guarantee the execution success rate of the instruction.

[0061] 3. The present invention analyzes different characteristics of drone data and constructs different timers to achieve data diversion, which not only ensures the normal operation of the link bandwidth, but also ensures the timeliness of data acquisition; it solves the problem that the existing interface-oriented framework design style only considers the response to an interface request once, so larger and higher-frequency interfaces are often called together with smaller and lower-frequency interfaces. This method easily leads to excessive continuous occupancy of link bandwidth, blocking the network, and causing damage to other data transmission.

[0062] 4. The present invention decouples the acquisition of telemetry data from the external push of telemetry data. The acquisition of UAV telemetry is an important basis for the control of UAV, and its stability and reliability should be guaranteed. However, the external push of UAV data has a low priority, and usually has problems such as high network failure rate and abnormal push processing. Therefore, by decoupling the two, the stability of the local system can be effectively improved and the occurrence of flight accidents can be reduced. The current interface-oriented system architecture style is solved, which often puts the telemetry broadcast into the interface response for obtaining telemetry information. The acquisition of telemetry data often has a high frequency. The packaging of the UAV's own status according to the other party's requirements and the external broadcast event are placed in the telemetry acquisition interface, which can easily lead to system abnormality risks. The external broadcast causes the failure of UAV telemetry monitoring, resulting in the problem of UAV flight accidents.

[0063] Example 2: Update of drone hovering properties and event-driven experiment

[0064] This embodiment is based on the method steps of Embodiment 1 to complete the update mechanism experiment of the hovering attribute of the drone.

[0065] In this embodiment, the hovering attribute of the drone is regarded as an important dictionary value of the current action attribute of the drone, as shown in Table 3:

[0066] Table 3 Definition of drone hovering attributes

[0067] Property name type illustrate action String Drone current action status

[0068] The action attribute sub-dictionary values ​​of the drone are shown in Table 4:

[0069] Table 4 UAV action attribute sub-dictionary value table

[0070] Action Dictionary Dictionary Values Action Name GROUND_TEST 0 Ground testing APV_PRE_LAUNCH_STATE 1 Pre-flight check APV_ATT_ASSIST_STATE 2 Posture Assist APV_HOVER_ASSIST_STATE 3 Hover assist APV_LIFT_OFF_STATE 4 Off the Ground APV_CLIMB_OUT_STATE 5 Climb APV_ACCELERATE_STATE 6 accelerate APV_V2L_STATE 7 Vertical to flat APV_AUTO_HOVER_STATE 8 Hover APV_FLYING_STATE 9 flight APV_LANDING_STATE 10 landing APV_DECELERATE_STATE 11 slow down APV_L2V_STATE 12 Horizontal to vertical APV_FINAL_HOVER_STATE 13 End Hover APV_FINAL_DESCENT_STATE 14 End drop APV_FORCED_LANDING_STATE 15 Forced landing APV_AHRS_FORCED_LANDING_STATE 16 AHRS forced landing APV_SEMI_AUTO_ASSIST_STATE 17 Semi-automatic assistance APV_SELF_DESTRUCTION_STATE 18 Self-destruct

[0071] The event-driven function corresponding to the current action attribute of the drone is:

[0072] dataTransmissionService.hoverNow(0,System.currentTimeMillis()); The hover action update detection rules in the drone's current action attribute are shown in Table 5:

[0073] Table 5. Update detection rules for hovering action in the current action attributes of the drone

[0074]

[0075]

[0076] Based on the above properties, the instruction function and update detection rules encapsulate the virtual drone object.

[0077] The drone control system is started, and the drone virtual object is created and initialized through the configuration file.

[0078] Automatically connect to the drone by connecting the IP and port number in the virtual drone properties (the prerequisite is that the drone signal is connected or when supporting 4 / 5G networked drones, the ground terminal is required to be connected to the Internet).

[0079] Receive the drone telemetry data packet and force (without verification) update the virtual drone properties through the telemetry data packet to ensure that the real-world drone state and the virtual drone state are completely consistent.

[0080] Provide a user operation interface. When the user clicks the hover button on the operation interface, the drone's current action - hover detection update event is triggered.

[0081] The backend receives the frontend interface call event and triggers the event update detection mechanism.

[0082] Get the update detection rules based on the properties to be updated. The hover property update detection includes the above 5 detection rules.

[0083] Update verification is performed item by item according to the rule level, and the detection results include the following events:

[0084] 1. Detection passed: trigger command is sent and virtual drone attributes are updated;

[0085] 2. Failure of detection: trigger different subsequent events based on the failure event;

[0086] a) Direct failure: Return to the front end and prompt the user that the operation failed;

[0087] a) Trigger after meeting the conditions: Create a timer based on the attribute name, listen to the drone telemetry update event, and trigger the attribute update event again when the conditions are met. For example, the drone loses connection. The drone loses connection for a short time due to radio signal interference or radio signal obstruction during flight. At this time, the user sends a hovering command. After the rule detection fails, the system will automatically create a scheduled task to detect the drone attribute update. When the drone reacquires telemetry and the drone status changes to connected, the hovering event update detection mechanism will be triggered again. When all rule detections pass, the system sends the drone hovering command and controls the drone to hover.

[0088] like Figure 3 As shown, this embodiment demonstrates the technical route of updating the hovering attributes of the drone, and draws the conclusion that the present invention can improve the security of the drone instructions and the reliability of instruction sending. At the same time, through the object-oriented abstract method, the system architecture clarity is optimized, the system complexity is simplified, and the workload of code maintenance personnel can be reduced to a large extent, reducing the system development and operation and maintenance costs. The extensibility of the attributes and detection rules can reduce the cost of later system expansion.

[0089] Example 3: Experiment on updating drone telemetry attributes and external push event-driven

[0090] This embodiment is based on the method steps of Embodiment 1 to complete the mechanism experiment of externally pushing attribute change events after the UAV telemetry attributes are updated.

[0091] In this embodiment, a drone attribute observer list is created based on the drone object, and observer A of the local ground control terminal and observer B of the external drone that needs to be pushed are added. This observer list can be expanded wirelessly; the system will automatically scan the list and push all of them to the observers.

[0092] The external data update of the drone includes basic telemetry data and airborne long-distance route and payload image data, etc. The basic telemetry data is a smaller data update and is usually acquired and updated at a high frequency. However, the airborne long-distance route and payload image data are larger data updates. The use of a high-frequency data update mechanism will cause the drone link bandwidth to be significantly temporarily used, resulting in the limitation of the basic monitoring and control functions of the drone, affecting the flight safety of the drone. Therefore, this embodiment provides a mechanism for creating different timer tasks to update and trigger external data push according to different attribute update requirements.

[0093] The acquisition and update time are sorted according to the attribute update requirement classification. Ordinary telemetry data includes various basic flight data of the UAV. In order to ensure the aircraft safety of the UAV and the effectiveness of the attribute update detection mechanism in Example 1, the data acquisition and update requirement is once every 200ms; the UAV onboard route data and payload image data have low update requirements and acquisition timeliness, so the update comment is once every 5 minutes; based on the above requirements, two timers are created in this embodiment, and users acquire and update two different types of data.

[0094] In the process of creating timers, two different timers are created according to the data acquisition and update frequency requirements. The timer calls the telemetry data acquisition interface at the set frequency, parses the interface, and converts the hexadecimal string into various attribute data formats.

[0095] The drone attribute update function will be called in the timer, and the attribute data will be updated to the drone singleton object; in the drone singleton object attribute update function, the telemetry change detection function will be automatically called, and the function will include data change criteria, for example: the drone power change is greater than 0.1, indicating that the power is reduced; the drone action attribute changes from hovering to other, indicating that the drone action state has changed, etc. After detecting the change, the system obtains the observer list, observer A and observer B, and automatically calls A and B's send functions to re-obtain the global singleton drone object, assemble the external system data requirement package, and send it to the external system.

[0096] This embodiment demonstrates the solution to the data update frequency requirements of two different telemetry data of the drone. The timer in the system can be created wirelessly (the hardware performance of the machine needs to be considered) to improve the flexibility of data acquisition. At the same time, the external data push mechanism is demonstrated based on this embodiment. The observer list created by the system can be dynamically adjusted and can be expanded to an unlimited number of external systems to meet the external data requirements of the drone. This shows that the present invention can improve the scalability of the system. At the same time, the push events do not interfere with each other, which reduces the coupling of the system and improves the stability of the system.

[0097] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for designing an attribute-driven drone control system architecture, characterized in that: The following steps are involved: S1, extract the drone attribute features, encapsulate them, and build a virtual drone object; S2. Use the observer mode to observe the changes in the attribute status of the drone, build an attribute change detection mechanism, and implement the information push interface of the external system based on the attribute change detection mechanism to push the drone status information to the external system for broadcasting; S3, adding an attribute update method to the virtual drone object according to the attribute change event, building an attribute update mechanism, and converting the attribute change into a control instruction for the drone according to the attribute update mechanism; S4. According to the property update requirements of different frequencies, real drone data is obtained by active acquisition, and the real drone data is used to determine whether the conditions for property update are met. If the conditions for update are met, the control command is sent to the drone control interface to complete the property update. Otherwise, the control command is transferred to the waiting command sending stage, and the real drone data is continued to be obtained for judgment until the update conditions are met.

2. The method for designing an attribute-driven drone management and control system architecture according to claim 1 is characterized in that: The drone attribute features in step S1 include the ground station attributes corresponding to the drone control, the drone model, name, position, posture, controller parameters, emergency parameters, maximum load, maximum flight speed, minimum flight speed, maximum climb angle, load type and load attributes. The drone attribute features are extracted and encapsulated to ensure that the real-world drone attributes are mapped to the virtual drone object, realizing attribute association analysis and attribute-driven design.

3. The method for designing an attribute-driven drone management and control system architecture according to claim 1, characterized in that: The construction of the virtual drone object in step S1 is to use the singleton mode to encapsulate and construct the virtual drone object, and create the corresponding virtual drone object through the unique ID of the drone to ensure the uniqueness of the global object.

4. The method for designing an attribute-driven drone management and control system architecture according to claim 1, characterized in that: In step S2, the observer mode is used to observe the changes in the attribute status of the drone. It adopts an object-oriented design, monitors the changes in the drone status and actively pushes the latest status and change amount to the subscribed message object, so as to realize the creation of multiple observer instances and monitor the changes.

5. The method for designing an attribute-driven drone management and control system architecture according to claim 4 is characterized in that: The monitoring of drone status changes is performed by adding an observer list to the drone virtual object, which is used to implement an information push interface of an external system according to the observer type added to the observer list when the drone attributes change, and complete the sending of drone information to terminal observers.

6. The method for designing an attribute-driven drone management and control system architecture according to claim 5 is characterized in that: The observer list is used to complete the operations of adding new observers and deleting observers according to system requirements by exposing the add observer method and the delete observer method.

7. The method for designing an attribute-driven drone management and control system architecture according to claim 1, characterized in that: The attribute update mechanism constructed in step S3 includes an attribute update mechanism based on telemetry data and an attribute update mechanism based on the user side. The attribute update mechanism based on telemetry data is to construct multiple timers, periodically call the telemetry data acquisition interface telemetry data, and then use the telemetry data to convert it into the attribute update of the virtual drone object, thereby realizing the synchronous update of the real-world drone attributes and the virtual drone object. The attribute update mechanism based on the user side is to update the change control of the drone attributes according to user needs.

8. The method for designing an attribute-driven drone management and control system architecture according to claim 7, characterized in that: The attribute update method of the telemetry data-based attribute update mechanism is as follows: the attribute update operation is completed by parsing the airborne telemetry data packet and according to the virtual drone object attribute format.

9. The method for designing a drone management and control system architecture based on attribute drive according to claim 7, characterized in that: The attribute update method based on the user-side attribute update mechanism is: according to the HTTP interface form and the attribute update verification rules, different interface operation interfaces are exposed through the virtual drone attribute information, which are triggered by the user and mapped to different attribute update events.

10. The method for designing a drone management and control system architecture based on attribute drive according to claim 9, characterized in that: The verification method of the attribute update verification rule is: by obtaining the drone singleton object in real time, the real state of the current drone is obtained, and then the attribute update verification is performed using the real state of the drone.

11. The method for designing an attribute-driven drone management and control system architecture according to claim 10, characterized in that: The attribute update verification includes an update verification of the basic attributes of the drone and an update verification of the flight mission management attributes of the drone.

12. The method for designing an attribute-driven drone management and control system architecture according to claim 7, characterized in that: The construction of multiple timers includes constructing a basic telemetry data acquisition timer every 200 ms and constructing a route and electronic fence attribute information acquisition timer every 5 s.

Images