The C11 core is built for constrained navigation hardware
INSLIB combines inertial measurements with GNSS, barometer, magnetometer, local position, ground speed, and zero-motion observations. Its C11 core avoids heap allocation and operating-system dependencies, which makes it suitable for a microcontroller as well as a desktop replay. Separate entry points cover attitude, inertial navigation, barometric altitude, and a combined navigation suite.
The repository is much larger than a filter library. Our checkout held 366 files, about 98,003 lines of source, and 226.6 MB before the Python environment was installed. It includes real and simulated datasets, plotting tools, calibration software, a UDP receiver, a requirements database, and a PDF manual. That breadth is useful for evaluation, though it creates more integration edges than the compact C API suggests.
Traceability and bounded execution are first-class concerns
The README links logic to machine-checked requirements and publishes core coverage plus MC/DC tracking. It also describes static stack analysis, checks for recursion and variable-length arrays, sanitizer runs, and bounded loops. These are relevant controls for embedded work because memory use and execution paths must be inspectable before code reaches a controller.
They are evidence of engineering discipline, not a certification certificate. The README references methods used in DO-178 DAL-A and ISO 26262 ASIL-D work without saying INSLIB itself has been certified. A flight or automotive program still needs its own requirements baseline, compiler qualification decisions, hardware tests, safety analysis, and change control. AGPL-3.0 obligations also need review before the core enters a closed product.
What happened when we ran it
Our sandbox installed commit 4d13deb in 34 seconds with Python 3.12 on Debian, 3 CPUs, and 8 GB of RAM. The Python environment pulled 63 packages and used 551 MB. The build completed successfully in 4 seconds, and pip-audit reported 0 known vulnerabilities. The repository had one CI workflow, no Dockerfile, and a tests directory.
Pytest failed after 15 seconds. Its summary reported 81 passed, 11 failed, 7 skipped, and 5 collection or setup errors out of 97. Nine named protocol failures attempted to read firmware headers such as cfg_keys.h, ubx.h, cfg_ubx.h, and an IMU saturation header from paths under /work/repo/embedded/stm32f429, but those files were not found.
Two runner tests failed because the INSLIB Python package could not find the libINSLIB shared library. Their error explicitly said to build it with make pylib. The final log does not explain the 5 collection/setup errors or why the embedded header tree was missing. We can report the absent paths and native library, but assigning them to a bad clone, packaging defect, or undocumented prerequisite would go beyond the evidence.
Python setup still depends on the native build
The README's quick start runs python/setup_venv.sh, which also invokes make pylib, then activates env.sh. Replay takes a dataset directory containing sensor CSV files and a YAML configuration. The GUI uses the same inputs. The core itself only needs a C11 compiler and make, but the full repository checks add formatters, static analyzers, coverage tools, and documentation generation.
The KFCore dependency is a git submodule, so the documented clone uses --recursive. That detail matters on build systems that fetch source archives or disable submodules. Exact formatting-tool versions matter too, according to the README. INSLIB provides a script to obtain the CI clang-format version when the host does not match Ubuntu 22.04. Reproducibility requires more than installing the 63 Python packages we measured.
Sensor preparation will decide whether the filter helps
The common-pitfalls section is one of the best parts of the project. Every sensor needs a shared monotonic clock and a consistent forward-right-down body frame. Magnetometers need hard-iron and soft-iron calibration. The configuration must account for the antenna lever arm, GNSS processing delay, vibration filtering, sensor noise, and temperature drift. A mathematically sound filter cannot recover information damaged before it arrives.
INSLIB includes tools for IMU and magnetometer calibration, GNSS delay estimation, replay, and board configuration. It also provides datasets with tunnel outages, pedestrian runs, UAV ground truth, and simulated references. These assets help a team ask whether its own sensor chain resembles the examples. They do not replace tests on the final antenna placement, enclosure, vibration spectrum, clock source, or motion profile.
The public code stops before the reference-board firmware
The repository documents an open UBX-based protocol and provides desktop tools for its reference board. The README says the board firmware itself is not public, with collaboration available through the author's university institute. You can build another sensor suite, but you then own its firmware, timestamp discipline, calibration storage, packet production, and electrical integration.
Release v1.1.1 arrived on September 28, 2026, the same date as the last recorded push. It added dual-antenna heading post-processing and range aiding, then fixed several lever-arm behaviors. GitHub showed 584 stars and no open issues or pull requests. The release and push show current maintenance; an empty issue queue alone cannot tell us how many outside deployments exist.
INSLIB is compelling when you need inspectable embedded navigation code and have the expertise to test the whole sensor chain. Its documentation is frank about the parts most likely to ruin an estimate. Our failed Python suite means the repository's desktop integration needs investigation at commit 4d13deb before adoption. Start by reproducing make pylib, locating the expected firmware headers, and running the complete suite on the exact source tree you plan to ship.