[feat] make M3ED-SPOT provisionable - #158
Conversation
The converter merged in #144 but m3ed_spot was absent from DATASETS, so nothing could build or upload its tarball. Register it with no EvalSpec, the same shape tum and icl_nuim had between their converter landing and their evaluation records. Registering alone was not enough. Provisioning runs the registry on PYTHONPATH only, which is right for a standard-library module, but a converter is not one: convert_m3ed_spot imports numpy and Pillow at module scope and prepare() imports h5py to read the processed HDF5 products. In ubuntu:24.04 with a bare venv, which is what cuvslam-ci:local is, importing prepare fails with ModuleNotFoundError: No module named 'numpy'. Install the tools package before conversion rather than restating those dependencies per dataset in an image. They are already declared in tools/python_tools/pyproject.toml, so an image list would be the same duplication the dataset registry removed from the shell. Measured at 72 seconds and a 1.4 GiB venv against conversions that run for tens of minutes. The registry keeps its standard-library-only guarantee: it validates in that container with nothing installed. M3ED therefore needs no dataset-specific image, and exposing it in the provisioning workflow is a one-line protected change. Note for the next TartanGround run: provisioning now also installs the package inside the TartanAir image. pyproject pins numpy and scipy to the versions Dockerfile.dataset-provision already installs, so pip should not move them, but confirm with dry_run=true before relying on it. Also stop using m3ed_spot as the unknown-dataset fixture. Registering a real corpus should not fail a test about error messages.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 12 included reviews per hour; 10 remain after this review. 📝 WalkthroughWalkthroughThe provisioning script now installs local Python tools temporarily. The dataset registry now includes the provisionable ChangesDataset provisioning
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change enables M3ED-SPOT provisioning by installing its local conversion tools and registering the dataset without evaluation records. The current changes preserve dataset lookup behavior and have no identified merge-blocking risk. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
Test Results
cuVSLAM Evaluation KPIs
Artifacts |
m3ed_spot has been provisionable since #158 but was unreachable: the dispatch input is a static choice list, so a registry entry alone does not appear in the UI. It needs no dataset-specific image. The TartanAir toolbox image and the x86-only runner guard are selected by literal equality with 'tartan', so M3ED runs on cuvslam-ci:local, and provision_dataset.sh installs the tools package that carries its numpy, Pillow and h5py. CODa stays unlisted. Its preparation converts archives fetched by hand, so a dispatch would fail without a pre-seeded raw directory. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added `m3ed_spot` as a selectable dataset option when provisioning datasets. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
The converter landed in #144 and provisioning in #158 and #161, but m3ed_spot carried no EvalSpec, so it never ran. Add one on m3ed_spot-vo_slam.cfg, the combined config, with the stereo flags KITTI and EuRoC use and an unrectified camera, since the EDEX keeps the published polynomial distortion. Full only. At 56 GiB staged and 57k frames evaluated in both modes it is the most expensive record in the suite by a wide margin, and KITTI already covers stereo pre-merge, so a PR would pay hours for nothing. Smoke therefore stays KITTI, EuRoC and ICL-NUIM. The 10 KPI entries are uncalibrated placeholders, as KITTI, EuRoC, TUM and ICL-NUIM were seeded: expected=null reports SKIPPED under a soft check. Their names come from dataset_registry kpi-keys, so the committed table covers exactly the 50 keys the full suite can produce. Merge after the provisioning run uploads m3ed_spot.tar. Staging resolves the tarball from the registry, so until the object exists every eval-enabled config fails before it evaluates anything. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added M3ED-SPOT as a full-suite evaluation dataset for stereo odometry and SLAM performance. - Added KPI baseline ranges to support performance tracking across M3ED-SPOT evaluation metrics. - **Tests** - Updated evaluation coverage and validation checks to include M3ED-SPOT in active dataset records and command-line reporting. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
The converter merged in #144 but m3ed_spot was absent from DATASETS, so nothing could build or upload its tarball. Register it with no EvalSpec, the same shape tum and icl_nuim had between their converter landing and their evaluation records.
Registering alone was not enough. Provisioning runs the registry on PYTHONPATH only, which is right for a standard-library module, but a converter is not one: convert_m3ed_spot imports numpy and Pillow at module scope and prepare() imports h5py to read the processed HDF5 products. In ubuntu:24.04 with a bare venv, which is what cuvslam-ci:local is, importing prepare fails with
ModuleNotFoundError: No module named 'numpy'.
Install the tools package before conversion rather than restating those dependencies per dataset in an image. They are already declared in tools/python_tools/pyproject.toml, so an image list would be the same duplication the dataset registry removed from the shell. Measured at 72 seconds and a 1.4 GiB venv against conversions that run for tens of minutes. The registry keeps its standard-library-only guarantee: it validates in that container with nothing installed.
M3ED therefore needs no dataset-specific image, and exposing it in the provisioning workflow is a one-line protected change.
Note for the next TartanGround run: provisioning now also installs the package inside the TartanAir image. pyproject pins numpy and scipy to the versions Dockerfile.dataset-provision already installs, so pip should not move them, but confirm with dry_run=true before relying on it.
Also stop using m3ed_spot as the unknown-dataset fixture. Registering a real corpus should not fail a test about error messages.
Summary by CodeRabbit
New Features
Tests