What Happens Inside the Software Thousands of Times Every Second?

In the previous article, we explained how an Inertial Navigation System (INS) transforms raw IMU measurements into attitude, velocity, and position.

But one important question remained unanswered.

Perhaps the most important one of all.

How does the software actually do it?

After all, an IMU does not transmit values such as Latitude, Longitude, or Speed.

Every sampling cycle, it sends only a handful of measurements.

For example:

• Angular rate about the X-axis
• Angular rate about the Y-axis
• Angular rate about the Z-axis
• Acceleration along the X-axis
• Acceleration along the Y-axis
• Acceleration along the Z-axis
• And, in many systems, additional information such as temperature, status flags, and diagnostic data.

That is all the information available to the computer.

There is no map.

There is no GPS.

There is no heading.

The software does not even know whether the platform is sitting on the ground, flying through the air, or moving at sea.

Yet, only seconds after startup, the navigation system is already able to estimate the platform’s attitude, calculate its velocity, and, in many cases, determine its position with remarkable accuracy.

So what actually happens between the moment a new IMU sample arrives and the moment a complete navigation solution is produced?

In this article, we look inside the heart of an INS and follow the journey of a single IMU sample—from the instant it enters the processor to the moment it becomes part of a real-time navigation solution.

IMU

↓

Gyroscope
Accelerometer

↓

Navigation Software

↓

Attitude

↓

Velocity

↓

Position

↓

Navigation Solution

Figure 1 – High-Level Overview of the INS Navigation Algorithm.
Each IMU sample enters a processing pipeline that transforms raw gyroscope and accelerometer measurements into a complete navigation solution. While the diagram is conceptually simple, every stage involves sophisticated mathematical computations executed continuously at rates ranging from hundreds to thousands of times per second, depending on the sampling frequency of the navigation system.

The Algorithm Does Not Wait for Data to Accumulate

One of the most common misconceptions about an Inertial Navigation System (INS) is that it collects sensor data for several seconds before calculating the platform’s position.

In reality, the opposite is true.

As soon as a new IMU sample is received, the navigation algorithm begins processing it immediately.

If the IMU operates at 1,000 Hz, the entire processing cycle must be completed in just one millisecond – before the next sample arrives.

In more advanced systems operating at 2,000 Hz or even 10,000 Hz, the available processing time is even shorter.

For this reason, an INS does not perform one large calculation every few seconds.

Instead, it executes thousands of small, continuous calculations every second.

During each processing cycle, the software reads the latest IMU measurements, updates the navigation state, estimates sensor errors, integrates information from other sensors when available, and generates an updated navigation solution.

An INS can be viewed as a continuous processing loop that runs for the entire duration of the platform’s operation.

Each time a new IMU sample arrives, the cycle starts again.

Start

↓

Read IMU

↓

Correct Sensor Errors

↓

Update Attitude

↓

Remove Gravity

↓

Calculate Linear Acceleration

↓

Update Velocity

↓

Update Position

↓

Receive GNSS?

↓

Yes → Sensor Fusion

↓

Update Navigation State

↓

Output Navigation Solution

↓

Wait for Next IMU Sample

↓

Repeat

Figure 2 – Typical INS Processing Cycle.

With each new IMU sample, the navigation algorithm executes a sequence of processing steps, including sensor error compensation, navigation state updates, and the integration of information from supporting sensors. This cycle repeats continuously, hundreds or even thousands of times per second, depending on the sampling rate of the navigation system.

Camera Frame
────────────●────────────●────────────

GNSS
────────────●─────────────────────────

IMU
────────────●────────────●────────────●────────────●────────────

Time →

Raw Gyroscope Data
│
▼
Bias Compensation
│
Temperature Compensation
│
Scale Factor Correction
│
Validity Checks
│
▼
Corrected IMU Data

Figure 4 – Measurement Preprocessing.

Before any navigation calculations are performed, the raw measurements received from the IMU undergo a preprocessing stage. During this step, the algorithm may compensate for sensor bias, temperature effects, and scale factor errors, while also performing validity checks and other filtering operations. The objective is to minimize the influence of measurement errors so that all subsequent navigation calculations are based on data that is as accurate and reliable as possible.

Step 3 – How Does the Algorithm Know Which Way the Platform Is Facing?

If you ask someone to stand in the middle of a room and close their eyes, they can usually still tell whether they are standing upright, leaning forward, or have turned to the left.

