What did Oomwoo actually launch?
Oomwoo launched in June 2026 as an open-source, build-it-yourself robot vacuum developed by Maker’s Pet (creator Ilia O.), with code and firmware released under Apache 2.0 and a first bill of materials targeted for mid-July 2026. The reference design pairs a 3D-printable chassis with a 2D LiDAR sensor and bumper sensors, maps the home, and cleans autonomously. Ilia is developing it in public, “from the first commit,” though the project is early enough that build instructions do not yet exist.
The project comes out of Maker’s Pet. A convenience kit (motors, PCB, brushes, gaskets, LiDAR) will be sold through Maker’s Pet, but buying it is not a requirement and every part can be sourced independently. That framing matters: this is not a kit business wearing an open-source costume. The kit exists to remove friction for people who do not want to hunt parts, not to gate the build.
The current v0 milestone, per the repo, covers a 3D-printed chassis, a ROS 2 Gazebo simulation, and LiDAR mapping with manual SLAM. Planned open-source deliverables run from the bill of materials and 3D-printable files to firmware, a motor-driver and sensor PCB, and full build, setup, bring-up, and troubleshooting instructions. None of that is shipped yet. Reading “open-source robot vacuum” as “shipping product” will leave you disappointed; reading it as “a public hardware project with a credible architecture and a dated BoM target” is closer to the mark.
How is the vacuum architected?
Oomwoo runs ROS 2 and the Nav2 stack on Raspberry Pi compute, maps with an affordable 2D LiDAR sensor, and integrates natively with Home Assistant, with no cloud required for regular functionality. The GitHub repo lists the stack as Raspberry Pi, ROS2, Home Assistant, 2D LiDAR, 3D-printed, ESP32, and Arduino, all under Apache 2.0.
The compute choice is not yet locked. The repo’s v0 target states the decision is “TBD” between ROS 2 on a Raspberry Pi 5, an ESP32 running micro-ROS with ROS 2 on a local PC, or both. That is a real architectural fork with real consequences: a Pi 5 is a full Linux node capable of running Nav2, SLAM, and a broker on-device; an ESP32 running micro-ROS is a microcontroller that depends on a companion PC for the heavy graph. Picking both preserves optionality but doubles the bring-up surface. The project is honest that this is unresolved, which is more than most hardware launches manage.
Local-first is the design constraint, not a feature checkbox. The repo commits to cloud-free, local operation for regular functionality out of the box, with cloud reserved for optional extras. Stretch goals listed in the repo include an app store and LeRobot plus OpenClaw integration. The pitch to a Home Assistant user is straightforward: this vacuum behaves like a local device, speaks a protocol you already run, and does not phone home to qualify for basic operation.
What changes for repairability when the schematics are public?
When the bill of materials, 3D-printable files, firmware, and PCB design are all public under permissive licenses, repairability stops being a vendor’s goodwill gesture and becomes a structural property of the device. That is the part of the Oomwoo pitch that is genuinely different from the Roomba/iRobot model of sealed units and proprietary firmware, and it is the part most likely to outlast the specific v0 design.
The license posture is asymmetric in a telling way. Code and firmware are Apache 2.0 today; the repo names no hardware license yet. The project’s stated goal is “affordable, fully open hardware, software and firmware,” but until a hardware license (CERN-OHL, TAPR, or similar) is named and the design files land, the “open hardware” claim is a commitment, not a delivered artifact. Apache 2.0 on the firmware and ROS 2 packages is real and present; the hardware side is a promise without a named license.
Why does running offline matter?
Oomwoo’s offline-only design is a direct response to a documented string of robot-vacuum security failures, in which cloud-connected vacuums became remotely accessible cameras and microphones inside buyers’ homes. The reference design navigates on 2D LiDAR and bumper sensors with nothing pointed at the room, per Tom’s Hardware, eliminating the camera and microphone attack surface present in commercial vacuums.
The threat model is not hypothetical. At DEF CON 32 in August 2024, researchers Dennis Giese and Braelynn Luedtke demonstrated that several Ecovacs models could be hijacked over Bluetooth to reach their cameras and microphones; Giese told TechCrunch the security was “really, really, really, really bad.” Hijacked DEEBOT X2 units later shouted slurs and chased pets in several U.S. homes. A token flaw in DJI’s Romo line let one tinkerer reach roughly 6,700 vacuums worldwide, including floor plans and live feeds, per Tom’s Hardware. One owner went as far as reviving a remotely bricked vacuum with custom boards and Python to run it offline. These are the incidents Tom’s Hardware cites as the backdrop for Oomwoo’s no-cloud default.
Open firmware makes the privacy claim auditable rather than aspirational. Oomwoo’s site states that because the firmware is open, “you can audit it and nothing leaves your home.” That is the mechanism: a vacuum you can read the source of cannot hide a telemetry path the way a binary blob can. The tradeoff is that auditability requires someone to actually do the auditing, and a project at RFC stage does not yet have the contributor base for sustained security review. The design removes the attack surface; whether the community holds that line is a separate, open question.
How does this differ from Valetudo?
The closest existing path to a cloud-free robot vacuum is Valetudo, maintained by Sören Beye since 2018 and also Apache 2.0, which replaces a commercial vacuum’s cloud connection with local-only control and Home Assistant integration. Installing it requires rooting the vendor firmware, which on many supported Dreame, Roborock, and Xiaomi models means disassembly, voids the warranty, and cannot be undone. Valetudo modifies a sealed appliance from the inside.
Oomwoo starts from scratch with no proprietary dependencies. There is no vendor firmware to root, no warranty to void, and no binary blob to reverse-engineer, because the entire stack is being written in the open. The cost of that cleanliness is that Oomwoo ships no vacuum today, while Valetudo runs on hardware you can buy this afternoon. They are complementary projects aimed at the same outcome through opposite routes: Valetudo liberates existing appliances; Oomwoo argues the next appliance should not need liberating.
How does the modular build model work?
Oomwoo splits the vacuum into independent modules called RFCs (Requests for Contributions), so a contributor claims a module, works on it whenever they want, and submits a pull request, enabling parallel community development. The repo describes this as building “massively in parallel,” with the project master having the last call and the best solution for each module surfacing over time.
The modules are not independent in the dependency sense. The repo’s RFC table currently lists urdf-gazebo-sim (the URDF and Gazebo simulation) as in progress and clean-and-map (coverage, mapping, and exploration) as ready to start, with ARCHITECTURE.md holding the system design and interfaces. The list is dependency-ordered rather than a free-for-all, and the project is candid that mechanical work is gated on parts Ilia is still sourcing.
What is missing, and what are the timeline risks?
The honest scope of v0 is narrow: a 3D-printed chassis, a ROS 2 Gazebo simulation, and LiDAR mapping with manual SLAM. Vision-based obstacle avoidance is deferred; the v0 design relies on 2D LiDAR and bumper sensors rather than a camera. Anyone expecting Roomba-equivalent obstacle handling at launch is reading the wrong spec sheet.
The timeline risks are concrete. The compute architecture (Pi 5 versus ESP32 micro-ROS versus both) is undecided, which blocks firmware bring-up decisions downstream. No hardware license has been named yet, which means the open-hardware half of the pitch is a commitment without a delivered license. The first BoM is targeted for mid-July 2026 and a final fully-costed BoM by end of August 2026, per oomwoo.com, but mechanical work waits on parts Ilia is still sourcing. A hardware project that misses a BoM date is normal; a hardware project that has not yet named its compute node or its hardware license has more than dates to settle.
The larger claim Oomwoo makes is not about price. It is that vacuum robotics stops being a black-box appliance category the moment the schematics, the BoM, and the firmware are public under permissive licenses. Whether v0 lands on schedule is a project-management question. Whether the category can be reopened at all is the one this launch actually poses.
Frequently Asked Questions
What happens if someone forks Oomwoo and sells it as a commercial product?
The Apache 2.0 license on firmware and software explicitly permits commercial use and does not require derivative works to stay open. Someone could manufacture and sell an Oomwoo-derived vacuum with closed hardware modifications, provided they preserve the Apache notices on any unmodified code. A named hardware license (CERN-OHL, TAPR) would add stronger share-alike obligations, but the project has not committed to one yet.
How does the Raspberry Pi versus ESP32 decision affect who can build this?
A Raspberry Pi 5 build keeps the vacuum self-contained but adds roughly $60-80 in compute cost. An ESP32 micro-ROS approach shifts the heavy navigation work to a companion PC or server, which means the vacuum is cheaper but your floor plan lives on another machine. The both option preserves flexibility but increases bring-up complexity and documentation burden.
What specific security incidents does Oomwoo cite as justification for its offline design?
The DEF CON 32 demo in August 2024 showed Ecovacs vacuums hijacked over Bluetooth to access cameras and microphones, with hijacked units later shouting slurs and chasing pets. A DJI Romo token flaw exposed roughly 6,700 vacuums worldwide, including live feeds and floor plans. These are the documented cases that motivated the camera-free, cloud-free architecture.
Can I contribute to Oomwoo without owning a 3D printer or buying the convenience kit?
Yes. The RFC system separates hardware procurement from software and firmware work. Modules like the URDF/Gazebo simulation, Nav2 tuning, ROS2 packages, and documentation can be developed entirely in simulation or with reference to the publicly posted design files. The project explicitly structures contribution to avoid gating on physical parts availability.
What obstacles will the LiDAR-and-bumper sensor setup fail to detect?
The 2D LiDAR sees walls and furniture legs at a single horizontal plane, so it will miss low-lying obstacles like power cables, socks, and pet toys that sit below the sensor beam. Without vision-based obstacle detection or structured depth sensors, the vacuum must either rely on bumper contact collisions to register these obstacles or require users to keep floors unusually clear. This is the tradeoff accepted to eliminate camera security exposure.
