Pre-Processing and Sensor Strategy: The Work That Happens Before Fusion

The Pre-Processing Problem

Picture a delivery robot navigating downtown. Your GNSS receiver is tracking 15 satellites. Sounds great. But four of those signals are arriving alongside multipath reflections from a glass building. The direct signal and the reflected signal combine in weird and unpredictable ways that corrupt the measurement by some degree. Two more satellites? The direct signal from one is completely blocked by a tall building. The only thing you see is multipath bouncing off somewhere else—which is definitely not correct, but it may not be obvious that’s what’s happening.

Your carrier phase measurements are precise to fractions of a centimeter—when they’re tracking correctly. But you just drove under a bridge. The signal dropped for half a second. When it came back, the carrier phase count jumped by an unknown number of full wavelengths. Your centimeter-level precision just became a meter-level error.

Your wheel speed sensor is reporting motion. But is it accurate? The tire pressure dropped overnight—now the wheel radius is different than what the system expects. You’re accelerating hard and one wheel is slipping. Or you’re moving slowly and the sensor has a dead-band—it reads zero when the speed is low but not actually zero. Sensor noise on top of all of that.

Your IMU is sampling at 3,000 Hz. But it’s mounted on a chassis with an electric motor. Engine vibration is creating high-frequency noise that has nothing to do with vehicle motion.

If you fuse all of this raw data as-is, your position solution will be degraded.

GNSS Pre-Processing: LOTS Going On

The GNSS data has a LOT going on. And pre-processing is looking for noise on the measurements—things that corrupt the signal before it reaches the fusion algorithm.

Multipath and NLOS (Non-Line-of-Sight) Detection

Multipath is when GNSS signals bounce off objects before reaching your antenna. The reflected signal travels farther than the direct signal. Your receiver thinks the satellite is farther away than it actually is.

Urban environments are brutal. Glass skyscrapers reflect signals like mirrors. Parking structures have concrete on all sides. Even open areas can have multipath from parked vehicles or metal fences.

The challenge: it’s actually even worse than this typically. Most multipath isn’t from so far away that your receiver can distinguish between the direct path and the multipath bounce. In practice, most multipath is just slightly delayed and ends up combining with the direct path. Your receiver tracks a weird combination of the two that changes rapidly. It will have strange characteristics that may stand out as bad some of the time, but can also look totally legitimate while introducing a significant amount of position error.

Extremely long bounces are slightly easier for the receiver to detect if it’s smart enough, though it may not be. In the case that it doesn’t get it right though, generally those measurements are likely going to be so out of character compared to the other measurements that they’ll stand out. It’s the closer-in multipath that’s the real problem.

Then there’s non-line-of-sight (NLOS) signals. That’s when a building or some other obstruction—for example, a tall truck—blocks the direct path and all you see is the multipath. In that case, you don’t have a weird combination of signals or two signals that are far apart. You just get a single delayed signal that otherwise might look totally normal. It may have lower-than-expected power some of the time, but have a totally normal-looking power level at other times, and many of the other characteristics of multipath signals may not appear either.

Our approach: analyze signal characteristics that multipath affects differently than direct signals. When a signal looks suspicious—signal strength fluctuating or lower than expected for that satellite elevation, observations inconsistent with each other, etc.—we will flag it.

What happens next depends on the severity. The system might discard it, especially if it has plenty of trustworthy measurements. Or it may choose to use it but de-weight it.

In severe multipath environments, this might mean preferring four clean satellites over twelve contaminated ones.

Environment Detection

Related to multipath detection, but broader: inferring your physical context from signal quality.

Open sky with strong signals from many satellites? You’re probably on a highway or open field.

Signals dropping intermittently? Probably driving under tree cover.

Urban canyon? You’ll see a few reasonably strong signals at high elevations mainly, but not as many as in the open sky because some will be blocked by buildings. Few signals at low elevations since everything is blocked—and when you do see low-elevation signals, you’re either seeing multipath bounces or, if you see a direct path, it’s only up and down the streets.

Weak signals from few satellites at low elevation angles—and not much at high elevation either? Possibly under an overpass or inside a parking structure.

