GPS-denied navigation
Optical flow, lidar or visual odometry: holding position when GPS is unavailable
Indoors, under a bridge, inside a tank or in an urban canyon, the position estimate a GNSS receiver was providing simply stops. The sensors offered as the answer measure four different things, none of which is a position, and choosing between them starts with being precise about that.
None of these is a replacement for a position fix
This is the misconception that wastes the most money, so it is worth stating first. A GNSS receiver provides an absolute position: it is wrong by some amount, but the error does not grow the longer you fly. Everything in this article is a relative measurement — a rate, or a change since the last frame — and a relative measurement integrated over time drifts without bound.
That is not a defect to engineer away; it is what the sensors are. It sets the honest goal for a GPS-denied system: not "navigate as if GPS were present", but "hold position well enough, for long enough, to do the job, and know what happens when the estimate degrades". A quadcopter that holds station indoors for a ten-minute inspection is a solved problem. One that flies a repeatable surveyed path through a building for an hour on the same sensors is not.
So write the requirement as a duration and a tolerance before comparing parts. Hold within a metre for the length of one battery, indoors, over a textured floor is a specification. Works without GPS is not.
What each one actually measures
A downward range sensor — a lidar or a time-of-flight module — measures the distance to whatever is directly beneath the aircraft. That is height above the surface, not altitude: fly over a table and the reading steps by the height of the table. It is the most reliable of these measurements and the least ambitious.
An optical flow sensor measures how fast the image beneath it is moving, in angular terms. On its own that is not a velocity: rotating on the spot produces flow with no translation, and the same angular rate means a slow drift at one metre and a fast one at ten. It becomes a horizontal velocity only when combined with a height from the range sensor and the attitude from the autopilot's gyroscopes. Optical flow and a range sensor are one measurement in two parts, not two options.
Visual odometry — including the visual-inertial variety running on a companion computer — estimates change in full pose between camera frames, so it gives translation and rotation rather than just velocity. It is far more capable and far more demanding: it needs compute, calibration, and a scene with enough persistent visual structure to track.
The inertial measurement unit in the autopilot is already measuring acceleration and rotation rate. It drifts fastest of all, which is precisely why the others exist: each of them corrects the inertial estimate at a rate the IMU alone cannot sustain.
Where each one fails, and the failures are environmental
Optical flow fails on surfaces with no texture to track: a clean concrete slab, still water, fresh snow, a polished factory floor. It fails in low light, because the sensor needs exposure like any camera. It degrades as height rises beyond the range sensor's reach, at which point the velocity it reports is being scaled by a height the aircraft no longer knows.
Time-of-flight range sensors have their own surface problem, and it is the mirror image: they mismeasure surfaces that absorb or scatter the beam, and they can be defeated by bright sunlight on a reflective floor. Over vegetation the return may come from the canopy or the ground depending on the moment.
Visual odometry fails on repetitive scenes — a corridor of identical panels — because frame-to-frame matching becomes ambiguous. It fails on rapid motion that blurs frames, and it fails when the scene itself moves: a room full of people, or a boat deck.
The pattern is worth internalising: these sensors do not fail randomly, they fail by environment. Which means the way to choose is to describe the surface, the lighting and the motion of your actual site, and rule out on that basis, rather than comparing headline specifications.
A stack that works, and the order to build it in
For most indoor and low-altitude work the practical arrangement is the autopilot's own IMU, plus a downward range sensor, plus an optical flow sensor, fused by the flight stack's estimator. That combination holds position over a textured floor at modest height and is the least complex thing that does so.
Add visual odometry from a companion computer when the mission needs pose rather than station-keeping — following a path, mapping, returning to a specific point. That is a materially larger integration and our companion computer guide covers the responsibility split, the power arrangement and the bench tests it needs.
Build it in that order, and test each stage before adding the next. A common failure is fitting flow and vision together, finding the aircraft drifts, and having no way to tell which subsystem is responsible. Range sensor first: confirm it reports sensible height over your actual floor. Then flow: confirm reported velocity matches a measured translation. Only then the vision stack.
Whatever the combination, configure the failsafe deliberately. Decide what the aircraft does when the estimate degrades — hold, descend, land — and test that behaviour by covering the sensor in flight, at a safe height, over a surface you are willing to land on.
A bench and flight check that separates the subsystems
1. Range, static. With the aircraft held at measured heights over your actual operating surface, confirm the reported distance matches. Repeat over each surface the mission includes.
2. Range, dynamic. Walk the aircraft over the obstacles it will fly over and watch for step changes. This is where you find that the sensor is reading the top of a workbench.
3. Flow, translation. Move the aircraft a measured distance at a measured height by hand and compare the integrated velocity against the tape measure. Do it over the worst-textured surface on site, not the best.
4. Flow, rotation. Rotate on the spot without translating. Reported horizontal velocity should stay near zero; if it does not, the attitude compensation is not working.
5. Lighting. Repeat step 3 at the lowest light level the site will present. Optical flow degrades before a person notices the room is dim.
6. Failsafe. In flight, at a safe height, occlude the sensor and confirm the configured behaviour happens. This is the test people skip and the one that matters.
Log the estimator's own health and innovation outputs throughout, and keep the logs: the difference between "it drifted" and "it drifted because flow quality collapsed at 40 lux" is the difference between a fixable problem and a mystery.
What to send with an enquiry
The surface you will fly over and its texture, the lighting, the height band, the flight duration, whether you need station-keeping or a repeatable path, your autopilot and firmware, and whether a companion computer is already in the design.
That last pair matters more than the sensor choice. Which sensors a given flight stack supports, on which ports, changes between releases, so the parts and the firmware have to be chosen together rather than in sequence.
The GPS-denied sensors in this catalogue
Sensing element, what it measures and the interface are from each product's own listing. These three are not alternatives to each other — the flow sensor and the range sensor are usually fitted together — so read the last column before the first.
| Product | Sensing element | Measures | Role in the stack |
|---|---|---|---|
| PMW3901 Optical Flow Sensor | PMW3901 | Optical flow — angular rate of image motion | Horizontal velocity, only when combined with a height source and attitude |
| ST VL53L1X Lidar | VL53L1X | Distance, by time of flight | Height above the surface below; also the scale factor the flow sensor needs |
| H-Flow | — not stated in the listing | Optical flow module | Flow and ranging in one module. Confirm the sensing elements and interface against the datasheet |
Sensing element, measurement and interface are as stated in each product listing held in this catalogue; a dash means the listing does not state it. Range, field of view, minimum illumination and supported firmware versions are not published here and are the figures that decide whether a sensor suits your site — ask us for the datasheet for the exact part number. Which sensors a flight stack supports, and on which ports, is release-specific: check your firmware's own documentation for the version you intend to fly.
Four measurements, none of them a position
Read the left column as what the hardware actually produces, and the right as what the estimator has to construct from it. The gap between the two columns is why a GPS-denied system is specified as a duration and a tolerance rather than as an accuracy.
Products discussed
The parts this guide names.
Specifications on each page are the manufacturer's. Confirm the exact variant and document revision before ordering.
PMW3901 Optical Flow Sensor
Optical flow. Needs a height source to become a velocity.
ST VL53L1X Lidar
Time-of-flight range sensor, and the height source flow needs.
Holybro H-Flow
Flow and ranging in one module; confirm the elements on the datasheet.
Pixhawk 6X
The autopilot whose estimator fuses these with its own IMUs.
All Holybro sensors
Airspeed, compass, optical flow and ranging.
Sources & basis
What this is based on.
- Sensing element, measurement type and interface for the PMW3901, VL53L1X and H-Flow as published in the Vebix Automation catalogue.
- The distinction between absolute and relative measurement, the dependence of optical flow on a height source and attitude, and the environmental failure modes described here are standard navigation-sensor behaviour, stated as engineering method rather than as any manufacturer's claim.
- No range, field-of-view, illumination or accuracy figure is stated for any of these parts: they are not held in this catalogue and are not reproduced from a similar product. Which sensors a given flight stack supports is release-specific and must be read from that firmware's own documentation for the version being flown.
- The bench and flight checks are a proposed test procedure, not a reported Vebix Automation test result.
Published 9 September 2026. Last revised 9 September 2026. Corrections to sales@
Talk to an engineer
Specifying a GPS-denied platform?
Send the surface, lighting and height band you will fly in, the flight duration, whether you need station-keeping or a repeatable path, and your autopilot and firmware — and we will return a compatible component shortlist. Request a component quotation for supply in India.
- sales@
vebixautomation.com - Phone
- +91 97028 20020