TLDR: Earlier we drew the navigation engine as a set of boxes: measurement modeling, dynamics modeling, the estimator, RTK fixing. This post opens the estimator box. The estimator’s real job is not to trust any single sensor but to weigh each measurement against how much it already knows, then combine them all into one filter state, while tracking how confident it is in the result.
By now the measurements are in good shape. Time synchronization gave everything a common time base. Pre-processing cleaned the raw streams. The navigation engine modeled what each sensor should read, and RTK fixing pulled the GNSS measurements down to the centimeter level.
At the center of all of that sits the estimator. It is the part of the system that takes separate, sometimes barely related measurements, all of which say something about the state of the world, and turns them into one answer.
This post is about what actually happens inside the estimator box.
The State Vector: What the Estimator Is Really Estimating
The filter state, or state vector, is the bundle of numbers the estimator is trying to pin down. Position, velocity, and orientation are the obvious ones. But the state usually carries less obvious quantities too: corrections for sensors that have underlying error, and other values the system only estimates as byproducts because it needs them to get to a good position.
Some measurements tell you directly about something in that state vector. A measurement of position is the simplest case: something just hands you a position. Other measurements are indirect. Wheel speeds tell you how fast you are moving, not where you are. A range to a satellite tells you something about position, but only in combination with many other ranges.
The estimator’s job is to take all of these, direct and indirect, and massage them into an update to the thing you actually care about. It does not get there in one shot. It learns the state over time, refining it with every measurement that arrives.
Weighting: Confidence Versus Expected Error
The single most important thing the estimator does is weigh each measurement.
Every measurement has some amount of wiggle room, some expected error. The estimator compares that against how confident it already is in its current estimate. How well do I think I know my position right now? My orientation? A measurement that is noisy or only loosely related to the state gets less say than one that is precise and confident.
That balance shifts over time. When you power on a device for the very first time, the estimator knows almost nothing. Position, orientation, sensor errors: all of it is uncertain. In that state, even a noisy measurement is valuable, because anything beats nothing, and the system leans on incoming data to learn.
Once the system has been running and is confident about where it is, the relationship flips. Suppose you have an RTK fix and you know your position very well, and then a faulty GNSS measurement arrives, corrupted by a building or some other source of error. The estimator can compare that measurement, and the error it should normally carry, against what it already believes. If the measurement sits far outside its expected error, the estimator can de-weight it, or reject it outright. (Part 3 covers this outlier handling in more detail.)
Complementary Sensors: The Best of Both Worlds
Rejecting a bad GNSS measurement does not mean going blind. The other sensors keep contributing.
This is the strength of multi-sensor fusion: the sensors are complementary. The wheel speeds know nothing about the tall building down the block, and they do not care. The GNSS measurements may be degraded by that building, but when they are not, they can be excellent. The IMU (inertial measurement unit) runs fast, faster than the GNSS updates, filling in the motion between them. Wheel speeds may arrive at a lower rate, sometimes even less often than GNSS. Over time they all aid each other. Combine them and each covers for the other’s weakness: the absolute accuracy of GNSS when it is healthy, and a steady sense of motion when it is not.
Two Families: INS Versus GNSS-Only
Before the estimator can predict how the state changes between measurements, it has to know what kind of system it is running on. There is a hard dividing line here, and it comes down to one sensor.
An inertial navigation system (INS) has an IMU available. A GNSS-only system does not. That distinction matters more than almost anything else in the engine.
An IMU very precisely measures accelerations and rotation rates. Integrate those over time and you get a direct picture of how position and velocity are changing. The IMU tells you how the state is evolving as the platform moves, between the absolute measurements like GNSS or computer vision that tell you something about the world outside the device. The quality of the IMU, which tracks with cost, power, and other factors, sets the precision you can reach.
Take the IMU away and you are in a much harder spot. Picture driving on a highway and entering a tunnel. Leading up to it, GNSS was healthy and everything was fine. Inside, GNSS is gone. With an IMU (or wheel speeds, or other sensors of relative motion), you can keep dead reckoning through the gap. With nothing, you might guess for a couple of seconds, and after that you are simply wrong.
When you do not have those relative-motion sensors, the best you can do is fall back on how this kind of vehicle normally moves. We have a pretty good idea of how cars behave: they generally do not go up, do not go down, do not roll much side to side, and certainly do not flip over. A boat or an airplane is a different story. Those assumptions, the ones an INS leans on far less because the IMU is measuring the motion directly, are what a GNSS-only system has to survive on. (For the platform-by-platform dynamics, cars versus airplanes versus motorcycles, see Part 3.)
This INS-versus-GNSS-only split is the foundation of the Atlas INS approach: pair a capable positioning engine with inertial sensing so the system keeps producing a usable position when the sky disappears.
Pseudo-Measurements: Manufacturing Information You Never Measured
This is one of the more interesting tricks the estimator has. Academics tend to call them pseudo-measurements: applying what you know about a vehicle to constrain what the system is allowed to do, and what simply does not make sense.
Stationary detection is the cleanest example. Suppose the IMU reports that you are not rotating, because rotation rate is exactly what it measures, and also that you are not accelerating. Strictly, no acceleration means your velocity is not changing, not that it is zero. But real vehicles almost never hold a perfectly constant speed, so in practice, when the IMU shows no acceleration and no rotation, it is a good bet you are stopped.
In practice we do not read the raw rotation and acceleration values and check them against zero. Acceleration is never truly zero anyway, because gravity is always present, spread across the axes unless the device happens to be perfectly level. Instead we watch how those signals change, and how noisy they are, over a window of time. A vehicle that is truly stopped produces a distinctive, steady signature, and reading it that way lets us detect the stop while ignoring the sensor’s own biases.
Once we know the vehicle is stopped, the trick pays off. A stationary car is not rolling and not pitching, so we can assert that the true rotation rate is zero and the true velocity is zero, feed that back in as a pseudo-measurement, and measure how far the sensors drift from it. That gap is the sensor error, laid bare. From it we build sensor corrections, statements like “this particular sensor is off by this amount, in this way,” and apply them to the dynamics model and the incoming measurements so the whole solution gets more precise over time.
Those corrections are not static. They evolve. Temperature and other environmental factors push them around, so the system keeps relearning them as it goes. But once you get a good bead on them, you can wring real precision out of measurements that, on paper, should not be that good.
Module Versus Host: Where the Estimator Runs
All of this sounds like pure math, and it is, but the math is not free. Propagating the estimator forward and running the dynamics modeling costs real computation.
First, the two places that computation can live. When positioning runs on a module, the estimator sits on a small, self-contained device with its own processor and its own power budget, a board dedicated to doing one job. When it runs on a host, the estimator runs on the larger main computer already onboard the vehicle or robot, the same class of processor handling perception, planning, and the rest of the application. A module is compact, power-efficient, and easy to drop into a design. A host has far more compute and memory to spare. That difference in headroom is what the rest of this section is about.
There is some history worth noting here: a lot of what we do today with estimators grew out of making this kind of calculation cheap enough for small computers, lineage that traces back to the Apollo guidance computer. So in one sense, the field has always been about fitting estimation onto constrained hardware. But it is all relative.
On a less capable device, say the embedded processor on a module, you can simply run out of headroom. If you are feeding it a very high-rate IMU, or running particularly expensive calculations or algorithms, you may not physically be able to keep up. And the consequences are not just “it runs slower.” Imagine a race car with heavy dynamics and a lot of vibration, where the high-rate measurements carry exactly the detail you want to capture. If the processor cannot keep up at that rate, you may be forced to use a lower-rate measurement, and the lower rate can hide the very things that mattered. Or you may be forced to limit or disable features in the navigation engine that you normally rely on, which can degrade performance.
That is one example out of many, but it captures the idea. Some of the techniques you need to reach the finest level of precision just will not fit well on certain devices, because of everything else those devices have to do at the same time. This is the practical line between a capable engine that runs on a module and a more robust one that runs on a host processor with room to spare. It is also why the right answer depends entirely on the platform.
Questions Worth Asking
If you are building your own stack or evaluating a commercial positioning engine:
- How does the estimator weight a measurement against its own confidence? What happens to a confident estimate when a single bad GNSS measurement arrives?
- Does the system learn sensor corrections in real time, and does it keep relearning them as temperature and conditions change?
- Can it exploit pseudo-measurements like stationary detection, or does it only consume the sensors at face value?
- How does it behave with an IMU versus GNSS-only? What is the fallback when the sky disappears?
- What hardware does the engine target? Does the high-rate path you need actually fit on your processor alongside everything else it runs?
What’s Next
The estimator has done its work. It is producing a precise filter state several or many times a second. But two problems remain. First, to use measurements that arrive out of order, the engine may be forced to run slightly behind real time, which means its latest answer is a little stale. Second, that answer is still just numbers inside the engine; nothing else in your system can use it yet.
In the next post we cover the last stage of the pipeline: the output propagator that recovers real time, and the output and transport services that turn the filter state into messages your stack can actually consume.
Frequently Asked Questions
What does the estimator in a positioning engine actually do?
It takes separate, sometimes barely related sensor measurements and combines them into a single filter state. Its core job is to weigh each measurement by its expected error against how confident the system already is, then update the state accordingly rather than trusting any one sensor outright.
What is a state vector?
The state vector is the bundle of values the estimator is solving for. It includes position, velocity, and orientation, plus less obvious quantities like corrections for sensors with underlying error and other values the system estimates as byproducts on the way to a good position.
What is the difference between an INS and a GNSS-only system?
An inertial navigation system (INS) includes an IMU that measures acceleration and rotation, so it can track how position and velocity change between absolute fixes and keep dead reckoning through outages like tunnels. A GNSS-only system has no such sensor and must fall back on general assumptions about how the vehicle moves once satellite signals are lost.
What are pseudo-measurements in sensor fusion?
Pseudo-measurements are constraints derived from what the system knows about the platform. For example, once the engine detects that a car is stopped, it can assert that the true rotation rate and velocity are zero, feed that back in, and measure how far the sensors drift from it. That gap exposes sensor error the system can then correct.
Does it matter whether the positioning engine runs on a module or a host processor?
Yes. A module has limited compute and power, and heavy demands like a very high-rate IMU or expensive algorithms can force lower measurement rates or disabled features. A host processor has far more headroom, which allows techniques a module cannot support. The right choice depends on the platform.
This is Part 5 of our series on positioning system architecture. Part 1 covered time synchronization. Part 2 covered pre-processing and sensor strategy. Part 3 covered the navigation engine. Part 4 covered RTK fixing.
Try our RTK Network for free. Affordable, global precision without the hassle. Start your free trial.