Cross-medium unmanned aerial vehicle flight control system based on modular loose coupling architecture
The UAV flight control system, with its modular loosely coupled architecture, solves the problems of tight coupling and limited functionality, achieving modularity, scalability, and efficient development, and supporting flexible configuration and integration of various automated flight missions.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING UNIV OF AERONAUTICS & ASTRONAUTICS
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-28
AI Technical Summary
Existing UAV automatic flight systems suffer from problems such as tight system coupling leading to difficulties in modification and expansion, limited functionality and poor versatility, and cumbersome hardware and algorithm adaptation work.
It adopts a modular loosely coupled architecture, and achieves decoupling of flight mission management, flight control, path planning and positioning calculation through clearly defined module interfaces and state management logic. It supports flexible configuration and execution of various automatic flight missions using task manager and adapter patterns.
It achieves modularity and strong scalability, supports plug-and-play integration of new modules, facilitates the integration of cutting-edge algorithms, improves development efficiency and reduces maintenance costs, and provides excellent versatility and flexibility.
Smart Images

Figure CN121934583A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of unmanned aerial vehicle (UAV) control technology, specifically a cross-media UAV flight control system based on a modular loosely coupled architecture. Background Technology
[0002] Currently, the development of unmanned aerial vehicle (UAV) automatic flight systems (such as fixed-point cruise systems) faces the following technical challenges: 1. Tightly coupled system, making modification and expansion difficult: Traditional UAV automatic flight systems typically integrate functions such as mission management, path planning, and flight control communication into a single program. When it is necessary to replace the flight controller (such as from PX4 to DJI MSDK / PSDK), update the path planning algorithm, or upgrade the positioning module, it is often necessary to modify a large amount of underlying code, or even reconstruct the entire system, resulting in low development efficiency and high trial-and-error costs.
[0003] 2. Limited functionality and poor versatility: Existing systems are mostly customized for specific tasks (such as fixed route inspection), making it difficult to flexibly configure and switch different flight modes (such as hover inspection mode and waypoint crossing mode) within the same system, and also unable to quickly integrate new advanced functions (such as subsequent autonomous exploration).
[0004] 3. The hardware and algorithm adaptation work is cumbersome: For different UAV platforms and sensor installation locations, it is necessary to repeatedly write code for coordinate transformation, communication interface adaptation, etc. The lack of a unified abstraction layer to shield the differences in the underlying hardware results in low code reusability. Summary of the Invention
[0005] This invention aims to solve the aforementioned problems by providing a highly modular and loosely coupled unmanned aerial vehicle (UAV) automatic flight control system. Through clearly defined module interfaces and state management logic, this system decouples core functions such as flight mission management, flight control, path planning, and positioning calculation. This allows for rapid adaptation to different hardware and algorithms and supports flexible configuration and execution of various automatic flight missions.
[0006] This invention provides a cross-media UAV flight control system based on a modular loosely coupled architecture, the control system comprising: The task manager, which is a finite state machine (FSM), is used to manage the execution flow of tasks and system state transitions, and is implemented in the form of ROS nodes. The adapter, the control system adopts the adapter pattern and interface-oriented programming logic, and completely separates the high-level logic from the low-level implementation through abstract base classes and runtime polymorphism, and is implemented in the form of ROS nodes.
[0007] Furthermore, the finite state machine (FSM) executes the process in the task message received by the task manager, and includes the following states: Waiting state: The waiting state is the initial state after the system starts up. In the waiting state, the task manager checks cyclically whether a new task has been received from the host computer before switching to the takeoff state. Takeoff state: After receiving a mission, the takeoff state sends a takeoff command to the adapter and blocks in this state, waiting for the adapter to return a takeoff end signal before switching to the corresponding mission mode; Execute waypoint mission mode one: If the mission type is waypoint mission mode one, then switching to waypoint mission mode one from takeoff indicates that the system is executing a mission where the UAV flies to a sequence of several target points in sequence, hovers at each target point and executes several tasks; when the execution completion message of n target points is received, switching out of waypoint mission mode one; Execute waypoint mission mode two: If the mission type is waypoint mission mode 2, then the system switches to waypoint mission mode 2 from takeoff, indicating that the system is executing a mission where the UAV flies to a sequence of several target points in sequence, without stopping at each target point, and quickly moves to the next target point; when the mission ends message is received, the system switches out of waypoint mission mode 2. Landing status: After the mission is completed, send a landing command to the adapter and wait for the landing completion message. Once received, switch to the completion status. Completion status: This indicates that the task is completed. No action is required; simply switch to the next task to be issued.
[0008] Furthermore, the abstract state machine adapter class contains three member variables: a pointer to the flight controller adapter base class responsible for adapting to different flight controllers, a pointer to the planner adapter base class responsible for adapting to different planner algorithms, and a pointer to the positioning adapter base class responsible for adapting to different positioning algorithms. The positioning adapter base class calls the abstract odometry deployment methods of the flight controller adapter base class and the planner adapter base class based on its internal pointers to the flight controller adapter base class and the planner adapter base class. The planner adapter base class calls the control expectation deployment method of the flight controller adapter base class through its internal pointer to the flight controller adapter base class. In the constructor of the abstract state machine adapter class, the corresponding derived class objects of the three member variables are initialized based on the base class pointers of the input function parameters; The abstract state machine adapter is also used to register callback functions for messages corresponding to actions such as takeoff, hovering, yaw adjustment, landing, and target point release. That is, after receiving the corresponding action instructions sent by the task manager, for each action, the abstract action function is called according to the flight controller adapter pointer; for the action of releasing the target point, the abstract action function is called according to the planner adapter pointer; and for the task of releasing the target point, the waiting process ends after the planner pointer sends a completion message to it.
[0009] Furthermore, the flight controller adapter base class defines abstract functions for takeoff, hovering, yaw adjustment, landing, odometer reading, and control expectation reading; among them, takeoff, hovering, yaw adjustment, and landing are abstract functions of actions controlled by the task manager.
[0010] Furthermore, the planner adapter base class defines three abstract functions: subscribing to expectations, publishing target points to the planner adapter, and publishing odometer readings to the planner adapter. The planner adapter base class also contains a pointer to the flight controller adapter base class, and the pointer member of the flight controller adapter base class is assigned a value through the constructor of the planner adapter base class. The function for publishing target points to the planner adapter is determined by different planner adapters.
[0011] Furthermore, the positioning adapter base class is used to publish positioning messages to the flight controller and the planner, and contains pointers to the flight controller adapter base class and the planner adapter base class. The pointer members of the flight controller adapter base class and the planner adapter base class are assigned values through function parameters in the constructor of the odometry adapter base class.
[0012] Furthermore, (1) the planner needs to input the positioning message of the positioning algorithm to work. (2) the cascade flight controller needs to input the positioning message of the positioning algorithm to achieve precise control of the trajectory position. (3) the cascade flight controller needs to input the control expectation output by the planner to fly. Based on the above three necessary requirements, and combined with the requirement that this system needs to adapt to different flight controllers, positioning algorithms, and path planning algorithms, the adapter process is used as the relay process for the above three message transmissions. It receives the messages sent by the sender, and then performs type conversion and coordinate conversion before sending them to the receiving end of the corresponding message to achieve the adaptation of different modules. For (1), the receiving function of the adapter process is determined by the specific positioning algorithm, so it is implemented in the positioning adapter class; the sending function is determined by the specific planner algorithm, so it is implemented in the planner adapter class. For (2), the receiving function of the adapter process is determined by the specific positioning algorithm, so it is implemented in the positioning adapter class; the sending function is determined by the specific flight controller type, so it is implemented in the flight controller adapter class. For (3), the receiving function of the adapter process is determined by the specific planner algorithm, so it is implemented in the planning adapter class; the sending function is determined by the specific flight control type, so it is implemented in the flight control adapter class.
[0013] Furthermore, to adapt to UAV systems that have already been configured with positioning and mapping modules, planner modules, and flight control modules, the switching on and off of the relay processes for the three message transmissions in the control adapter process can be configured through parameters during the non-compilation stage according to specific needs.
[0014] The beneficial effects of this invention are as follows: I. Innovative Loosely Coupled Architecture: Through the design of a task manager, general adapters, and abstract interfaces, a complete separation of business logic, control execution, and core algorithms is achieved. This gives the system unparalleled modularity.
[0015] II. Exceptional Scalability: "Plug and Play" Integration: New flight controllers, planners, or positioning modules can be seamlessly integrated into the system simply by implementing the corresponding adapter base class interface. This achieves the significant advantage of "writing N+M+P modules to obtain N×M×P combinations".
[0016] III. Easy integration of cutting-edge algorithms: The latest SLAM or planning algorithms in academia can be tested and verified on this system at the fastest speed, which greatly accelerates the scientific research process.
[0017] IV. Exceptional Versatility and Flexibility: A single system unifies multiple autonomous flight modes (fixed-point cruise, exploration, tracking, etc.). While this patent focuses on cruise, its architecture provides a unified framework for all autonomous flight missions based on "waypoints" or "trajectories." The mission manager, as a programmable state machine, allows users to flexibly define and combine complex flight mission processes without affecting underlying stability.
[0018] V. Significantly Improved Development Efficiency and Reduced Maintenance Costs: Engineers from different teams can develop mission logic, flight control drivers, and algorithm modules in parallel. Each module can be unit tested independently. For example, a "simulated flight control adapter" can be created to test the entire mission process without connecting to a real drone. Adapter code and mission manager code are fully reusable across different projects. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a system overall architecture block diagram of the present invention; Figure 2 This is a state transition diagram of the task manager in an embodiment of this application; Figure 3 This is an adapter class diagram in an embodiment of this application; Figure 4 This is a data format structure diagram of the task message in the embodiments of this application. Detailed Implementation
[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0022] like Figure 1 As shown, Figure 1 This application outlines the overall technical solution and architecture of the system. Each module is responsible for a single, clearly defined task and communicates with the outside world through well-defined interfaces. The overall system architecture is as follows: Figure 1 As shown, it clearly illustrates the hierarchical relationships and data interaction processes between the core modules.
[0023] This invention provides a cross-media UAV flight control system based on a modular loosely coupled architecture, the control system comprising: The task manager, which is a finite state machine (FSM), is used to manage the execution flow of tasks and system state transitions, and is implemented in the form of ROS nodes. The adapter, the control system adopts the adapter pattern and interface-oriented programming logic, and completely separates the high-level logic from the low-level implementation through abstract base classes and runtime polymorphism, and is implemented in the form of ROS nodes.
[0024] Furthermore, the finite state machine (FSM) executes the process in the task message received by the task manager, and includes the following states: Waiting state: The waiting state is the initial state after the system starts up. In the waiting state, the task manager checks cyclically whether a new task has been received from the host computer before switching to the takeoff state. Takeoff state: After receiving a mission, the takeoff state sends a takeoff command to the adapter and blocks in this state, waiting for the adapter to return a takeoff end signal before switching to the corresponding mission mode; Execute waypoint mission mode one: If the mission type is waypoint mission mode one, then switching to waypoint mission mode one from takeoff indicates that the system is executing a mission where the UAV flies to a sequence of several target points in sequence, hovers at each target point and executes several tasks; when the execution completion message of n target points is received, switching out of waypoint mission mode one; Execute waypoint mission mode two: If the mission type is waypoint mission mode 2, then the system switches to waypoint mission mode 2 from takeoff, indicating that the system is executing a mission where the UAV flies to a sequence of several target points in sequence, without stopping at each target point, and quickly moves to the next target point; when the mission ends message is received, the system switches out of waypoint mission mode 2. Landing status: After the mission is completed, send a landing command to the adapter and wait for the landing completion message. Once received, switch to the completion status. Completion status: This indicates that the task is completed. No action is required; simply switch to the next task to be issued.
[0025] Furthermore, the abstract state machine adapter class contains three member variables: a pointer to the flight controller adapter base class responsible for adapting to different flight controllers, a pointer to the planner adapter base class responsible for adapting to different planner algorithms, and a pointer to the positioning adapter base class responsible for adapting to different positioning algorithms. The positioning adapter base class calls the abstract odometry deployment methods of the flight controller adapter base class and the planner adapter base class based on its internal pointers to the flight controller adapter base class and the planner adapter base class. The planner adapter base class calls the control expectation deployment method of the flight controller adapter base class through its internal pointer to the flight controller adapter base class. In the constructor of the abstract state machine adapter class, the corresponding derived class objects of the three member variables are initialized based on the base class pointers of the input function parameters; The abstract state machine adapter is also used to register callback functions for messages corresponding to actions such as takeoff, hovering, yaw adjustment, landing, and target point release. That is, after receiving the corresponding action instructions sent by the task manager, for each action, the abstract action function is called according to the flight controller adapter pointer; for the action of releasing the target point, the abstract action function is called according to the planner adapter pointer; and for the task of releasing the target point, the waiting process ends after the planner pointer sends a completion message to it.
[0026] Furthermore, the flight controller adapter base class defines abstract functions for takeoff, hovering, yaw adjustment, landing, odometer reading, and control expectation reading; among them, takeoff, hovering, yaw adjustment, and landing are abstract functions of actions controlled by the task manager.
[0027] Furthermore, the planner adapter base class defines three abstract functions: subscribing to expectations, publishing target points to the planner adapter, and publishing odometer readings to the planner adapter. The planner adapter base class also contains a pointer to the flight controller adapter base class, and the pointer member of the flight controller adapter base class is assigned a value through the constructor of the planner adapter base class. The function for publishing target points to the planner adapter is determined by different planner adapters.
[0028] Furthermore, the positioning adapter base class is used to publish positioning messages to the flight controller and the planner, and contains pointers to the flight controller adapter base class and the planner adapter base class. The pointer members of the flight controller adapter base class and the planner adapter base class are assigned values through function parameters in the constructor of the odometry adapter base class.
[0029] Furthermore, (1) the planner needs to input the positioning message of the positioning algorithm to work. (2) the cascade flight controller needs to input the positioning message of the positioning algorithm to achieve precise control of the trajectory position. (3) the cascade flight controller needs to input the control expectation output by the planner to fly. Based on the above three necessary requirements, and combined with the requirement that this system needs to adapt to different flight controllers, positioning algorithms, and path planning algorithms, the adapter process is used as the relay process for the above three message transmissions. It receives the messages sent by the sender, and then performs type conversion and coordinate conversion before sending them to the receiving end of the corresponding message to achieve the adaptation of different modules. For (1), the receiving function of the adapter process is determined by the specific positioning algorithm, so it is implemented in the positioning adapter class; the sending function is determined by the specific planner algorithm, so it is implemented in the planner adapter class. For (2), the receiving function of the adapter process is determined by the specific positioning algorithm, so it is implemented in the positioning adapter class; the sending function is determined by the specific flight controller type, so it is implemented in the flight controller adapter class. For (3), the receiving function of the adapter process is determined by the specific planner algorithm, so it is implemented in the planning adapter class; the sending function is determined by the specific flight control type, so it is implemented in the flight control adapter class.
[0030] Furthermore, to adapt to UAV systems that have already been configured with positioning and mapping modules, planner modules, and flight control modules, the switching of the three transfer channels in the seven modules can be controlled through parameter configuration during the non-compilation stage according to specific needs.
[0031] Example 1:
[0032] The core architecture modules of the cross-media UAV flight control system based on the modular loosely coupled architecture of this application include: 1. Mission Manager: The system's command center, responsible for advanced task analysis and process control.
[0033] II. Adapter: The communication hub of the system, responsible for connecting all modules and shielding underlying differences through polymorphism technology. It includes flight controller adapter, planner adapter, and odometer adapter.
[0034] 2. Detailed description and technical specifications of the core modules: 2.1 Mission Manager: The Task Manager is the "logical brain" of this system; its essence is a carefully designed Finite-State Machine (FSM). It does not involve any specific flight control or algorithm calculations, but focuses solely on managing the execution flow of tasks and system state transitions.
[0035] Internal state machine design: WAIT (Waiting State): The initial state after system startup. In this state, the manager continuously checks whether a new task has been received from the host computer before switching to takeoff state.
[0036] TAKE_OFF (Takeoff State): After receiving the mission, send a takeoff command to the adapter and block in this state, waiting for the adapter to return the TAKEOFF_COMPLETE signal, and then switch to the corresponding mission mode.
[0037] EXEC_WAYPOINTS_MODE1 (Execute Waypoint Mission Mode 1): If the mission type is waypoint_mode1, this mode is entered upon takeoff. It indicates that the system is executing flight mode 1, where the UAV sequentially flies to a sequence of target points, hovers at each point, and performs several tasks. This mode is exited after receiving completion messages from n target points.
[0038] EXEC_WAYPOINTS_MODE2 (Execute Waypoint Mission Mode 2): If the mission type is waypoint_mode2, this mode is entered upon takeoff. It indicates that the system is currently executing flight mode 1, where the UAV flies sequentially to a sequence of target points without stopping at each point, quickly moving to the next, thus controlling the overall trajectory shape through position points. This mode is exited upon receiving a mission completion message.
[0039] LAND (Landing State): After the mission is completed, send a landing command to the adapter and wait for the landing completion message. Once received, switch to FINISH state.
[0040] FINISH (Completed Status): Indicates that the task is complete. No further action is required. The system will immediately switch to the WAIT state and wait for the next task to be released.
[0041] Figure 2 This is a diagram showing the state transitions of Task Manager, where; 2.2 Adapter: The adapter is the technical hub of this invention and the key to realizing the "loosely coupled" architecture. It adopts the Adapter Pattern and the idea of interface-oriented programming, and completely separates high-level logic from low-level implementation through abstract base classes and runtime polymorphism.
[0042] The class diagram of the adapter is as follows Figure 3 As shown.
[0043] The abstract state machine adapter has three member variables: `flight_control_module`, `odom_fusion_module`, and `planner_module`. These are pointers to the base classes of the flight controller adapter, odometry adapter, and planner adapter, respectively. The constructor of the abstract state machine adapter initializes the corresponding derived class objects through these three pointers based on the input configuration parameters. Furthermore, the abstract state machine adapter registers callbacks for actions such as takeoff, hovering, yaw adjustment, landing, and target point deployment. Upon receiving the corresponding action commands from the task manager, for takeoff, hovering, yaw adjustment, and landing actions, it calls the abstract action function based on `flight_control_module`; for target point deployment, it calls the abstract action function based on `planner_module`. For target point deployment tasks, it waits for the planner to send a completion message before exiting the waiting state.
[0044] The `flight_control_adapter_base` class defines a series of abstract functions for takeoff, hovering, yaw adjustment, landing, publishing odometry, publishing control expectations, and subscribing to RTK data. These functions directly interact with the flight controller. Different flight controllers have different interaction methods, which should be implemented by a derived class representing the specific flight controller. For example, the takeoff function code differs between DJI, PX4, and APM flight controllers. The abstract function for publishing odometry refers to the fact that external odometry calculations typically require input to the flight controller for EKF fusion, but different flight controllers implement the interface for inputting external positioning differently. Publishing control expectations means that the planner inputs discretized control expectations into the flight controller for execution, but the interface for inputting these expectations varies depending on the flight controller.
[0045] The `planner_adapter_base` class defines three functions: subscribing to expectations, publishing target points to the planner, and publishing odometry data to the planner. These are all abstract interfaces. In addition, the class contains a pointer to `flight_control_adapter_base`, whose value is passed to the constructor. Subscribing to expectations refers to the process where the planner outputs discrete control expectations to the flight controller. Different planners use different interfaces to send these expectations, and this callback function immediately performs the publishing operation based on the `flight_control_adapter_base` pointer within the class. The function for publishing target points to the planner is determined by the specific planner and is therefore placed within the planner's class. Publishing odometry data to the planner refers to the planner's need for odometry positioning input; the interface for sending this positioning message varies depending on the planner.
[0046] In `odom_fusion_adapter_base`, the abstraction of outputting odometry data to the flight controller and odometry terminals is primarily implemented. Internally, it contains pointers to the flight controller adapter and planner adapter, whose specific values are passed to the constructor. The `Sub_odom` function receives the positioning message from the odometry and performs a coordinate transformation. Because the position of the positioning sensor relative to the aircraft's geometric center differs in different UAVs, a coordinate transformation interface is provided here to adapt to different UAV models by accommodating the relative positions of different hardware sensors. This receiving interface varies depending on the positioning algorithm. Then, in the message callback, two publish functions are executed based on two pointers to publish the message to the planner and flight controller.
[0047] This invention proposes a cross-media UAV flight control system based on a modular, loosely coupled architecture. The task manager, an independent process based on a finite state machine, is responsible for managing the task execution flow and system state transitions. Its internal states cover waiting, takeoff, various waypoint mission modes, landing, and completion states, enabling the UAV to automatically complete flight operations according to preset logic based on the received task type. The adapter, also an independent process, is implemented using the adapter pattern and interface-oriented programming. It decouples high-level control logic from low-level implementation through an abstract base class and runtime polymorphism. Internally, it includes a flight control adapter, a planner adapter, and a positioning adapter. These three are linked through base class pointers and can dynamically instantiate different derived classes based on configuration, thus supporting flexible adaptation to different flight control, planning algorithms, and positioning systems. The system uses adapters to relay and convert various message flows, achieving data interoperability between the positioning, planning, and control modules. It also allows for control of the opening and closing of each adapter channel through non-compiled parameter configuration. This invention improves the modularity, scalability, and cross-platform adaptability of the UAV control system.
[0048] Example 2:
[0049] Based on the system provided in Embodiment 1, this embodiment presents the complete workflow of the system. The workflow of this system will be described below using the fixed-point cruise mode 1 as an example: The host computer sends a task message, and the data format of the task message is as follows: Figure 4 As shown: The task message consists of a task name and task data. The task name can be either waypoint_mode1 or... waypoint_mode2 represents mode 1 and mode 2 for fixed-point cruise. The mission data consists of an array of several three-dimensional coordinate points used to describe the mission's target point.
[0050] After receiving a task message, the Task Manager first sends a takeoff command to the adapter. Upon receiving a takeoff completion message, it then, depending on the task type of the received message, switches to different internal sending logic to send a point or point sequence to the adapter. After completing the task, it sends a landing command, waits for landing to complete, and then re-enters the waiting task state.
[0051] The adapter is responsible for performing takeoff, hovering, yaw adjustment, and landing. Upon receiving the corresponding instructions from the task manager, it immediately executes these actions and sends a completion signal to the task manager upon completion. However, for incoming target point sequences, it directly forwards them to the planner for execution. After receiving the planning completion message, it forwards it to the task manager.
[0052] After receiving the target point sequence forwarded by the adapter, the path planning module begins planning the trajectory. Once planned, the trajectory is discretized and sent to the flight controller as the desired control action. The flight controller then directly controls the UAV to fly along the planner's precise trajectory. Upon reaching the target point, the planner sends an execution completion message to the adapter.
[0053] Once the adapter receives the completion message, it will forward it to the Task Manager.
[0054] After the Task Manager receives the execution completion command forwarded by the adapter, if it is in mode one, it will execute hovering and other load tasks, then execute the next target point, and repeat the same loop until there is no next target point. Then it will send a landing command and wait for the landing to complete. If it is in mode two, it will wait for the execution end command, and after receiving the end command, it will send a landing command and wait for the landing to complete.
[0055] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, for the device embodiments, the above descriptions are merely preferred embodiments of the present invention. Since they are fundamentally similar to the method embodiments, the descriptions are relatively simple, and relevant parts can be referred to the descriptions of the method embodiments. The above descriptions are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention, without departing from the principle of the present invention, should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A cross-media UAV flight control system based on a modular loosely coupled architecture, characterized in that, The control system includes: The task manager, which is a finite state machine (FSM), is used to manage the execution flow of tasks and system state transitions, and is implemented in the form of ROS nodes. The adapter, which is part of the control system, adopts the adapter pattern and interface-oriented programming logic. Through abstract base classes and runtime polymorphism, it completely separates high-level logic from low-level implementation. It is an independent process that defines objects of the abstract state machine adapter class internally. The abstract state machine adapter is run by registering message callback functions and timer callback functions in the abstract state machine adapter object, and is implemented in the form of ROS nodes.
2. The cross-media UAV flight control system based on a modular loosely coupled architecture according to claim 1, characterized in that, The finite state machine (FSM) executes the process in the task message received by the task manager, and includes the following states: Waiting state: The waiting state is the initial state after the system starts up. In the waiting state, the task manager checks cyclically whether a new task has been received from the host computer before switching to the takeoff state. Takeoff state: After receiving a mission, the takeoff state sends a takeoff command to the adapter and blocks in this state, waiting for the adapter to return a takeoff end signal before switching to the corresponding mission mode; Execute waypoint mission mode one: If the mission type is waypoint mission mode one, then switching to waypoint mission mode one from takeoff indicates that the system is executing a mission where the UAV flies to a sequence of several target points in sequence, hovers at each target point and executes several tasks; when the execution completion message of n target points is received, switching out of waypoint mission mode one; Execute waypoint mission mode two: If the mission type is waypoint mission mode 2, then the system switches to waypoint mission mode 2 from takeoff, indicating that the system is executing a mission where the UAV flies to a sequence of several target points in sequence, without stopping at each target point, and quickly moves to the next target point; when the mission ends message is received, the system switches out of waypoint mission mode 2. Landing status: After the mission is completed, send a landing command to the adapter and wait for the landing completion message. Once received, switch to the completion status. Completion status: This indicates that the task is completed. No action is required; simply switch to the next task to be issued.
3. The cross-media UAV flight control system based on a modular loosely coupled architecture according to claim 1, characterized in that, The abstract state machine adapter class contains three member variables: a pointer to the base class of the flight controller adapter responsible for adapting to different flight controllers, a pointer to the base class of the planner adapter responsible for adapting to different planner algorithms, and a pointer to the base class of the positioning adapter responsible for adapting to different positioning algorithms. The positioning adapter base class calls the abstract odometer publish method of the flight controller adapter base class and the planner adapter base class based on its internal pointers to the flight controller adapter base class and the planner adapter base class; The planner adapter base class calls the control expectation release method of the flight controller adapter base class through its internal flight controller adapter base class pointer; In the constructor of the abstract state machine adapter class, the corresponding derived class objects of the three member variables are initialized according to the base class pointers of the input function parameters; The abstract state machine adapter is also used to register callback functions for messages corresponding to actions such as takeoff, hovering, yaw adjustment, landing, and target point release. That is, after receiving the corresponding action instructions sent by the task manager, for each action, the abstract action function is called according to the flight controller adapter pointer; for the action of releasing the target point, the abstract action function is called according to the planner adapter pointer; and for the task of releasing the target point, the waiting process ends after the planner pointer sends a completion message to it.
4. The cross-media UAV flight control system based on a modular loosely coupled architecture according to claim 3, characterized in that, The flight controller adapter base class defines abstract functions for takeoff, hovering, yaw adjustment, landing, odometry release, and control expectation release. These abstract functions are defined by derived classes of different flight controller adapter base classes. Takeoff, hovering, yaw adjustment, and landing are action abstract functions called by the task manager.
5. The cross-media UAV flight control system based on a modular loosely coupled architecture according to claim 3, characterized in that, The planner base class defines three abstract functions: subscribing to expectations, publishing target points to the planner, and publishing odometry to the planner. These three abstract functions are specifically defined by derived classes of different planner adapter base classes. Based on the parameter configuration, the expectation publishing function inside the object pointed to by the pointer is selectively called through the internal flight controller adapter base class pointer. The planner base class contains a pointer to a flight controller adapter base class, and the pointer member of the flight controller adapter base class is assigned a value through the constructor of the planner adapter base class.
6. The cross-media UAV flight control system based on a modular loosely coupled architecture according to claim 3, characterized in that, The positioning adapter base class defines an abstract function for subscribing to positioning messages from the odometry. This abstract function is specifically defined by derived classes of the positioning adapter base class. Based on the parameter configuration, the odometry publishing function inside the object pointed to by the pointer is selectively called through the pointers of the planner adapter base class and the flight controller adapter base class. The positioning adapter base class contains pointers to the flight control adapter base class and the planner adapter base class. The pointers to the flight control adapter base class and the planner adapter base class are assigned values as function parameters in the constructor of the odometry adapter base class.