Building a UAV MPC System: Perception, Detour Planning, and Lessons From My First Simulations

I started this project with a question "how should a UAV respond when its original plan is no longer the most suitable option?" Getting a vehicle to execute a mission is one part of autonomous flight. Building a system that can interpret its surroundings, consider alternatives, and execute an appropriate response is a different challenge.

That is the direction I want to explore with my UAV Model Predictive Control (MPC) project. My work brings together perception, detour behavior, vehicle-state monitoring, and an evaluation layer that helps me understand what the system is actually doing.

01. Perception is more than detecting an obstacle

Perception is useful when the information it produces can support a decision. Identifying an obstacle is one problem; determining whether it affects the intended maneuver, whether enough clearance is available, and whether an alternative is appropriate are separate problems.

In this project, I treat perception as an input to the decision-making process rather than an isolated detection module. At a high level, the intended workflow is:

1. Perception: provide information about the surrounding environment.
2. State and environment representation: consider the perception output alongside the vehicle's current state and intended movement.
3. Detour decision: consider an alternative when the direct maneuver is unsuitable.
4. Execution: send the selected behavior through the vehicle-control interface, subject to its supported commands and safety constraints.
5. Evaluation: collect telemetry to assess how the vehicle actually responds.

This separation makes the system easier to test. Perception quality can be assessed independently from the quality of the decision that follows it. An important next step is to measure not only whether the system identifies relevant environmental information, but whether that information leads to an appropriate response.

02. The detour feature: considering an alternative

One feature I am exploring is the ability to perform a detour when a direct maneuver is unsuitable. Rather than treating the original mission as something that must always be followed unchanged, the system should be able to consider an alternative while retaining awareness of the destination and the vehicle's operating constraints.

The first version of the detour layer is deliberately simple and works toward a goal position. Each control cycle it follows the same loop:

1. Estimate the state. A small filter combines GPS position and velocity into a smoother estimate of where the vehicle is and how it is moving.
2. Propose candidate motions. Using a dynamic-window style search, it samples a set of short-horizon velocity and heading options that the vehicle can reach within its acceleration limits.
3. Reject unsafe candidates. Each option is rolled forward in time and discarded if it comes within a safety buffer of an obstacle or no-fly area. The buffer accounts for vehicle size, command latency, and stopping distance.
4. Score what remains. Surviving candidates are ranked on progress toward the goal, clearance, and smoothness.
5. Execute and fall back safely. The best option is sent as a continuous stream of velocity commands. If no candidate is safe, the vehicle lands rather than gambling on an unsafe path.

The important part is not simply generating a detour. It is determining whether the alternative is appropriate and whether the vehicle can execute it reliably. A meaningful evaluation should ask:

• Does the alternative provide sufficient obstacle clearance?
• Can the vehicle execute the maneuver within its operating constraints?
• Does the alternative introduce unnecessary movement or control effort?
• Can the vehicle resume the intended mission afterward?
• Does the behavior remain consistent across repeated runs?

A detour can be generated successfully without necessarily being the best solution. The evaluation needs to consider both the decision and the vehicle's actual response.

03. Establishing a baseline before evaluating MPC

Before comparing a more advanced controller against the existing system, I wanted to understand the conventional autopilot's behavior. I ran three simulated scenarios: an open-field mission, an obstacle-rich environment, and an emergency recovery scenario. A separate evaluation layer observed the vehicle and calculated a cost from its measured behavior.

The first surprise was the difference between intended cruise speed and observed behavior.

Across the cruise segments, the observed speed remained close to 5 m/s. In one recovery segment, the mean was 5.004 m/s and the maximum was 5.038 m/s.

The vehicle behaved consistently, but not according to the intended cruise speeds. An autopilot configuration or default behavior needed further investigation before these runs could serve as a fair reference for evaluating a different control strategy.

Validate the behavior of the existing system before evaluating a new controller.

04. When the scoring function does not represent the mission

The initial evaluation layer used a preferred speed of 2 m/s. Based on the recorded values, its speed-related cost was approximately:

Jᵥ = 2 × (v − 2)²

• At 5 m/s, the speed cost was 18.
• At standstill, the speed cost was 8.
• At exactly 2 m/s, the speed cost was zero.

In two scenarios, the speed component contributed approximately 91.4% and 90.9% of the total cost. The position and energy-related components remained zero in the recorded data.

This exposed a weakness in the initial objective: it rewarded closeness to a preferred speed without adequately representing mission progress. A stationary vehicle could receive a better score than one completing a useful maneuver.