A computer has no such intuition.

For the navigation algorithm, everything begins from zero.

When an INS is powered on, the algorithm does not inherently know whether the platform is facing north or south, whether it is level or tilted, or even whether it is stationary or already in motion.

The only information available is the continuous stream of measurements produced by the gyroscopes and accelerometers.

During every sampling cycle, the gyroscopes measure the platform’s angular rate about the three axes. The algorithm does not receive the platform’s orientation directly – it receives only how fast that orientation is changing.

To determine the current attitude, the algorithm must continuously update its estimate using every measurement received since the system started operating.

A useful analogy is navigating while blindfolded.

If you know exactly how much you have rotated since the previous moment, you can continuously estimate which direction you are facing without ever seeing the outside world.

This is exactly how an INS estimates attitude.

With each new IMU sample, the algorithm combines the latest angular rate measurements with the attitude estimated during the previous processing cycle and computes the platform’s new orientation.

In other words, the algorithm does not recalculate the attitude from scratch every time.

It updates it continuously.

This is one of the most critical variables in the entire navigation system. Every subsequent calculation – from gravity compensation to velocity and position estimation – depends on the accuracy of this attitude estimate.

Modern navigation systems rarely represent orientation internally using Roll, Pitch, and Yaw angles alone. These Euler angles can introduce mathematical singularities under certain conditions, so professional INS algorithms typically use more robust representations such as quaternions or rotation matrices, allowing the platform’s orientation to be updated continuously, accurately, and without singularities.

The user almost never sees the quaternion itself.

Instead, the navigation system displays familiar Roll, Pitch, and Yaw angles.

Behind the scenes, however, the algorithm performs its calculations using a completely different mathematical representation.

Gyroscope
(Angular Rate)

│
▼

Quaternion Update

│
▼

Rotation Matrix

│
▼

Roll
Pitch
Yaw

Figure 5 – Attitude Estimation.

During each processing cycle, the navigation algorithm combines the angular rate measurements received from the gyroscopes with the attitude estimate from the previous cycle to update the platform’s orientation in three-dimensional space. In professional navigation systems, these calculations are typically performed using quaternions or rotation matrices, which provide a stable and continuous representation of orientation without the limitations of Euler angles. Only after the attitude has been updated is it converted into the familiar Roll, Pitch, and Yaw angles used for display and by subsequent navigation algorithms.

Step 4 – Gravity Compensation

Once the algorithm knows the platform’s orientation in space, it can perform a calculation that would not have been possible before:

It can separate the Earth’s gravity from the platform’s actual acceleration.

At first glance, this sounds straightforward.

In reality, it is one of the most critical steps in the entire navigation process.

Imagine a drone resting motionless on a table.

From the user’s perspective, its acceleration is zero.

The accelerometers, however, do not know that the drone is stationary.

Instead, they measure approximately 1 g, caused by the Earth’s gravitational field.

If the algorithm interpreted this measurement as actual platform acceleration, it would incorrectly conclude that the drone was accelerating upward, even though it was not moving at all.

Before velocity or position can be estimated, the algorithm must first determine how the platform is oriented relative to the Earth, calculate the direction of the gravity vector in the IMU’s reference frame, and subtract it from the accelerometer measurements.

Only after gravity has been removed does the algorithm obtain the platform’s true linear acceleration.

This is the acceleration that can be integrated to estimate velocity.

At this point, it becomes clear how tightly each stage of the navigation algorithm depends on the previous one.

If the attitude estimate computed in the previous step is even slightly inaccurate, the gravity vector will also be estimated incorrectly.

As a result, part of the gravitational acceleration may remain in the measurement, or genuine platform acceleration may be removed by mistake.

In other words, a small error in the estimated orientation immediately becomes an error in the calculated linear acceleration.

Since this acceleration is subsequently integrated to estimate velocity and position, the error continues to propagate throughout the entire navigation solution.

This is precisely why modern Inertial Navigation Systems devote so much effort to accurate attitude estimation.

Its purpose is not merely to display Roll, Pitch, and Yaw to the user.

It provides the foundation upon which nearly every subsequent navigation calculation depends.

Measured Acceleration

│

├──────   Gravity (1g)

└── Linear Acceleration

│

▼

Remove Gravity

│

▼

True Linear Acceleration

Figure 6 – Gravity Compensation.

