Unmanned aerial vehicle calling system and method based on open source gap atomization service

Abstract

The invention provides an unmanned aerial vehicle calling system and method based on open source gap atomization service. The system comprises a gap equipment layer, an atomization service framework layer, a protocol hard mapping engine layer, a shared memory direct writing layer and a PX4 flight control layer which are in communication connection with one another. Wherein the gap equipment layer is used for carrying out atomization service standardization packaging on basic services of the unmanned aerial vehicle according to a gap system rule, and constructing an interaction channel between the unmanned aerial vehicle and various terminals; the atomization service framework layer is used for managing the atomization service of the unmanned aerial vehicle; the protocol hard mapping engine layer is used for constructing a hard coding mapping table of an unmanned aerial vehicle atomization service and a PX4 flight control instruction; the shared memory direct writing layer is used for constructing a direct connection framework between a shared memory area special for the unmanned aerial vehicle and a hardware module in a swan-gap system; and the PX4 flight control layer is used for carrying out direct execution on an instruction from the swan gap system through PX4 flight control and carrying out quadruple safety protection on flight control.

Description

Technical Field

[0001] This invention relates to the field of drone technology, and in particular to a drone invocation system and method based on the open-source HarmonyOS atomic service. Background Technology

[0002] OpenHarmony, an open-source distributed operating system independently developed in my country, boasts core advantages in achieving seamless cross-device collaboration and atomic services (one-time development, multi-device deployment) through "soft bus" technology, combined with the Star Shield security architecture to ensure industrial-grade reliability. Meanwhile, the open-source PX4 flight controller, a mainstream control technology in the global drone industry, while possessing a mature modular architecture and rich ecosystem, has long been constrained by fragmented development environments (high hardware adaptation costs), real-time bottlenecks, and weak multi-device collaboration capabilities. The combination of these two technologies is creating a disruptive technological fusion: OpenHarmony provides a unified OS foundation for PX4, leveraging distributed capabilities to connect the drone-ground station-robot collaborative link, significantly improving cluster task efficiency; PX4 flight controller injects highly reliable real-time control capabilities into Harmony, optimizing algorithm performance through Model-Based Design (MBD) and deeply integrating large models (such as DeepSeek-R1) with Harmony's native AI framework to achieve intelligent scenarios such as voice-controlled flight and autonomous obstacle avoidance. Future trends focus on the explosive growth of the low-altitude economy. The integration of open-source HarmonyOS and PX4 will drive drones to leap from "single-machine intelligence" to "integrated air-ground-space swarm intelligence," while accelerating the export of domestic technologies.

[0003] The following solutions are proposed for drone flight control in existing scenarios such as industrial inspection and logistics distribution: 1. MAVROS+ROS Architecture: This technology works by building a middleware layer using the Robot Operating System (ROS) and utilizing MAVROS bridging packets to parse the MAVLink (Micro Air Vehicle Link) aircraft message transmission protocol of the PX4 flight controller. The control command flow path is: Application Layer → ROS Node → MAVROS → UDP / TCP → PX4 Flight Controller. However, its drawbacks include: ① High latency: Layered protocol stack encapsulation leads to command latency of 5-8ms. At a flight speed of 20m / s, a 5ms latency results in a positional deviation ≥0.1 meters, and in formation flight scenarios, the cumulative deviation >1 meter; ② Incompatibility with HarmonyOS ecosystem: ROS relies on the Linux system and cannot run natively on OpenHarmony devices (cameras / scanners / other devices); ③ Complex deployment: A Linux system + ROS environment needs to be deployed on the drone, increasing additional load and power consumption.

[0004] 2. Closed-source commercial SDKs (e.g., DJI MSDK): Manufacturers provide pre-compiled SDKs, and developers call flight control functions (such as takeoff and waypoint planning) through APIs. However, the underlying protocol is closed, and the ecosystem is limited. Specifically, this includes: ① Closed ecosystem: PX4 open-source algorithm libraries cannot be reused, such as VIO visual obstacle avoidance and dynamic path planning; ② High cross-platform costs: Adaptation to new devices requires manufacturer authorization; ③ Functional limitations: Key interfaces are restricted (e.g., direct access to mixer output is prohibited), which hinders the development of complex tasks.

