GPS-denied navigation
Optical flow, lidar or visual odometry: holding position when GPS is unavailable
Indoors, under a bridge, inside a tank or between tall buildings, the position a GNSS receiver was giving 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 added up over time drifts without limit.
No engineering removes that; it is how these sensors work. That sets a realistic goal for a GPS-denied system: "hold position well enough, for long enough, to do the job, and know what happens when the estimate gets worse". Navigating as if GPS were there is not realistic. 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 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, which is different from altitude: fly over a table and the reading jumps 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. You need both.
Visual odometry, including the visual-inertial kind running on a companion computer, estimates the change in full position and orientation between camera frames, so it gives translation and rotation as well as 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 why the others exist: each one corrects the inertial estimate more often than the IMU alone could manage.
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, such as a corridor of identical panels, because it cannot tell one frame's features from the next. 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. So choose by describing the surface, lighting and movement at your site and ruling sensors out on that basis. Headline specifications will not decide it.
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 full position and heading, beyond holding station: following a path, mapping, or 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 gets worse (hold, descend or land) and test it by covering the sensor in flight, at a safe height, over a surface you are happy 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 surface on site with the least texture.
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 choose the parts and the firmware together.
The GPS-denied sensors in our shop
Sensing element, what it measures and the interface are from each product's own listing. These three are not alternatives: the flow sensor and range sensor are usually fitted together. Read the last column 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 in our shop; a dash means the listing does not state it. Range, field of view, minimum illumination and supported firmware versions are not published here, and they 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
The left column is what the hardware produces; the right is what the estimator has to work out from it. The gap between the two columns is why a GPS-denied system is specified as a duration and a tolerance, and not as a single accuracy figure.
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 listed in the Vebix Automation shop.
- The difference between absolute and relative measurement, optical flow's need for height and attitude, and the environmental failure modes described here are standard navigation sensor behaviour. They are engineering method, not any manufacturer's claim.
- No range, field-of-view, illumination or accuracy figure is stated for any of these parts: they are not in the product listings we hold, 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 suggested test procedure. They are not results from a Vebix Automation test.
Published 9 September 2026. Last revised 9 September 2026. Corrections to sales@
More in UAV avionics
Other guides on this subject.
Talk to an engineer
Specifying a GPS-denied platform?
Send the surface, lighting and height range you will fly in, the flight duration, whether you need to hold station or follow a repeatable path, and your autopilot and firmware. We will reply with a shortlist of compatible parts. Request a component quotation for supply in India.
- sales@
vebixautomation.com - Phone
- +91 97028 20020