Skip to content

lidarslam_ros2 v0.9.0

The stable product-foundation release candidate. v0.9.0 preserves the documented rosbag2-to-Autoware-compatible map workflow and makes every remaining v1.0 gate explicit, machine-readable, and fail-closed.

This candidate is not v1.0 and does not claim that ROS apt distribution or independent adoption is complete. The release workflow publishes v0.9.x as a normal GitHub Release—the stable candidate channel—while versions below v0.9 remain prereleases.

Supported product path

The maintained installed interface remains:

lidarslam-map doctor /data/bag
lidarslam-map run /data/bag --output-dir /data/map
lidarslam-map inspect /data/map

The fixed Docker demo and source quickstart exercise the same profiles and verification core. view is optional; migrate-manifest and rollback-plan remain advanced recovery tools. No new beginner entrypoint was added. The published image predates the receipt-only lidarslam-map report handoff; review first_map_validation_receipt.json and follow the stable-image fallback until a reviewed image carrying the newer CLI is published.

What v0.9 adds

One authoritative v1 readiness audit

python3 scripts/check_v1_readiness.py validates all ten product gates, their evidence paths, the independent-user ledger, root version, and immutable tag state. --require-complete rejects any missing gate instead of inferring readiness from a narrower CI result.

At candidate preparation time the audit is honestly NOT_READY: 6/10. Distribution, first tagged rollback evidence, three-user adoption, and publication remain open.

Release-ready ROS dependency boundary

The official PRBonn RKO-LIO 0.3.2-1 binary passed the pinned MID-360 installed golden-path E2E on both Humble and Jazzy. The product therefore declares rko_lio >= 0.3.2; normal apt installation still waits for that version to reach the main repositories.

The pinned ndt_omp_ros2 0.1.0 candidate is locally ready at 8b77fa5a6cdcad45bf35918361c892b6d94a287e. Its read-only preflight checks the parent gitlink, source branch, metadata, CMake exports, Bloom gate, source tag, release repository, and both rosdistro entries. Network or API failures are BLOCKED, never treated as missing publication artifacts.

ROS apt installation and upgrade evidence

The manual package-manager workflow is ready for the first public builds. On Humble and Jazzy it:

  • installs the exact four product Debian versions;
  • verifies ndt_omp_ros2 >= 0.1.0 and rko_lio >= 0.3.2;
  • validates the installed CLI, resources, schemas, completion, and historical node from /opt/ros/<distro>;
  • compares package-owned paths across a main-to-testing upgrade and rejects stale files;
  • runs and validates the pinned public MID-360 map with the installed apt product.

The workflow is manual until packages exist, so its presence is not presented as execution evidence. Its exact source ref, version, apt channel, and mode are encoded in the public workflow run name. The live v1 audit requires the main-channel clean-install identity and successful Humble/Jazzy jobs before the distribution gate can complete.

Release and recovery integrity

The tagged workflow builds exact Humble/Jazzy image digests, checks the installed CLI and source revision, verifies SBOM, BuildKit provenance, and GitHub attestations, then performs conflict-safe immutable promotion. The release bundle contains a schema-validated SHA-256 inventory.

Before a tag exists, the main CI job now builds that curated bundle twice from the clean candidate commit, reopens both archives with the publication verifier, checks every manifest size and hash, requires byte-identical output, and retains the verified rehearsal artifact. This catches source-inventory or reproducibility failures before the immutable tag is created.

Each published image produces release-image-<distro>.json and a digest-pinned rollback-plan-<distro>.json; release-promotion.json proves that moving a conflicting version tag is forbidden. The first successful tag run then performs an independent read-only audit of the tag, stable release, all six assets, cross-file identities, every bundled file hash, and the live Humble/Jazzy GHCR version-tag digests. That publication and audit completed successfully on 2026-07-31; the exact workflow, tag, and recovery assets are preserved in the published-release evidence.

Research changes remain isolated

The oriented appearance matcher now supports extensible, separate intensity and height correlations for radarless degeneracy studies. Tunnel and fog holdouts showed that the channel gap was not reliable enough for automatic selection. The adapters therefore remain default-off and do not change the golden-path registration or correction policy.

Dataset-specific voxel compatibility

The existing legacy_voxel_downsample option now restores both passes of the pre-v0.3 voxel pipeline. This fixes the Newer College Maths-Hard regression without adding an option or changing the modern default. On the clean candidate, Maths-Hard improved from 0.140755 m to 0.081247 m APE; NTU VIRAL and both RTK-SLAM Construction profiles reproduced their preceding clean accuracy values exactly.

All five blocking release profiles passed from the same clean candidate commit, and the Leo Drive map passed Autoware compatibility verification. See the voxel compatibility and release-gate evidence.

Upgrade notes

  • The public CLI and output schemas retain the v1 compatibility contract.
  • Upgrade from a source-built v0.6.0 prefix has already passed fresh-prefix parity on Humble and Jazzy.
  • A real Debian main-to-testing upgrade must be captured after both versions exist in ROS apt; do not substitute the source-prefix result for that gate.
  • Use a new output directory for every mapping run. Existing outputs remain immutable.

Known release blockers

  • ndt_omp_ros2 0.1.0 still needs its source tag, release repository, Bloom tracks, and Humble/Jazzy rosdistro entries.
  • Required binary dependencies and lidarslam packages must sync to the normal ROS apt repositories before the apt command becomes a supported beginner path.
  • The first tagged release must publish and verify its rollback assets.
  • Three distinct independent users must complete the documented first-map validation. The tracked ledger remains 0/3.

Authoritative status and procedures: