How Sensor Fusion and Reusable Checkpoints Improve Indoor Positioning
GPS is often unreliable inside large buildings, and motion sensors drift over time. Learn how inertial tracking, visual landmarks and reference checkpoints can work together to support indoor navigation—and where engineering validation is still necessary.
What is sensor fusion in indoor positioning?
Sensor fusion combines multiple imperfect signals into a more useful estimate of position, heading and movement. A smartphone may provide accelerometer, gyroscope and magnetometer readings, GPS where available, and—in some devices—a barometric pressure sensor. None is sufficient on its own for robust navigation across a complex building.
The purpose is to combine information while accounting for uncertainty. Inertial measurements can estimate relative motion; occasional trusted reference points can correct the accumulated error. A navigation engine should also understand which paths are physically possible instead of letting a position estimate jump through walls.
Accelerometer and gyroscope signals help estimate device motion, turns and step events, subject to phone orientation and sensor quality.
Recognised visual or known-location checkpoints can constrain the position estimate and help reset accumulated drift.
Known navigable areas, entrances and floor-transition points can reduce implausible guidance when suitable venue data exists.
Why pedestrian dead reckoning drifts
Pedestrian dead reckoning (PDR) estimates movement from a starting location using detected steps, step length and heading. A tiny heading error, repeated over many movements, can put the estimated route on the wrong side of a corridor or even a different shop. Carry position, pocket placement, magnetic interference and lift movements introduce further uncertainty.
Filtering techniques such as Kalman-family estimators can balance signals and uncertainty, but filters alone do not guarantee centimetre-level accuracy. External corrections, sensible motion models and repeatable testing are essential.
How reusable visual checkpoints can reduce drift
A reusable checkpoint is an identifiable reference associated with a verified location. Examples might include a stable shop sign, an approved landmark image or another known reference. When the app reliably recognises a checkpoint, the system can use that observation to update its estimated position.
- Create a known reference: Record the landmark, coordinate, venue and floor, plus evidence of reference quality.
- Detect the reference: Use an appropriate visual recognition method, with checks for false matches, changes in lighting and viewpoint.
- Correct the estimate: Combine the observed landmark with the current motion estimate rather than assuming every detection is perfect.
- Reuse and maintain: Validated landmarks may support other routes or users; changed signage and stale coordinates need review.
IGC's location-based loyalty ecosystem creates an interesting path to collecting and refining reference locations over time. However, user activity alone does not establish a survey-grade coordinate; reference accuracy and recognition performance should be validated before production use.
How does a phone know which floor it is on?
A barometer can detect small air-pressure changes associated with vertical movement where the device provides a suitable sensor. Combined with motion patterns and known stairs, elevators or escalators, this may help classify a floor transition. Absolute floor identity typically still requires a calibrated reference, venue context or a recognised checkpoint.
Not every handset includes a barometer. Developers should design fallback behaviour, communicate uncertainty and test elevators, escalators, stairwells and open atriums separately. Emergency or safety-critical routing needs independent verification and must not rely on unverified positioning estimates.
What is different about the IGC Fusion approach?
IGC Nav is being positioned around beacon-free indoor positioning APIs, reusable checkpoints and developer-first integrations. This aims to reduce the need for dedicated radio-beacon installations and repetitive sensor-fusion development within each app. It does not mean that every location is mapped automatically, that no venue setup is needed, or that all features are available on every phone.
For the current, implemented API surface and operational requirements, review the live endpoint documentation. For a product-focused introduction, see the Indoor Navigation API Without Beacons developer guide.
How to test accuracy honestly
Performance should be validated with repeated, independently checked reference locations—not a single best-case measurement. Log the test device, floor, route, raw and fused estimates, recognition events and expected ground-truth positions.
| Metric | Why it matters |
|---|---|
| Median error | Typical horizontal positioning performance |
| 95th-percentile error | How badly location can deviate in difficult cases |
| Drift over distance/time | How error grows between reliable references |
| Floor classification accuracy | Reliability of selecting the correct level |
| Checkpoint precision/recall | False landmark recognition and missed corrections |
| Route completion and safety checks | Whether the guidance gets users to reachable destinations safely |
IGC has described ambitious indoor-accuracy targets, but those numbers should not be treated as universal guarantees without published device- and venue-specific results. Good technical documentation should distinguish design targets, internal observations and independently repeatable production measurements.
What can a developer integrate?
Start with the IGC Nav API reference to confirm authentication, request parameters and available endpoints. Because this is an API-first approach, integration can be considered from Flutter, Unity, React Native, native Android/iOS or a compatible backend where supported. This does not imply a published, native SDK exists for every language.
Frequently asked questions
Can sensor fusion replace GPS indoors?
It can help estimate movement where GPS is unreliable, but it requires reliable initialisation and reference corrections to limit drift.
Are Bluetooth beacons necessary for indoor navigation?
No. Inertial, visual and other software-based signals may provide an alternative, with trade-offs involving venue setup, lighting, device support and accuracy.
What is the difference between OCR and visual landmark recognition?
OCR extracts text from scenes such as store signs; image-feature methods can match visual structure. Each has different failure modes and requires carefully validated references.
Does reusable checkpoint positioning require floor plans?
Reference recognition and routing are different tasks. Safe route computation generally needs navigable path information and floor transition points, even without installed beacons.
Can every phone provide multi-floor positioning?
No. Sensor availability varies, especially for barometric pressure measurements, so fallback strategies and per-device validation are important.
Explore the IGC Nav developer API
Learn what the current service supports, then test a representative venue and device set before deployment.