Math

From the device to depth measurements

The scanner projects known light patterns and measures how the surface deforms them. That requires coordinated device control, continuous data transfer, and processing fast enough to keep up with acquisition.

I rebuilt the driver and runtime around explicit device states and separate processing stages. The acquisition path sustained approximately 67 MB/s; the RGB-D processing pipeline reached approximately 45 frames per second against a 27 fps requirement.

Keeping timing explainable

The runtime separates work performed by a stage from time spent waiting for input or a downstream consumer. Replay tools can also time decoding in isolation and report the median, tail, and longest frame time. That makes a slow computation distinguishable from a pipeline blocked elsewhere.

Acquisition bandwidth and RGB-D processing throughput describe those stages; reconstruction and offline refinement have their own workloads and measurements.

Driver and pipeline design

A trait-based USB layer supports multiple transport backends. Dedicated reader threads feed an asynchronous pipeline that reassembles frames, decodes projected patterns, computes depth, and prepares the camera data for reconstruction.

The device state machine expresses permitted transitions in Rust's types, catching illegal transitions at compile time. Transport and processing interfaces keep scanner-specific behavior from spreading through the rest of the runtime.