Why this matters: it lets the system adjust trust levels and strategy adaptively. In the open sky, we can be more aggressive with GNSS. In a canyon, we rely more heavily on other sensors—IMU, wheel speeds, and vision.

And it’s not entirely true that the fusion algorithm downstream doesn’t need to know what type of environment you’re in. In some cases, it may actually be helpful to know—to the best of our ability, that is. A parking deck with open sides may look similar to a road underneath an elevated highway. The navigation engine might decide to take different actions if you’re driving under an overhead highway than if you’re driving in an urban canyon. For instance, adjusting which elevations it considers or how it weights the measurements.

Cycle Slip Detection

Carrier phase measurements are how you get centimeter-level precision. Instead of measuring the time a signal traveled (pseudorange, good to ~1 meter), you measure the phase of the carrier wave itself.

The L1 GPS signal has a wavelength of about 19 centimeters. If you can track the phase, you can measure distance to fractions of that wavelength. That’s how RTK gets to 1-3cm accuracy.

The problem: you don’t know which cycle you’re on. You could be exactly 10,000 cycles away from the satellite, or 10,001 cycles. Even after you finally figure it out (which is a whole separate challenge), if the signal drops briefly—drive under a bridge, lose lock for half a second—when it comes back, the receiver might have miscounted the cycles.

A cycle slip. Your measurement is now wrong by an integer number of 19 cm jumps.

Cycle slip detection monitors carrier phase measurements for these discontinuities. When we detect a slip, we have to re-resolve the ambiguity (which ties back to the RTK fixing process we’ll cover in a later post). Until that’s resolved, we can’t use that satellite’s carrier phase for precision positioning.

This is the kind of error that’s silent if you don’t check for it. The individual measurement will be wrong, and combined with the other measurements it will corrupt the position in weird ways. It might not affect things much and the position could still be fine, or it could be really inconsistent with everything else and push the position many centimeters or even meters away.

IMU Pre-Processing: Filtering Motion from Noise

Coarse Alignment

When you install a positioning device in a vehicle, you can’t guarantee perfect alignment. The IMU might be mounted upside down. Rotated 90 degrees. Tilted at an odd angle because of how the enclosure fits in the vehicle.

The IMU itself doesn’t know. It just reports acceleration and rotation in its own body frame. If it’s upside down, “up” acceleration looks like “down.”

Coarse alignment corrects for this at the 90-degree level. The user tells the system the orientation in 90-degree increments, and the system applies the appropriate rotation. All IMU data gets rotated into the vehicle’s coordinate frame before fusion. “Forward” means forward for the vehicle, not forward for however the IMU happened to be installed.

But that’s not the end of it. There are still finer-grained angular errors to account for:

Fine alignment handles the degrees of error that add up from multiple sources: you didn’t install the device perfectly and it’s off by a degree. The IMU wasn’t soldered to the circuit board perfectly and it’s off by another degree. The MEMS (Micro-Electro-Mechanical Systems) components inside the IMU itself aren’t perfect and are off slightly too. All of that adds up to degrees of error in each axis.

The system learns these errors over time during the initial calibration period—really tens of minutes of driving. While the system performs this calibration and applies corrections within the navigation engine, the result is the same: accurate orientation estimates despite imperfect installation.

There’s another related problem the system has to solve: IMU sensor measurement errors. Each axis might have a bias—so instead of reading 0 when you’re stationary, it might report 0.5 m/s². Or it may have a scale factor error—so when you accelerate by 1 m/s², it changes by just 0.9 m/s². Those errors are unknown and vary by device, and also change with temperature and time. The system has to constantly account for them.

Downsampling and Vibration Filtering

High-end IMUs sample at 3,000 Hz or more. That’s 3,000 measurements per second.

Most of that high-frequency content isn’t vehicle motion. It’s engine vibration. Chassis resonance. Road texture. Noise.

If you integrate raw 3,000 Hz IMU data, you’re integrating noise. Position drifts. Velocity estimates get corrupted.

Downsampling filters this out. We take the 3,000 Hz signal, low-pass filter it to remove frequencies above what the vehicle can physically generate, and downsample to something like 100 Hz.

Now you’ve got IMU data that represents actual vehicle dynamics, not vibration.