[0005] 3. Cloud-based central control solution: This technology works by uploading control commands to the cloud via 4G / 5G for parsing, and then distributing them to the drone. A typical architecture includes: mobile app → cloud server → 4G base station → drone data transmission module → PX4 flight controller. However, drawbacks include: ① Weak network vulnerability: In weak network environments, momentary delays can cause severe jitter, leading to system uncontrollability and increasing the risk of accidents; ② Privacy risk: Sensitive data such as flight trajectory transmitted via a third-party cloud platform can easily violate relevant laws and regulations, resulting in privacy leaks; ③ High cost: The additional introduction of a cloud environment requires significant expenditure in complex scenarios.

[0006] Therefore, while all three solutions can achieve drone flight control, they have high development barriers, an imperfect ecosystem, certain safety risks, require developers to manually write hundreds of lines of code to implement basic functions, and have low module reusability. Specifically, these drawbacks include the following: 1. High development threshold: Traditional solutions require proficiency in MAVLink (Micro Air Vehicle Link) aircraft message transmission protocol and C++ programming, resulting in a long development cycle; 2. Insufficient real-time performance: The real-time performance of command transmission needs to be improved. The delay may exceed 5ms, resulting in a formation flight position deviation of ≥1 meter (calculated at a speed of 20m / s). 3. Poor cross-device collaboration: In diverse IoT scenarios, it is unable to quickly link with devices such as cameras, scanners, and communication equipment in the HarmonyOS ecosystem. Summary of the Invention

[0007] The purpose of this invention is to provide a drone invocation system and method based on open-source HarmonyOS atomic services, aiming to solve the above-mentioned problems in the prior art.

[0008] This invention provides a drone invocation system based on open-source HarmonyOS atomic services, including a HarmonyOS device layer, an atomic service framework layer, a protocol hard mapping engine layer, a shared memory direct write layer, and a PX4 flight control layer that are interconnected. The HarmonyOS device layer is used to perform atomic service standardization encapsulation of basic drone services according to HarmonyOS system rules, and to build interaction channels between drones and various terminals. The atomic service framework layer is used to manage the atomic services of drones; The protocol hard mapping engine layer is used to construct a hard-coded mapping table between UAV atomic services and PX4 flight control commands; The shared memory direct write layer is used to build a direct communication architecture between the dedicated shared memory area for drones and hardware modules in the HarmonyOS system; The PX4 flight control layer is used to directly execute commands from the HarmonyOS system and provide quadruple safety protection for flight control.

[0009] This invention provides a method for drone invocation based on open-source HarmonyOS atomic services, including: By standardizing and encapsulating basic drone services into atomic services according to HarmonyOS system rules through the HarmonyOS device layer, and building interaction channels between drones and various terminals; The drone atomic services are managed through the atomic service framework layer; A hard-coded mapping table between UAV atomic services and PX4 flight control commands is constructed through the protocol hard mapping engine layer; A direct-write layer for shared memory is used to build a pass-through architecture between a dedicated shared memory area for drones and hardware modules in the HarmonyOS system. The PX4 flight control layer enables direct execution of commands from the HarmonyOS system and provides four layers of safety protection for flight control.

[0010] This invention also provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the above-described drone invocation method based on the open-source HarmonyOS atomic service.

[0011] This invention also provides a computer-readable storage medium storing an information transmission implementation program, which, when executed by a processor, implements the steps of the above-described drone invocation method based on the open-source HarmonyOS atomic service.

[0012] The embodiments of this invention can include the following beneficial effects: By using shared memory direct writing and BDMA zero-copy reading, the embodiments of this invention effectively improve instruction latency by more than 70%, solving the core pain point of formation flight position deviation ≥1 meter; simultaneously, based on the low-code platform of HarmonyOS atomic services, the function development cycle is greatly shortened, completely eliminating the need for handwritten MAVLink protocols; the national cryptographic SM2 signature + MPU hardware isolation of the embodiments of this invention greatly reduces the bit error rate, and its hardware pass-through architecture achieves zero licensing fees, saving a significant amount of overhead and customization costs compared to closed-source SDK solutions. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of a drone invocation system based on open-source HarmonyOS atomic services, according to an embodiment of the present invention. Figure 2 This is a flowchart of the method for invoking atomic services of unmanned aerial vehicles based on open-source HarmonyOS and PX4 flight control according to an embodiment of the present invention; Figure 3 This is a flowchart of a drone invocation method based on open-source HarmonyOS atomic services, according to an embodiment of the present invention. Detailed Implementation

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

