GNSS Tunnel Positioning: Why Post-Processing Wins

1 / 3

‹ ›

Part 1 — Why Post-Processing Beats Real-Time (Especially In Tunnels)

Tunnels make one core point very easy to see: post-processing has a structural advantage over pure real-time.

Assume the position error grows quadratically with time while GNSS is unavailable (classic IMU drift behavior in position). Let the tunnel traverse take time T. A real-time (forward-only) solution reaches its maximum error at the exit, call it E_RT,max. At the tunnel midpoint (T/2) you only have a quarter of that: E_RT,mid = ¼ · E_RT,max.

Now in post-processing we can also run the estimator backwards in time. At the midpoint we have two estimates with similar uncertainty (one from the forward pass, one from the backward pass). Combine them, and the standard deviation reduces by √2 (two independent estimates of equal variance). So the maximum post-processed error occurs at the midpoint and is:

That is the clean math picture. In practice, the gap often widens further: robust outlier handling, model consistency checks, and bi-directional integer fixing typically cut the effective error to 10% or even ~1% of a comparable real-time result on hard segments.

“Use a real-time solution only when you truly need real-time. If you can process offline, do it — you get a large, structural accuracy win for free.”

Part 2 — Tunnel ≠ Hardest Algorithmic Case. Exits Are.

Many teams treat tunnels as the ultimate algorithm challenge. Reasonable at first glance: no GNSS, so IMU drift accumulates. Our view is different:

• Inside the tunnel: The algorithmic picture is actually simple: you integrate IMU (plus odometry, motion constraints). Stability is set by sensor quality and correct stochastic modeling.
• The real fight: The algorithmic fight happens at dense entrances/exits. You leave the tunnel with large state uncertainty and immediately face urban canyon visibility with many potential outliers — but not much redundancy to separate good from bad.

The AlgoNav Strategy For Tunnel Transitions

To handle this, you need logic that goes beyond a forward Kalman filter:

1. Iterative outlier detection: Use an optimal smoother (e.g., RTS) over a window spanning before and after the exit to re-evaluate residuals.
2. Smoothing-stage ambiguity fixing: Allow bi-directional/lagged fixing inside the smoothing pass. Short clean windows after the exit can “reach back” and lock ambiguities earlier.
3. Reliability before availability: Right after the exit, cap measurement influence in weak directions and use MDB-aware gating.
4. Tightly-coupled fusion: Feed raw carrier/code + IMU jointly to shrink the integer search space.
5. Deferred optimism: First stabilize, then go aggressive with fixing and tighter weights as confidence grows.

What We See In Data

• Inside tunnels: Smooth IMU/odo propagation; covariance grows as modeled; no algorithmic drama.
• Exits into dense streets: First GNSS samples are a mix — some clean, some multipath. Forward-only filters either over-trust or over-reject.
• With smoother-based reweighting and lagged fixing, the solution stabilizes within a few seconds without lateral jumps.

Practical Takeaways

• Post-processing is structurally stronger: Midpoint error at ~17.7% of real-time’s worst case.
• The exit is the algorithm test, not the tunnel itself.
• Use smoother-driven, iterative outlier logic around exits.
• Perform ambiguity fixing during smoothing, not just online.

What This Means For Your Projects

If you can run post-processing, do it. You’ll get smaller errors exactly where you fear them most. If your routes include tunnel exits into dense city, invest in smoother-based outlier handling. That’s where robustness is won.