I’ve recently completed the calibration for my NEO-M8U module and conducted several test runs in a tunnel environment. While the calibration was successful, I am encountering two specific issues during GNSS-denied periods (UDR mode):
Coordinate Clustering (Velocity Lag): The moment the module loses GNSS signal and switches from DGPS to UDR (Untethered Dead Reckoning), the spacing between coordinate points becomes extremely narrow. It seems as if the module is under-reporting the velocity or there is a significant lag in the IMU-based speed estimation.
Exponential Drift after 2 Minutes: The positioning remains surprisingly stable for the first 60–120 seconds. However, after the 2-minute mark, the accuracy drops off a cliff. In the most severe cases, the reported coordinates drift completely off the road and show wildly incorrect positions.
I would like to ask the community:
Are these known technical limitations of the internal IMU when operating in UDR mode (without external wheel-tick/speed pulse)?
Are there any recommended algorithms (e.g., custom Kalman Filter tweaks) or post-processing methods to compensate for this drift during extended outages?
Are there specific “pro-tips” regarding u-center configuration (like Dynamic Model settings) that could improve long-term stability in tunnels?
I have attached a reference image in the original post (or see link below) to illustrate this behavior. Any insights would be greatly appreciated!
UDR for the M8U is capped at about 60 secs of gnss outage/non-signal; losing signal for more than 60 secs is going to become sketchy
Without wheel ticks when the signal is lost the reported location will be drifting at an initially small amount, but because signal is not restored the fusion algorithm readings drift exponentially as fewer gnss-aided points in time are being integrated in the estimate (initially it has a good guess of where it might be, then is guessing based entirely off raw IMU readings (bc no wheel ticks)
each missed GNSS epoch means one fewer constraint on the IMU error states, so the uncertainty ellipse inflates until it’s essentially useless (as above). ADR has wheel ticks to provide an independent velocity measurement, even in tunnels, which bounds that velocity’s error and prevents the “runaway” integration you’re seeing. UDR has nothing to go off of once GNSS cuts out except integrating acceleration twice to get position, which is mathematically brutal :-/
Lag: During the outage, the reported velocity is essentially “frozen” or coasting on stale IMU data while the actual position drifts. When GNSS comes back, the filter has to reconcile:
The reported velocity (which has been wrong/frozen/drifted during outage)
The actual GNSS velocity (instantaneously correct, throws recent readings off, adjusts slowly)
The lag is the EKF’s smoothing period as it drags the velocity state back to reality. If they’ve been in a long outage, that correction might take several seconds because the filter’s uncertainty weighting on the IMU has grown so large. There might be settings for integration cycles or similar to adjust the filter a bit
for my F9R data.