Teaching a Drone to Perch
How I'm developing Perch, a drone that places sensor nodes in the physical world.
Tom Wade
10/3/20266 min read
The expensive part of monitoring a structure is rarely the sensor. It's getting the sensor there: scaffolding on a bridge, rope access on a dam, a lane closure for an afternoon's work on a girder. Perch is Continuis Labs' answer to that: drones that survey a structure in 3D, plan where each node should go, and eventually place the nodes themselves.
"Eventually" is doing honest work in that sentence. Drone placement is a concept proven only in simulation. Nothing in this post has flown, and until it does, crews place nodes by hand to the same plan. This post is about how I'm developing the manoeuvre anyway: in a physics simulator first, with a test harness I trust more than my own eyes, and a path from the simulator to flight firmware that doesn't depend on anyone copying numbers correctly.
The manoeuvre
On a wall or a pillar, the drone lines up so that one clean pitch will bring it to the surface. Then it flips: ninety degrees nose-down in a fraction of a second, with thrust cut and reversed as its belly swings in. A pad on its belly takes hold, and the drone squares itself to the surface. To leave, the rotors spool up, the pad lets go and the drone flies clear. Roofs and decks are simpler: they're landings, not flips.
The lab
The Quad Physics Lab is a browser application, about 9,500 lines of JavaScript with three.js for the 3D view and a tiny Python server with no dependencies. Under the visuals it's a physics model:
6-DOF rigid-body dynamics, with each rotor modelled separately (thrust and torque proportional to rotor speed squared).
A motor and ESC electrical model (resistance, inductance, torque and back-EMF constants, battery voltage, current limits), with saturation and a simple thermal estimate.
Noisy gyro and accelerometer models, an attitude estimator, nested attitude and rate PID loops, and an X-quad mixer.
Contact with Coulomb friction and a configurable attachment force.
A simulated LIDAR, a voxel map and A* path planning, so the drone senses and avoids rather than being told where things are.
The README lists what the model leaves out, because a simulator is only useful if you know where it's wrong: propeller coefficients are lumped constants rather than blade-element models, rotor gyroscopic moments are omitted, wall aerodynamics are simplified, and the ESC is a reduced-order model.
As of 12 October 2026 the result in simulation is 90 perches and 90 releases out of 90 across eight structures, with no propeller strikes, a mean of 73 mm from the planned spot, and 3.1 to 7.1 seconds to attach depending on the structure.
The test that tested the wrong thing
For a long stretch of work, the regression suite scored the perch by setting the target surface directly: the drone was handed the answer. The interface, and any real flight, uses a different path, where the drone finds the surface with its own simulated sensors and navigates to it. The shortcut seemed harmless.
It wasn't. On identical geometry the "oracle" path scored 12 out of 12 while the sensing path scored 0 out of 12. The suite had been passing over an entire class of bugs. The harness now always drives the sensing path, because confident numbers about a code path nobody uses are worse than no numbers.
Two habits came out of the same period:
Seeded randomness. The harness runs headless under Node with `Math.random` replaced by a seeded generator, so every failure reproduces exactly.
Re-measuring across seeds. Marginal targets can flip between seeds, so a fix that improves one seed is re-run across a range of seed offsets before I believe it. Otherwise a fix and a coin flip look the same.
Truth versus estimate
A simulator knows things a drone can't: its true attitude, its true position, exactly where the surface is. The flight computer only has its estimates. Every decision point in the manoeuvre was first written against the simulator's ground truth, and that substitution was the single biggest risk in taking it to hardware.
So I measured it rather than assuming it. A switch routes every one of those decisions through the estimator instead of the truth, and the full suite ran both ways. The results were identical: 90 of 90 perches, 90 of 90 releases, no strikes. The manoeuvre doesn't depend on anything the vehicle can't measure.
There's also an independent physics check. Released from a wall, the simulated drone loses 0.58 m of height before the rotors recover, a figure that agrees to within 0.02 m across seven test heights. Separately, the time the motors need to reverse can be computed from their constants (rotor inertia, speed change, torque constant and current) as 0.331 s, and free fall over that time is 0.537 m. The model was never told to produce that number; it comes out of the same physics.
From simulator to firmware
The flight firmware (`perch_fw`) targets a flight controller built on an STM32F405 microcontroller. Its job is to be the same controller that was measured over 90 perches, and two rules protect that:
Parameters are generated, never copied. The tuned constants header is written by a script from the simulator's own defaults. Nobody types a gain by hand.
The port is checked numerically. `make test` runs the C core against vectors generated from the simulator: 260 vectors, 500 comparisons, no failures, with a worst relative disagreement of 3×10⁻⁵. A sign error in a quaternion gives a plausible attitude that's wrong, and it wouldn't show up until an airframe was against a wall. This catches it at a desk.
The hardware brought its own lessons before a single flight. The manoeuvre needs motor controllers that can reverse direction quickly, which rules out most off-the-shelf parts. And the first board has no velocity sensor (no optical flow, no GNSS). On a multirotor, an accelerometer mostly measures the vehicle's own thrust, so it can't tell the estimator which way is down during sustained manoeuvres. Without a velocity aid the estimate drifts. That's a hardware decision, not a tuning problem, and it's written down as one.
The product around it
Perch is a pipeline of eight stages: survey, refine, mark, reference, plan, fly, commission and hand off. A site's stage is derived from what exists (a point cloud, marked positions, a flight plan, commissioned devices) and never stored, so it can't drift out of date. A live survey streams from the simulator as server-sent events, and each frame carries only the points captured since the last one; resending the whole cloud every frame would grow quadratically. Real scans can be imported too, from PCD files (including the LZF-compressed variant, whose fields are stored one after another rather than point by point), PLY or XYZ, with no third-party libraries.
What's still open
One known bug, recorded rather than hidden: a deck target approached from below, beside a covered structure, gets routed under the slab, and the drone bonds to the underside about a metre off target. The regression suite never saw it because it launches every run on the side the target faces. Recordings for the website follow the same convention and are checked against the final telemetry, and the bug stays on the list until the suite covers it.
The lab also taught me something about recording. Screen-capturing the simulator gave about ten frames a second, and reading frames back from the GPU cost about 1.5 seconds each. The recorder that works replaces `requestAnimationFrame` and `performance.now` with a virtual clock and renders on the CPU at about 0.05 seconds a frame, so footage is smooth and every run is deterministic.
What I'd keep
Simulation is a design tool, not a certificate. It earns its keep when the harness drives the same code path a real vehicle would, the randomness is seeded, the model's blind spots are written down, and the firmware is checked against it number by number. The rest is flying, which comes next.
---
How this was built. I'm the founder of Continuis Labs. I set the requirements and the test discipline, made the engineering calls, and reviewed and measured the work; AI coding agents (Claude Code among them) wrote much of the simulator, harness and firmware under my direction. Everything in this post is simulation or code. Nothing has flown.
