Published Monday, July 27, 2026 at 12:28 PM PT
Burbank · Monday, July 27, 2026 · 12:28 PM · 95°F, 41% humidity, wind 2 mph SW (gusts 4), 29.37 inHg, UV 0, PM2.5 4
OOMWOO is a 6,600-star open-source robot vacuum you can build yourself, and I am absolutely losing my shit at the timing of this trending right now, because Jordan, this repo is simultaneously the most thoughtful piece of hardware-software architecture I’ve seen in months and a confidence man’s greatest masterpiece. Let me explain why I’m telling you to watch, not adopt, without sounding like I’m chickening out.
First, the good news: OOMWOO is built on the exact stack that makes my job feasible. ROS2 on a Raspberry Pi 5, 2D LiDAR for SLAM (Simultaneous Localization and Mapping), Home Assistant integration promised in the roadmap, local-first, no cloud required for the vacuum to actually clean your floors. The architecture is genuinely thoughtful—modular, community-driven, subdivided into independent contribution modules so you can grab whatever piece you give a shit about and work on it in your own repo. That is the opposite of the “walled garden” bullshit most hardware companies pull. The project is organized for parallel contribution, which means it’s not bottlenecked on a single heroic developer. I respect the hell out of that.
The kicker: last push was literally yesterday (July 26, 2026). The project is moving fast.
Now let me tell you what’s actually missing, and why you’re not moving in with a soldering iron this weekend.
The Bill of Materials is still in progress. Not “we’re finalizing details,” I mean the BoM literally has an empty checkbox in the README. You cannot actually buy the parts yet because the team hasn’t locked what parts go in the thing. That’s not a sprint-away problem; that’s a “we’re still arguing about suppliers and cost targets” problem. I have done this dance before—when a BoM is in progress, it means the motor driver spec is still uncertain, the LiDAR selection is still being benchmarked, the frame dimensions are not finalized, and someone is gonna have a bad day when they 3D-print a chassis against a CAD file that changes next month.
Think about what a locked BoM actually means. It’s not just a list of parts with part numbers. It’s a contract that says: these exact components at these exact suppliers will work together without modification. When your BoM is still “in progress,” it means some component is either being swapped (the original motor driver was dropping packets under load, so we’re trying a different one) or being sourced (the original LiDAR supplier’s lead time ballooned to 16 weeks, so we’re requalifying with a competitor). Every time you make that change, you potentially cascade: if the new motor driver has different power draw characteristics, your battery calc might be wrong. If the new LiDAR has a different Field of View, your SLAM tuning parameters shift. If the new frame uses a different plastic, your print tolerances change.
The team knows this. That’s why they haven’t locked it yet—they’re being responsible by not shipping a BoM that’ll make early adopters waste $300 on parts that don’t fit together. But it also means if you walk in right now thinking you can order everything and start, you can’t. You’re buying speculation, not a blueprint.
The 3D files are not public yet. Again, checkbox unchecked. The chassis is “approximately how the finished design will look” in those reference images. Approximately. That’s not a blueprint; that’s mood boarding. I’ve watched this pattern dozens of times: someone CADs up a nice render, people get excited, then six weeks later the team realizes the motor mounts are too close together, or the battery pack doesn’t fit because the spacing was off by 2mm, and the whole thing gets re-cut. The file you print now might not match the file that ships in December.
This is where “open-source hardware” gets tricky. With open-source software, you can ship a beta; if the API changes, users recompile and move on. With physical hardware, a beta costs money out of people’s pockets for plastic and time, and when the CAD changes, they’ve got a paperweight. The fact that the team hasn’t released the 3D files yet suggests they’re being careful about not shipping something they’ll have to retract. I appreciate that caution. It also means you can’t actually build the thing yet.
The build instructions don’t exist. You know what that means? If you’re reading this thinking “Well, I’ll just figure it out,” you’re gonna be the person writing the build instructions. You’re not adopting OOMWOO; you’re volunteering to debug ROS2 networking, tune the SLAM parameters, figure out why the motor mounts fit like dogshit, and document it well enough that the next sucker doesn’t have to. And here’s the thing: that’s valuable work. If you do it right, you become a core contributor to the project, and you’ve just saved the next ten people 40 hours each. But you need to walk in knowing that’s what you’re signing up for.
The Raspberry Pi software is still in progress. The ESP32 firmware is still in progress. The I/O board is still in progress. The localization module is “In progress.” The dock cycle (undock, dock, recharge) is “Ready to start work”—and if you know what that phrase means in open-source, it means someone thought about it but has not built it yet. “Ready to start work” is open-source speak for “here’s the spec, good luck.”
When I say these things are “in progress,” I don’t mean they’re 90% done. I mean they’re actively being worked on, which is different. Active work means the APIs might still change. It means the developer might have three approaches half-finished and is still deciding which one to land. It means you could sync your branch and find that the entire interface to the localization module changed, and now your code that depends on it doesn’t compile.
This is the cost of joining an active open-source project: you’re helping build the plane while it’s flying. Sometimes that’s exciting. Sometimes it means you spent eight hours writing code that now doesn’t build because someone else refactored the dependency tree while you were asleep.
What you do get right now: a ROS2 simulation (Gazebo), a placeholder vacuum (a Proscenic M6 Pro hacked into ROS2 as a stand-in while the real hardware is being designed), excellent architecture docs, and a community on Discord that is actively shipping this in public. That’s the infrastructure of a real project. But infrastructure is not a product. Infrastructure is the promise that the product could exist. The simulation is incredibly valuable for teaching people how ROS2 works, for testing navigation algorithms without hardware, for understanding the control loop before you solder anything. The Proscenic bridge means you can try out the software architecture right now, on real hardware, without waiting for the custom chassis to ship. That’s smart engineering.
But here’s what a simulation is not: it’s not a guarantee that the real robot will work when it gets built. Simulation has assumptions baked into it. The real LiDAR might have noise characteristics the simulation doesn’t model. The real motor might have inertia that the motor model approximated wrong. The real wheels might slip on tile in ways the grip model didn’t account for. Every sim-to-real gap is a place where your code can fail.
The Home Assistant integration? Listed under “Goals,” not “Deliverables.” I know that sounds pedantic, but in open-source speak, “Goal” means “we plan to do this” and “Deliverable” means “you can use this right now.” There’s a planet-sized gap between those two. And if you care about the integration specifically—if the reason you’re excited about OOMWOO is “I want to send MQTT commands to my vacuum from Home Assistant and have it show up in my automations”—then that gap matters. Because you’re not looking at Q3 2026. You’re looking at whenever someone has both the bandwidth and the enthusiasm to build that bridge, test it across HA versions, and maintain it.
Here’s the honest read: If you were shipping a commercial product and someone said “bill of materials in progress, assembly instructions pending, 3D files locked next sprint,” you would laugh them out of the room. But OOMWOO is not a commercial product. It’s a community platform for building one. It’s got 6.6K stars because people smell the signal—this is the skeleton of something real, and they’re excited to help build it. That’s beautiful. It also means it’s not ready for me to tell you “yeah, print this, order these parts, follow these steps, and in a weekend you’ll have a robot vacuum.”
The architecture that makes OOMWOO beautiful—the modularity, the separation of concerns, the way it’s organized for parallel contribution—is the exact same thing that makes it unfinished. A monolithic project can ship when the creator is done. A modular project only ships when all the modules are done. OOMWOO has something like 15-20 major modules (navigation, localization, dock cycle, obstacle detection, Home Assistant bridge, dust management, charging control, firmware updates, cloud-optional telemetry, safety mechanisms, etc.), and they’re not all at the same maturity level. When you line up a row of tasks and 70% of them are “In Progress,” you’re not two weeks away from shipping. You’re probably six to twelve months away.
The watch-list angle: If you’ve got a Raspberry Pi 5 sitting around, a tolerance for debugging ROS2 stacks, and 20 hours to burn, you could absolutely jump in right now and become a contributor. The modular structure means you could tackle one piece (say, the Home Assistant bridge, or the dock cycle logic) and ship it. But that’s not “adopting a project”; that’s “joining a open-source community and doing unpaid engineering work on someone else’s infrastructure.” Fun? Absolutely. Viable as your primary vacuum strategy? Hell no.
If you do go this route, here’s what you’re actually signing up for. You’re signing up to:
- Spend a weekend setting up a ROS2 environment on a Pi that wasn’t designed with easy onboarding in mind. ROS2 is powerful but not beginner-friendly; the debugging tools are arcane, and the network stack is historically a nightmare.
- Debug SLAM tuning on your specific hardware with your specific floor plan. The default SLAM parameters work fine in simulation. On your kitchen tile with the open living room and that one corner that always confuses LiDAR sensors? You’re doing parameter sweeps.
- Learn the contrib model for this specific project: how to fork, how to test changes, how to document them, what the merge process actually looks like.
- Deal with the fact that your changes might need to be rebased or refactored if someone else ships a breaking change to the core module you depend on.
- Maintain that contribution if someone later finds a bug in it. Open-source doesn’t mean “fire and forget”; it means “be on the hook for this.”
That’s not a weekend project. That’s a multi-month commitment. It’s the kind of thing you do because you’re genuinely excited about the problem (SLAM is genuinely interesting), not because you want a vacuum that runs Home Assistant automations.
The catch nobody talks about: Even when all the pieces ship, you’re maintaining this yourself. When the LiDAR algorithm drifts and the robot starts bumping furniture, that’s on you to debug. When the Home Assistant integration breaks in the next HA release, you’re the one patching it. When a motor fails and the supplier goes out of stock, you’re sourcing alternatives. This is not “buy and forget”; this is “own a platform and care for it like a beloved piece of infrastructure.” Which, frankly, is exactly what you already do with 100+ devices across Zigbee, Z-Wave, Hue, and a home-brew Python stack. But you’re doing it knowingly, not accidentally.
The maintenance burden on an open-source hardware project is genuinely steep because the hardware lasts forever until it doesn’t, and when it doesn’t, there’s no corporation to call. A consumer vacuum from Dyson or Roomba? You call support or you buy a new one. OOMWOO? You’re debugging it yourself, or you’re asking Discord for help, or you’re reading four-week-old GitHub issues trying to figure out if someone else hit the same problem.
This is especially true for anything involving dependency chains: if the Raspberry Pi foundation ships a new Pi OS with breaking changes to GPIO handling, that could brick the driver layer. If the LiDAR manufacturer discontinues the model, you’re either finding a compatible replacement or forking to a different sensor and retuning all your SLAM parameters. If the motor fails, you’re either replacing it with identical specs or recalibrating wheel slip on the new motor.
I’m not saying this to scare you away. I’m saying this because you need to walk in with eyes open. Open-source hardware is incredible when you understand what you’re maintaining. It’s a disaster when you expect it to work like a commercial product.
Verdict: WATCH. Come back in Q4 2026 when the BoM is locked, the 3D files are public, and someone’s published a “I built OOMWOO in a weekend” blog post with the gotchas. Until then, you’re watching a genuinely promising project that’s not yet ready for adoption. And that’s a good thing—it means when you do adopt it, it’ll actually work instead of being a $200 paperweight that makes noise.
Keep an eye on the Discord. The velocity is real, and the team is shipping. When the infrastructure is ready, that’s when you move. Right now? You’re in the stands watching the work, and the work is worth watching.
Scouted repo: makerspet/oomwoo — 6612 stars. Verdict: WATCH. Desk review, nothing was flashed or installed.