Your Drone Has a Technical Problem. But Is That Where the Problem Actually Started?

Why the visible fault may not be the source

A drone team measures flight time and finds it short of target. The first move is a reasonable one: look at the battery. Then the motors, the propellers, the weight of the airframe. Each check costs a bench session or a purchase order, and each can come back clean.

Now suppose the battery is fine. What follows is an illustrative systems example, not a case from a project, and how much each link matters depends on the airframe, the payload and the mission. A payload decision raised the amount of data the aircraft has to handle. That data needed more compute at the edge. The compute drew more power and gave off more heat, which can call for cooling and a larger battery, and both add mass. Flight time fell. The symptom showed up in the power system. The decision was made in the sensor.

If you own a drone or UAV program at the stage where a working prototype has to become a product that can be built, updated and supported, this is the question to ask before the next revision: is the component that shows the fault the place where the decision was made? Each subsystem is specified and tested on its own terms, so the cost of a decision can stay hidden until hardware and software meet at integration, when changing course is expensive.

Treating the symptom is not wrong. Sometimes the battery really is the problem. The risk is that it is the only thing anyone examines, because the battery is where the number turned red.

Power, heat, mass and bandwidth are shared budgets. Every subsystem draws on them, so a decision that changes one budget changes it for every neighbor, whether or not the neighbor had a say. In program terms, that is how a team ends up with another hardware revision, a longer validation cycle, or rework between groups that each met their own requirement. So who was watching the budget all three decisions drew on?

Each decision was sensible. No one owned the budget

Look at the same sketch from the point of view of each team that touched it. The camera team chose a better sensor, because it improves what the payload can see. The compute team met its performance target. The power team sized the battery to the brief. Nobody missed a requirement, and no one owned the budget the three of them shared.

Someone has to own the shared budgets for the whole aircraft: the technical lead or chief engineer, with the authority to say no to a subsystem that spends a budget it was not given. That is a program decision as much as an engineering one, and it is cheapest to make before the first revision is committed.

That is why optimizing subsystems one at a time can produce a system problem. How detection models are sized for onboard compute is covered in Indeema's article on AI in drone defense. What the problem costs the program is mostly time and sequence: the discovery arrives after the commitments it affects, so each fix pushes back the date by which the product can be tested, shown or shipped, and is paid for with engineering effort that was planned for something else.

To trace a fault back to its decision, start where the teams' decisions meet. That place is a boundary.

Trace the decision back to its boundary

A drone is a stack of subsystems: payload and sensors, edge compute and AI, flight control, connectivity, and cloud and operations. Between each pair is a boundary, the place where one subsystem's decisions become another's constraints. A boundary carries data, power, heat, timing and mechanical envelope, and a software contract about what each side may assume.

Components change. Sensors get replaced, a compute module is swapped when a better one ships, a radio is changed for range or regulatory reasons. Well-defined boundaries let those parts change without renegotiating everything around them. Implicit ones turn every swap into a program-wide event.

The working principle is freeze the boundary, not the technology.

This does not mean freezing every interface on day one. An interface frozen too early locks in assumptions nobody has tested. The point is to know which boundaries you have committed to, what evidence they rest on, and what it would cost to move them.

Firmware is usually where the contract between hardware and software is actually implemented, which is why embedded firmware engineering sits close to this question. The far end of the same question is covered in Indeema's reference architecture for connected drone operations, which shows one way to draw the cloud and operations boundary.

A written boundary says what has been committed. The next question is what the commitment rests on.

What the evidence under a boundary actually proves

A prototype is often described as working or not working. That framing hides what matters. Every prototype buys a different kind of evidence, and each kind answers a different question. Ordered from simulation to production evidence, the kinds form a ladder, and each rung answers one question and not the next.

Trouble starts when evidence from one rung is read as evidence from the next. A bench result about one interface is not an answer about the integrated aircraft. A field test with one unit is not an answer about repeatability. The commitments that follow, such as a board revision, a compute platform or a supplier, then rest on less than the team believes.

So the useful question about any prototype is not whether it works. It is what uncertainty it retired, and what it deliberately did not attempt to prove. A prototype that states its own limits is easier to trust, and easier to plan the next one around.

A real example: what one data-link project showed about evidence and boundaries

The ladder is easiest to see in a small real case. For an agricultural-drone maker, Indeema built a firmware prototype of a QSPI-to-Wi-Fi bridge, and the question was whether the interface could carry the data rate the product required. The case illustrates the evidence boundary and, at the end of this section, how an upstream decision can narrow a boundary. It is not evidence for the camera-to-endurance sketch above, which remains an illustration.

The prototype bridge ran on an ESP32-PICO module, and even the networking layer was a decision. The team weighed the third-party stack the client had used before against the native ESP-IDF networking layer, and chose the native one, reasoning that it covered the requirement and that a third-party stack would add integration risk without a demonstrated need.

