BIEVR-LIO: bump-image voxel maps keep LiDAR odometry alive where geometry runs out

The problem: uninformative geometry

LiDAR-inertial odometry works by matching each new scan against a map, and matching needs something to match against. In a long tunnel, a flat parking structure or a foggy field, the geometry is repetitive or nearly empty, point cloud registration loses its constraints, and the estimated trajectory drifts or diverges entirely. The README's abstract states the target plainly: mobile robots entering challenging environments where little information exists to constrain registration.

BIEVR-LIO, from ETH Zurich's autonomous systems lab, is built for exactly those scenes. Its response is representational: store the world at higher resolution than usual, in a form that preserves subtle surface variation, and spend the registration effort where that variation actually lives. The claim attached is state-of-the-art performance in well-constrained scenes and substantial improvements in the challenging scenarios where baseline methods diverge, demonstrated across multiple sensors, platforms and environments.

Bump images: the map representation

The core idea is a map that stores surfaces as voxel-wise oriented height images, which the README calls bump images: within each voxel, a small image of the surface's fine height variation along its dominant direction. Two properties follow. Registration can use these images directly, without computing intermediate geometric primitives such as planes or edges, and the map still supports efficient updates as new scans arrive.

The payoff shows up in information-sparse scenes. A corridor wall that a plane-based map collapses into one flat surface retains its bumps, seams and slight variations in a bump-image map, and those subtleties are precisely the constraints registration needs when nothing else in the environment helps. The abstract also notes a downstream dividend: the fine-grained geometry supports tasks beyond odometry, with elevation mapping for robot locomotion given as the example.

Sampling where the information is

High-resolution maps create their own problem: most points add nothing, because informative geometry is sparsely distributed. BIEVR-LIO's answer is a map-informed point sampling strategy that focuses registration on geometrically informative regions instead of sampling globally at high resolution.

The claimed effect is twofold and points in opposite, useful directions: resilience improves in uninformative environments, because the optimizer's budget concentrates on the few constraints that exist, and computational cost drops compared to global high-resolution sampling, because the uninformative majority is skipped. Combined with the bump-image representation, this is the paper's practical thesis, and the abstract ties it to the experimental finding that baselines diverge where this method holds.

Installing: docker first, then catkin or colcon

The core estimator has deliberately light dependencies, only Eigen and Ceres, and the README offers a container route for a first look without setting anything up:

cd docker/
./run_docker_ros1.sh -b

The -b flag builds the image, later runs reuse it, and your ~/data folder is mounted into the container so datasets stay outside. A native ROS1 Noetic build uses catkin, with a repository script that builds Ceres 2.2.0 from source:

sudo ./BIEVR-LIO/docker/scripts/install_ceres.sh

then the standard workspace flow: catkin init, extend /opt/ros/noetic, clone into src, and catkin build bievr_lio_ros followed by sourcing devel/setup.bash. On the ROS2 side the same structure exists with colcon and Jazzy, which the README says was the tested distribution while noting others may work. Livox owners have optional support: generation one and two drivers are compiled in only if they are present in the workspace at build time, each with its Livox SDK installed system-wide.

Running it: live topics or bags at full speed

Two entry points serve both ROS versions. process_topics runs online, subscribing to the LiDAR and IMU topics for a live sensor or alongside a rosbag play. process_bag reads a recorded bag directly and pushes messages through the pipeline as fast as they can be processed, no real-time playback, which the README names as the preferred route for offline evaluation and reproducing results.

Launch commands take a sensor_config parameter selecting one of the per-sensor configurations shipped in config/, with rviz as an optional flag for visualization. Configuration is split in two files by concern: params.yaml holds the algorithm parameters, map resolution, sampling and optimization settings, and the README says these defaults are validated across a wide range of sensors and typically do not need adjustment; sensor_configs hold the per-dataset details, topic names, LiDAR-to-IMU extrinsics and range limits, which are the parts every deployment must get right.

Architecture: a ROS-independent core

The repository separates the estimator from its wrappers. The bievr_lio core is a self-contained, ROS-independent library, and the ROS1 and ROS2 interfaces live side by side under interfaces/, which is why the project can maintain continuous-integration builds for ROS Noetic, ROS2 Humble and ROS2 Jazzy simultaneously.

For a robotics team this shape matters as much as the accuracy numbers. The algorithm can be adopted without adopting a middleware, evaluated through the Docker images on any of three ROS generations, and upgraded across ROS versions without touching the estimator. The BSD-3-Clause licence covers the whole tree, the arXiv paper is linked from the README, and one release is published with the last push on 2026-08-18, so the release cadence is early but the packaging is already disciplined.

Where it sits among the odometry options

LiDAR-inertial odometry is a mature field with established baselines, and BIEVR-LIO's positioning is not accuracy on easy data, where it claims state-of-the-art parity, but survival on hard data, where it claims baselines diverge. The representational bet, fine surface detail kept per voxel, trades map memory for resilience, and the sampling strategy is what keeps that trade affordable.

For a team choosing an odometry stack, the decision inputs in the README are concrete: light dependencies, Eigen and Ceres only, for the core; per-sensor configs already shipped for the datasets the authors used; a bag-processing mode that reproduces results at full speed; and the elevation-mapping demonstration as evidence the map representation carries information usable beyond localization. Whether its bump images beat your current stack on your tunnel, parking garage or field is exactly what the process_bag entry point exists to find out.

Editorial conclusion

BIEVR-LIO fits robotics teams whose LiDAR-inertial odometry drifts in tunnels, corridors and other geometrically sparse scenes, and who can accept a ROS1 or ROS2 deployment with Eigen and Ceres as the only hard dependencies. Skip it if your environment is information-rich and your current odometry holds, since the bump-image map spends memory on detail you may not need. Verify on your own worst dataset: run the process_bag entry point with the sensor configs in config/, and compare trajectory drift against your current stack where your current stack is at its worst.

Frequently asked questions

Official sources

1. ethz-asl/BIEVR-LIO on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases