Add View-of-Delft (VoD) dataset support

[stepankonev]

Summary

Adds View-of-Delft (VoD) dataset support — a from-scratch processor that reads the extracted KITTI-style lidar/ tree directly, with no devkit dependency (the vod-tudelft devkit pins numpy=1.19 / python=3.7, incompatible with this project's numpy 2.x / py3.12 — same rationale as nuScenes reading its tables directly).

Ingested into StandardFrameData:

• cameras — the single front camera (CameraDirection.FRONT; intrinsics from the calib P2, extrinsics inv(Tr_velo_to_cam))
• lidar_pc — the Velodyne HDL-64 xyz in the ego (velodyne, FLU) frame
• detections_3d — KITTI boxes mapped into the ego frame, each class folded into the coarse DetectionType taxonomy (the two-wheeler family → BICYCLE; Car/truck/vehicle_other → VEHICLE; static/ambiguous → UNKNOWN; DontCare dropped)
• ego past/future trajectory — T_map_from_lidar from the per-frame pose, via FuturePastStatesFromMatricesAggregator

Frames are grouped into the official scenes (vendored split table from the devkit docs) so per-segment trajectories never span two recordings.

Why not the devkit's FrameTransformMatrix?

The VoD devkit ships convenient frame transforms — from vod.frame import FrameTransformMatrix; transforms = FrameTransformMatrix(frame_data), exposing t_camera_lidar, t_lidar_camera, t_map_camera, … — so the natural question is why we reimplement them in _vod_geometry.py rather than importing them. Two reasons:

• It's a Python 3.7 / numpy 1.19 stack. The devkit's environment.yml pins python=3.7, numpy=1.19 (plus open3d=0.13, k3d, transforms3d, …), which is incompatible with this project's numpy 2.x / py3.12 — so it can't be a runtime dependency. Same rationale as nuScenes reading its JSON tables directly (its devkit pins numpy<2).
• Coupling. FrameTransformMatrix(frame_data) is constructed from a devkit FrameDataLoader + kitti_locations, so adopting it means taking on the devkit's whole IO layer — not just the matrix algebra, which is only @ and np.linalg.inv, done here via standard_e2e.utils (se3, transform_points, wrap_to_pi).

We reproduce exactly the transforms we need: devkit t_camera_lidar ≡ our parse_calibration (K from P2, Tr_velo_to_cam); devkit t_lidar_camera = inv(t_camera_lidar); devkit t_map_camera @ t_camera_lidar ≡ our ego_pose_map_from_lidar (mapToCamera @ Tr_velo_to_cam). The one non-trivial convention — the box-yaw -(rotation + π/2) — was validated against the devkit's own corner builder (see Geometry below).

Geometry (verified against the devkit and real data)

• Ego pose — VoD's mapToCamera is the camera pose in the map (T_map_from_camera), so T_map_from_lidar = mapToCamera @ Tr_velo_to_cam (the inverse yields ~50× too-fast, non-physical ego motion; caught by checking speed on consecutive frames).
• Box height — KITTI location is the bottom-face center, raised by H/2 to the geometric center (verified by lidar containment: z-ratio +1.04 → +0.04).
• Box yaw — VoD keeps the KITTI camera-x zero-reference, so the FLU heading is -(rotation + π/2), not -rotation (verified against the devkit's get_transformed_3d_label_corners and the lidar PCA major axis: median misalignment 78° → 12° over 1101 elongated objects).

Not ingested / limitations

• The 3+1D radar (radar / radar_3frames / radar_5frames) has no StandardE2E modality yet.
• Per-point reflectance dropped (lidar is xyz-only).
• Per-frame timestamps synthesised at the 10 Hz LiDAR-lead rate (the detection release ships none).
• The test split is sensor-only (no labels → no detections).
• A handful of scene-start frames have unconverged map-localization (xy jumps while camera height stays sane) — a faithful source artifact, not a conversion issue.
• ~5.3 MB/frame at native resolution (full train ≈ 26 GB); bound via the config's cameras_identity_adapter: {max_size} / lidar_adapter: {max_points}.

Tests

Comprehensive unit tests (calibration / ego-pose / box-geometry incl. the −π/2 yaw offset and H/2 lift, velodyne decode, KITTI label + track-id parse, class taxonomy, scene/split table, root resolution and frame enumeration) plus VOD_ROOT-gated real-frame checks. wrap_to_pi lifted to utils.geometry with its own test. Full suite green (the two failing navsim tests are pre-existing real-data / permission environment failures, unrelated).

Commits

• Add View-of-Delft (VoD) dataset support
• Refactor VoD: lift generic geometry helpers to utils, slim FrameRef
• Fix VoD box heading: KITTI rotation needs the −π/2 reference offset

[codecov]

Codecov Report

❌ Patch coverage is 79.48718% with 56 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../caching/src_datasets/vod/vod_dataset_processor.py	57.14%	33 Missing ⚠️
standard_e2e/caching/src_datasets/vod/_vod_io.py	89.09%	12 Missing ⚠️
.../caching/src_datasets/vod/vod_dataset_converter.py	57.89%	8 Missing ⚠️
...dard_e2e/caching/src_datasets/vod/_vod_geometry.py	94.44%	2 Missing ⚠️
standard_e2e/caching/process_source_dataset.py	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!