← Back to the scanner case study

Registration · ICP · CUDA · Rust

Aligning frames and point clouds

Aligning observations for tracking, reconstruction, and loop closure. The work spans point clouds and RGB-D frames, with control over how measurements are matched and their errors weighted.

One operation, several uses

Tracking, frame-to-model alignment, and loop closure all require registration, but use different inputs and matching strategies. I built a family of methods around shared computation, with separate choices for the data representation, correspondence search, error model, and weighting.

Choosing the match and the error

The Rust interfaces select source and target representations independently: point clouds, RGB-D frames, or mixed pairs. RGB-D targets use projected pixel lookups, interpolation, or neighborhood searches; point-cloud targets use spatial indices.

Error models include point-to-point, point-to-plane, and symmetric point-to-plane alignment. Measurements can contribute equally or carry per-point and per-pixel confidence weights. Robust losses further limit the influence of outliers.

Reusing the computation

I extended the C++/CUDA ICP interface with point-to-point and point-to-plane alignment, including Tukey loss variants that reduce the influence of outliers. A templated Jacobian helper shared correspondence search and validity checks while accepting different residual and derivative calculations. A templated dispatcher handled CPU/CUDA selection and memory transfers around those variants.

The Rust implementation is generic over precision and the selected methods. It supports Tukey and Huber losses under graduated non-convexity scheduling: start with a forgiving loss and tighten it as alignment improves. Its CPU and GPU paths compile from the same kernel source, differing in dispatch: rayon on CPU, wgpu compute on GPU.

Integration

The C++/CUDA registration interfaces were used by scanner services and subsequently revised by the team. The Rust implementation provides one generic algorithmic core for tracking, model alignment, and loop closure across CPU and GPU.

Measuring the tradeoff

A February 2026 replay compared registration on 415 consecutive frame pairs. Restricting tracking to the coarse 80 × 60 image level reduced the work, with one additional rejected pair:

Recorded configurationMean registration timeAccepted pairs
Multiple image levels133 ms415 / 415
Coarse level only9.6 ms414 / 415

These timings describe that replay and configuration. The choice put fast local tracking in the frontend and longer-range drift correction in the backend.

The current mapr benchmarks measure preparation, a single ICP iteration, and a complete registration separately. They vary image resolution and correspondence-search radius on recorded depth frames, so a faster kernel can be distinguished from a solve that simply took fewer iterations.

Client work for E4D Technologies, now Planmeca, described at a technical level. References are available on request.