Industry Research

Appearance

HDL Graph SLAM: 3D LiDAR-Based Graph SLAM ​

Related localization docs: SLAM algorithms, production LiDAR map localization, and map construction pipeline.

Executive Summary ​

HDL Graph SLAM is a practical ROS package for real-time 6-DoF graph-based SLAM with 3D LiDAR. Created by Kenji Koide, it combines scan matching, keyframe-based pose graph optimization, loop detection, and optional constraints from GPS, IMU orientation, IMU acceleration, odometry, and detected floor planes. Unlike LOAM-family methods, its front end is commonly based on NDT scan matching rather than edge/plane feature extraction.

The method is important because it is an engineering-oriented package rather than only a paper algorithm. It exposes the pieces needed for field mapping: keyframes, graph edges, loop closures, map export, GPS constraints, floor constraints, and integration with ROS sensor streams. It has been tested with Velodyne HDL-32E, VLP-16, and RoboSense 16-channel sensors in indoor and outdoor environments.

For airside work, HDL Graph SLAM is most relevant as an offline or near-online survey mapping tool. Its support for GPS and floor-plane constraints matches airport conditions well: open sky often provides GNSS, and ground surfaces provide roll/pitch/height priors. However, the package is ROS1-era, parameter-sensitive, not a production runtime localizer, and less suitable than modern LiDAR-inertial systems for high-rate safety-critical vehicle state estimation.

Historical Context ​

HDL Graph SLAM emerged from the practical robotics need to build maps with 3D LiDAR while fusing additional constraints when available. The repository describes it as an open-source ROS package for real-time 6-DoF SLAM using a 3D LiDAR, based on 3D graph SLAM with NDT scan-matching odometry and loop detection.

The package is associated with Koide's work on portable 3D LiDAR mapping and long-term people behavior measurement. In that system, an observer carried a backpack with a Velodyne HDL-32E and PC. Mapping was performed offline with graph-optimization-based SLAM, using floor-plane constraints indoors and GPS constraints outdoors to reduce accumulated rotational or positional drift.

HDL Graph SLAM became a widely used baseline because it offered a complete ROS pipeline while being easier to deploy than research-only code. It also influenced later Koide projects such as Interactive SLAM for manual map correction and GLIM for modern range-inertial mapping.

Sensor Assumptions ​

HDL Graph SLAM assumes a 3D point cloud stream and benefits from auxiliary sensors.

Core sensor assumptions:

  • A 3D LiDAR with sufficient overlap between consecutive scans.
  • Stable extrinsic calibration between LiDAR and base frame.
  • Accurate timestamps for LiDAR and optional sensor topics.
  • A ROS TF tree consistent with the robot base and sensor frames.
  • Enough geometric structure for NDT/GICP-style scan matching.

Optional inputs:

  • GPS position constraints for outdoor mapping.
  • IMU acceleration constraints for gravity direction.
  • IMU orientation constraints, including magnetic heading where available.
  • Wheel odometry or other relative motion priors.
  • Floor-plane constraints detected from the point cloud.

The package is flexible across common spinning LiDARs, but registration quality still depends heavily on voxel resolution, downsampling, initial guesses, and environment structure.

Map Representation ​

HDL Graph SLAM represents the map through keyframes and a pose graph.

Main elements:

  • Keyframe point clouds: Selected scans stored with estimated poses.
  • Pose graph vertices: Vehicle or sensor poses at keyframe times.
  • Odometry edges: Relative pose constraints from scan matching between sequential keyframes.
  • Loop closure edges: Relative pose constraints between revisited places.
  • GPS edges: Absolute or semi-absolute position constraints.
  • IMU/floor edges: Orientation, gravity, and plane constraints.
  • Global point cloud map: Generated by transforming keyframe clouds with optimized poses.

The front-end local matching often uses NDT or related registration over downsampled clouds. The back end optimizes the graph so that all constraints are jointly balanced.

This representation is well suited to offline HD map construction because individual keyframes can be inspected, removed, corrected, or reoptimized. It is less compact than a production runtime localization map unless post-processed into tiles, voxels, surfels, or NDT cells.