Here is what was observed. In one test with a logic analyzer, our firmware prototype clocked a four-line QSPI interface at 40 MHz, a nominal 160 Mbit/s, while UDP data from a Wi-Fi client was passed toward it; the requirement was at least 40 Mbit/s of data.

Read that carefully. The test showed that the interface could be driven at its design ceiling. A nominal line rate is arithmetic, not a measurement of sustained throughput, and the records we hold do not include a measured payload throughput. The test also did not measure what the radio link carries end to end or at operational range. Those questions sit higher on the evidence ladder.

• The question the requirement raises: could the interface carry the data rate the product needed?
• Evidence: one logic-analyzer observation of the interface at its nominal rate.
• What it can inform: whether to commit to this interface and build against a fixed contract.
• Not shown: what the integrated link sustains end to end, at range.

For this client, we built the bridge firmware, added two-way transmission after a change request, and supported its engineers as they integrated it.

The point of the example is not the number. It is the shape of the evidence: a requirement, one observation, and an explicit list of what that observation does not show. Read that way, the observation can inform whether to build against this interface. It cannot say what the integrated link sustains. The design record shows a second thing, one that needed no test.

A boundary can be constrained before anything is built on its far side. The pins available on the ESP32-PICO used in the design ruled out the fast routing path for the four-line QSPI interface, so the design record documented a 40 MHz maximum clock. The interface and its pin mapping were written down before the client firmware was written to them.

This does not show that the constraint later caused a field problem, and the record shows no such problem. It shows that an upstream hardware decision had already narrowed the solution space for a downstream interface before the downstream implementation existed. The visible problem may arrive later. The constraint can be created much earlier. Which of your own commitments is already narrowing a decision that has not been made yet?

Decide what to commit to, and when

One way to run a program is to build, integrate, discover and redesign. The discovery arrives late because integration is where the shared budgets first meet, and by then the redesign touches things already committed.

The alternative puts the evidence before the commitment: uncertainty, evidence, decision, commitment. Name what the team does not know. Choose the cheapest credible evidence that would resolve it. Decide what that evidence now allows. Only then commit.

The goal is not to eliminate uncertainty. A prototype program exists because things are unknown. The goal is to retire the right uncertainty before an expensive commitment.

A commitment can be a PCB revision, a compute platform, a payload interface, a radio architecture, a cloud dependency, a firmware architecture, a certification path or a manufacturing choice. Each is cheaper to change before it is made than after other work depends on it, and the cost of changing it grows as that work accumulates up the ladder. The loop applies well beyond drones. It matters more in a drone because mass, power and heat couple everything to everything else. Whether any commitment should wait depends on what kind of problem the visible fault is.

Gap or system? A first diagnostic

Once the boundary and the uncertainty are visible, a first diagnostic becomes possible. It is a thinking tool, not an algorithm. Ask three questions about the visible fault.

1. Neighbors. Would fixing the faulty component change the power, heat, mass, data or timing constraints of any neighboring subsystem?
2. Evidence. Could one bounded test or measurement tell you which fix to make?
3. Assumptions. Do the teams on either side of the boundary rely on assumptions about each other that nobody has written down or tested?

If the answers point to one gap

• Next action. Give the fault one owner, run the bounded test from the second question, make the fix, then ask the first question again of the result.
• Hold off. A program-wide review, or a new revision that the fix does not need.
• Expect. One result that closes the fault.
• You chose right if the fix leaves every neighbor's constraints where they were.

If they point to a system problem

• Next action. Write down the boundary using the list above, name the owner of the shared budget, pick the cheapest credible evidence for the largest open uncertainty, and decide which commitment waits for it.
• Hold off. New hires and new revisions that touch that boundary until the evidence exists.
• Expect. A boundary and an evidence plan first, and a fix only after them.
• You chose right if the list of untested assumptions gets shorter before anything is rebuilt.

If the answers are mixed, treat it as a system problem until the first and third questions have been answered. Treating a system problem as a gap is how engineering effort gets spent on the wrong layer.

Before the next revision

Go back to the flight-time shortfall in the sketch. A larger battery adds mass, and mass changes the power budget again, so the answer to the first question is yes: the fix moves a neighbor's constraints. That points to a system problem. The battery may still need work, but the first move is to find where the decision was made. Before assigning another engineer, replacing a component or starting another hardware revision, ask four questions.

1. Where is the boundary at which this problem became visible, and which upstream decision changed its constraints?
2. What uncertainty actually matters here?
3. What evidence would resolve it, and at which rung of the evidence ladder?
4. What commitment should wait until that evidence exists?

If the answers point to a system problem, the open question is which boundary to examine first.