INSLIB: Aviation-Grade Inertial Navigation Library with DO-178C Discipline in C

Why Inertial Navigation Is Hard

An IMU contains a gyroscope measuring angular rate and an accelerometer measuring linear acceleration. In theory, integrating angular rate yields attitude, and double-integrating acceleration yields position. However, integration amplifies errors: gyroscope bias, accelerometer scale factor errors, and misalignment accumulate non-linearly, causing position drift of tens of meters within seconds. Pure dead reckoning is therefore only viable for very short durations.

Kalman Filtering as the Standard Solution

Kalman filtering fuses continuous IMU propagation with absolute measurements from GNSS, barometer, and magnetometer. Each sensor has known noise statistics; the filter dynamically weights them to produce an optimal estimate. While the mathematics is well understood, achieving aviation-grade robustness in implementation is rare in open source.

Three Pillars of Aviation-Grade Engineering Discipline

INSLIB targets DO-178C DAL-A (civil aviation flight control) and ISO 26262 ASIL-D (automotive functional safety) levels of rigor:

MC/DC test coverage >90% : Modified Condition/Decision Coverage requires every logical branch condition combination to be exercised. Test code often exceeds implementation code in size.

Requirements traceability : Every code segment links to a machine-checkable requirements database ( make reqs verifies). Changes can be impact-analyzed precisely.

Numerical stability via UDU/Bierman-Thornton square-root filtering : Standard covariance propagation becomes ill-conditioned; UDU factorization keeps the covariance matrix well-behaved. Crucially, the filter runs stably on 32-bit IEEE 754 floats without requiring 64-bit hardware — decisive for MCUs lacking double-precision FPUs.

Embedded-First Architecture

Pure C11, zero external dependencies; builds with a C11 compiler and make.

No heap allocation — all memory static, eliminating fragmentation and leaks.

No OS dependency — runs bare-metal or on Linux/Windows.

No recursion, no unbounded loops — worst-case execution time (WCET) is predictable for real-time control loops.

These constraints mean the library runs on a low-cost STM32-class MCU with guaranteed real-time behavior.

Multi-Sensor Fusion Beyond IMU+GNSS

Barometer : Parallel vertical channel ( baro_alt) maintains altitude and attitude during GNSS outages.

Magnetometer : Built-in lightweight World Magnetic Model (WMM) for declination compensation.

GNSS dual-antenna compass : Direct heading observation.

OBD-II vehicle speed : Wheel-speed aiding from automotive CAN bus.

ZUPT/ZARU : Zero-velocity and zero-angular-rate virtual sensors for pedestrian/robot platforms.

Local motion capture (mocap) : Indoor positioning systems like Lighthouse.

A notable detail: GNSS latency estimation . Receivers introduce 100–200 ms processing/transmission delay; uncompensated, this biases dynamic position. INSLIB provides --estimate-gnss-delay which cross-correlates IMU+baro vertical velocity with GNSS-reported vertical velocity to measure true latency.

Achievable Precision with Augmentation Services

Galileo HAS (free) : Horizontal <10 cm (1-sigma), no correction service needed.

u-blox SPARTN/PointPerfect Flex (commercial) : 3–6 cm, convergence in seconds.

RTK via NTRIP : 1 cm, requires local base station or regional service (e.g., Germany SAPOS).

Centimeter-level accuracy enables precision landing versus approximate area positioning.

Two Ways to Get Started

1. Software replay with real datasets (easiest). The repo includes datasets: Crazyflie 2.1 drone, rotorcraft (MEMS vs fiber-optic gyro comparison), automotive tunnel (GNSS loss), handheld pedestrian. A Python script replays data and emits PDF plots and Google Earth KML:

sh python/setup_venv.sh  # one-time venv creation
. env.sh                 # activate
python3 python/replay.py datasets/fog --plot --plot-out /tmp/plots.pdf

2. Live hardware integration . An open UBX-based protocol ( inslib_protocol.md) feeds arbitrary sensors via UDP port 29800 into insrcv, which outputs to PlotJuggler for visualization and can bridge to MAVLink for ground stations.

Positioning Among Peers

ArduPilot EKF3 : Mature but welded into the flight stack; not usable as an independent library.

KF-GINS : Academic GNSS/INS library from Wuhan University i2Nav; INSLIB's README includes comparative datasets.

robot_pose_ekf : Legacy ROS EKF, unmaintained, simpler scope.

MATLAB Navigation Toolbox : Commercial, closed-source, expensive.

INSLIB's niche: a standalone, aviation-grade engineered, bare-metal-capable C library — neither coupled to specific hardware nor a mere teaching demo.

Who Should (and Should Not) Use It

Suitable for :

Drone, robot, autonomous driving teams needing an independently integrable, hardware-ready navigation filter.

Embedded developers targeting MCUs without FPU or with tight memory.

Safety-critical engineers studying DO-178C/ISO 26262 reference implementations.

Not suitable for :

Hobbyists wanting quick position fixes without sensor calibration effort (README lists common pitfalls: uncalibrated magnetometer, IMU calibrated on ferromagnetic surface, missing GNSS antenna lever arm, timestamp misalignment — each can corrupt output).

Closed-source commercial products (AGPL-3.0 requires source disclosure).

Transparent AI-Assisted Development

The README explicitly states:

Core library ( src/ and KFCore) hand-designed by a 20-year veteran engineer.

README written by a human.

Real datasets collected, analyzed, and tested by humans.

Code extensions and comments assisted by Claude, but all human-reviewed, no auto-commits. insrcv, unit tests, build system, and Python GUI tools largely written by Claude.

This "AI-accelerated, human-gated" transparency is itself an engineering stance: in a domain where a single decimal-place error cascades into total failure, human judgment remains the final safety net.