[0016] System Implementation Examples According to embodiments of the present invention, a drone invocation system based on open-source HarmonyOS atomic services is provided. Figure 1 This is a schematic diagram of a drone invocation system based on open-source HarmonyOS atomic services, as described in an embodiment of the present invention. Figure 1 As shown, the drone invocation system based on open-source HarmonyOS atomic services according to an embodiment of the present invention specifically includes: The HarmonyOS device layer, atomic service framework layer, protocol hard mapping engine layer, shared memory direct write layer, and PX4 flight control layer are interconnected and communicate with each other. Among them, HarmonyOS device layer 10 is used to perform atomic service standardization encapsulation of basic drone services according to HarmonyOS system rules, and to build interaction channels between drones and various terminals. Specifically, it is used for: Based on the open-source HarmonyOS capability framework, the basic services of drones are atomically encapsulated by declaring service metadata templates in the integrated development environment, and parameter constraints and access control are defined. It also uses the HarmonyOS soft bus to scan various HarmonyOS terminals on the same network to build an interaction channel between the drone and various terminals.

[0017] Atomized Service Framework Layer 12 is used to manage drone atomic services, specifically for: The service management engine uses an in-memory database to register several core standard services in the drone atomic service and opens a dynamic injection interface to support third-party extended services. The workflow engine models the call relationships between services based on a directed acyclic graph, and uses a topology sorting algorithm to generate drone task sequences based on the modeled call relationships. Conditional logic is introduced according to actual needs to adaptively orchestrate the drone task sequences, thus completing the full lifecycle management of drone atomic services.

[0018] Protocol hard mapping engine layer 14 is used to construct a hard-coded mapping table between UAV atomic services and PX4 flight control commands, specifically for: The NOR Flash stores a hard-coded mapping table between the UAV atomic service and the PX4 flight control command; wherein the hard-coded mapping table includes magic number verification, protocol version, service and MAVLink command mapping, and parameter offset rules; When the service is triggered, the Flash mapping area is traversed, the instruction number is extracted after matching, and the parameters are filled according to the parameter offset rules to generate a binary instruction stream that skips protocol stack serialization, thus constructing a hard mapping mechanism between the UAV atomic service and the PX4 flight control instructions.

[0019] Shared Memory Direct Write Layer 16 is used to build a direct communication architecture between the drone-specific shared memory area and hardware modules in the HarmonyOS system. Specifically, it is used for: In the HarmonyOS system, a shared memory driver was developed based on the HDF framework, and a dedicated physical address range was established as a dedicated shared memory area for UAVs; and a direct bus memory access channel was established as a hardware pass-through link between the HarmonyOS side and the PX4 side. After the instruction transmission is completed, an interrupt is triggered and the instruction is pushed to the PX4 mixer to build a pass-through architecture between hardware modules.

[0020] PX4 flight control layer 18 is used to directly execute commands from the HarmonyOS system via the PX4 flight control system and provides four layers of safety protection for flight control. Specifically, it is used for: The source code of the PX4 mixer was modified to change the command receiving and processing path. When the command is transmitted to the PX4 flight control system through the UAV-dedicated shared memory area, it is directly obtained and executed by the PX4 mixer without going through the MAVLink parsing layer. Furthermore, a four-fold security protection system is constructed through dual-machine hot standby monitoring, national cryptographic algorithm verification, memory hard isolation, and dual-channel redundancy mechanism, and the flight control is protected by the four-fold security protection system.

[0021] The following describes the specific implementation of the drone invocation system based on open-source HarmonyOS atomic services, as described in this embodiment of the invention. Figure 2 As shown, the above technical solutions of the embodiments of the present invention will be described in detail.

[0022] This invention proposes a drone control technology that deeply integrates the open-source Harmony distributed operating system and the PX4 open-source flight control architecture. Specifically, it is an atomic service call method. Through three core technologies—atomic service encapsulation, protocol hard mapping, and shared memory direct writing—it achieves low-code development, sub-millisecond command response, and full-scenario device collaboration, providing an independent and controllable technical foundation for the low-altitude economy.

[0023] To address the challenge of upgrading drone control development from "handwritten code" to "low-code programming," this invention constructs a visual low-code platform that supports atomic service encapsulation. Encapsulating basic service modules significantly improves code reusability, lowers the development threshold, and drastically reduces the number of programs required for deployment, enabling one-click rapid deployment. Furthermore, this invention employs a physical layer pass-through architecture, skipping protocol stack encapsulation and eliminating microsecond-level jitter.

