OOMWOO: the open-source robot vacuum you build yourself

What OOMWOO is, and the gap it aims at

OOMWOO is an open-source home robot vacuum you build yourself, described in the README as using Raspberry Pi, 3D printing, Home Assistant, Arduino and ROS2. It maps with an affordable 2D LiDAR and navigates on its own. The stated goals are an affordable, fully open hardware and software stack, Home Assistant integration for local control, and a 3D-printable, documented, hackable chassis. The README is explicit that regular functionality needs no cloud and that there is no vendor lock-in.

The audience is narrow and specific. This is for people who already know what a URDF is, who are comfortable with a Linux SBC, and who treat a vacuum as a robotics platform rather than an appliance. The README frames the whole thing as built by the community, massively in parallel, with modules picked off an RFC board. If you want a vacuum that arrives in a box, this project is not aimed at you, and the README does not pretend otherwise.

The module architecture, and why the README links instead of copying

The repository is deliberately thin. Top-level entries are .github/, .gitignore, BOM.md, LICENSE, README.md, assets/, contributions/ and docs/. The actual work is split across sibling repositories: oomwoo-install for the ROS2 and Ubuntu environment, oomwoo_urdf for the robot description package and config, oomwoo-one-cad for 3D-printable files, oomwoo-pcb for motor drivers and sensor boards, and oomwoo-io-firmware for the STM32 I/O board firmware.

Contributions follow two paths. For code and simulation modules, a volunteer builds the package in their own repository and sends a short PR that links it from the module. For docs and specs, files go in-tree under contributions/module-name/<github-username>. The README states plainly that the RFC board is the single source of truth and that a second copy on the main page would only drift out of date. That is an honest call, and it also means the README alone will not tell you what is currently buildable. You have to open contributions/README.md.

Multiple developers may work the same module, and the README says the project master has the last call on which solution surfaces. That is a governance choice worth noticing: it keeps quality control central, but it also means a merged contribution is not guaranteed to be the one that ships.

Installing the ROS2 environment and running the Gazebo simulation

The README does not put install steps on the main page. It points to the oomwoo-install repository for the software development environment and to a tutorial on simulating the OOMWOO ONE robot vacuum in Gazebo with ROS 2. The checked-off deliverables list includes the software development environment, the robot description package and the tutorials, so the simulation path is the part of the project that is furthest along.

Start by cloning the install repository, which is where the ROS2 and Ubuntu setup lives:

git clone https://github.com/makerspet/oomwoo-install
cd oomwoo-install

The robot description and configuration live in a separate package, so a simulation setup pulls both:

git clone https://github.com/makerspet/oomwoo_urdf

Before writing any code against the robot, read the two design documents the README names for contributors:

ls docs/ARCHITECTURE.md docs/SOFTWARE_INTERFACES.md

Those files describe the system design and the ROS2 interfaces. The README does not publish the exact launch command for the Gazebo world on the main page; it routes you to the tutorial linked from the deliverables list. Treat the tutorial as the source for the launch invocation rather than guessing one.

The hardware side is not finished, and the README says so

Look at the deliverables checklist. Checked: software development environment, robot description package, tutorials, a placeholder real vacuum with tutorials, a rough bill of materials, and 3D-scanned sourced parts. Unchecked: 3D-printable files, Raspberry Pi software, motor drivers and sensor PCB boards, I/O PCB firmware, and build, setup, bringup and troubleshooting instructions.

The README states that early build instructions will be available in Fall 2026. Until then, the only physical robot you can drive is a placeholder: a Proscenic M6 Pro connected to ROS2, documented in a tutorial. That is a sensible way to let software contributors work before the chassis exists, but it means a reader who wants to 3D print and assemble an OOMWOO today has no files to print and no bringup sequence to follow.

The v0 target is described as a bare-bones build: 3D-printed chassis, ROS2 Gazebo sim, basic cleaning and mapping, and a Raspberry Pi CM4 or CM5 running ROS2. Note the module boundary. The compute board is a CM4 or CM5, while the I/O and motor control sit on a separate STM32 board. That split is normal for a robot, and it also means two firmware surfaces to keep in sync, one of which is still unchecked.

Licence and the cost of tracking an unfinished project

The repository is Apache-2.0, and the README repeats the licence badge. Apache-2.0 is a permissive licence with an explicit patent grant, which matters for a project that expects contributors to publish packages in their own repositories and link them back. It does not obligate anyone to publish hardware files, and the 3D-printable files are a separate repository whose status the main README does not resolve. If you plan to sell anything derived from this, read the licence text and the contributing guide yourself rather than working from a badge.

The upgrade cost is the real one. Because code modules live in contributors' own repositories and are linked from the RFC board, there is no single versioned release to pin. The repository has no retrieved releases. Tracking this project means watching the RFC board, the discussions, and several sibling repositories, and accepting that the best solution for a module can change when the project master makes a call. That is a maintenance burden you take on deliberately, not one the project hides.

How OOMWOO differs from Valetudo and from buying a Roborock

The README lists Valetudo as related prior art and describes it as a cloud-free firmware replacement for commercial vacuums, offering local app-level control, not ROS2. That is the cleanest way to see the fork in the road. Valetudo keeps the commercial vacuum you already own and replaces its cloud dependency, so the hardware, motors and cleaning performance stay whatever the manufacturer shipped. OOMWOO goes the other way: it replaces the whole machine with a design you source, print and assemble, and it puts ROS2 and Nav2 at the centre so you can write applications on top of the vacuum.

Against a Roborock or a Roomba, the difference is not features, it is who owns the stack. A commercial vacuum will clean your floor sooner and with less effort. OOMWOO gives you a URDF, a Gazebo world and a documented ROS2 interface, and asks you to earn the rest. The README also lists kaiaai/LDS and kaiaai/lds2d as open-source 2D LiDAR libraries covering 23 or more LiDAR models, and codetiger/VacuumTiger as reverse-engineered low-level control for a 3irobotix CRL-200 based vacuum. Those are the parts of the ecosystem you would lean on if you wanted to reuse existing LiDAR support instead of writing it.

What to check before you commit a weekend to it

Open contributions/README.md first. The README says every module there is actionable now, either against the Gazebo simulation or against a placeholder robot, and that the board carries each module's current progress and status. If the module you care about is not on that board, check docs/RFC_BACKLOG.md, which holds planned and on-hold modules including mechanical design and later-phase software.

Second, read BOM.md. The README calls it a rough version, which is a warning about sourcing, not a promise. Cross-check every part against what is actually purchasable before you order anything.

Third, read docs/SOFTWARE_INTERFACES.md before writing a package. If the ROS2 interfaces are still moving, a module you build against them may need rework when the project master settles a competing solution. The simulation is the safe place to start, and it is the part the deliverables list marks as done.

Editorial conclusion

Adopt OOMWOO if you already run ROS2 and want a hackable vacuum whose navigation stack you control, and you are willing to work from the Gazebo simulation and the rough BOM while the hardware files are unfinished. Do not adopt it if you want a vacuum this month, or if you have no ROS2 experience and no 3D printer. Before committing, check the RFC board for the module you would depend on, confirm the parts in BOM.md are still sourceable, and read docs/SOFTWARE_INTERFACES.md to see how much of the ROS2 interface is actually frozen.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. makerspet/oomwoo on GitHub
4. Project website
5. README