[Valdi320]

Ten validated engineering work packages for OOMWOO cleaning-jobs

Follow-up to merged PR #78. The only upstream file changed is
contributions/cleaning-jobs/Valdi320/README.md, which links the
independent Apache-2.0 source and reproducible reports. No shared
OOMWOO Nav2 runtime or other contributor files are modified.

Tested code: Valdi320/oomwoo-cleaning-jobs@c9fab39

Four evidence levels (do not conflate)

REAL OOMWOO Gazebo / REAL Nav2: imported original sweep geometry
without spinning its own executor; six accepted terminal-success
Nav2 goals and 348 newly swept cells from the unmodified official
simulator coverage meter. A separate station-service intermission
after goal 3 was SYNTHETIC, preserving 246 externally measured cells.
The overall room did NOT complete.

REAL Nav2 live KeepoutFilter: after an initially failing lab
attempt, a fresh offline Gazebo boot successfully replaced the old
220-cell mask with a new 198-cell mask using the actual LoadMap service.
Two distinct updated GLOBAL and LOCAL costmap observations were
verified with time-fenced map<-odom TF2 conversion, while no robot
motion command was issued. ComputePathToPose then reached the old
forbidden destination via 32 poses and stayed 40 cm short of the new
forbidden destination despite a nominal success result. We explicitly
keep the application-side forbidden-goal admission guard.

REAL ROS2 services with FAKE Nav2 server: experimental locally
compiled rosidl StartCleaning/ControlCleaning/GetCleaningStatus
services exercised real ROS2 middleware, including idempotent request
handling, two accepted action stubs and two terminal cancels. These
are PRIVATE simulation-first interfaces, not the official project API.

SYNTHETIC full-home bench: 12/12 seeded three-room scenarios
completed all eligible simulated cells with no virtual-wall entries.
Includes deterministic kinematic disk coverage, simulated
recharge/empty/wash station services, one restart and room selection.
Do NOT interpret them as Gazebo full-home or hardware trials.

Additional durable code

The 10-milestone suite adds a write-ahead coverage journal synchronizing
CleaningJobs and SweepCampaign checkpoints across injected crashes;
conservative gap-cluster audit; bounded, persisted route attempts;
selected-room ordering; station transaction nonce, unique telemetry
sequences, regression checks and reboot invalidation; versioned
live-mask transactions with independent costmap receive sequences.

383/383 Python tests pass (ordinary + Python -O + Python 3.12).
Real ROS2 and Gazebo experiments have separate machine evidence.

• Full ten-milestone report
• Real dynamic KeepoutFilter reproducibility
• Real six-goal Nav2 machine report
• Twelve synthetic scenarios
• Real typed ROS2 middleware machine report

Maintainer decisions / explicit nonclaims

This is NOT a completed OOMWOO RFC or field-ready hardware. The
persistent live ROS2 node still needs a true full-room queue, upstream
single-owner navigation arbitration, dynamic edit UI/ROS2 endpoint,
real dock-cycle service provider, physical sensor/actuator-state
coverage estimator, MCU cliff/bumper/stop validation and multi-room
Gazebo endurance. The actual OOMWOO runtime was not altered.

Please advise the canonical job service/action interface and which
component exclusively owns Nav2 actions for full-room integration.

ChatGPT-assisted; Apache-2.0; ready for source and test review.

Latest follow-up: measured virtual-room completion in REAL Gazebo

Independent source commit: Valdi320/oomwoo-cleaning-jobs@1cd6b5e

The opt-in persistent ROS2 controller now schedules the original OOMWOO
sweep-plan geometry under one Nav2 owner, saves the per-room plan and
verifies coverage from the unmodified official Gazebo ground-truth meter.
For one operator-defined digital region in an OPEN test_room (NOT a
physically separated apartment room), actual checkpoints show
171/171 eligible floor cells externally measured, BOTH durable
CleaningJobs and SweepCampaign states COMPLETED, 11 Nav2 requests in
the log and the final UUID terminal CANCELED.