An accelerometer measures specific force, which includes both the acceleration produced by the platform’s motion and the effect of Earth’s gravity. Once the navigation algorithm has estimated the platform’s attitude, it can determine the direction of the gravity vector in the sensor’s reference frame and subtract it from the accelerometer measurements. The result is the platform’s true linear acceleration, which is then used to estimate velocity and, ultimately, position.

Step 5 – From Acceleration to Velocity

Once the algorithm has computed the platform’s true linear acceleration, it can proceed to the next stage of the navigation process:

Estimating the platform’s velocity.

From a mathematical perspective, the concept is straightforward.

If acceleration is known at every instant, velocity can be determined by integrating that acceleration over time.

For example, if an aircraft accelerates at a constant rate for several seconds, its velocity increases accordingly. The navigation algorithm does not wait until the maneuver is complete. Instead, it updates the velocity estimate during every processing cycle.

In a system operating at 1,000 Hz, this means the platform’s velocity vector is recalculated one thousand times every second.

This is also where one of the fundamental challenges of inertial navigation becomes apparent.

Any small error in the estimated linear acceleration does not remain confined to that single measurement.

It is carried forward into the velocity estimate.

If the algorithm incorrectly estimates even a few thousandths of a g while the platform is actually moving at constant velocity, that error is continuously integrated, causing the estimated velocity to drift farther and farther from the true value.

For this reason, an Inertial Navigation System does much more than simply perform mathematical integration.

While estimating velocity, the algorithm continuously monitors measurement quality, updates its estimates of sensor errors, and looks for opportunities to correct accumulated drift using information from other sensors.

In other words, the algorithm is not merely calculating velocity.

It is also constantly asking itself:

“How confident am I that this velocity estimate is correct?”

That same question becomes even more important in the next stage, where the estimated velocity is integrated once again to determine the platform’s position.

True Linear Acceleration
│
▼
Integration
│
▼
Velocity
│
▼
Navigation State

Figure 7 – Velocity Estimation Through Acceleration Integration.

After gravity compensation has been applied, the navigation algorithm integrates the platform’s linear acceleration over time to estimate its velocity. This process is repeated during every processing cycle, continuously updating the velocity vector. Any error in the estimated acceleration is also integrated, causing the velocity estimate to drift over time. Consequently, the accuracy of this stage depends directly on the quality of the sensor measurements, the precision of the attitude estimation, and the effectiveness of the navigation system’s error compensation algorithms.

Step 6 – The Algorithm Does More Than Compute Position – It Estimates the System State

At this point, it might seem that an Inertial Navigation System only needs to keep track of three quantities:

• Position
• Velocity
• Attitude

In reality, these are only a small part of the information maintained by the navigation algorithm.

A modern INS continuously maintains an internal system state, often referred to as the state vector.

This state describes much more than where the platform is located. It also represents how the system is behaving, which sensor errors have been identified, and how much confidence the algorithm has in each estimated quantity.

In relatively simple systems, the state vector may contain only position, velocity, and attitude.

In more advanced tactical navigation systems, however, it typically includes additional variables such as gyroscope bias, accelerometer bias, and, in some cases, parameters related to sensor alignment, time synchronization, or the platform’s motion model.

In other words, the algorithm is not simply remembering where the platform is.

It is also keeping track of how much it trusts its own estimates.

This is one of the fundamental differences between a simple integration algorithm and a true Inertial Navigation System.

During every processing cycle, after updating attitude, acceleration, and velocity, the algorithm does not stop at updating the navigation solution.

It also updates the entire state estimate.

When a new IMU measurement arrives, or later when data is received from a GNSS receiver or another aiding sensor, the algorithm does not recalculate everything from the beginning.

Instead, it refines its existing state estimate using the newly available information.

A useful analogy is a continuously updated engineering logbook.

Each new measurement not only adds information but also changes the algorithm’s confidence in every estimated variable.

As a result, even if one of the sensors temporarily stops providing data or its measurements become less reliable, the navigation system can continue operating by relying on the knowledge accumulated in its internal state.

This is one of the key reasons why an INS can continue providing a navigation solution even when GNSS signals are unavailable for several seconds – or, in high-performance systems, even for several minutes.

Navigation State
│
▼
Prediction
│
▼
New GNSS Measurement
│
▼
Comparison
│
▼
Kalman Update
│
▼
Updated Navigation State

Why Is Building an Inertial Navigation System So Difficult?

