DEV Community: Adeline

How much of your pool does the robot actually clean? A coverage simulator in 60 lines of Python

Adeline — Fri, 13 Nov 2026 14:18:22 +0000

A distributor forwarded me a customer email last month. Two lines:
"The robot runs for 40 minutes and the floor still looks striped. Is it broken?" stonebotclean.com
The honest answer is that I didn't know. Every spec sheet in this category quotes a runtime, a swath width and a suction power. None of them quote coverage, because coverage is not a spec you can print — it is what happens when a path meets a rectangle with walls on four sides.
So I stopped reading brochures and wrote a simulator. Rasterise the pool at 2 cm, stamp the brush along the path, count how many cells never get touched.
Here is what came out, and the three things I got wrong on the first pass.
**
The model
Nothing fancy. A 12 × 6 m pool (72 m², a normal residential rectangle), a 42 cm effective swath, 0.28 m/s while scrubbing, 6 s for a 180° lane change, 15 cm of standoff so the brush housing clears the wall, and a 150 minute battery.
Four serpentine variants, differing only in lane pitch:
pitch = 1.00 × swath (0.42 m): the textbook answer, lanes exactly tangent
pitch = 0.85 × swath (0.36 m): 15% overlap
pitch = 0.70 × swath (0.29 m): 30% overlap
pitch = 1.30 × swath (0.55 m): what happens when someone tunes the lane spacing up to "finish faster"
Plus one control: a random-bounce run with no planning at all — drive until you hit a wall, deflect, keep going, change heading roughly every 8 seconds. That is what a $300 hobby unit does, and it is the baseline every lidar-equipped robot is implicitly being compared against.
The measurement is a disk stamp: at every 4 cm along the path, mark every 2 cm cell within 10.5 cm of the centre as cleaned. Then count.
def boustrophedon(pitch, pool, bot):
L, W = pool["length"], pool["width"]
stand, w = bot["standoff"], bot["width"]
x0, x1 = stand, L - stand
y0, y1 = stand, W - stand
lane_y, y = [], y0 + w / 2
while y <= y1 - w / 2 + 1e-9:
lane_y.append(y)
y += pitch
if lane_y[-1] < y1 - w / 2 - 1e-6: # edge pass
lane_y.append(y1 - w / 2)
...

That edge pass line is the first thing I got wrong. Without it, the loop stops as soon as the next lane would cross the top wall, and the last 28 cm of the pool simply never gets driven. On the 15% overlap run that was 4.9% of the floor — invisible in a spec sheet, visible to anyone standing at the shallow end.
What the numbers said
Strategy
Lane pitch
Floor reached
Time
Swept area / floor
Lane changes
Tangent lanes
0.42 m
99.66%
11.9 min
1.03×
13
15% overlap
0.36 m
100.00%
13.4 min
1.17×
15
30% overlap
0.29 m
100.00%
15.8 min
1.37×
18
Over-spaced
0.55 m
80.69%
9.5 min
0.83×
10
Random bounce, 1 charge
—
100.00%
150 min
13.68×
1,507
Random bounce, 3 charges
—
100.00%
450 min
41.20×
4,277

