Oomwoo is an early open-source robot vacuum project from Makers Pet. The pitch is a modular, community-built robovac with printable parts, off-the-shelf components, and software you can modify yourself. The appeal was obvious. People want robot vacuums that do not depend on vendor clouds, do not ship camera data off-box, and can actually be repaired or customized when they fail. That broader demand came through much more clearly than confidence in this specific project.
The strongest reaction was that building the whole machine from parts is economically upside down. A decent
lidar-based vacuum can already be bought used or even new for less than the parts cost here. That pushed attention toward a more credible open strategy: reuse commodity hardware, replace the brains, and keep the motors, sensors, dock, and chassis that manufacturers already mass-produce.
Valetudo came up repeatedly as the current version of that instinct, though several people pointed out it is a control layer for rooted vacuums rather than a full replacement firmware.
A second theme was that existing robot vacuums are not uniformly disposable junk. Several owners described old Roborock, Xiaomi, and Roomba models that are years old, easy to open, and still repairable with replacement batteries, motors, brushes, or lidar parts. That cuts against the premise that the only path to repairability is full open hardware. The more compelling case for Oomwoo was not basic longevity. It was custom behavior, privacy, and the ability to tune navigation and cleaning logic for weird homes and edge cases that commercial software handles badly.
What held people back was the state of the project itself. The
repo is very young, the materials look thin, and multiple readers said the announcement and docs read like
LLM boilerplate rather than evidence of a working prototype. That did not kill enthusiasm for the idea. It did make people treat Oomwoo as a wishlist and coordination layer, not as a demonstrated robot. Even the comments most sympathetic to AI-assisted development drew a bright line here: using coding agents to bootstrap a one-person hardware-software project is plausible, but generated prose and mockups are not a substitute for a build log, test videos, or a clear bill of materials tied to something that already moves.