NODEDC_MISSION_CORE/docs/adr/0021-dataset-gateway-repres...

91 lines
4.0 KiB
Markdown

# ADR 0021: separate native scans, normalized scans and rolling local maps
Status: accepted
Date: 2026-07-25
## Context
Public autonomous-driving and field-robotics dataset viewers commonly display
one LiDAR revolution. Fixed-channel rotating sensors therefore produce the
familiar sparse rings. The current XGRIDS K1 MQTT `lio_pcl` evidence is a
different product: firmware evidence places it after LIO/modeling, and the
field-review UI accumulates multiple already registered increments in the map
frame.
Point count alone does not make these representations comparable. A cloud can
be sparse per publication and still look dense after several seconds of pose
registration. Conversely, voxel downsampling does not restore timing, scan
lines or raw sensor geometry that the source no longer carries.
Patchwork++ is a ground classifier. It does not decode sensor packets, deskew
motion distortion, estimate pose, stabilize a rolling map or remove ghosts
from stale/dynamic observations. A successful Patchwork++ call against
`lio_pcl` remains diagnostic and does not repair the input domain.
## Decision
Mission Core defines three non-interchangeable LiDAR products:
1. `native-scan`: one losslessly decoded source scan/frame with its native
point-aligned fields and labels. It is never accumulated.
2. `normalized-scan`: one sensor-frame scan after an explicit transform,
deskew and bounded cleanup profile. Every transformation retains source
identity and point alignment.
3. `rolling-local-map`: normalized scans registered by pose into a bounded
local map with explicit TTL, voxel deduplication and dynamic-point policy.
The Dataset Gateway is the first producer of this contract. GOOSE 3D is the
first admitted source because it publishes off-road point-wise semantic and
instance labels in SemanticKITTI-compatible `XYZI + uint32 label` files. Its
annotated point-cloud file represents one LiDAR revolution.
The gateway:
- preserves the native GOOSE frame before adaptation;
- never transforms labels independently of their points;
- does not assume a coordinate convention, mounting transform or sensor height
unless source metadata supplies it;
- refuses automatic downloads of large archives;
- admits storage only under `D:\NDC_MISSIONCORE\datasets` or its WSL mirror;
- never promotes K1 `lio_pcl` to `native-scan`.
The normalized pipeline is:
```text
native packet/source frame
-> decode + calibration
-> per-point-time deskew
-> range/self/outlier/voxel policy
-> normalized-scan
-> ground/object inference
-> pose registration + TTL + voxel deduplication
-> rolling-local-map
```
Deskew is conditional: it requires per-point time plus synchronized IMU or
odometry. If those fields are missing, the gateway reports the stage as
unavailable rather than inventing timestamps.
## Consequences
- The UI must label accumulated K1 evidence as a map product, not a scan.
- Dataset and device inputs can share downstream algorithms only after their
normalized contracts match.
- Sensor adaptation may change range, FOV, point density, noise and dropout for
robustness experiments, but it cannot recreate lost timestamps, occlusions
or material response.
- Patchwork++ becomes eligible for a real quality gate only on a sensor-centric
scan with declared scan geometry and physical mounting height plus
independent labels.
- Stable operator visualization is owned by rolling-map policy, not by the
ground classifier.
## Primary references
- [GOOSE dataset structure](https://goose-dataset.de/docs/dataset-structure/)
- [GOOSE setup and archive sizes](https://goose-dataset.de/docs/setup/)
- [GOOSE 3D challenge ontology](https://goose-dataset.de/docs/3d-semantic-segmentation-challenge/)
- [Livox ROS Driver 2 point formats](https://github.com/Livox-SDK/livox_ros_driver2)
- [Livox LIO motion-distortion handling](https://github.com/Livox-SDK/LIO-Livox)
- [ROS FilterDeskew timestamp requirement](https://docs.ros.org/en/noetic/api/mp2p_icp/html/classmp2p__icp__filters_1_1FilterDeskew.html)