**
Finding one: tangent lanes lose 0.34% of the floor to pinholes.
99.66% sounds like rounding. It isn't. When lane centres sit exactly one swath apart, the brushes are tangent, and any raster cell on the boundary line between two lanes has a fighting chance of being missed. In the picture that shows up as a hairline of uncleaned floor every 42 cm — the "striped" look, at one-pixel width. In a real pool, a 1 cm strip is not a defect you can see. In a real pool with 3° of yaw drift and a slightly conical brush, it is.
Finding two: 15% overlap costs 1.5 minutes and buys the last 0.34%.
200.7 m of path instead of 177.3 m, 15 lane changes instead of 13, 13.4 minutes instead of 11.9. Sweep ratio goes from 1.03× to 1.17× — 17% more brush passes over the same floor. That is a cheap insurance policy against yaw drift, brush wear and a slightly out-of-square pool. 30% overlap buys nothing the 15% run didn't already have, and costs 2.4 more minutes plus 17% more brush passes over the floor. If you have to pick one number for a lane pitch, it is around 0.85 × swath, not 1.0.
Finding three: over-spaced lanes are the only strategy that fails visibly, and it fails fast.
0.55 m pitch finishes in 9.5 minutes — the fastest run in the table, 29% quicker than the 15% overlap case. It also misses 19.3% of the reachable floor in 19 cm stripes. This is the exact trade a manufacturer makes when the marketing number is "cleans your pool in 10 minutes", and it is why customers write emails about stripes. Fast, and visibly wrong.
Finding four: random bounce reaches 100%, which is the least useful 100% in the table.
The unplanned run covers every cell inside one 150-minute charge. It also sweeps 13.7 times the floor area to do it — 2,344 m driven, 1,507 wall nudges — which is 11× the runtime of a planned 13.4 minute run. So "coverage" alone cannot rank these strategies. Two numbers, not one: how much of the floor, and how much work per square metre. A lidar robot that plans lanes is not selling coverage. Coverage was never the hard part. It is selling the 1.17×.
Bonus, because it surprised me: turning is 11% of the runtime.
At 6 s per lane change, the 15% overlap run spends 90 of its 804 seconds rotating. On a 6 m width that is fine. Halve the pool width and the lane count barely changes; double it and you are spending a fifth of your battery on pirouettes. Lane pitch affects runtime twice — once through path length, once through lane count.
Where the model lies
I would rather list this than have someone in the comments list it for me.
The drive is lossless. No slip, no wheel scrub on the tiles, no slowdown in the shallow end, no current. Real units lose 5–15% of nominal speed and lose most of it on turns.
The swath is a perfect disk. Real suction mouths lose width at the edges and lose more when the filter is half-full. Effective width drops through a cycle.
No dirt model. "Covered" means "the brush passed over it". Whether one pass removes algae film is a chemistry question I have no data for.
Flat floor only. No slope, no steps, no main drain, no ladder. Wall climbing and waterline scrubbing are outside the raster entirely.
The random run is friendly. 8 seconds between heading changes, no stalling in corners, no getting stuck on the drain cover. Real chaotic navigation is worse than this, so 13.7× is closer to a floor than a ceiling.
One cycle, one direction. No multi-cycle accumulation, no slope-driven drift in the serpentine.
Everything above is a constant at the top of the file. Change BOT["width"] to 0.28 and the whole table shifts; that is the point of writing it down instead of arguing about it.
What I would add next
Two things, in this order.
First, yaw drift. Model the robot leaving each lane 2–3° off axis and let the error compound; that turns the pinhole problem from a raster artefact into a real stripe generator, and it will tell you whether 15% overlap is enough or whether you need 25%.
Second, dirt-weighted coverage. Right now every square centimetre is worth the same. In reality the shallow end and the steps collect most of the debris, and a planner that spends its extra passes there is worth more than one that spends them evenly. That needs a weight map, which needs real pool data, which I do not have yet.
Code, figures and the JSON output are all in one file, roughly 280 lines, numpy and matplotlib only:
python pool_coverage_sim.py # writes results.json + figures/

If you build pool robots, the number I would like from you is not swath width. It is lane pitch, lane-change time, and whether the planner does an edge pass.

Inside a Smart Cleaning Robot: Navigation, Sensors and App Control

Adeline — Fri, 23 Oct 2026 13:41:25 +0000

A robot that climbs a window, maps a pool or scrubs a floor looks like a single black box from the outside. From the inside, it is a small embedded system built from four layers — sensing, navigation, execution and communication — plus the safety and power systems that hold them together. This is a developer's breakdown of how those layers work, and why the engineering choices in each one are what separate a robot that gets used from one that gets shelved.
A note on scope and security. This post covers general engineering principles only. None of the code or diagrams below are real product implementations — there are no real protocols, API endpoints, keys, firmware details, or security configurations here, and it is not a guide to controlling any specific device. It is written for developers who build or evaluate such systems. (The author works with stonebotclean, a cleaning-robot manufacturer; the hardware references are general and illustrative.)

