NDT (Normal Distributions Transform)

NDT (Normal Distributions Transform) – definition

Normal Distributions Transform (NDT) is a probabilistic point-cloud registration method used to estimate the relative pose between a current LiDAR scan and a reference map or another scan. In mobile robotics, it is commonly used for 2D or 3D localization, scan matching, odometry correction, and map alignment.

Instead of directly finding point-to-point correspondences, NDT divides the reference point cloud into spatial cells. Each occupied cell is represented by a normal distribution with a mean vector and covariance matrix. Points from the incoming scan are transformed into the map frame and evaluated against these local distributions. The pose estimate is optimized to maximize the likelihood that transformed scan points belong to the distributions stored in the reference cloud.

For a UGV, NDT can estimate the robot pose in the map or odom frame. This makes it useful on platforms such as Leo Rover and Raph Rover when a LiDAR sensor, a stable transform tree, wheel odometry, and a ROS 2 localization pipeline are available. NDT is not an autonomous-navigation stack by itself. It provides a pose estimate that can be consumed by navigation, mapping, or state-estimation nodes.

How NDT scan matching works

NDT represents the environment as a set of Gaussian distributions. For every occupied voxel or grid cell, the algorithm calculates the mean position and covariance of reference points. The current scan is then transformed repeatedly until the scan-to-map likelihood is maximized.

For a point x transformed by a candidate pose, its probability density under a cell distribution can be expressed as follows:

p(x) = 1 / √((2π)^d |Σ|) * exp(-0.5 * (x - μ)ᵀ Σ⁻¹ (x - μ))

In this expression, μ is the mean position of points in a cell, Σ is the covariance matrix, and d is the dimensionality of the distribution. The optimizer searches for the translation and rotation that maximize the accumulated likelihood across scan points. Implementations commonly use Newton-based optimization methods. The exact convergence behavior depends on the NDT implementation, map resolution, initial pose estimate, scan density, and environmental geometry.

NDT does not require explicit nearest-neighbour point correspondences in the same way as Iterative Closest Point (ICP). This can make it effective for registration against large point-cloud maps. However, it still requires sufficient geometric structure. Long corridors, flat fields, repetitive warehouse-like layouts, vegetation motion, dust, and sparse returns can reduce localization quality.

NDT in ROS 2 mobile robotics

ROS 2 does not define one mandatory NDT node or a single standard parameter interface. NDT is typically provided by packages built on the Point Cloud Library (PCL), by autonomy frameworks, or by custom robotics software. PCL includes the pcl::NormalDistributionsTransform registration class and documents its main configuration methods, including resolution, step size, transformation epsilon, and maximum iterations.

A ROS 2 NDT localization pipeline normally uses the following interfaces. Topic names are conventions and may differ between packages.

Function	Typical ROS 2 interface	Purpose
Live LiDAR input	`sensor_msgs/msg/PointCloud2`	Current 3D scan for registration
Reference map	`sensor_msgs/msg/PointCloud2`	Static point-cloud map or submap
Pose output	`geometry_msgs/msg/PoseWithCovarianceStamped` or `nav_msgs/msg/Odometry`	Estimated robot pose and covariance fields
Coordinate transforms	`tf2`	Transforms between `map`, `odom`, `base_link`, and sensor frames

Frame semantics should follow REP 105. For a mobile robot, base_link is attached to the robot body, odom provides a locally continuous frame, and map provides a globally consistent frame that may change discontinuously after localization correction. An NDT localizer commonly publishes or contributes to the map → odom transform rather than replacing wheel odometry directly.

Key NDT parameters

Parameter names vary between ROS 2 packages, but their technical meaning is similar. Parameters should be tuned against the actual LiDAR characteristics, vehicle motion, map density, and available compute resources.

Resolution: the voxel or grid-cell size used to construct normal distributions. A coarse resolution reduces map detail. A fine resolution requires denser data and increases computation.
Step size: the maximum step length used by the line-search procedure during optimization. It affects optimizer behavior during pose updates.
Transformation epsilon: the convergence threshold for pose updates.
Maximum iterations: the upper limit for optimizer iterations per scan-registration attempt.
Initial guess: an estimated starting pose, often obtained from wheel odometry, IMU integration, or GNSS/RTK.
Fitness score: an implementation-specific registration-quality metric. It should not be treated as an absolute accuracy measurement without validation against ground truth.

The following C++ fragment shows the principal PCL configuration calls. Values are intentionally not prescribed because they must be validated for the specific sensor, map, and UGV operating conditions.

pcl::NormalDistributionsTransform<PointT, PointT> ndt;

ndt.setResolution(resolution);
ndt.setStepSize(step_size);
ndt.setTransformationEpsilon(transform_epsilon);
ndt.setMaximumIterations(max_iterations);

ndt.setInputTarget(reference_map);
ndt.setInputSource(current_scan);
ndt.align(aligned_scan, initial_guess);

Use on Leo Rover and Raph Rover

On Leo Rover, NDT is usually part of a custom ROS 2 integration rather than a default platform function. Leo Rover uses differential drive. A practical configuration requires a LiDAR driver, a correctly defined sensor transform in URDF or TF, wheel odometry, and a localization node running on the onboard Raspberry Pi or on an external compute unit.

For outdoor localization, an initial pose from GNSS/RTK can reduce the search space for NDT. An IMU can improve short-term orientation estimation and support state estimation during rapid motion or reduced LiDAR observability. Sensor timestamps must use a consistent clock source because delayed point clouds or incorrect TF timestamps can cause registration errors.

Raph Rover can carry larger or more demanding payload configurations where a higher-capacity compute unit, 3D LiDAR, GNSS/RTK receiver, and additional perception sensors are required. The NDT workflow remains the same: acquire a reference map, maintain a valid TF tree, provide an initial pose estimate, register live scans, and monitor convergence and pose consistency.

Limitations and validation

NDT is sensitive to map quality and initialization. If the initial pose is too far from the correct solution, the optimizer may converge to an incorrect local optimum. Dynamic objects can also contaminate registration, especially when the reference map and current scan contain different moving obstacles.

Validation should include recorded ROS 2 bags, repeated runs over the same route, comparison with independently measured control points or RTK trajectories, and inspection of TF timing. For navigation, the localization output must remain stable enough for the controller and costmap configuration used by the robot.

Normative references and technical sources

The ROS coordinate-frame convention is defined by REP 105. ROS 2 message definitions are maintained in the official ROS 2 documentation. The PCL API documents the reference NDT implementation and its configuration interface.

NDT (Normal Distributions Transform)