After following the complete navigation processing chain, it becomes easier to understand why developing an INS involves far more than selecting a high-performance IMU or implementing a few mathematical equations.

Every millisecond, the system may need to perform dozens of tasks:

• Acquire the latest IMU measurements.
• Synchronize all sensors to a common time base.
• Compensate for temperature effects and sensor biases.
• Estimate the platform’s attitude.
• Remove the effect of gravity from the accelerometer measurements.
• Update the platform’s velocity and position.
• Predict the system state.
• Fuse information from aiding sensors.
• Evaluate the quality of incoming measurements.
• Continuously refine the navigation model.

And this entire sequence is repeated hundreds or even thousands of times every second.

When the platform performs an aggressive maneuver, when GNSS signals are lost, when the temperature changes, or when mechanical vibrations appear, the algorithm must continue operating without interruption while maintaining a reliable navigation solution.

This is why an Inertial Navigation System is much more than a mathematical algorithm.

It is a real-time estimation system in which every processing stage depends on the accuracy of the previous one, and even small errors can rapidly propagate through the navigation solution if they are not detected and compensated.

Ultimately, the performance of an INS is determined not only by the quality of its sensors, but also by the algorithm’s ability to model sensor behavior, manage uncertainty, compensate for accumulated errors, and extract the most reliable navigation solution from imperfect measurements.

Conclusion

From the outside, an Inertial Navigation System appears deceptively simple.

It receives measurements from an IMU and produces a navigation solution.

In reality, one of the most sophisticated real-time estimation algorithms in engineering operates between those two steps.

During every processing cycle, the navigation algorithm reads the latest sensor measurements, compensates for known errors, estimates the platform’s attitude, removes the effect of gravity, updates velocity and position, maintains the system state, and combines information from external sensors to continuously reduce accumulated navigation errors.

This entire process repeats continuously throughout the operation of the system.

It is also the reason why two engineering teams can build navigation systems around the exact same IMU and still achieve dramatically different levels of performance.

In many cases, the difference is not the sensor itself, but the quality of the navigation algorithm, the precision of time synchronization, the effectiveness of error estimation and compensation, and the way every component works together to produce a single, reliable navigation solution.

A Real Example – What Happens When a New IMU Sample Arrives?

So far, we have explained the principles behind an Inertial Navigation System.

Now let’s go one step deeper and examine what a real processing cycle looks like inside navigation software.

For this example, we will use an IMU from the LandMark™ SX2 family developed by Gladiator Technologies.

The IMU transmits a data packet to the navigation computer at a fixed rate, which can be configured up to 10,000 samples per second. Each packet contains gyroscope measurements, accelerometer measurements, sensor temperature, a message counter, and additional fields used for communication control and data integrity verification.

Assume the following packet has just been received:

---------------------------------------------
Message #15234

Time          12.001000 s

Gyro X        +0.32 °/s
Gyro Y        -0.15 °/s
Gyro Z        +4.81 °/s

Accel X       +0.031 g
Accel Y       -0.012 g
Accel Z       +1.002 g

Temperature   31.8 °C

Status        OK
---------------------------------------------

What Happens When the Packet Reaches the Processor?

The moment the IMU packet arrives, the navigation algorithm begins its work.

The first task is not to calculate position, velocity, or attitude.

Instead, the software first parses the communication packet and converts the received bytes into data structures that can be processed by the navigation algorithm.

During this stage, the software also verifies the integrity of the message, checks the message counter, evaluates the status fields, and confirms that the received data is complete and valid.

Only after all of these checks have passed can the navigation calculations begin.

From the programmer’s perspective, this first step may appear surprisingly simple.

// Read one IMU packet
IMUSample sample = imu.read();

Although this is only a single line of code, a considerable amount of work happens behind the scenes.

The imu.read() function does far more than return six sensor values.

It reads the serial data stream, detects the beginning of the packet using the synchronization byte, verifies the packet structure, decodes each field, validates the checksum, and converts the raw gyroscope, accelerometer, and temperature measurements into a structured data object. The packet format and individual fields are defined by the SX2 communication protocol.

After decoding, the resulting object may look something like this:

sample.gyro.x
sample.gyro.y
sample.gyro.z

sample.accel.x
sample.accel.y
sample.accel.z

sample.temperature

sample.status

sample.messageCounter

This is the point where the raw numbers received from the hardware become meaningful information that the navigation software can process.

Even now, however, the navigation algorithm does not immediately use these measurements to estimate the platform’s motion.