The sensing layer: how the robot knows where it is A cleaning robot cannot do anything useful until it knows its surroundings. The sensing stack is usually a combination of: Edge / drop sensors — short-range infrared or ToF sensors pointing at the surface the robot rides on. For a window robot, this detects the pane edge and stops the unit from driving off the glass. For a floor robot, it prevents a fall down stairs. IMU (gyroscope + accelerometer) — orientation and tilt. Essential for a window robot to know it is still flat against the glass, and for a pool robot to know it has not flipped over. Laser / ToF ranging — measures distance to a wall, an obstacle or a pane frame, for edge detection and mapping. Odometry from wheel encoders — measures how far each drive has travelled, so the robot can estimate position between sensor updates. The budget trade-off is real: cheap robots often ship only edge sensors and a gyro, which forces a random-bounce strategy. Adding a ToF or LiDAR sensor is what unlocks mapping.
Navigation: from random bounce to a cleaning plan Navigation is where the "smart" happens, and the spectrum is wide: Random bounce — bounce off walls until the coverage seems done. Simple, cheap, no map, but it wastes time and misses corners. Systematic sweep (boustrophedon) — travel in parallel lanes, turn at the edge, move to the next lane. Deterministic and effective for simple, flat surfaces. A window pane is a great fit for this: # Generic textbook algorithm (illustrative only — not product code) def boustrophedon(width, lane_step): x = 0 direction = 1 path = [] while x < width: path.append((x, direction)) # one full pass across the pane x += lane_step direction *= -1 # reverse on the next lane return path

SLAM (Simultaneous Localization and Mapping) — build a map while localising within it, usually with LiDAR or vision. This is how a floor robot covers a whole home without repeating rooms, and it is what makes "no-miss coverage" claims possible.
For a pool robot, navigation is closer to the sweep model plus wall-tracking: climb the walls, scrub the waterline, then cover the floor in lanes. The hard part is not path planning but localising in water — odometry and pressure sensing matter more than lidar.

The execution layer: climbing, scrubbing and moving The actuators turn the plan into clean: Negative-pressure suction is what lets a window robot climb vertical glass. The motor draws air between the pad and the pane; the pressure differential holds the unit on. The rating in pascals matters — a higher rating means the robot can hold on through more load and larger panes. Scrubbing — a rotating brush or roller, a spray of water or solution, and a vacuum or pump to lift the dirty water back out. Wet-dry vacuums and upholstery cleaners share this spray-and-suction architecture. Drive motors — two driven wheels (differential drive) for steering, plus a pump or propeller on pool robots. The execution layer is also where dirt actually leaves the surface, which is why suction and brush design do more for real-world results than the navigation spec.
Communication and app control Modern robots talk to a phone through Wi-Fi or BLE, and the app layer is where a lot of the product experience lives — pairing, schedules, cleaning maps, battery, OTA updates. We deliberately do not show any real control frames or wire format here. In broad terms, app control works through the interfaces the manufacturer exposes and supports — typically a cloud channel over Wi-Fi (often MQTT or a REST/WebSocket API) with a local BLE fallback so the robot still works without internet. The exact protocols, endpoints and authentication mechanisms are outside the scope of this post and are not public material. From a developer's standpoint, the interesting engineering is in the state machine rather than the wire format — scheduling, low-power sleep, safe cancellation of a cleaning cycle mid-run, and how the app reflects the robot's real state instead of a guess. Authentication and secure pairing belong to the manufacturer's platform, not to a public engineering overview.
Safety and power Two systems keep a cleaning robot usable rather than alarming: Safety — a physical tether on high-rise window robots, drop/edge sensors, IP ratings for water exposure (essential on pool robots and wet vacuums), and overload detection on the motors. Power — battery management plus an auto-dock. A robot that returns to a charge dock and starts again on its own is far more likely to be used weekly than one that needs manual recharging. For pool robots, cordless autonomy is the trend — a full cycle on one charge is now the baseline buyers expect.
Why it matters when you source or build one These four layers are why two products that look alike can differ completely in real use. When we build cleaning robots for wholesale and OEM customers, the decisions that matter are the same ones above: which sensors to spend on, whether the navigation is mapping or sweep, how the app reflects real robot state, and how safely the unit handles an edge, a puddle or a fall. A robot that nails execution and safety — even with simple navigation — beats one with a fancy map and weak suction every time. Wrap up A smart cleaning robot is an embedded system wearing a cleaning product's body. Understand the sensing, navigation, execution, communication, safety and power layers, and you can tell at a glance whether a spec sheet is marketing or engineering. If you are building or sourcing one, the questions worth asking are the same in every category: how does it detect edges, does it map or sweep, how does the app talk to it, and what happens when it runs into something it was not expecting.