A drone is carrying out an inspection of an industrial park. Most waypoints have been completed and little battery power remains, but new obstacles have suddenly appeared in a construction area ahead while an anomaly is reported in the equipment zone. Should it continue along the original route, address the anomaly first, or initiate return-to-home immediately?

Questions like these go beyond basic flight control. A flight controller can keep the drone stable as it reaches a target point, but a higher-level system must decide task sequencing, risk, and resource allocation. As drones take on inspection, search and rescue, logistics, and other applications, the system's focus is shifting from executing trajectories to choosing missions. Reinforcement learning offers one way to address such problems, but it has clear limits. Real-world deployment still depends on layered system architecture, safety constraints, and validation on real aircraft.

01

The Hard Part of Mission Execution Is Choosing What to Do

Preplanned routes work well for missions with fixed procedures and little environmental change. Once conditions in the field change, however, the original route often needs to be adjusted: Should an anomalous target be moved to the front of the queue? How much additional power will a detour consume? Can the mission continue after communication quality deteriorates? How much safety margin should be reserved for the return flight?

These decisions usually involve multiple conditions. Adding more fixed rules can cover some scenarios, but as the rule set grows, so do the costs of resolving conflicts and maintaining the system. For example, if "inspect the anomalous target first" and "return immediately when battery power is low" are triggered at the same time, the system must determine the final action based on risk and mission benefit.

The output of autonomous decision-making is not mysterious. It is usually a target point, a mission mode, or a route switch. The system reads position, battery level, obstacles, mission progress, and communication status, then chooses among actions such as continuing, detouring, switching targets, and returning to home. Every action must still satisfy safety conditions such as geofencing, speed limits, and the energy reserve required for return.

02

How Responsibilities Are Divided Across the System

Take PX4 as an example. The flight controller estimates position, velocity, and attitude from IMU, GPS, visual positioning, and other data. It then uses position, velocity, and attitude control to keep the drone tracking its target steadily. Hover stability and trajectory tracking are primarily the flight controller's responsibility.

The mission system handles decisions at a higher level. The decision layer determines where to go first and whether to continue or return; the planning layer generates a feasible trajectory based on the map and motion constraints; the flight controller executes that trajectory while maintaining stable flight. With this layered architecture, each layer can be tested independently, and problems are easier to locate.

A learned policy can sit in the mission decision layer, or it can be used for local obstacle avoidance and speed adjustment; its placement depends on mission risk. Low-level control that directly affects flight stability requires stricter validation and fail-safe protection. A more common engineering approach is for AI to output constrained goals or actions that are then executed by the planning and flight-control systems.

03

How Policies Are Trained

Reinforcement learning starts by defining three things: what the system can observe, what actions it can take, and how each choice will be evaluated. In an inspection mission, the state may include position, battery level, obstacles, mission progress, and communication quality. Actions may include selecting a target, adjusting speed, switching routes, or returning to home. The reward combines factors such as mission completion, time, energy use, and separation from obstacles.

Reward design directly shapes the policy. If minimizing time is the only objective, the policy may fly too close to obstacles; if safety penalties are too high, it may wait frequently or return prematurely. Whether the trained behavior is reasonable often depends on how well these metrics reflect the real mission, not on the name of the algorithm.

The training environment should also include wind disturbances, sensor noise, communication delays, payload variations, moving obstacles, and other conditions. If the simulation is too idealized, the policy is likely to fail when deployed on a real drone. If the randomization range is too broad, training becomes more difficult. Developers should gradually expand the training range based on platform performance and mission boundaries.

After training, the result is a mapping from states to actions. It can provide choices when rules are impossible to enumerate exhaustively, but its outputs must still be subject to output limits, collision checks, and safety logic. For high-risk missions, human takeover and fallback to conventional control remain essential.

04

AI Is Beginning to Learn Aerial Decision-Making

In research on autonomous aerial decision-making, DARPA's AlphaDogfight Trials and Air Combat Evolution (ACE) program are two prominent examples. The AlphaDogfight Trials trained and compared the decision-making capabilities of different AI agents in simulated close-range air combat. ACE goes further by focusing on autonomous decision-making in highly dynamic environments and on trusted collaboration between humans and intelligent flight systems.

These studies differ markedly from civilian drone applications, but they reveal a clear direction: research into intelligent aircraft is expanding beyond attitude control and trajectory tracking toward mission-level judgment, strategy selection, and human-machine teaming.

For civilian drones, these capabilities will ultimately be applied to more specific tasks. Examples include setting target priorities during inspections, deciding whether to adjust the search area during a search mission, and determining whether to continue or return early when communication or battery conditions change. The drone must weigh multiple feasible options in light of the environment, its own state, and mission objectives.

Improving drone intelligence, therefore, cannot be judged solely by flight range, image quality, and control accuracy. In a dynamic environment, the system's ability to update its plan promptly, manage risk, and choose the right next action is equally important in determining whether the mission succeeds.

05

The Hurdles to Real-World Deployment

When a policy moves from simulation to a real drone, the first challenges are data and timing. The model must receive real sensor data, perform inference at a fixed frequency with limited onboard computing power, and then pass target points, velocities, or mission modes to the planning and flight-control systems. Coordinate-frame errors, unsynchronized data, and inference latency can all cause a policy that worked in simulation to fail.

Validation usually starts with offline data replay, then moves through software-in-the-loop testing, hardware-in-the-loop testing, and flight tests in a controlled environment before the mission envelope is gradually expanded. At every stage, sensor data, model outputs, planning results, and flight-controller states must be logged so that problems can be reproduced and traced to the layer where they originated.

Safety mechanisms should be implemented independently of the learned policy. These include geofencing; speed and altitude limits; return-to-home on low battery; loss-of-communication handling; output limiting; human takeover; and emergency landing. If policy output exceeds defined boundaries, the lower-level system must reject it or switch to a safe mode.

When drones are used for industrial-park inspection, disaster search and rescue, warehouse logistics, power-line inspection, and similar missions, conditions change constantly. Obstacles, target priorities, battery level, and communication status may all shift at any time. Preplanned routes alone cannot cover every situation.

The challenge is to deploy AI policies validated in simulation reliably on real drones. The model must not only receive data from cameras, LiDAR, and other sensors, but also perform inference onboard and work reliably with the planning system and flight controller.

Amovlab's drone platforms support this development workflow by integrating NVIDIA edge-computing platforms, providing Ubuntu, CUDA, and other development environments, and offering integrated interfaces for perception, inference, planning, and PX4 flight control. Developers can move progressively from simulation training and algorithm validation to onboard deployment and flight testing, reducing the effort and cost of hardware/software adaptation and interface debugging.

For example, during an industrial-park inspection mission, the AI decision layer can select the next task based on target priority, battery level, and environmental risk. The planning layer generates a trajectory, and the PX4 flight controller tracks it while maintaining stable flight. Through this layered collaboration, algorithms can move beyond computers and demonstration environments and gradually enter real flight missions.