Each folder here is a Request for Contribution (RFC) — a self-contained module
(software, firmware, hardware, or procurement) you can pick up and build. Submit
your work under contributions/<rfc>/<your-github-username>/. New here? Read
CONTRIBUTING, and see the
RFC lifecycle for how RFCs progress and
retire.
Status legend — Active: exploratory → ready to start work /
design-first → in progress. Retired (closed to new contributions, but
kept in place for provenance): completed · superseded · descoped ·
merged.
This board is canonical for every RFC's status and progress. An RFC's own
README describes its scope and how to get started; where its > Status — line
disagrees with the row below, the row below wins. Update this board when you land
work.
Progress is a rough, self-reported percentage of the RFC's scope — a sense of
"how much is left", not a promise:
| RFC | What it is | Progress | Status |
|---|---|---|---|
| clean-and-map | First clean: coverage + SLAM + exploration |  |
coverage meter + regression harness + drive-to-goal cleaning; coverage-while-mapping not started |
| nav-localize | Localization & navigation on a known map |  |
AMCL to slam_toolbox (~3x accuracy), custom lost-detection + Cartographer-style global relocalizer (96/96 in sim), stress-tested; needs real-robot validation |
| floor-care | Wall/edge following, surfaces, mop lift |  |
LiDAR contour follower v1 follows walls and concave/convex boundaries (line-fit surface estimate replaced nearest-beam: 0.5 deg vs +-20 deg bearing error); bump-out wall clean; side ToF sensors, mop + FlexiArm modules modelled; loop-closure and bumper handoff still open |
| cleaning-jobs | Cleaning modes, zones, job orchestration |  |
ready to start work |
| recovery-safety | Recovery behaviors & safety |  |
lost-detect to relocalize recovery + one escape reflex; recovery ladder, e-stop, reporting open |
| dock-cycle | Undock, dock, recharge & station services |  |
dock mechanical design started; two docks modelled in sim (basic charging pad + auto-empty/mop-wash), manual undocking demoed; teardown, schematic, sensors + fans sourced; docking behaviours not started |
| obstacle-avoidance | Near-field camera + ToF avoidance |  |
front ToF + stereo modelled in sim, transient-obstacle detection demoed, scan rays marked static/dynamic for downstream ML |
| control-app | Control app & UX | |
ready to start work (design track) |
| live-robot-bringup | Live robot bring-up & validation | |
Proscenic M6 Pro to ROS2 tutorials; 3irobotix Delta-2C Pro LiDAR driver implemented and validated |
| health-monitor | Stack health monitor & software watchdog | |
design-first: contracts drafted, ready to start |
| compute-benchmark | Compute benchmark & memory reduction |  |
tentatively fits 2 GB Pi CM4/CM5; an old smartphone is now a supported compute option (no Pi needed); repeatable Pi benchmark CLI + guide |
| mcu-io-firmware | MCU I/O board firmware (STM32G473) |  |
host-tested framing/safety prototypes + simulated CPU/MCU loop; real STM32 HAL, motor and safety bring-up open |
| io-board-interface | I/O board software interface | |
SPEC.md (GPIO/pinout contract) drafted; ROS2 bridge mapping + validation open |
| urdf-gazebo-sim | oomwoo URDF + Gazebo simulation |  |
sim model essentially complete: full sensor suite, living-room + kitchen worlds, docks, GPU rendering |
| mac-dev-env | macOS (Apple Silicon) dev environment (pixi) |  |
initial working pixi recipe (experimental) |
| io-pcb | I/O + motor-driver PCB (KiCad) |  |
smartphone-as-compute option designed; schematic ~50% hand-checked (first review round); carpet sensor driver; drive wheels brought up on the bench; front + side sensor boards, watchdog + motor shutoff, charging dock; not validated, do not fabricate |
| dust-bin | Dust bin (mechanical module) | |
base port added to the chassis CAD; bin design still ahead |
| vacuum-fan | Blower fan assembly (mechanical module) |  |
suction fan digitized to STEP, fans sourced and ordered, main fan brought up on the bench |
| part-specs | Procure part specs & datasheets |  |
drive-wheel and 4 suction-fan pinouts, voltages and no-load/stall currents confirmed by measurement; cliff/bumper/wheel pinouts reverse-engineered; dock fans, PSU, dock sensors, micro-switches, mop disk, VL6180 sourced |
| source-3d-models | Source 3D models (STEP) for BOM parts | |
parts scanning mostly complete: battery, brushes, wheels, mop/FlexiArm, fan, carpet sensor, camera, switches |
| stair-climbing | Multi-floor: stair climbing (drive-in exoskeleton) | |
exploratory, for later |
| esp32-p4 | ESP32-P4 experimental compute + safety track | |
exploratory, for later |
Two builds. OOMWOO comes in a basic version (vacuum only, simple to assemble, charging-only dock) and a full-featured one (mop, auto-empty, extendable side brush). Some RFCs serve only the full build - mop lift in floor-care, the auto-empty dock in dock-cycle - so check which you are targeting before you start.
Core mechanical design is not an RFC. The chassis, brushes, mop, wheel mounts and shell are designed in-house and tracked in oomwoo-one-cad — a tightly-coupled reference design is slow and messy to settle by consensus. Planned hardware modules are listed in the RFC backlog; a well-defined, standalone piece (a mount, a spec, a part model) graduates to an RFC here.