What this is: A dev-log entry about building two independent “isolation layers” that stop a simulated drone from flying into walls — one inside the decision pipeline, one running completely on its own.
Why it’s here: It is one of the clearest examples in the project of defense-in-depth: never trust a single component to keep an autonomous vehicle safe. We document both why the obvious hardware brake was unavailable to us and what we built instead.
Date: 2026-06-06 Ticket: v2 Block 3 — isolation layers
Glossary
- Isolation layer — a safety mechanism that sits between the decision-maker and the real world, so that a bad decision cannot reach the hardware unfiltered. Think of it like the laminated glass and the seatbelt in a car: two unrelated systems, each able to save you on its own.
- Process isolation — running a safety check as its own program (its own “node”) rather than as a function call inside a bigger program. Because it is a separate process, it cannot be skipped, starved, or corrupted by a bug elsewhere in the pipeline. It is the difference between a smoke alarm wired into your house versus a checkbox in an app that is supposed to remind you about smoke.
- Action gate — a fast yes/no check applied to a proposed move before it is sent to the flight stack. If the move would end inside a wall, the gate rejects it instantly.
- Safety guard — a small, always-on watchdog program that reads the raw distance and motion sensors many times a second and slams the brakes if the drone gets too close to something, regardless of what the rest of the system wanted.
- GUIDED / position setpoints — a flight mode where we tell the autopilot “go to this point” rather than “move at this velocity.” This choice matters a lot below, because the autopilot’s built-in obstacle brake only works on the velocity flavour.
- SITL — Software In The Loop. The autopilot firmware runs as ordinary software on a PC instead of on a real flight board, so we can fly thousands of “flights” with no hardware at risk.
- ToF sensor — a Time-of-Flight distance sensor. It fires a pulse and times the echo to measure how far away the nearest surface is.
1. The brief
The goal was stated plainly: build a hardware-level isolation layer (simulating a forced stop when there is a wall nearby) plus our own middleware on top of it. The model should live in a comfortable world; when needed, we — not the model — stop the drone by reading the sensors directly. The model may not even know what a collision is.
That last sentence is the design philosophy in one line. We do not want the decision-making model to learn fear of walls the hard way. We want a separate, dumb, reliable system that simply will not let it hit one.
2. Why the “obvious” hardware brake did not fit
The natural first idea is to use the autopilot’s own avoidance feature — point it at the proximity sensors and let the firmware refuse to move toward obstacles. We researched this thoroughly (the autopilot’s avoidance docs, community discourse, and the nav2 stack).
The catch: the autopilot’s built-in avoidance brakes only velocity commands in GUIDED mode. But we deliberately fly on position setpoints. Velocity-style control had already failed us across many earlier attempts, and the position approach is proven to work. So the built-in “hardware” stop is simply unreachable for us without switching back to a control style we know is worse. The same logic ruled out the nav2 collision monitor — it, too, only filters velocity-style commands.
We did not change our control style to get a free brake. Position control demonstrably works, and that is the foundation we protect.
So in our stack, the “hardware-level” simulation becomes Layer 2 below: an independent node that reads the raw sensors itself, fully detached from the model and the bridge. Feeding distance readings into the flight controller (via the standard distance-sensor messages) was parked as groundwork for real hardware — it helps in the hover-style modes but has no effect on GUIDED position flight.
3. The two layers (defense-in-depth)
| Layer | Where it lives | What it does |
|---|---|---|
| 1. Action Gate | In the policy bridge, before a move is executed | A step heading 0–3 cells into a wall is rejected instantly. This mirrors training exactly: in the training world, a step into an occupied cell simply does not move the drone. The model “lives in a comfortable world” — a rejected step is a normal, expected event for it. |
| 2. Safety Guard | In the drone-sim side, as its own independent node | Reads the distance and motion sensors at 50 Hz and issues a zero-motion stop when clearance drops below an adaptive threshold (with a floor of 0.8 m). It is the last line of defense and is invisible to the model. |
The key property is independence. Layer 1 is part of the thinking pipeline; if a bug let a bad move through, Layer 2 — a separate process reading raw sensors — would still catch it. Two systems, different code, different inputs, either one sufficient.
4. Live proof that we needed this
Before the gate existed, a run walked straight into the wall and gave us a textbook crash to point at.
The drone was exploring right up against a software wall. It hit a series of arrival timeouts, with the drone drifting 0.36–0.45 m even at low commanded speed — that drift was the safety guard’s braking pulses shoving the drone around. Meanwhile the speed weighting let the drone aim inside the safety guard’s stop zone. The result was a tug-of-war: the position stream pulling the drone forward, the zero-motion stop pulling it back. The autopilot eventually reported a crash from an angle error (tilt 61.8°) and disarmed itself. The drone ended up on the floor.
That is exactly the failure the gate is meant to prevent: never let the drone aim into the stop zone in the first place.
5. What we built
-
A clean action-gate module. It maps each proposed action to the relevant distance channels (forward, back, and a sideways “strafe” that takes the minimum of a 60°/120° pair) and decides with a strict “is the clearance less than the margin?” test. Rotate, scan, and the smart-travel action are deliberately not gated — a drone boxed in on all sides must still be allowed to turn, or it deadlocks forever.
-
Bridge behaviour on a rejected move. A rejection means: hold position, count the step as taken, and still hand an observation back to the model — exactly the semantics of a collision in the training world. The gate margin is set to 0.9 m, which is the 0.8 m safety floor plus one cell: we refuse to begin any step that would end inside the stop zone. A counter logs how many steps were blocked.
-
Adaptive-speed fix. Two speed-weighting cases had let the drone target the boundary or the inside of the stop zone; both were raised. The rule that came out of it: the speed weighting must never sit below floor-plus-one-cell.
-
Tests. Twelve new tests (channel mapping, boundary conditions, deadlock protection), bringing the suite to 48 passing.
6. Verification
- Unit tests: 48 of 48 passing.
- End-to-end (headless, ~10 minutes): the old code in this same configuration crashed in about 5 minutes with the angle-error fault. The new code kept the drone alive for the whole run.
- 8 gate blocks were logged — e.g. “gate: action 0 rejected — clearance 0.57 m < margin 0.90 m” — precisely the scenario that used to end in a tug-of-war.
- Zero stale-data skips; arrival timeouts became rare (5 in 10 minutes, versus constant before).
- Coverage rose from 0.005 to 0.043, well past the earlier ceiling of 0.022.
- Layer 2 was also exercised for real: drift carried the drone in to 0.57 m and the safety guard held it (tilt 9°, no crash).
So both layers earned their keep in a single run — the gate stopped the aim-into-wall behaviour, and the independent guard caught the residual drift the gate could not see.
7. Open items / next steps
- Yaw timeouts at the wall. A ~120° turn does not finish inside the 8-second window at the current turn rate. This needs a separate tuning pass balancing the arrival timeout against the angular speed.
- Distance readings into the flight controller — groundwork for real-hardware hover modes; on the backlog.
- Safety-guard brake pulse. Its counter-velocity pushes the drone into drift when it fights the position stream. With the gate in place that fight should disappear; we will re-check on the next end-to-end run and, if it recurs, soften the pulse.