The jump is your dead-reckoning error becoming visible all at once
While GNSS is unavailable, your robot navigates on dead reckoning and accumulates error it cannot see. When satellites return, the estimator corrects to the new global measurement and the whole accumulated error appears as a single discontinuity. A second, smaller jump often follows when the solution transitions from float back to fix. Some correction is unavoidable — what matters is that its size is bounded and that it is reported, not hidden.
Why a jump is worse than a slow drift
Most navigation stacks are built on an assumption of continuity. A path follower computes cross-track error and steers to reduce it; a jump of a metre produces an instant, large cross-track error and a correspondingly aggressive steering command. Behaviour trees re-plan. Geofence logic may trigger. On a machine with real mass, an abrupt correction is visible as a swerve and, near a boundary or an obstacle, is a safety concern rather than a comfort one.
There are usually two separate events, and it is worth distinguishing them in your logs:
- The re-acquisition jump — drift accumulated during the outage is corrected when a global measurement returns. Its size scales with how long the outage lasted and how well your dead reckoning held.
- The float-to-fix jump — the ambiguity resolution completes and the solution shifts from a decimetre-to-metre float position to a centimetre-level fixed one. This one arrives seconds or tens of seconds after the first.
What to check
- Log fix type alongside position. Plot them together. If the discontinuities line up with fix-type transitions, the cause is confirmed and you can stop investigating your controller.
- Is your stack consuming covariance? Many integrations discard it and treat every pose as equally trustworthy. If the positioning system reports its uncertainty and your localisation node ignores it, the estimator cannot weight the new measurement sensibly.
- Measure jump size against outage duration. If a five-second outage produces a metre of jump, dead reckoning is the thing to improve — not the filter tuning.
- Check for a false fix before it. A large jump can also mean the pre-outage position was wrong rather than the post-outage one.
- Look at how the correction is applied. Snapping to the new measurement in one cycle produces the harshest behaviour; a bounded, rate-limited correction is gentler but adds lag. Both are legitimate; the choice should be deliberate.
Mitigations, honestly ranked
Do not simply smooth the output. A low-pass filter on position hides the discontinuity without reducing the error, and adds delay to a signal your controller needs to be timely. It makes plots look better and control worse.
What genuinely reduces the jump:
- Reduce the drift itself. The jump is the drift. Better dead reckoning means a smaller correction — this is where nearly all the available improvement lies.
- Keep partial GNSS in the solution. A tightly coupled estimator can use two or three satellites that could never produce a standalone fix, so the global anchor is weakened during the outage rather than removed. Less divergence, smaller correction.
- Expose uncertainty to the consumer. A navigation stack that knows the position is uncertain can slow down, widen its clearances, or defer a decision instead of steering confidently towards a wrong estimate. Vision-RTK 2's covariance output is designed to be read this way: it is low under an RTK fix, rises gradually through an outage as the solution leans on inertial and visual measurements, and falls again as soon as good signal returns.
- Apply corrections as a bounded trajectory adjustment rather than a teleport, and make the bound a design parameter you have chosen.
What good behaviour looks like
A well-fused system emerging from behind a building should show a small, brief correction rather than a step — because vision and inertial held the trajectory closely enough during the outage that there is little left to correct, and because partial satellite information kept the solution loosely anchored throughout. It is worth being clear about the limit: without any absolute reference, position uncertainty grows without bound. Fusion buys you a far slower growth rate and a much smaller correction, not an exemption. Fixposition's xFusion engine is designed around this: deep fusion of two multi-band RTK GNSS receivers with visual odometry, IMU and optional wheel speed, with global position, orientation and velocity output together with their covariances, so the consuming stack can act on uncertainty rather than being surprised by it.
Frequently asked
Is a position jump ever acceptable?
A small one is unavoidable in any system that fuses dead reckoning with an absolute reference. What should not be acceptable is a jump large enough to destabilise control, or one that arrives with no accompanying uncertainty information.
Should I ignore GNSS for a few seconds after re-acquisition?
It is a common workaround and it does reduce visible jumps, at the cost of continuing to navigate on a solution you already know is drifting. It treats the symptom.
Does a better IMU reduce the jump?
Yes, by reducing the drift it is correcting for — but inertial error grows with the square of time, so the improvement fades quickly as outages lengthen.
Smaller corrections, because there is less to correct. See how Vision-RTK 2 holds the trajectory through GNSS outages.
