We gave an autonomous drone one destination and one rule: never guess.

August 12, 2026 · by Kate Sai Kishore

Editorial illustration. The recorded simulation and screenshots below are from the actual run.

A drone does not look uncertain. When its map is old, its position jumps, or two sensors disagree, it still looks calm. The propellers keep turning. The route remains a neat line on a screen. That is precisely why the difficult moment is not a dramatic crash. It is the ordinary second in which the machine has enough information to move, but not enough trustworthy evidence to know that it should.

We wanted to see what qbrin would do in that second. So we connected it to an autonomous drone mission, gave the drone a destination, stored the route offline, and let the entire run play out for ten minutes.

The result was not a stunt. The drone took off, reached the survey area, completed its route, returned home and landed. The interesting part was what happened before every one of those actions.

The mission was simple on purpose

The aircraft was an X500 quadcopter carrying a survey camera. Its destination and return path were loaded before takeoff, so the mission did not depend on a browser map or an internet connection. The autopilot was the official open-source PX4 stack, flying inside the Gazebo simulator.

That distinction matters. This was a simulation, not a claim about a field-ready aircraft. But the autopilot, mission commands, telemetry stream, arming, navigation, return-to-launch and landing were the real PX4 workflow. Nothing in the route was a browser animation, and the ten-minute result was not edited to manufacture a successful ending.

PX4 flew the drone. qbrin stood in the decision path and asked whether the evidence supporting the next action was fresh, coherent and allowed.

Can the machine prove enough about the world to act now?

The most important decision was HOLD

At the beginning of a run, signals do not all become trustworthy at exactly the same instant. A heartbeat may arrive before position. Position may arrive before a stable attitude sample. A system that is eager to move can mistake “some telemetry exists” for “the mission is ready.”

qbrin started closed. While the evidence was incomplete or still settling, it returned HOLD. It did not invent a missing value, smooth over a disagreement or treat yesterday’s route as proof of today’s position. Once the required evidence agreed, the mission could continue.

Across the run, qbrin checked the live heartbeat, position and attitude, the age of those readings, the planned destination, the local safety boundary, remaining battery and the authority to continue. The route could be perfectly valid and the next action could still be refused if the evidence describing the current moment was not.

Ten minutes, measured from start to safe finish

We recorded the complete run, not just the attractive takeoff and landing. The final film is exactly ten minutes long and includes the qbrin decision state throughout.

The destination was reached. The survey completed. The aircraft returned with return-to-launch, landed, and finished disarmed. The mission stayed inside its local boundary, and every qbrin decision was written to the audit record.

Watch the uncut mission

The full recording is below. It is deliberately longer than a product demo because trustworthy autonomy should survive the uneventful minutes too. A safety check that only works during a carefully chosen 30-second clip has not proved very much.

Why this matters outside a simulator

Autonomous machines rarely fail because they suddenly forget how to move. They fail because they act on a picture of the world that is stale, incomplete, spoofed or internally inconsistent. A map can be valid while a location is wrong. A command can be authorised while the battery state makes it unwise. Two sensors can each look plausible while being impossible together.

The same problem appears in inspection drones, farm equipment, warehouse robots, power systems, treatment plants and financial agents. Their own controllers are built to execute valid actions. They are not always built to ask whether the story behind an action is true enough, current enough and complete enough.

qbrin is being built for that boundary: between an agent that proposes an action and a system that can make the proposal real.

What this shows, and what it does not

It shows that qbrin can sit beside the official PX4 autopilot workflow, evaluate live mission evidence, fail closed when that evidence is incomplete, allow a valid offline mission to continue, and preserve an auditable record from start to safe finish.

It does not show that a simulated mission proves a production drone deployment is safe. Real aircraft add wind, radio loss, hardware faults, regulations, people and terrain that no single simulation can settle. Those require field testing, independent review and domain-specific controls.

The useful result is smaller and more concrete: the drone did not have to guess in order to finish. Waiting did not ruin the mission. Verification made completion explainable.

See qbrin check your own agent →