It knows that every sensor contains errors.

Before performing any navigation calculations, it must verify that the measurements are reliable, update its internal sensor models, and apply the appropriate compensation algorithms.

In other words, reading data from the IMU is only the gateway into the navigation system.

The actual navigation process has not yet begun.

The Next Step – Error Compensation Begins Before Navigation Calculations

Once the measurements have been successfully received, the navigation algorithm still does not use them to estimate the platform’s attitude or position.

Instead, it begins by answering a simple question:

Are these measurements describing the real world, or are they also reflecting the sensor’s own imperfections?

This is far from a theoretical concern.

Every gyroscope and every accelerometer is affected by bias, temperature-dependent errors, electronic noise, and small residual inaccuracies that remain even after factory calibration.

If these errors are ignored, they become part of the navigation solution, accumulate over time through continuous integration, and eventually produce significant drift in the estimated position.

For this reason, one of the first tasks performed by the software is to compensate for known sensor errors before any navigation calculations take place.

In pseudocode, this might look like:

correctBias(sample);

temperatureCompensation(sample);

Only two lines of code.

Yet each represents a sophisticated processing stage.

For example, correctBias() does far more than subtract a fixed value from each measurement.

It may use calibration coefficients determined during factory testing, parameters learned while the system is operating, or bias estimates that are continuously updated by the Kalman Filter as new information becomes available.

Similarly, temperatureCompensation() is much more than a simple temperature check.

In advanced navigation systems, it relies on calibration models developed over a wide temperature range to predict how thermal changes affect each individual sensor axis, allowing those effects to be compensated before the measurements are used.

You can think of these functions as the system’s data-cleaning stage.

Before the navigation algorithm trusts the measurements, it first removes as much of the sensor’s known behavior as possible, leaving data that more accurately represents the platform’s actual motion.

Only after the software determines that the measurements represent the platform’s motion as accurately as possible – rather than the limitations of the sensors – can the actual navigation calculations begin.

Raw IMU Data
      │
      ▼
Bias Compensation
      │
      ▼
Temperature Compensation
      │
      ▼
Validated Sensor Data
      │
      ▼
Navigation Algorithm

Figure 10 – IMU Measurement Preprocessing.

Before the navigation calculations begin, the algorithm compensates for known sensor errors such as bias and temperature-dependent effects. The objective of this preprocessing stage is to ensure that the subsequent navigation algorithms operate on measurements that represent the platform’s true motion as accurately as possible, rather than the inherent limitations of the measurement system.

A Numerical Example – Calculating a Change in Orientation

Assume the IMU reports the following measurement:

Sampling Rate : 1000 Hz

Δt = 0.001 s

Gyro Z = 20.0 °/s

This means the sensor measures that the platform is rotating about the Z-axis at a rate of 20 degrees per second.

The navigation algorithm, however, is not interested in how many degrees the platform will rotate over the next second.

It only needs to know what happened during the last millisecond.

It therefore performs the following calculation:

Angle Change

Δθ = ω × Δt

Δθ = 20 × 0.001

Δθ = 0.02°

In other words, during the last sampling interval, the platform rotated by only

0.02°.

At first glance, this seems like a tiny angle.

However, when this calculation is repeated 1,000 times every second, the algorithm can continuously track the platform’s orientation with extremely high temporal resolution.

In pseudocode, the calculation might look like this:

double dt = 0.001;

Vector3 deltaAngle;

deltaAngle.x = gyro.x * dt;
deltaAngle.y = gyro.y * dt;
deltaAngle.z = gyro.z * dt;

At this stage, the algorithm is not calculating the platform’s Roll, Pitch, or Yaw angles.

Instead, it is computing only how much the platform has rotated since the previous IMU sample.

This illustrates the fundamental difference between angular rate and angle.

The gyroscope measures angular velocity.

The navigation algorithm converts that angular velocity into an incremental rotation by integrating it over time.

The next line of code is one of the most important operations in an Inertial Navigation System.

attitude.update(deltaAngle);

Although it appears to be a single function call, it encapsulates the mathematical operations that update the platform’s orientation in three-dimensional space.

Modern navigation systems do not update orientation by simply adding Roll, Pitch, and Yaw angles together.

Instead, they update an internal mathematical representation of rotation – typically a quaternion – which allows thousands of orientation updates per second while maintaining numerical stability and avoiding singularities such as Gimbal Lock.