Algorithm Pipeline ​

  1. Point cloud preprocessing

    • Transform incoming LiDAR scans into the target frame.
    • Downsample clouds with voxel filtering.
    • Optionally remove outliers or crop ranges.

  2. Scan matching odometry

    • Register each new scan or keyframe candidate against the previous keyframe or local target.
    • Use NDT/GICP-style registration depending on configuration.
    • Produce a relative pose estimate and registration score.

  3. Keyframe selection

    • Add a keyframe when translation, rotation, or elapsed time exceeds thresholds.
    • Store the downsampled point cloud and pose.

  4. Graph construction

    • Add a vertex for each keyframe.
    • Add odometry edges from scan matching.
    • Add GPS, IMU, floor-plane, and odometry-prior edges when available.

  5. Loop detection and loop constraint creation

    • Search historical keyframes for plausible revisits.
    • Register candidate clouds.
    • Add loop closure edges when registration passes validation gates.

  6. Graph optimization

    • Optimize the pose graph with nonlinear least squares.
    • Use robust kernels where appropriate to reduce outlier influence.
    • Update all keyframe poses.

  7. Map generation

    • Transform keyframe clouds by optimized poses.
    • Aggregate and downsample for a global point cloud map.
    • Export for inspection, localization, or map construction post-processing.

Formulation ​

The back end is a pose graph optimization problem:

text
X* = arg min_X
     sum_(i,j) || e_lidar(X_i, X_j, Z_ij) ||^2_Omega_ij
   + sum_i     || e_gps(X_i, z_i) ||^2_Omega_gps
   + sum_i     || e_imu(X_i, z_i) ||^2_Omega_imu
   + sum_i     || e_floor(X_i, pi_i) ||^2_Omega_floor

where:

  • X_i is the pose of keyframe i.
  • Z_ij is a relative pose from scan matching.
  • e_lidar is the relative-pose residual between keyframes.
  • e_gps constrains global position.
  • e_imu constrains gravity or orientation.
  • e_floor constrains pose against a detected floor plane.
  • Omega terms are information matrices.

The front-end scan matching is usually NDT-based. NDT divides space into cells, models local point distributions as Gaussians, and estimates the transform that maximizes the likelihood of the source points under the target distribution. In graph-SLAM form, the resulting transform becomes a relative constraint; the optimizer decides how much to trust it relative to other constraints.

The practical power of HDL Graph SLAM is the constraint mix. GPS can prevent global drift outdoors. Floor planes can stabilize indoor height, roll, and pitch. IMU orientation can keep the map upright. Loop closure can reduce long-term drift when revisits are detected correctly.

Failure Modes ​

  • NDT local minima: Poor initial guesses or repetitive geometry can cause incorrect scan alignment.
  • Sparse or planar scenes: Large open aprons, empty roads, and single-plane areas provide weak constraints.
  • Wrong loop closures: False loop edges can deform the entire map.
  • GPS outliers: Multipath near terminals, hangars, and aircraft can pull the graph if not robustly gated.
  • Floor-plane errors: Ramps, curbs, dock plates, drainage slopes, and non-flat ground can bias floor constraints.
  • Dynamic object pollution: Moving vehicles and people can degrade scan matching and map quality.
  • Parameter sensitivity: Voxel size, NDT resolution, keyframe spacing, loop search radius, and robust kernel settings matter.
  • Map scale and memory: Very large deployments can produce heavy keyframe maps and slower optimization.
  • Timing/extrinsic errors: Inconsistent sensor frames or timestamp offsets create systematic graph inconsistency.
  • ROS1 deployment age: The original package needs modernization for long-term production maintenance.

AV Relevance ​

HDL Graph SLAM is relevant to AVs as a mapping and graph-fusion baseline, not as a complete production localization stack.

Strengths for AV development:

  • Full pose graph structure instead of pure odometry.
  • Direct support for GPS and IMU constraints.
  • Works with common 3D LiDAR sensors.
  • Produces inspectable keyframe maps.
  • Useful for survey drives and map QA.
  • Aligns with factor-graph thinking used in production state estimation.

Limitations:

  • Runtime localization against a prebuilt HD map is a different problem.
  • NDT scan matching can be slower or less accurate than tuned VGICP in some production stacks.
  • The package does not provide the full health monitoring, covariance calibration, fallback hierarchy, and safety interfaces needed for deployed AVs.
  • It lacks modern dynamic-object filtering and semantic map validation.

For an AV program, HDL Graph SLAM is a useful reference implementation of graph constraints and offline mapping, while production LiDAR map localization should define the runtime scan-to-map module.