An optimizer does not automatically understand what the mission requires. It minimizes the mathematical objective supplied to it, subject to its model and constraints. A more useful objective needs to represent desired vehicle behavior, mission progress, control effort, operational constraints, and energy consumption where reliable measurements are available.

The same principle applies to detours: the score should not reward a maneuver merely because it minimizes one isolated quantity. It should assess whether the vehicle makes useful progress while respecting the relevant constraints.

05. Why flight phases need separate evaluation

The recovery simulation lasted 175.4 seconds and covered approximately 534.1 metres. Its overall average speed was:

534.1 / 175.4 ≈ 3.04 m/s

Takeoff and landing accounted for 67.4 seconds, or about 38% of the run. The cruise segments maintained a speed close to 5 m/s. A whole-flight average therefore concealed important differences between flight phases.

For the next stage, I want to distinguish takeoff, cruise, maneuver transitions, detour execution, recovery, and landing wherever telemetry allows. This should make it easier to evaluate detour execution separately from the rest of the mission.

06. Battery readings and telemetry have limits

The obstacle-rich run recorded a battery decrease of 9 percentage points over 89.3 seconds and about 303 metres. The recovery run recorded a decrease of 13 percentage points over 175.4 seconds and about 534 metres.

These readings are useful observations, but they are not sufficient to establish which scenario was more energy-efficient. Battery values were available only in whole percentage points, the runs differed in duration and altitude profile, and direct current and power measurements were unavailable.

A stronger energy evaluation would record voltage and current over time:

E ≈ ∫ V(t) I(t) dt

Telemetry quality also matters when estimating acceleration and jerk. Data arrived at approximately 4.95 Hz, so numerical differentiation could amplify small variations. A speed wobble of only 0.05 m/s over a 0.2 s step already looks like 0.25 m/s² of acceleration. The logs contained acceleration peaks around 3.4 m/s² and jerk peaks around 12 m/s³, while mean absolute acceleration was approximately 0.1 m/s².

These peaks need further investigation before being treated as reliable indicators of control quality. For a system combining perception, detour planning, and MPC, a trustworthy measurement pipeline is essential.

07. Guidelines I am carrying forward

• Baseline first. Confirm what the existing system does before judging anything built on top of it.
• Score progress, not just proximity. An objective must reward getting the mission done, otherwise standing still can win.
• Evaluate by phase. Averages over a whole flight hide the behavior that matters.
• Measure what you intend to compute. Log position and electrical data up front, and filter before differentiating.
• Repeat before concluding. One run is an observation, not a result.

08. What I need to validate next

The simulations were useful, but successful mission execution is not the same as a meaningful evaluation. Two of the scenarios did not yet challenge what they were designed for:

• Obstacle-rich: the vehicle flew at about 18 metres while the walls were 10–12 metres tall, leaving 6–8 metres of clearance. It never needed the detour.
• Emergency recovery: the configured wind has a magnitude of about √(6² + 3²) ≈ 6.7 m/s, yet cruise speed stayed within about 0.05 m/s. Either the autopilot absorbed it completely or the wind is not acting on the vehicle; ground speed alone cannot tell me which.

My next steps are:

1. Validate perception: measure how reliably relevant environmental information is identified and represented.
2. Evaluate detour behavior: redesign the obstacle scenario so a detour is required, then test whether the alternative is appropriate, whether the vehicle executes it, and whether the mission can continue afterward.
3. Refine the objective function: reward useful mission behavior rather than minimizing deviation from a preferred speed alone.
4. Improve telemetry: collect position and electrical measurements and investigate filtering for derived metrics.
5. Establish repeatability: repeat scenarios and report medians, variability, and failure cases.
6. Compare against MPC: once the baseline is reliable, use equivalent conditions and the same evaluation metrics for a controlled comparison.

Final thoughts

This project is teaching me that autonomous UAV development involves more than making a vehicle fly or generating an alternative maneuver.

Perception must provide useful information. Detour planning must turn that information into an appropriate decision. The control system must execute the resulting behavior, and the evaluation process must determine whether the outcome meets the intended objectives.

My first simulations did not demonstrate an improvement from MPC. They revealed assumptions, measurement limitations, and objective-function weaknesses that need to be addressed before such a comparison can be trusted.

The next milestone is to bring these components together in a repeatable simulation workflow and evaluate their behavior using evidence rather than assumptions.