The navigation algorithm combines both estimates and determines the most probable orientation of the platform.

Gyroscope Measurements
        │
        ▼
Attitude Prediction Model
        │
        ▼
Predicted Attitude
        ▲
        │
Gravity Vector from Accelerometer
        │
        ▼
Kalman Filter / Sensor Fusion
        │
        ▼
Corrected Attitude

Figure 12 – The Principle of Sensor Fusion in an Inertial Navigation System.

The navigation algorithm combines the gyroscope’s fast and responsive estimate of rotational motion with the gravity reference provided by the accelerometer. Using sensor fusion techniques – typically implemented with a Kalman Filter or a similar state estimation algorithm – it continuously refines the platform’s attitude estimate. The result is an orientation solution that is both highly responsive to rapid maneuvers and stable over long periods of operation.

What Happens When a GNSS Measurement Becomes Available?

Up to this point, the navigation system has relied entirely on the IMU.

It has estimated the platform’s attitude using the gyroscopes, calculated linear acceleration from the accelerometers, and integrated those measurements to estimate velocity and position.

This approach offers a major advantage.

It operates continuously and does not depend on any external source of information.

However, it also has a fundamental limitation.

Every small error in the sensor measurements accumulates over time.

Even if the error introduced during each processing cycle is almost negligible, after minutes or hours of operation it can grow into a significant navigation error.

For this reason, when a position measurement becomes available from a GNSS receiver, the navigation algorithm does not replace the INS solution.

Instead, it compares the two independent estimates.

On one side is the position predicted by the INS.

On the other is the position measured by the GNSS receiver.

The difference between them is called the innovation (or measurement residual), and it forms the basis of the correction process.

For example:

INS Position

X = 1245.32 m
Y = 842.17 m

GNSS Position

X = 1245.08 m
Y = 842.51 m

In this example, the algorithm detects that the inertial solution differs from the external measurement by only a few tens of centimeters.

It does not immediately jump to the GNSS position.

Instead, it evaluates whether the discrepancy is the result of drift in the INS or simply temporary noise in the GNSS measurement.

Only after this evaluation does the navigation system perform a controlled update of its internal state.

In pseudocode, the process might look like this:

State prediction = ins.predict();

GNSSMeasurement gnss = receiver.read();

Innovation innovation =
    gnss.position - prediction.position;

kalman.correct(innovation);

The kalman.correct() function does far more than adjust the estimated position.

Modern navigation systems may use this correction step to update not only the platform’s position, but also:

• Position
• Velocity
• Attitude
• Gyroscope bias
• Accelerometer bias

In other words, a single GNSS measurement can improve the accuracy of many elements of the navigation state – not just the platform’s geographic coordinates.

This is why the Kalman Filter is often described as doing much more than “correcting the position.”

It updates the entire state estimate.

INS Prediction
      │
      ▼
Predicted Position
      │
      ├────────── GNSS Position
      │
      ▼
Innovation (Error)
      │
      ▼
Kalman Correction
      │
      ▼
Updated Navigation State

Figure 13 – Correcting the INS Solution Using a GNSS Measurement.

Whenever a GNSS measurement becomes available, the navigation algorithm compares it with the position predicted by the INS. The difference between the two, known as the innovation (or measurement residual), is processed by the Kalman Filter to update the system’s state estimate. Rather than simply correcting the platform’s position, the filter may also refine estimates of velocity, attitude, and sensor biases, reducing accumulated drift and improving the overall accuracy and stability of the navigation solution over time.

🧩 Further Reading and Deeper Insight

This article is part of a broader series exploring the engineering principles behind modern inertial sensing and motion stability in advanced control and navigation systems. For deeper technical context and system-level insights, you may also find the following articles valuable:

