Skip to content

LaserPerception v0.1.0

Latest

Choose a tag to compare

@muhammadmahadazher muhammadmahadazher released this 13 Aug 08:29
· 5 commits to main since this release
4280fa3

LaserPerception v0.1.0 release notes

Release date: 2026-08-13

LaserPerception v0.1.0 is an evidence-backed research release for reproducible 3D LiDAR detection,
TensorRT FP16 deployment, exact deterministic deployment voxelization, and ROS 2 Humble
integration. LaserPerception did not train or invent the PointPillars detector.

Reproducibility scope

Correctness claims—exact-fast 81/81 bit-exact voxel outputs, frozen detector exactness, and ROS
message-contract correctness—are semantic/software evidence intended to be reproducible when the
pinned software stack and inputs are reproduced.

Performance claims are measurements from one system: an NVIDIA GeForce RTX 4060 Laptop GPU under
WSL2 with driver 610.88 and the pinned CUDA, TensorRT, and OpenMMLab environment. Timings are
measurements of this specific environment, not portable hardware capability guarantees.
They do
not guarantee 10 Hz on every RTX 4060 laptop or equivalent performance on another GPU, Windows
native, native Linux, Jetson, or another environment.

What shipped

  • Official pretrained MMDetection3D PointPillars inference on nuScenes v1.0-mini.
  • Framework-independent 3D detections with explicit frame, axes, length-width-height, yaw, class,
    score, and velocity semantics.
  • Pinned MMDeploy ONNX export and TensorRT 8.6.1 FP16 execution with external artifact validation.
  • The supported exact_fast LaserPerception deterministic voxelizer, which preserves pinned
    official deterministic hard-voxel outputs.
  • A ROS 2 Humble package with a model-ready multi-sweep PointCloud2 contract,
    Detection3DArray, bounded QoS, replay, RViz/Foxglove markers, and native tests.
  • Reproducibility, parity, fidelity, component-diagnostic, benchmark, and ROS-rate evidence.
  • A lightweight CPU wheel; GPU, ROS, datasets, checkpoints, ONNX, and TensorRT engines remain
    external.

Key evidence

M1 — historical FP32 scene-start result

The archived M1 warm-cache microbenchmark repeatedly used mini_val index 0, a scene start with
zero historical sweeps. Model/test-step median was 52.896 ms and end-to-end median was 55.097 ms.
It is historical context, not a same-session denominator for later results.

M2 — TensorRT deployment and repaired benchmark

Parity v1 failed and remains recorded. The separately preregistered parity v2 passed all Stage 1
per-metric gates on the unchanged frozen 20-sample suite and engine. Native MMDetection3D and the
MMDeploy-rewritten FP32 graph were then shown bit-identical on all frozen samples.

The first M2 benchmark at e2f9b6b… was rejected because it used MMDeploy-rewritten eager PyTorch
as the performance denominator. The repaired canonical comparison uses native MMDetection3D
PyTorch FP32 versus TensorRT FP16 on repeated scene-start index 0:

Boundary Native PyTorch FP32 median TensorRT FP16 median Median ratio
End to end — headline 59.289 ms 45.637 ms 1.2991×
Raw network — secondary 19.189 ms 6.126 ms 3.1326×

These are warm-cache, repeated-single-sample measurements, not cold-storage latency, whole-dataset
throughput, or a sensor-rate guarantee.

M3B-V2 — exact deterministic deployment voxelization

The easy upstream deterministic=False shortcut was rejected: saturated voxels retained different
point subsets, and observable detector repeatability changed. LaserPerception’s exact_fast path
instead uses the pinned MMCV dynamic-coordinate CUDA operation plus PyTorch grouping while
preserving official retained-point semantics.

  • 81/81 mini_val samples matched official voxel, point-count, and coordinate tensors bit-for-bit.
  • Both 30-run W1 and W2 repeatability suites were exact.
  • All frozen 20 raw TensorRT outputs and final DetectionFrame results were exact.
  • W1 hard-voxel-layer median changed from 238.910 ms to 1.758 ms (about 136×). This ratio is for
    the hard voxel layer, not whole LiDAR inference.
  • W1 direct live median changed from 333.137 ms to 43.168 ms. The ~43 ms value is direct runtime,
    not ROS callback or loopback latency.

M3 — representative full-history ROS result

The canonical workload is W1, mini_val index 42: 10 historical sweeps plus current, 354,182
points, exact-fast voxelization, live provenance, the unchanged TensorRT engine, ROS 2 Humble, and
rmw_fastrtps_cpp.

10 Hz was the highest tested clean sustained rate on the representative full-history W1
workload.
Fifteen hertz and 20 Hz were not sustained.

Offered rate Effective useful output Measured input drops Result
10 Hz 9.949 Hz 0/200 sustained cleanly
15 Hz 13.336 Hz 21/221 not sustained
20 Hz 10.825 Hz 159/359 not sustained; first/second-half intervals and drops grew

The full callback, loopback, variance, telemetry, and half-run backlog distributions are in the
canonical M3 record.

Known issues

Known issues are observed behavior in implemented functionality. They are separate from the feature
limitations below.

GPU performance-session variability

During M3B-V1 diagnostics, comparable fast/no-hash work measured materially different sessions on
the same RTX 4060 Laptop GPU, approximately 52 ms to 105 ms. The cause was not isolated. Benchmark
performance is sensitive to host/GPU operating state; warm the GPU and record clocks, power,
temperature, and utilization where possible. Do not assume one timing result is portable across
sessions. Thermal throttling was not established as the cause.

Historical M1 reproduction variance

The archived M1 model/test-step median was about 52.9 ms. A later M1-style reproduction in the M2
environment measured about 84.2 ms. The cause was not established. The archived M1 and later
diagnostic sessions must not be directly ratioed as though they were controlled same-session
measurements.

Offered-rate overload behavior

For representative W1, 10 Hz sustained cleanly, 15 Hz was not sustained but produced about 13.34 Hz
useful output, and 20 Hz was not sustained with lower useful output of about 10.83 Hz. This is
behavior consistent with overload under the measured ROS configuration. The evidence does not
isolate DDS contention, executor contention, thermal throttling, or another single cause.

Limitations

These describe capabilities v0.1.0 does not provide:

  • The ROS interface requires model-ready multi-sweep PointCloud2; no raw physical-LiDAR history
    builder is included.
  • No detector training or fine-tuning.
  • No tracking, camera fusion, second detector architecture, INT8 path, or Jetson measurement.
  • No guarantee of sensor-rate operation outside the measured system and workload.
  • The system is not safety certified and is not suitable as a certified perception component around
    people or vehicles.
  • nuScenes, the pretrained checkpoint, ONNX, TensorRT engine, CUDA/OpenMMLab environment, and ROS 2
    installation are external and remain under their own terms.

Preserved failures and chronology

  • M2 parity v1: failed.
  • First M2 benchmark: rejected and retained as non-canonical diagnostics.
  • Sweep-history audit: qualified M1/M2 scene-start inputs without invalidating the configured
    multi-sweep pipeline.
  • M3A 20 Hz scene-start stress test: failed.
  • M3B-V1 nondeterministic voxelizer: rejected.
  • M3B-V2 exact replacement: passed and integrated.
  • Final representative M3: 10 Hz sustained; 15 Hz and 20 Hz not sustained.

Installation and evidence

Start with the v0.1.0 quickstart. Detailed records are separated by scope:

The release does not include a DOI. Cite v0.1.0 and the exact commit where reproducibility matters.