The trick: you need to know what frequency content is signal vs noise. A race car can generate dynamics at higher frequencies than a delivery robot. An aircraft has different vibration profiles than a car. Platform-specific filtering matters.

This is one reason the Indy Autonomous Challenge cars wanted 800 Hz IMU output. At racing speeds with extreme vibration, downsampling too aggressively loses real dynamics. Our standard 100 Hz output wasn’t capturing the motion they needed.

The Underrated Sensor: Wheel Odometry

Wheel odometry is one of the most underrated sensors in positioning. You get tremendous value even from a single wheel speed input.

Here’s why: wheel speeds work perfectly in tunnels and parking garages where GNSS fails. And GNSS doesn’t care about tire pressure or wheel slip—it measures absolute position from satellites regardless of road surface conditions.

They fail in opposite ways.

GNSS measures absolute position from satellites. It doesn’t care if you’re on ice or asphalt. But it breaks in urban canyons, under bridges, indoors.

Wheel speeds work perfectly in tunnels and parking garages. But they’re sensitive to tire diameter, wheel slip, and road surface.

When you combine them, you get a system that’s robust across environments. GNSS coverage drops in a tunnel? Wheels keep tracking. Wheels start slipping on ice? GNSS corrects.

Even single-wheel speed—just one wheel encoder—provides valuable forward velocity information. Two wheels give you differential motion for heading. Four wheels and you can detect individual wheel slip.

The fusion algorithm learns wheel scale factors over time (actual tire radius vs nominal), compensates for slip, and uses wheel speeds as a complementary sensor to GNSS and IMU.

Generally speaking, any sensor is better than not having a sensor, even if it’s noisy or not always available. The bare minimum is typically GNSS + IMU. The IMU is the glue that holds all the other sensors together. From there, adding wheel speeds, vision, or other complementary sensors makes the system more robust across different failure modes.

Plan for Implementation Complexity

Pre-processing sounds straightforward. In practice, it’s full of edge cases:

Multipath in dynamic environments: That glass building was behind you a second ago. Now it’s to your left. Are you backing up and maybe the building is ahead of you? Multipath patterns change constantly. Detection needs to adapt in real-time.

IMU temperature effects: A cold IMU behaves differently than a hot one. Temperature affects the IMU’s MEMS components and changes how they drift. Your filtering strategy needs to account for this.

Wheel slip detection: How do you distinguish wheel slip from actual acceleration? If all four wheels slip together (ice), you can’t detect it from wheel speeds alone—you need GNSS or IMU to catch it.

Sensor dropout: What happens when a wheel encoder fails mid-drive? When half your GNSS satellites disappear behind a building? The system needs to gracefully degrade, not catastrophically fail.

Computational constraints: Running multipath detection across 20 satellites at 10 Hz, cycle slip monitoring on carrier phase, vibration filtering at 3,000 Hz—this all requires processing power. Embedded systems have tighter constraints than larger computers.

These details vary enormously by platform and deployment environment. There’s no universal answer.

Questions Worth Asking

If you’re building your own positioning stack or evaluating a commercial solution:

• How does your system detect multipath vs clean GNSS signals?
• What happens when the carrier phase slips? How quickly do you re-resolve ambiguities?
• Can your IMU pre-processing adapt to changing temperature (e.g., warming up the car on a cold day)?
• Do you account for environment-specific error characteristics (urban vs open sky)?
• Can you process wheel speeds from non-standard sensors (CAN bus, direct encoder taps, single wheel)?
• What’s your computational footprint for pre-processing? Can it run on your target hardware?
• How does the system handle partial sensor failures (one wheel encoder down, half the satellites blocked)?

These questions don’t have universal answers. But they’re worth asking.

What’s Next

Pre-processing gives you clean, characterized measurements. But they still need to be combined intelligently.

In the next post, we’ll cover the fusion algorithm itself—how the estimator weighs different sensors, handles outliers, models vehicle dynamics, and learns sensor errors in real-time.

Because getting clean data is only half the problem. Knowing what to do with it is the other half.

This is Part 2 of our series on positioning system architecture. Part 1 covered time synchronization and the P1 time architecture. Read Part 1 here.