[0024] This invention leverages the Internet of Things (IoT) advantages of the open-source HarmonyOS, utilizing its soft bus technology to construct a cross-platform service framework, enabling multi-terminal collaboration between mobile phone planning, vehicle monitoring, and smartwatch emergency stop. Furthermore, it introduces national-level cryptographic TEE verification to establish a hardware-isolated secure channel, ensuring the confidentiality of communication and data.

[0025] The detailed steps of this invention are as follows: I. HarmonyOS Device Layer Implementation 1. Standardized encapsulation of atomic services Based on the open-source Harmony Ability framework, service metadata templates are declared in the integrated development environment (IDE). Taking the takeoff service (ohos.ability.takeoff) as an example: (1) Define parameter constraints: the altitude value (alt) is limited to 10-500 meters, and the drone ID (drone_id) is subject to mandatory verification; (2) Access control: Distributed access control (ohos.permission.DRONE_CONTROL) ensures that only authorized devices (such as dispatcher tablets) can trigger sensitive commands.

[0026] 2. Cross-device service discovery mechanism Dynamic networking of devices using HarmonyOS soft bus: (1) Call DeviceManager.getDeviceList() to scan for HarmonyOS terminals (mobile phones / vehicle systems / watches) on the same network. (2) Construct cross-device Intent (Example: vehicle-mounted system calls tablet return service), specify the target device ID and Ability name through the Operation object to achieve command-level coordination.

[0027] II. Implementation of the Atomized Service Framework Layer 1. Service Management Engine (1) Register core capabilities using an in-memory database (ConcurrentHashMap): Preload 32 standard services including takeoff and return (abilityRegistry.put("ohos.ability.takeoff", TakeoffAbility.class)); (2) Open the dynamic injection interface (registerAbility()) to support third-party extended services (such as lighting control).

[0028] 2. Workflow Engine (1) Modeling service dependencies based on directed acyclic graph (DAG): Nodes (WorkflowNode) are bound to service parameters, and edges (addDependency()) define the execution order; (2) The topological sorting algorithm (topologicalSort()) determines the task sequence and embeds conditional branching logic (such as inserting a return node when the battery level is <20%).

[0029] III. Protocol Hard Mapping Engine Layer Implementation 1. Rule base design The hard-coded mapping table is stored in NOR Flash (address: 0x08080000), as shown in Table 1: Table 1 Hard-coded mapping table

[0030] 2. Zero-parse instruction generation When the service is triggered, it directly iterates through the Flash mapping area (strcmp(ability_name, flash_ptr)). After a successful match: (1) Extract the instruction number MAVLink CMD_ID (e.g., 0x00000016); (2) Fill in the parameters according to the offset rules (height value → param7); (3) Generate binary instruction stream (skip protocol stack serialization), reducing the time to 0.1ms.

[0031] IV. Implementation of Shared Memory Direct Write Layer 1. HarmonyOS side-drive design: (1) Develop a shared memory driver based on the hardware development framework HDF, and allocate physical addresses 0x60000000-0x60000FFF (4KB). (2) Initiate memory mapping via ioctl(SHM_WRITE).

[0032] 2. High-efficiency reading on the PX4 side: (1) Configure STM32H7 BDMA channel 1 (BDMA_CCR_MEM2MEM|BDMA_CCR_PL_HIGH): Source address: 0x60000000 (shared memory area); Target address: PX4 instruction queue (&px4_cmd_queue); (2) The transmission is completed and an interrupt is triggered (bdma1_handler), which directly pushes the instruction to the mixer. The direct memory access DMA read delay is 0.1ms.

[0033] V. Implementation of PX4 Flight Control Layer 1. Direct instruction execution: Modify the PX4 mixer source code (MulticopterPositionControl.cpp) to bypass the MAVLink drone communication protocol parsing layer with shared memory instructions.

[0034] 2. Four-fold safety protection: (1) Dual-machine hot standby monitoring: The coprocessor (STM32F7) detects the heartbeat of the main processor and triggers an emergency landing after a timeout of 50ms; (2) National cryptographic algorithm verification: HarmonyOS side SM2 signature command → PX4 signature verification and execution (key stored in TEE secure area); (3) Hard memory isolation: The MPU is configured to allow access to the shared memory area only in privileged mode (MPU_RASR_AP_RW_PRIV_ONLY). (4) Dual-channel redundancy: When the CRC check of the primary area (0x60000000) fails, it will switch to the backup area (0x60100000) within 3ms.

