contributions(clean-and-map): pointer to yugeeklab's coverage-while-mapping implementation

[yugeeklab]

Description

Claims a second track on the clean-and-map module and adds a pointer to my
self-hosted implementation, per CONTRIBUTING (code in the contributor's repo, a link
in-tree). One file, contributions/clean-and-map/yugeeklab/README.md.

Self-hosted repository: https://github.com/yugeeklab/oomwoo-clean-and-map
Discussion: #66

Approach

The part the RFC board lists as coverage-while-mapping not started, complementing
@Arkz-Deepak's clean-only-first track. The robot starts with no map, sweeps the floor
slam_toolbox has drawn so far, replans as more of the room appears, decides it is
finished and saves the map.

Where it stands on living_room

Six sessions, no map at start, headless, scored by coverage_meter at
cleaning_radius 0.20 — what coverage_regression.launch.py uses.

	crossing 0.90 at	efficiency there	final coverage
best	47.6 m	0.716	0.933
median	53.4 m	0.638	0.941
worst that crossed	64.2 m	0.530	0.980
one session of six	never crossed	—	0.822

deploy/run_coverage_livingroom.sh with the stock coverage_planner, same world,
same harness: coverage 0.8772, target never crossed. This node crosses 0.90
where upstream's does not reach it. Neither meets the runner's 0.80
efficiency_target, and I think why is the most useful thing in this PR.

Why neither planner makes 0.80 on that world

Coverage per metre driven is the pass spacing, and the spacing cannot exceed the
swath. Covering 90 % of living_room's 13.62 m² at a 0.40 m swath has a floor of
30.7 m; the gate allows 42.6 m. Measured at the crossing:

sweeping                            35.2 m   ← 12.26 m² at the 0.35 m spacing used
turn-arounds, 17 of them            + 6.1 m
travel between furniture-cut pieces + 5.9 m
                                     47.2 m  against 42.6

The spacing is 0.35 m rather than the full 0.40 m swath because localisation error
on these runs is 11 mm mean and 26 mm at p90 (localization_error), and passes laid
exactly one swath apart come apart at the seams. Sweeping the two spacings against
error from 0 to 23 mm, with contacts modelled, exactly one cell of that table passes:
no error at all.

coverage_regression.launch.py sets row_overlap 0.05, which on a 0.05 m grid
rounds to an 8-cell step — a whole swath, no real overlap. That is the wide-spacing
column, and it fails on coverage; this node takes the narrow one, reaches coverage,
and fails on efficiency. Same fact, two sides, and a property of a 0.40 m swath
against a centimetre of error in a cluttered room rather than of either planner.
Four planner families and twenty-odd variants were measured against it — including
spanning-tree coverage, which cannot tile this room at any sub-cell size the budget
allows, and a Hamiltonian path, which provably does not exist on this floor.

Also in the repo

• map_completeness_meter in the shape of coverage_meter, so map completeness can
  be gated headless the way coverage already is — the RFC asks for regression tests
  of both, and the harness has only the second.
• A SLAM-mode launch with no map_server and no AMCL.
• An offline planner bench. A simulated session takes the better part of an hour and
  two sessions of identical code landed 33 % apart, so planner changes are chosen
  offline. It imports the node's own _plan_sweep and models what the simulator does
  to a plan — including hitting things, which is what finally made its numbers agree
  with the simulator's.
• 50 geometry tests needing neither ROS nor a simulator, under a second.

What is not done

Stated plainly because the acceptance criteria ask for them and I have not met them:

• several initial poses — almost everything so far is the one spawn;
• dynamic obstacles — not tested;
• an additional multi-room Gazebo world — the bench has drawn floor plans, but no
  world;
• one session in six ended itself at 0.822 coverage with a complete map and
  nothing left it could plan to, after seven bumper contacts. A real defect in the
  done condition, and the first thing I would fix.

Caveats

Every simulated number was measured on an arm64 rebuild of jazzy-dev, because the
published image is amd64 only. The upstream baseline reproduces on it (test_room
96.4 % against 97.0 %) and the CI job in the repo is how that caveat gets retired —
it has not been run yet.

No board row change in this PR; progress is reported in the discussion and folded in
as milestones land.

🤖 Generated with Claude Code

[makers-pet]

Hi @yugeeklab - I noticed you closed this. In case it was about overlapping with
another track: contributions are per-contributor folders, so parallel clean-and-map
approaches are welcome, and coverage-while-mapping is exactly what #66 is about.

Your measured comparison is excellent, and you're right about row_overlap - in
coverage_regression.launch.py, 0.05 rounds to 8 cells, a full 0.40 m swath with
no real overlap. Thank you for digging into that.

Whenever you're ready, feel free to open a new PR (the branch was deleted, so this
one can't be reopened).