opensourceprojects.dev

A broadsheet for software that doesn't ask for your email

LiDAR-inertial odometry that works across platforms without sensor-specific tuni...
GitHub RepoImpressions3

Project Description

View on GitHub

LiDAR-Inertial Odometry That Doesn't Make You Tune for Every Sensor

If you've ever set up a LiDAR-inertial odometry pipeline, you know the drill: the sensor-specific modelling, the parameter tuning, the slow realization that the config that worked on one platform won't transfer to the next. RKO-LIO from the University of Bonn's PRBonn group takes a different approach—robust LiDAR-inertial odometry without sensor-specific modelling. The project's own tagline says it best: four different platforms, four different environments, one odometry system.

What It Does

RKO-LIO is a LiDAR-inertial odometry system designed to work across platforms without requiring you to model or tune for each specific sensor. It's published in IEEE RA-L (with a preprint on arXiv), and it's available both as a Python package on PyPI and as a ROS package across several distributions—Humble, Jazzy, Kilted, Lyrical, and Rolling.

The core pitch is portability of configuration: instead of adapting the algorithm to every sensor, the system aims to stay robust across them. It consumes rosbags (both ROS1 and ROS2 are supported) and produces odometry, with an optional visualizer built on rerun. The README is upfront that this is still early days for the broader ecosystem—if you want loop closures, a pose graph back-end, and drift correction, you're pointed toward the companion project, rko_slam.

Why It's Cool

  • No sensor-specific modelling is the whole point. Most LIO stacks ask you to characterize your LiDAR and IMU before you get useful results. RKO-LIO's framing suggests you can skip that step and still get robust odometry across platforms. That's a meaningful reduction in setup friction if it holds up on your hardware.

  • The Python path is genuinely quick. A three-package pip install gets you running on a rosbag directory. The rko_lio[all] extra pulls in the optional dependencies, and a single CLI command with a -v flag gives you odometry plus visualization. No ROS workspace build required if you just want to try it.

  • Both bag formats, one dataloader. The rosbags dependency handles ROS1 and ROS2 bags alike, which is a small but practical convenience when you're working across mixed datasets.

  • Sensible CLI ergonomics. You can dump a default config with rko_lio --dump_config, edit it, and pass it back with --config. That's a low-friction way to see what's tunable without digging through docs first.

  • Explicit extrinsics handling. The system needs the IMU-to-LiDAR extrinsic. If your data carries it, the dataloaders try to read it automatically; if not, you supply it in a config file with two required keys—extrinsic_imu2base_quat_xyzw_xyz and extrinsic_lidar2base_quat_xyzw_xyz. The README also spells out its transform convention carefully (transform_<from-frame>2<to-frame>), which saves you from the classic ambiguity about which direction a transform points.

How to Try It

  1. Install the package along with the bag loader and visualizer:
pip install "rko_lio[all]"
# or
pip install rko_lio rosbags "rerun-sdk>=0.31"
  1. Point it at your data. The path should be a directory containing *.bag files (ROS1) or a metadata.yaml (ROS2):
rko_lio -v /path/to/data
  1. If your data doesn't include the IMU-to-LiDAR extrinsic, dump a config, fill in the two required keys, and pass it back:
rko_lio --dump_config
rko_lio --config config_file.yaml
  1. Check rko_lio --help for the rest of the CLI options, and the Python docs for more detail. If you'd rather work in ROS, the package is on the ROS index for the distributions listed above.

The repository is at github.com/prbonn/rko_lio.

Final Thoughts

RKO-LIO is best suited to people who work with multiple LiDAR-inertial setups and are tired of re-tuning per sensor—or to anyone who wants to evaluate a bag quickly without building out a full SLAM stack. The honest caveat is in the README itself: this is an odometry component, not a complete SLAM system, and the authors are candid that it's early days. If you need loop closure and drift correction today, pair it with rko_slam. If you want a low-ceremony way to get robust odometry running from a pip install, this is a solid place to start.

Back to Projects
Project ID: 83c90c42-ac31-4d77-bd51-a25329426285Last updated: October 22, 2026 at 06:02 PM