[0035] Preferably, the embodiments of the present invention can also use the ROS 2+Zenoh solution: deploying ROS 2 nodes on the HarmonyOS side requires 1.2GB of memory, and the instruction latency is >3ms. However, when 200 concurrent instructions are executed, the CPU load reaches 85%, which cannot support large-scale cluster control.

[0036] And WebAssembly edge computing solutions: WASM interpretation and execution result in a latency of >2ms, and cannot directly access sensors (requires forwarding through the HarmonyOS driver layer), and its critical instructions are easily intercepted.

[0037] The shared memory direct write proposed in this embodiment of the invention is the only technical path to achieve sub-millisecond response, and forms a "low code - hard real-time" closed loop when combined with protocol hard mapping.

[0038] In summary, the key to the embodiments of the present invention lies in: 1. Hard mapping mechanism from atomized services to flight control commands Static rule mapping method between HarmonyOS Atomized Services (Ability) and PX4 MAVLink instructions; 2. Cross-operating system physical memory passthrough architecture HarmonyOS and PX4 can communicate via a direct instruction write method that specifies the physical address range (0x60000000-0x60000FFF). 3. Security-enhanced control chain system An end-to-end protection framework based on national cryptographic algorithms and hardware isolation.

[0039] Method Implementation Examples According to an embodiment of the present invention, a method for drone invocation based on open-source HarmonyOS atomic services is provided. Figure 3 This is a flowchart of a drone invocation method based on open-source HarmonyOS atomic services, as described in an embodiment of the present invention. Figure 3 As shown, the drone invocation method based on open-source HarmonyOS atomic services according to an embodiment of the present invention specifically includes: Step S301 involves standardizing and encapsulating the basic drone services into atomic services according to the HarmonyOS system rules at the HarmonyOS device layer, and constructing interaction channels between the drone and various terminals. Specifically, this includes: By using the HarmonyOS device layer based on the open-source HarmonyOS capability framework, service metadata templates are declared in the integrated development environment to atomically encapsulate the basic services of drones, and to define parameter constraints and access control. It also uses the HarmonyOS soft bus to scan various HarmonyOS terminals on the same network to build an interaction channel between the drone and various terminals.

[0040] Step S302: Manage the UAV atomic services through the atomic service framework layer; Step S303: Construct a hard-coded mapping table between UAV atomic services and PX4 flight control commands through the protocol hard mapping engine layer; Step S304: Construct a direct-pass architecture between a dedicated shared memory area for drones and hardware modules in the HarmonyOS system through a shared memory direct-write layer; Step S305: The PX4 flight control layer is used to directly execute commands from the HarmonyOS system and provides four layers of safety protection for flight control.

[0041] The embodiments of the present invention are method embodiments corresponding to the system embodiments described above. The specific operations of each step can be understood by referring to the description of the system embodiments, and will not be repeated here.

[0042] In summary, the embodiments of the present invention have the following beneficial effects: 1. Real-time breakthrough: By using shared memory direct writing and BDMA zero-copy reading, the instruction latency is improved by more than 70% compared with the MAVROS solution (5~8ms), solving the core pain point of formation flight position deviation ≥1 meter; 2. Development Revolution: Based on HarmonyOS atomic services, the low-code platform greatly shortens the function development cycle, achieves a reuse rate of over 90%, and completely eliminates the need for hand-written MAVLink protocols; 3. Excellent in both security and cost: The national cryptographic SM2 signature + MPU hardware isolation greatly reduces the bit error rate, and the hardware pass-through architecture achieves zero licensing fees, saving a lot of expenses and customization costs compared to closed-source SDK solutions; 4. Core barriers: Sub-millisecond latency relies on physical memory passthrough (other solutions are theoretically unattainable), and the HarmonyOS atomized service ecosystem is bound to form a technological monopoly.

[0043] Device Example 1 This invention provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, performs the steps described in the method embodiment.

[0044] Device Example 2 This invention provides a computer-readable storage medium storing an information transmission implementation program, which, when executed by a processor, performs the steps described in the method embodiment.

[0045] The computer-readable storage media described in this embodiment include, but are not limited to, ROM, RAM, disk, or optical disk.

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

Claims

1. A drone invocation system based on open-source HarmonyOS atomic services, characterized in that... This includes the HarmonyOS device layer, atomic service framework layer, protocol hard mapping engine layer, shared memory direct write layer, and PX4 flight control layer, which are interconnected and communicate with each other. The HarmonyOS device layer is used to perform atomic service standardization encapsulation of basic drone services according to HarmonyOS system rules, and to build interaction channels between drones and various terminals. The atomic service framework layer is used to manage the atomic services of drones; The protocol hard mapping engine layer is used to construct a hard-coded mapping table between UAV atomic services and PX4 flight control commands; The shared memory direct write layer is used to build a direct communication architecture between the dedicated shared memory area for drones and hardware modules in the HarmonyOS system; The PX4 flight control layer is used to directly execute commands from the HarmonyOS system and provide quadruple safety protection for flight control.

