Virtual GPS vs. Optical Flow: A Deep Dive

The "Indoor Problem"

When GNSS signals (GPS/Galileo/BeiDou) are blocked by concrete or steel, drones lose their absolute positioning. To prevent a failsafe (switching to AltHold or Land), the autopilot needs an alternative source of X/Y velocity or position data. The two most common solutions are Optical Flow and Virtual GPS (Network Fusion).

While both enable non-GPS flight, they rely on fundamentally different physical principles and suffer from opposing failure modes. This guide breaks down the architectural differences to help you choose the right tool for the job.

Architectural Comparison

Feature	Optical Flow	Virtual GPS (Network Fusion)
Data Type	Relative Velocity (AID_RELATIVE)	Absolute Position (AID_ABSOLUTE)
Primary Sensor	Downward-facing Camera	WiFi / Cellular Radio
Environment Req	Textured Surface, Light	WiFi Access Points, Cell Towers
Failure Mode	Darkness, Smooth Floors, High Speed	Faraday Cages, Remote Areas
EKF Handling	Secondary Aiding	Primary Source (Treated as GPS)

Why Optical Flow Fails

Optical Flow sensors (like the ThoneFlow, HereFlow, or PX4Flow) calculate velocity by tracking the movement of contrast features (pixels) on the ground. They are essentially low-resolution cameras running a continuous image processing loop.

1. The Texture Trap

The underlying algorithm (often Lucas-Kanade) requires "features"—distinct points of contrast—to track frame-to-frame.

• The Physics: If you point a camera at a white wall and move it, the image doesn't change. The algorithm sees zero pixel displacement and reports zero velocity, even if the drone is drifting at 2 m/s.
• The Code: The EKF3 (Extended Kalman Filter) monitors a metric called surface_quality (or SQUAL). In AP_NavEKF3_Measurements.cpp, the EKF has a hard gate: if surface_quality drops below a threshold (often 0), the measurement is rejected entirely.
• The Reality: Shiny floors (gymnasiums), water, or uniform concrete (warehouses) have "low texture." The camera sees a uniform blur. With no features to track, surface_quality drops, and the EKF rejects the data, causing a "loss of navigation" failsafe.

2. The Lighting Constraint

Flow sensors are passive cameras. They need photons to generate contrast.

• The Reality: Flying at night, in dim warehouses, or under bridges often provides insufficient light for the sensor's electronic shutter speed to freeze motion. The result is motion blur, which destroys feature tracking.

3. Motion Limits

• The Code: The EKF3 has a hard-coded gate for angular rates. If the gyro reports rotation > 4.2 rad/s, flow data is ignored.
• The Reality: If the drone yaws or pitches too aggressively, the pixel motion blur exceeds the sensor's correlation capability. The EKF stops trusting the sensor precisely when you need it most (during a rapid maneuver).

The Virtual GPS Advantage

"Virtual GPS" bypasses the visual spectrum entirely by using the RF (Radio Frequency) spectrum. It injects position data directly into the EKF's top-tier logic.

1. The EKF Hierarchy (AID_ABSOLUTE)

ArduPilot's EKF3 uses a state machine to decide which sensor to trust.

• Priority 1: GPS (AID_ABSOLUTE) - The preferred mode. It constrains both position and velocity drift.
• Priority 2: Optical Flow (AID_RELATIVE) - A fallback mode. It only constrains velocity. Position is estimated by integrating velocity, which accumulates error (drift) over time.

Virtual GPS provides AID_ABSOLUTE data. This means the EKF treats it with the same high priority as a real u-blox GPS module. It does not "downgrade" to relative navigation; it stays in the highest accuracy mode.

2. Immune to "Visual" Noise

• Darkness: WiFi signals penetrate darkness. You can fly in pitch black.
• Texture: WiFi signals don't care if the floor is shiny, matte, or liquid.
• Smoke/Dust: In emergency response (fire/rescue), smoke obscures optical sensors. RF signals punch through smoke, allowing for reliable positioning in low-visibility environments.

3. Scenario: The Warehouse Transition

Imagine a drone flying from a well-lit loading dock into a dark, unlit aisle.

• With Optical Flow: As the drone enters the dark aisle, surface_quality drops. The EKF rejects the flow data. The drone enters "Dead Reckoning" mode (AID_NONE), rapidly drifting until it hits a rack.
• With Virtual GPS: The phone continues to see the WiFi Access Points through the walls. The position fix remains valid. The EKF stays in AID_ABSOLUTE mode, and the drone holds its position in the dark aisle.

Source Code Reference

• Aiding Mode Logic: libraries/AP_NavEKF3/AP_NavEKF3_Control.cpp - See setAidingMode and the preference for readyToUseGPS() over readyToUseOptFlow().
• Flow Gating: libraries/AP_NavEKF3/AP_NavEKF3_Measurements.cpp - See writeOptFlowMeas and the surface_quality check.