TLDR: Pre-processing prepared your measurements. Time synchronization aligned them to a common time base. Now what? The navigation engine is where sensor fusion actually happens—combining noisy GNSS, drifting IMUs, and imperfect wheel speeds into a coherent position estimate that updates 10-100 times per second. The key to precision isn’t perfect measurements—it’s how you correct incorrect measurements. Here’s how the estimator weighs different sensors, learns their errors in real-time, and adapts to different vehicle dynamics.
Your measurements are clean. Pre-processed GNSS with multipath detection. Downsampled IMU data with vibration filtered out. Wheel speeds from all four corners. Everything synchronized to a common time base and arriving in the correct order.
You feed it all into your navigation engine and it works. Position updates smoothly. Velocity estimates track reality. The system holds centimeter-level accuracy through downtown, under tree cover, in parking garages.
Until you deploy the same code on a different platform. A delivery robot using the filter tuned for a sedan. An agricultural robot running dynamics models designed for a drone. Performance degrades.
The navigation engine isn’t just math. It’s the integration of measurement modeling (comparing expected vs actual sensor readings), sensor error learning (correcting for biases and drift), and platform-specific dynamics (understanding how different vehicles move).
Understanding how these pieces work together is essential for building production-grade positioning systems.
Time Alignment: Putting Chaos Back in Order
Time alignment reorders asynchronous sensor data so measurements can be processed in the sequence they actually occurred.
The GNSS receiver captures a measurement and transmits it 50 milliseconds later. The IMU streams data every 10 milliseconds at 100 Hz. Wheel speeds arrive at 20-50 Hz with variable CAN bus latency. Everything arrives in random order.
You can’t operate a system if your data is random. The big challenge in a real-time system is every sensor is different—data generation and transmission times vary, so measurements arrive in somewhat random order.
Remember P1 time from Part 1? The time provider coordinated timestamps across GNSS time, IMU clock time, and wheel speed timestamps. Now time alignment uses those timestamps to reorder measurements—putting them back into the sequence they actually occurred in the real world.
The naive approach drops late arrivals. But that impacts performance—you’re throwing away valid measurements because they arrived a few milliseconds late.
A lot of positioning engines actually fail due to poor time alignment. Not necessarily the algorithms themselves, but if you don’t get this properly aligned, you’re in a mess of trouble.
Once the data is in order, it flows into the actual navigation engine. This is where fusion happens.
Measurement Modeling: Expected vs Reality
Measurement modeling predicts what each sensor should measure given the current position estimate, then compares predictions to actual measurements. The differences—called innovations—drive the position update.
The system has been operating. It’s calculated position, velocity, orientation. Given where the system thinks it is, what should the measurements from each sensor look like?
Take GNSS. At a given place on earth, you’re going to see measurements from specific satellites. The measurements will be specific ranges to those satellites. If the system thinks it’s at a certain location, it expects to see measurements consistent with being at that location.
You take the actual measurements that just came in through time alignment and compare them to what you think they should be. The difference tells you something about how wrong you are about where you really are in the world.
But that’s not an immediate answer. You can’t take one measurement and know precisely where you are. In practice, the measurements you’re bringing in have noise and other sources of error. An important part of this modeling is not just doing this comparison, but also trying to model and eliminate as much of that error as you possibly can to get down to a precise answer.
Outlier Detection and Weighting
Here’s where it can get complicated.
Say the system thinks it’s on 1st Avenue. It’s very confident about that. Then measurements come in that say you’re on 10th Avenue.
If the system is really confident about where it is, then it’s entirely possible those measurements are just wrong. If there are lots of measurements and they’re all consistent with being on 10th Avenue, then maybe that’s a sign the system is mistaken. But at first glance, the system might want to throw some measurements away.
In the real world, measurements have varying quality—some good, some bad, some subtly degraded. The challenge is weighting the good and eliminating the bad without corrupting your position estimate.
If you accept a measurement that says you’re on 10th Avenue, that might pull the position very far away. If you reject it entirely but have other measurements consistent with 2nd or 3rd Avenue, your position might drift to the other side of 1st.
It’s a balance. Sometimes it’s clear a measurement is bad—discard it. More often, measurements aren’t obviously wrong. The system must determine what information they provide, how much to trust them relative to other sensors, to avoid getting dragged around from one street to another.
This is why pre-processing matters. Multipath detection can flag bad measurements ahead of time. When you get to measurement modeling, you already know that measurement is compromised and won’t use it.
RTK Input: Canceling Common Errors
Measurement modeling also integrates RTK corrections. This is critical to getting down to the super fine, precise position level.
RTK is effectively providing a source of comparison so you can remove most or in some cases all of the sources of error that affect GNSS. GNSS is affected by a lot of different kinds of error.
RTK input basically provides you a picture of those same measurements from a nearby base station, typically within 10-50 kilometers (see the Point One RTK base station map for an example). Imagine somebody else down the street looking at those same satellites and seeing almost the exact same picture that you’re seeing. They’re also seeing a lot of the same sources of error.
You take this stream of corrections and use it to eliminate, or at least mitigate, some of the biggest sources of error affecting the GNSS measurements at your location. This isn’t perfect. That base station is not at your location, and it doesn’t see what you see, just a similar picture. So you may not eliminate every error source perfectly, but what you’re left with will be much better. Instead of meters of error on each satellite, you’re down to a much more accurate picture, often 1-3 centimeter-level of accuracy.
So in practice, RTK is actually just another kind of sensor. It’s not one of the sensors on your vehicle, but it’s a remote sensor that helps you out from a nearby location.
The Estimator: Combining It All
The estimator combines measurements from multiple sensors, weights them based on expected error and confidence, and updates the position, velocity, and orientation estimate.
There are many kinds of estimators—when we’re talking navigation engines, the most common might be the Kalman filter. Whichever you choose, the estimator’s job is to find a way to combine these many measurements, tease out the ones that maybe aren’t so good, compare them with the current picture of the world, and then update that picture. The innovations it computes—the differences between the expected measurements and reality—tell you how big that update should be.
To do this, the system is constantly estimating the current state: what it believes the position, velocity, and orientation are at this moment. But your sensors might not measure position or velocity directly. Maybe you measured the range to a satellite, or the speed of the left rear wheel. You have to find a way to relate those pieces of information—those measurements—into the things of actual interest: position, velocity, orientation. That relationship enables you to model the expected measurements and compute innovations.
Then you take these innovations, which are telling you how those measurements differ from what you think they should have been, and you use that same relationship to work backwards—how wrong was your position? How wrong was your velocity?
Confidence and Skepticism
The estimator does all of this by considering how noisy the measurements are, and how much error they might have, and then comparing that with how confident it is about its own estimate of the state. Your model might tell you to expect measurements from 1st Avenue, but if you just walked around the neighborhood blindfolded, you can’t really be that sure, can you?
If the estimator is extremely confident in the position and receives conflicting measurements, it considers them skeptically.
Conversely, at device startup when position is uncertain or unknown, measurements—even noisy ones—significantly influence the estimate. The system incorporates the information, updates the position estimate accordingly, and continues learning with each new measurement.
The estimator’s job is to learn about the world over time and become more confident the more information it gathers. And this is happening at 10 or 50 or 100 times a second!
Sensor Error Learning: The Key to Hard Environments
Here’s what separates research code from production systems: Any system can take measurements and compute a position. A GPS receiver in a parking lot produces a great position all day.
But if you drive under a grove of trees into a tunnel, through that tunnel for 10 kilometers, and emerge on the other side—that’s much more difficult.
It’s the way in which you correct those incorrect measurements from measurement modeling and feed them back into the estimator calculations which is going to dictate how good that position is in the more difficult environments.
The key insight: When you’re extremely confident about where you are and you get a sensor reading that you know is wrong, you feed that information back into the system to correct future measurements from that sensor.
Every sensor has sources of error. Some can be measured, some cannot. The estimator tries to learn as many as it can, and then applies them to make your $10 IMU perform like a $10,000 IMU.
Wheel Speed Errors
Wheel speeds tell you how far you drove based on rotation rate. But tire diameter changes with inflation and temperature.
Underinflated tires have smaller diameter. The tire spins the same amount, but you didn’t travel as far. Overinflated tires create the opposite error.
For best performance, the system needs to learn the actual tire diameter over time and use that to correct the measurements. The more measurements the system processes, the more it learns about the world—comparing wheel measurements with other sensors explicitly and implicitly through the estimator, the more accurately those corrections can be applied.
IMU Bias and Scale Errors
The IMU measures acceleration and rotation rate. Gravity is 9.8 m/s² (1G) when you are stationary. What if the sensor reads 10 or 11? Or 8? Or what if it reads 1 m/s² forward? The system would think it’s accelerating up or down, or driving forward, when it isn’t.
Similarly, what if it reads 0 m/s², but then you start to drive forward, accelerating at 1 m/s², and it reads 2 m/s²? Or 0.5 m/s²? The more you use your IMU, the more you integrate this error and the worse your state estimates become!
Here’s another one: say you’re sitting perfectly still on a flat road. You expect all 9.8 m/s² to point vertically. But what if you read 9.0 vertically and 0.8 forward? Or to the side? No matter how hard you try to install your device, the IMU will never be perfectly aligned with your car. There will always be a degree of error. Even if you manage to get it just right, the IMU might not be soldered to the circuit board perfectly. Or the physical sensors inside the IMU might have a small error tolerance.
Not enough for you? Just for fun, let’s add temperature to the mix. Not only do we not know these bias and scale factor errors, but they change as the temperature of the IMU changes. A cold IMU might behave very differently than a hot one. You might get into your car on a cold morning and everything’s great, but once you start blasting that heat, your IMU might start to drift like it’s filming the next Fast and Furious movie.
These are IMU bias, scale factor, and mounting angle errors. Just like with wheel diameter, the system needs to learn these errors over time, and needs to monitor and update its error estimates continuously in real-time as the vehicle drives.
Dynamics Modeling: Every Platform is Different
Dynamics modeling predicts how the vehicle state (position, velocity, orientation) evolves over time based on vehicle type and physics constraints.
The estimator needs to predict where the vehicle is between measurements. That’s what dynamics modeling is all about. How do you evolve these things in the absence of other information?
Every type of vehicle behaves differently.
Car Constraints
Cars have pretty well known constraints that are useful for navigation.
Unless you’re in trouble, your car won’t go sideways. It won’t go up or down. It stays on the road.
You can take advantage of these features. If the IMU says you’re accelerating rapidly upward for a while, you know that’s probably not true. You might go over a bump, but you’re not floating off to space. And if you are, IMU bias is probably the least of your concerns.
Airplanes: Different Rules
Airplanes behave differently. They can fly sideways (to a degree): they crab into the wind. They climb and descend, and get jostled up and down in turbulence. Cars don’t.
You must consider this in the modeling process. You allow more rapid variation of your position and velocity because an airplane might get hit by wind gusts. You apply different constraints than you would for a car. Even the way in which you estimate sensor errors might need to be adjusted or rethought entirely.
Plus, not all airplanes are created equal. A small package delivery drone will be impacted by the wind way more than a 737.
Motorcycles: Banking Behavior
When motorcycles turn at speed, they bank to the side. The rider rolls with the turn. At high speeds, this must be accounted for carefully. Not only does it affect your dynamics, but it also turns out your GNSS antenna doesn’t particularly love staring at the ground!
Cars don’t lean (much). A little bit on a highway onramp, and maybe more on a test track, but generally the car isn’t leaning over by 20, 30, 40 degrees.
Predicting the Current State
Dynamics modeling makes the estimator’s ability to predict position better or worse. That prediction feeds back into the measurement model.
For a new measurement at a new time, you have an estimate of where you were previously. To model new measurements, compare them, and compute innovations, you don’t need to know where you were earlier. You need to know where you are now.
That’s what this process is about—moving yourself forward in time given what you know internally, so you can apply the latest and greatest measurements.
IMU Integration
When you have an IMU, rather than operating with GNSS only, this becomes slightly more straightforward. Instead of more or less taking an educated guess at how the state—position, velocity, and so on—changes over time for your type of vehicle, the IMU tells you how the vehicle is accelerating and rotating in every direction. Integrate that, and you get a picture of how the state is evolving.
That said, all of the constraints and differences described above still apply. In order for your IMU to be its best self, you have to factor all of those things in. That’s how you wring out the IMU errors to get that sweet, sweet motion.
Platform-Specific Tuning
Adapting the navigation engine across platforms requires careful parameterization. A delivery robot needs different dynamics models, measurement noise assumptions, and sensor priorities than an agricultural tractor or survey drone. The system must account for these platform-specific differences or performance will degrade significantly.
Plan for Implementation Complexity
The navigation engine sounds straightforward. In practice, it’s full of edge cases.
Temperature-dependent sensor errors: A cold IMU behaves differently than a hot one. A filter tuned for steady-state temperature will drift during warmup. The system needs to track temperature or model how errors change over time.
Partial sensor failures: What happens when one wheel encoder fails mid-drive? When half your GNSS satellites disappear behind a building? The filter needs to gracefully degrade. Detect the failure, adjust trust levels, rely more heavily on remaining sensors.
Conflicting measurements: GNSS says you’re moving at 15 m/s. Wheel speeds say 12 m/s. IMU integration says 14 m/s. Which one is right? The estimator has to weight them based on expected error characteristics, environment, and recent performance.
Computational constraints: Running measurement modeling for 60 satellites, integrating IMU at 100 Hz, processing 50 Hz wheel speeds, incorporating other sensors like computer vision, updating the estimator, propagating dynamics—all of this requires processing power and memory. Embedded systems have tighter constraints than workstations. The filter needs to run in real-time on your target hardware. Your capabilities might be limited by how much processing you can afford.
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 estimator weight conflicting measurements? What happens when GNSS and wheel speeds disagree?
- Can your system learn sensor errors in real-time? Wheel scale factors, IMU biases, antenna offsets?
- Does your dynamics model adapt to different platforms? Can the same filter handle a car, a drone, and a robot without redesigning?
- How does measurement modeling handle outliers? Do you reject them, de-weight them, or have a more sophisticated approach?
- What happens during partial sensor failures? If one wheel encoder drops out, does the filter degrade gracefully?
- How quickly does your system converge after startup? How long until IMU biases are learned, wheel scale factors estimated?
- What’s your computational footprint? Can it run in real-time on embedded hardware?
Use these questions as evaluation criteria when comparing vendors or as design requirements when building your own system.
What’s Next
Measurement modeling combines your sensors. The estimator learns their errors. Dynamics modeling predicts motion between updates.
But there’s one more critical piece: RTK fixing. How do you resolve the unknown ambiguity in your carrier phase measurements? How do you get from meter-level position to centimeter-level precision?
In the next post, we’ll cover carrier phase measurements, the search space problem, and how RTK fixing actually works in production systems.
This is Part 3 of our series on positioning system architecture. Part 1 covered time synchronization and the P1 time architecture. Part 2 covered pre-processing and sensor strategy.
Try our RTK Network for free
Affordable, global precision without the hassle