2. The system according to claim 1, characterized in that, The HarmonyOS device layer is specifically used for: Based on the open-source HarmonyOS capability framework, the basic services of drones are atomically encapsulated by declaring service metadata templates in the integrated development environment, and parameter constraints and access control are defined. It also uses the HarmonyOS soft bus to scan various HarmonyOS terminals on the same network to build an interaction channel between the drone and various terminals.

3. The system according to claim 1, characterized in that, The atomic service framework layer is specifically used for: The service management engine uses an in-memory database to register several core standard services in the drone atomic service and opens a dynamic injection interface to support third-party extended services. The workflow engine models the call relationships between services based on a directed acyclic graph, and uses a topology sorting algorithm to generate drone task sequences based on the modeled call relationships. Conditional logic is introduced according to actual needs to adaptively orchestrate the drone task sequences, thus completing the full lifecycle management of drone atomic services.

4. The system according to claim 1, characterized in that, The protocol hard mapping engine layer is specifically used for: The NOR Flash stores a hard-coded mapping table between the UAV atomic service and the PX4 flight control command; wherein the hard-coded mapping table includes magic number verification, protocol version, service and MAVLink command mapping, and parameter offset rules; When the service is triggered, the Flash mapping area is traversed, the instruction number is extracted after matching, and the parameters are filled according to the parameter offset rules to generate a binary instruction stream that skips protocol stack serialization, thus constructing a hard mapping mechanism between the UAV atomic service and the PX4 flight control instructions.

5. The system according to claim 1, characterized in that, The shared memory direct write layer is specifically used for: In the HarmonyOS system, a shared memory driver was developed based on the HDF framework, and a dedicated physical address range was established as a dedicated shared memory area for UAVs; and a direct bus memory access channel was established as a hardware pass-through link between the HarmonyOS side and the PX4 side. After the instruction transmission is completed, an interrupt is triggered and the instruction is pushed to the PX4 mixer to build a pass-through architecture between hardware modules.

6. The system according to claim 1, characterized in that, The PX4 flight control layer is specifically used for: The source code of the PX4 mixer was modified to change the command receiving and processing path. When the command is transmitted to the PX4 flight control system through the UAV-dedicated shared memory area, it is directly obtained and executed by the PX4 mixer without going through the MAVLink parsing layer. Furthermore, a four-fold security protection system is constructed through dual-machine hot standby monitoring, national cryptographic algorithm verification, memory hard isolation, and dual-channel redundancy mechanism, and the flight control is protected by the four-fold security protection system.

7. A method for invoking drones based on open-source HarmonyOS atomic services, characterized in that... include: By standardizing and encapsulating basic drone services into atomic services according to the rules of the HarmonyOS system through the HarmonyOS device layer, and building interaction channels between drones and various terminals; The drone atomic services are managed through the atomic service framework layer; A hard-coded mapping table between UAV atomic services and PX4 flight control commands is constructed through the protocol hard mapping engine layer; A pass-through architecture between a dedicated shared memory area for drones and hardware modules is built in the HarmonyOS system through a shared memory direct write layer. The PX4 flight control layer enables direct execution of commands from the HarmonyOS system and provides four layers of safety protection for flight control.

8. The method according to claim 7, characterized in that, By standardizing and encapsulating basic drone services into atomic services according to HarmonyOS system rules at the HarmonyOS device layer, and by building interaction channels between drones and various terminals, the specific steps include: By using the HarmonyOS device layer based on the open-source HarmonyOS capability framework, service metadata templates are declared in the integrated development environment to atomically encapsulate the basic services of drones, and to define parameter constraints and access control. It also uses the HarmonyOS soft bus to scan various HarmonyOS terminals on the same network to build an interaction channel between the drone and various terminals.

9. An electronic device, characterized in that, include: The memory, the processor, and the computer program stored on the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the drone invocation method based on the open-source HarmonyOS atomic service as described in any one of claims 7-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an implementation program for information transmission, which, when executed by a processor, implements the steps of the drone invocation method based on the open-source HarmonyOS atomic service as described in any one of claims 7-8.

Images