Indoor/Outdoor Relevance ​

Indoor: HDL Graph SLAM can be strong indoors because floor-plane constraints help keep the map level, and loop closure can correct repeated paths. It is suitable for warehouses, hangars, terminals, hospitals, and corridors if loop closures are validated carefully.

Outdoor: Outdoor use benefits from GPS constraints. The package is well suited to campus, road, yard, and industrial mapping when GNSS is available. In urban canyons, near terminal buildings, or under canopies, GPS gating becomes important.

Large-scale mixed deployments: Graph SLAM is a good fit for multi-session survey mapping because it can incorporate external priors and loop closures. However, very large maps require keyframe management, tiling, and offline optimization discipline.

Airside Deployment Notes ​

HDL Graph SLAM has several airside-friendly properties:

  • GPS constraints can anchor open-apron trajectories.
  • Floor-plane constraints match mostly flat apron and service-road surfaces.
  • Keyframe graph maps are inspectable during airport onboarding.
  • Loop closure can help around terminal service roads and stand loops.
  • The package has documented RoboSense 16-channel testing, relevant to cost-sensitive platforms.

Airside risks:

  • Aircraft stands can be geometrically repetitive.
  • Moving aircraft and GSE can create false alignment structure.
  • GNSS multipath near terminals and under jet bridges can be severe.
  • Open apron segments can be weak for LiDAR-only scan matching.
  • Floor plane constraints can hide real slope changes needed for precise docking or drainage-aware maps.

Recommended airside use:

  • Use for offline survey mapping experiments and comparison against modern LIO pipelines.
  • Add strict GPS outlier rejection and ground-control checkpoints.
  • Filter dynamic objects before map insertion.
  • Split airport maps into operational zones before optimization becomes too large.
  • Use interactive or manual correction tools for map QA if loop closures are ambiguous.
  • Convert the final point cloud into production map layers through the map construction pipeline.

Datasets/Metrics ​

Primary source contexts:

  • HDL Graph SLAM repository testing with Velodyne HDL-32E, VLP-16, and RoboSense 16-channel sensors indoors and outdoors.
  • Koide, Miura, and Menegatti's portable 3D LiDAR system, which used graph-optimization-based mapping with floor constraints indoors and GPS constraints outdoors.
  • Hospital and outdoor people-behavior measurement field tests from the associated paper.

Recommended metrics:

  • Absolute trajectory error against RTK/INS or surveyed ground control.
  • Relative pose error over keyframe intervals.
  • Loop closure precision and false-positive rate.
  • NDT fitness score distribution.
  • GPS residuals before and after optimization.
  • Floor-plane residuals and map levelness.
  • Map cloud thickness on walls, floors, curbs, and poles.
  • Keyframe count, optimization time, and memory growth.
  • Manual QA defect count per kilometer of map.

For airside work, evaluate separately on open apron, terminal edge, stand approach, service road, hangar indoor, under-canopy, and GNSS-degraded segments.

Open-Source Implementations ​

  • koide3/hdl_graph_slam: Primary package, BSD-2-Clause, ROS, real-time 6-DoF graph SLAM using 3D LiDAR.
  • koide3/interactive_slam: Interactive map correction tool useful after graph-SLAM map generation.
  • koide3/glim: Newer 3D range-inertial localization and mapping package from the same author, recommended by the HDL Graph SLAM repository as a newer SLAM package.
  • hdl_localization derivatives: Related scan-to-map localization examples exist in the same ecosystem, but should be evaluated separately from graph-SLAM mapping.

Practical Recommendation ​

Use HDL Graph SLAM when you need a practical ROS graph-SLAM baseline that can combine LiDAR scan matching with GPS, IMU, and floor constraints. It is especially useful for offline mapping studies and for understanding how auxiliary constraints improve global consistency.

For airside Part A:

  • Keep it as the graph-SLAM and NDT-based mapping baseline.
  • Use it to compare against LOAM-family feature methods and ICP-family methods.
  • Do not treat it as the default runtime localization stack.
  • Prefer newer LIO or production scan-to-map systems for deployed AVs.
  • Consider GLIM or a custom GTSAM-based pipeline for new long-term development.

The practical verdict is "good survey-mapping baseline and graph-fusion reference; aging as a production runtime component."

Sources ​

Public research notes collected from public sources.

Copyright © 2026 kvynlim