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.
Top comments (0)