Engineering journal

The worker can now show what it’s doing with a light on top: white when idle, blue while driving, green while carrying a part, red on a fault. It runs as its own process, separate from the robot’s brain, so if the display crashes the robot keeps building. The physical LED ring isn’t wired up yet — for now it runs against a stand-in until the parts arrive.

The worker now builds the full three-part plate using only its onboard depth camera, with no access to the simulator’s true positions — the one shortcut that wouldn’t survive a real table. The last bug was a part that kept sliding off the table; giving the parts real weight let them settle like actual bricks. Every earlier demo still passes.

We tested what happens when robots fail partway through a build. A harness kills up to a third of the swarm at the worst possible moment, and the build still finishes every time: a dead robot’s claim expires, its unfinished job reopens, and another robot takes it over — with no coordinator involved. Recovery takes about as long as the claim timeout, and total build time degrades gradually instead of collapsing. Confirmed both in the harness and live in simulation.

Some jobs are too big for one robot — out of reach for a single arm, or a piece that needs flipping. A worker that hits one now calls for help, nearby idle robots offer, and the closest is picked — still with no central coordinator. In simulation, two robots built an oversized part together, one carrying and one steadying it, placed within a couple millimeters.

Two robots now build the three-part plate together, each part placed on the first try. The fix came from the run logs: the robot was treating a slightly-short parking spot as a failure and re-driving from scratch, even when its arm could already reach. It now accepts a close-enough position and places — but a genuinely stuck robot still reports a failure, so real problems aren’t masked.

The first end-to-end run worked but was messy — the robot tipped, shoved parts, and rarely finished cleanly. The main culprit was navigating by wheel odometry, which drifts; switching to a clean position reference fixed the aim. After that it was ordinary tuning: more torque to turn, a firm grip during the carry, and parts spaced so the robot doesn’t trip over its own work. It now drives out, carries each part, and lays them in a tidy row within a few millimeters of target.

The full pipeline ran end-to-end for the first time. In simulation, one robot reads its next job, drives to the part, picks it, places it, and checks its own work. It’s not clean yet — the base tips and retries shove parts around — but the loop is closed, with no human in it.

This is the worker’s execution engine — the part that turns a single job into motion. Each job expands into a small tree of steps with recovery and a verification check built in: a placement isn’t marked done until it’s confirmed, otherwise the job goes back to the swarm. The decision-making is kept separate from the hardware, so the same code runs against a test stub, a simulator, or a real robot.

Most multi-robot systems rely on a central scheduler handing out jobs. WEAVE doesn’t have one. Every robot keeps its own copy of the build plan, and they stay in sync by passing a couple of small messages per job — no dispatcher, no polling. Work is claimed with short leases that expire on their own, so if a robot drops out its job reopens for someone else automatically.

WEAVE starts by turning a LEGO instruction booklet into something the robots can read. A vision model works through the booklet page by page and turns each step into a node in a dependency graph: which part, where it goes, and what has to exist first. Parts are matched against a real catalog so the plan names exact components. That graph is the shared plan every robot builds from.

First hardware steps. The starting code is in place and the first worker chassis and gripper are coming off the 3D printer. Early focus is the mechanical platform and the perception scaffolding for part detection.

Everything so far runs in simulation. Next is putting the same software on physical worker robots — one to start, then a few — and seeing how the coordination holds up off the simulator.