Added guarded gap-route proposals (Nav2 endpoint tolerance can leave
a narrow dirty fringe) and a software-only dock geometry / exclusive
cmd_vel owner handoff contract. 425/425 pure Python regressions PASS.
This is NOT proof that the real robot can safely hand motors between
Nav2 and dock-drive, charge, empty its dustbin, wash mop or remove dirt.

Report: https://github.com/Valdi320/oomwoo-cleaning-jobs/blob/main/docs/REAL_ROOM_AND_DOCK_BOUNDARY_20261027.md

Physical station service, real motor mux/Nav2 dock arbitration, MCU
safety and whole multi-room Gazebo endurance remain for integration.

Follow-up 2026-10-27: TWO COMPLETE digital zones in REAL OOMWOO Gazebo

Published implementation and tests:
Valdi320/oomwoo-cleaning-jobs@471a483

The same persistent simulation-only cleaning controller completed two
different operator-defined, disjoint virtual regions on the official
OOMWOO test_room map in ONE selected-room job. These regions are on the
SAME OPEN FLOOR, not separated by architectural walls.

• Area A: 80/80 externally measured cells.
• Area B: 40/40 externally measured cells.
• Total: 120/120 independently measured eligible cells, 100%
  of exactly the selected virtual map scope.
• REAL OOMWOO Nav2 Jazzy: 18 accepted goals; original OOMWOO
  ground-truth meter: 200 observed frames; 12 bounded
  gap-repair routes proposed (no fabricated cleaning credit).
• Both durable CleaningJobs and SweepCampaign checkpoints reached
  COMPLETED with identical 120-cell credited sets. CoverageWAL had
  20 applied events and zero pending. The final UUID was terminal
  CANCELED after external completion; no active goal remained.
• Earlier 117/120 partial/timeout runs are preserved separately and
  were not misreported as successful.

An experimental isolated ROS2 dock velocity relay now uses the fsync'd
CURRENT Nav2 goal UUID, observed ACTIVE during this lease and then
matching terminal before transferring from Nav2 to dock_drive. Old
terminal statuses cannot authorize a new run. Foreign Nav2 action,
battery-low, empty/stale status and expired owner commands force STOP.
Actual ROS2 middleware/typed control test PASS, with SYNTHETIC
status/odometry/battery and NO MOTOR CONNECTIONS. The separate
UNMODIFIED upstream OOMWOO 2D docking harness also passed 7/7
simulated geometric approaches, not physical charging.

437/437 headless regressions PASS on host, optimized Python and
Python 3.12; existing ROS2 probe matrix remains green.

• Actual two-zone Gazebo evidence
• ROS2 exact-UUID dock relay evidence
• Integration and production limits

Production remainers: physically divided furnished-room navigation,
real exclusive robot cmd_vel remaps and MCU safety; charge current,
auto-empty and mop-wash provider protocols plus hardware sensors; actual
vacuum/mop actuator-state coverage, full-home endurance, and canonical
OOMWOO ROS2 API/maintainer approval. Lab relay publishes to a SAFE,
NON-MOTOR topic only. This is not 100% of a hardware cleaning robot.

Additional nonhardware physical coverage-admission contract

Source: Valdi320/oomwoo-cleaning-jobs@0bf06d5

PhysicalCoverageAdmission is a fail-closed, pure-Python policy that
rejects credit for floor cells unless fresh and map-matching
localization, an accepted active navigation goal, independently
verified vacuum current and/or mop actuator contact, and a trusted
coverage source all agree. It has 22 additional negative/positive
tests; the entire regression suite passes 459/459 tests in normal,
optimized and Python 3.12-container modes.

No real vacuum-current sensor, mop-switch, source authentication or
physical actuator has been connected. This does NOT certify that
the hardware actually cleans. Production must supply independent
signed/trusted sensor metadata and MCU-owned safety interlocks.

Follow-up: physical coverage requires sensor evidence BEFORE durable WAL credit

Independent tested source commit: Valdi320/oomwoo-cleaning-jobs@e82f29c

A new opt-in PhysicalCoverageWALGate connects the prior conservative PhysicalCoverageAdmission policy to the durable CoverageWAL staging boundary. It rejects stale or missing actuator/localization/goal/map/source evidence before any coverage journal entry is created. It accepts only a dedicated producer=physical WAL and does not change the existing Gazebo controller.