• Bridging Control and Navigation: How Advanced MEMS IMUs Are Redefining System Performance
• Gyro and IMU for Advanced Control Systems
• The Silent Problem of Precision Systems – Why Gyros and IMUs Are Control Components, Not Just Sensors
• Why External Sync is Critical in Gyro and IMU Systems
• Stabilization, Tracking & Time Sync: The Foundation of Precise Line-of-Sight Control
• Mission-Grade Stabilization in Dynamic EO/IR Systems: Why Bandwidth, Data Rate, and Phase Lag Define Gimbal Performance
• Why Gladiator? What Truly Differentiates a High-End MEMS IMU Manufacturer
• Common Misconceptions About MEMS Inertial Sensors
• Bias Stability vs. Bias Instability: What really determines the performance of Gyro and IMU systems in stabilization, tracking, and navigation
• Scale Factor in MEMS IMUs – The Error That Quietly Destroys Accuracy
• The IMU Was Excellent. The Image Still Shook.
• 2000Hz IMU? Before You Get Impressed, Understand Three Completely Different Numbers
• SX3: Pushing MEMS Beyond Traditional Stabilization
• Why a Smaller IMU Can Save Months of Development
• Your Image Still Shakes Despite Choosing a Gyroscope with Excellent Bias Stability
• Why Replacing an IMU Can Lead to Weeks of Recalibration
• From IMU to INS: How a Tactical Navigation System Is Really Built

Frequently Asked Questions (FAQ)

Does this article explain everything required to build an INS?

No.

The goal of this article is to explain the fundamental principles of an Inertial Navigation System in a practical and accessible way. Operational navigation systems incorporate many additional algorithms and implementation details, each of which could easily justify an article of its own.

What is an Error-State Kalman Filter (ESKF)?

In modern INS architectures, the Kalman Filter usually does not estimate position, velocity, and attitude directly.

Instead, it estimates the errors associated with those quantities.

This approach, known as the Error-State Kalman Filter (ESKF), improves numerical stability, simplifies the estimation process, and enables more accurate corrections over long periods of operation. Today, it is one of the most widely used architectures in professional inertial navigation systems.

Why are quaternions used instead of Roll, Pitch, and Yaw?

Euler angles (Roll, Pitch, and Yaw) are intuitive and convenient for displaying orientation to the user, but they are not well suited for continuous mathematical calculations.

Most INS algorithms use quaternions, which provide a compact and numerically stable representation of three-dimensional rotation while avoiding singularities such as Gimbal Lock. This allows the orientation to be updated millions of times without losing accuracy.

What are Earth-centered reference frames (ECEF and NED)?

Every navigation system must define the coordinate frame in which it operates.

Many INS implementations use reference frames such as ECEF (Earth-Centered, Earth-Fixed) or NED (North-East-Down) to express the platform’s position, velocity, and orientation relative to the Earth.

What is Coning and Sculling Compensation?

When a platform experiences rapid rotational and translational motion, simply integrating the IMU measurements is no longer sufficiently accurate.

Coning Compensation and Sculling Compensation correct integration errors that arise from complex motion between consecutive IMU samples, significantly improving navigation accuracy, particularly in high-dynamic applications and high-sampling-rate systems.

What is Lever Arm Compensation?

In many systems, the GNSS antenna is not located at the same physical position as the IMU.

The distance between them, known as the lever arm, introduces measurement differences whenever the platform rotates or accelerates.

Lever Arm Compensation accounts for this offset, allowing the GNSS and IMU measurements to be fused more accurately.

What is Zero Velocity Update (ZUPT)?

In applications where the platform periodically comes to a complete stop, the navigation system can use this information to reset the estimated velocity.

This technique, known as Zero Velocity Update (ZUPT), greatly reduces accumulated drift and is widely used in pedestrian navigation, mobile robotics, and autonomous ground vehicles.

What is GNSS/INS Tight Coupling?

In loosely coupled systems, the INS receives only the final position solution produced by the GNSS receiver.

In tight coupling architectures, the navigation algorithm processes raw satellite measurements directly within the Kalman Filter.

This approach enables reliable navigation even when only a limited number of satellites are visible or when GNSS signal quality is degraded.

Why do some systems use multiple GNSS antennas?

Navigation systems equipped with two or more GNSS antennas can estimate the platform’s heading directly, even while stationary.

This capability is particularly valuable for aircraft, marine vessels, autonomous vehicles, and stabilized platforms that require an accurate heading before movement begins.

What is RTK Integration?

RTK (Real-Time Kinematic) improves GNSS positioning accuracy by using correction data from a reference station in real time.

When RTK is integrated with a high-quality INS, positioning accuracy can reach the centimeter level while maintaining continuous navigation during brief GNSS outages.

Does every INS use all of these algorithms?

No.

The algorithms implemented in an INS depend on the application’s performance requirements, the desired level of accuracy, the available processing resources, and the quality of the inertial sensors.

For example, the navigation system of a commercial drone is fundamentally different from that of a missile, an aircraft, or an autonomous vehicle, even though all of them may be described as INS.