odometry from points that are already vendor-mapped;
- deskew and LiDAR-inertial SLAM are blocked until the scanner or a future
vehicle LiDAR driver supplies raw scans, timing and IMU evidence.
The executable truth is
`missioncore.lidar-evidence-profile/v1` in
`src/k1link/compute/lidar_contract.py`. It assesses each stage as `ready`,
`degraded` or `blocked` and refuses to infer absent sensor fields.
## 3. Current system result
The existing camera-heavy E10–E26 line is valuable and remains in place:
- raw recording and content-addressed worker handoff;
- camera detection and semantic segmentation;
- factory KB4 camera/LiDAR projection;
- map-frame LiDAR support and ground-aware cuboids;
- bounded temporal stabilization;
- persistent support motion evidence;
- camera ego-motion evidence and conservative fusion.
E25 proved the LiDAR limit: missing current returns cannot be recovered by
threshold tuning. E26 passed its reviewed 11/11 diagnostic windows by adding
camera parallax, but it is not planner-ready: most camera observations remain
unknown, camera-only velocity is not metric, 374 conflicts remain, and the
benchmark is not independent ground truth.
The next work must therefore improve the LiDAR-native input and evaluation
surface, not add another visual smoothing pass.
## 4. Market and stack assessment
### 4.1 NVIDIA components worth retaining
| Component | Correct use in Mission Core | Decision |
| --- | --- | --- |
| [TAO PointPillars](https://docs.nvidia.com/tao/tao-toolkit/latest/text/cv_finetuning/pytorch/point_cloud/pointpillars.html) | Train/evaluate a LiDAR-native 3D detector over sensor-frame XYZI | First neural 3D baseline after replay v2 and labels |
| [DeepStream LiDAR 3D inference](https://docs.nvidia.com/metropolis/deepstream/7.1/text/DS_3D_Lidar_Inference.html) | Reference production pipeline for XYZI → Triton/TensorRT → 3D boxes | Reuse the inference pattern, not its file loader or UI |
| [TAO Deploy PointPillars](https://docs.nvidia.com/tao/tao-toolkit/latest/text/tao_deploy/pointpillars.html) | Build a pinned FP16/FP32 TensorRT engine and evaluate it | Worker optimization only after an accuracy baseline |
| [Isaac ROS nvblox](https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_nvblox/isaac_ros_nvblox/index.html) | GPU local TSDF/occupancy/ESDF and Nav2 cost-map producer | Later; blocked on admitted scan geometry and better timing |
| DeepStream multimodal 3D fusion | Later camera/LiDAR BEV baseline | Deferred until LiDAR-only, sync and calibration gates pass |
NVIDIA does not provide a magic “clean the K1 map” stage. PointPillars produces
classified 3D objects. Nvblox produces reconstruction and distance fields. The
quality of both remains bounded by source timing, calibration, scan geometry
and training-domain fit.
### 4.2 Independent components worth benchmarking
| Component | Correct use | Decision |
| --- | --- | --- |
| [Patchwork++](https://github.com/url-kaist/patchwork-plusplus) | Fast adaptive ground segmentation, including reflection-noise handling | First non-neural geometry baseline |
| [Autoware CenterPoint](https://github.com/autowarefoundation/autoware_universe/tree/main/perception/autoware_lidar_centerpoint) | Mature ROS 2/TensorRT 3D detection and multi-frame reference | Second detector baseline after PointPillars |
| [MMDetection3D](https://github.com/open-mmlab/mmdetection3d) | Training/evaluation harness and dataset adapters | Laboratory only |
| [OpenPCDet](https://github.com/open-mmlab/OpenPCDet) | Alternative LiDAR detector benchmark/model zoo | Laboratory only; not the production runtime |
| [KISS-ICP](https://github.com/PRBonn/kiss-icp) | Simple LiDAR-only odometry baseline | Future raw sensor scans only |
| [KISS-SLAM](https://github.com/PRBonn/kiss-slam) | Global LiDAR SLAM/loop-closure baseline | Future raw sensor scans only |
| [FAST-LIO2](https://github.com/hku-mars/FAST_LIO) | Raw LiDAR + IMU odometry/mapping | Future vehicle sensor profile only |
| [LIO-SAM](https://github.com/TixiaoShan/LIO-SAM) | Deskewed LiDAR-inertial factor-graph reference | Future profile with ring/time/IMU only |
| [GLIM](https://github.com/koide3/glim) | GPU-accelerated range-inertial mapping, loop correction and map cleanup | Strong future mapping candidate; blocked for current K1 evidence |
Autoware is a useful architecture and component reference; importing the whole
autonomous-driving distribution into the worker would add a large operational
surface that Mission Core does not currently need.
## 5. Target worker shape
The worker exposes provider-neutral jobs rather than one growing camera script:
overlays and world-state products; it does not host CUDA/TensorRT/ROS 2
compute.
7. All LiDAR results remain diagnostic/shadow until separate navigation and
safety gates pass.
## Consequences
- PointPillars integration is blocked for replay pack v1 and degraded for the
current live vendor-mapped source.
- Nvblox is blocked until the LiDAR scan geometry and timing/pose contract are
admitted.
- LiDAR odometry and LiDAR-inertial SLAM are blocked for current K1 evidence.
- L1 lossless replay and scanner-quality telemetry precede new model installs.
- Future scanners, simulation providers and datasets can use the same
readiness contract without being forced into K1-specific code.
## References
The detailed product rationale, market review, gates and sequence are in
`docs/13_LIDAR_WORKER_PRODUCT_AND_ROADMAP.md`.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
DCCONSTRUCTIONS