466/466 host Python regression tests PASS, including seven new gate positive/negative tests; the local main push was checked against GitHub remote SHA. No physical sensor, motor controller, charging station or actual dirt removal is tested. The trusted-source inputs still require a real independent hardware adapter and MCU interlocks. This is NOT robot hardware certification or a canonical OOMWOO runtime change.

[Valdi320]

Valdi320 cleaning-jobs — consolidated contribution log (28 October 2026)

Scope: contributor-owned Apache-2.0 experimental cleaning-jobs code, not changes to upstream OOMWOO navigation runtime. The versioned pointer in this PR is the authoritative current summary: contribution index. Independent implementation: https://github.com/Valdi320/oomwoo-cleaning-jobs

What improved: fail-closed Nav2 goal/docking authorization; correct terminal and unknown states; synchronized cleaning evidence; complete robot footprint and forbidden-zone checks for rotated/static/local maps; faster collision checking; robust multi-process journals and file validation. These changes target safety, fault recovery, and affordable computation.

Latest verified source: 8123edd8b30e. Reported 617/617 Python regressions PASS (normal and -O), Python 3.10/3.12 CI 2/2 PASS: Actions. Synthetic CPU benchmark: 9.104s to 0.796s, same 530 simulated cells; no ARM, ROS2 or hardware measurements. Current indexed pointer: PR #79 files.

18 source increments (all links retained; oldest to newest):

• 08511a1b275e — Revalidate persisted navigation goal
• f7f475f1b93a — Reject unknown Nav2 state
• 72ff69144da6 — Conflicting terminal results
• 913519b47f9d — Revoke stale docking authorization
• bc3ffb07fbf0 — Synchronize cleaning sensor evidence
• 8d58ea220f74 — Full swept-footprint obstacle checks
• e59247eaa48c — Optimize footprint collision checking
• 2762d6555e9f — Cross-check static and live obstacle maps
• 63f008487242 — Reject invalid map orientations
• 22e1a857fae3 — Validate malformed ROS2 map/TF inputs
• b6705a0f7eb1 — Fully validate global forbidden zones
• 6f286d01f0ad — Fully validate local forbidden zones
• 39bd32612bf4 — Zone writer lock and stale revisions
• a6582801fa9c — Exclusive journal writers
• 5f93fa4e43a8 — Guard replaced/unsafe journal files
• 6dca3bbd0ad7 — Reject FIFO and hardlinked lock files
• ac4ccd7c8369 — Block goals on foreign/stale Nav2 activity
• 8123edd8b30e — Reuse local traversability snapshot; measured synthetic CPU improvement

Validation limits: above follow-ups are primarily synthetic Python/Linux tests; they do not validate physical motors, MCU stop chains, charging/docking or actual dirt removal. Earlier Gazebo/Nav2 results are documented in the independent repository, separate from these specific regression counts. Production integration still needs maintainer-defined cleaning API, global single-owner Nav2 arbitration, real ROS2/Gazebo regression and physical interlocks.

Maintainer action: no per-commit response needed. When convenient, please advise the canonical cleaning-jobs interface and which component exclusively owns Nav2 goals. We will update the versioned PR pointer rather than posting repetitive hourly comments.

[makers-pet]

Hi @Valdi320, I'm getting an email every time you push, about at an hourly pace. Do you think you can batch future updates into one PR per milestone rather than continuous pushes?

If possible, please keep the pointer README short (a few lines, as in #78: what it is, link, how to run it) and put the running log in your own repo. Once it's trimmed I'll merge.

On your questions: there's no frozen cleaning-jobs API yet. Please feel free to propose one in a discussion. FYI, coverage motion is moving to a reactive executor that drives /cmd_vel directly, with Nav2 kept for transits between areas, docking and localization. So, for a room sweep, Nav2 should own only the transit goals. For virtual walls, a separate PR to oomwoo-ros2-tools that adds a KeepoutFilter (mask and costmap filter info servers) to the sim's Nav2 params would be welcome.