How a Robot Vacuum Is Made: Lidar, SLAM, Firmware and Home Maps

A robot vacuum is made by assembling wheel, brush and fan motors, a lithium-ion battery, bump and cliff sensors, and a navigation sensor (usually a spinning lidar or a camera) around two computers: an application processor running Linux and a microcontroller running a real time loop. Software called SLAM turns sensor readings into a floor plan of your home, and most robots sync that map, plus usage data and sometimes camera images, to the maker's cloud through a phone app.

That last sentence is why this post exists. A robot vacuum is the one smart home device that walks every room, measures every wall and, on camera models, looks at the floor where your family lives. Knowing how it is built tells you what it can collect, and knowing what it can collect tells you which settings to change.

This post goes one level deeper than our explainer on Zigbee, Thread and Matter, and it sits next to our builds of camera image sensors and lithium-ion batteries, both of which end up inside a modern robot. For general device hygiene, see IoT device security fundamentals.

A note on sources. Robot vacuum makers do not publish their factory yields, test rigs or burn in times. Where a standard, a regulator or an official project document says something, we cite it. Where nothing public does, we describe the step as typical industry practice without inventing a number, and the arithmetic in the worked examples is labelled illustrative. Every claim about how a named company handles map data comes from that company's own privacy policy, quoted from the version we fetched.

Key takeaways

• A robot vacuum has six main subsystems: chassis and drive, cleaning head (brushes, fan, mop), sensing (lidar or camera, bumper, cliff, wheel drop, odometry, inertial sensor), compute (Linux application processor plus a microcontroller), power (battery and dock), and connectivity (Wi-Fi, sometimes Bluetooth for setup).
• Lidar robots build a 2D map by matching each new laser scan against what they have already seen, then correcting accumulated drift when they recognise a place again. Open source SLAM projects such as slam_toolbox and Cartographer document exactly this: scan matching, a pose graph, loop closure and an occupancy grid.
• The map is not a photo. It is a grid of cells marked free, occupied or unknown. ROS stores it as a row major array of signed bytes; its message definition says 0 frequently means unoccupied and minus 1 unknown.
• The data a robot can collect goes well beyond the floor plan. iRobot's privacy policy, for example, lists floorplans, keep out and clean zones, objects detected by the camera, presence of pets and people, the location of Wi-Fi devices on your network and Wi-Fi heat maps.
• ETSI EN 303 645 (V3.1.3, September 2024) sets the European baseline: unique passwords, a vulnerability disclosure policy, secure updates, a published support period, and a simple way to delete user data from the device and from associated services.
• The US Cyber Trust Mark is a voluntary FCC labelling programme for wireless consumer IoT products, adopted in March 2024 and built largely on NIST criteria. According to the FCC, it is still being stood up.
• Matter added robotic vacuums as a device type in Matter 1.2 (October 2023), not Matter 1.4. Matter lets a robot be controlled from more than one smart home system on your local network.
• Open source local firmware such as Valetudo replaces the vendor cloud entirely. Its own documentation says installation is permanent, the vendor app stops working, and over the air updates from the vendor stop. Treat that as a warranty and bricking decision, not a settings change.
• The practical defence for most homes is simpler: put the robot on an isolated IoT network, review its app permissions, turn off image sharing you do not want, know how to delete your data, and check that firmware updates still arrive.

Raw material to mapped robot: the step table

This table follows a robot from raw materials to a mapped, cloud connected device in your home. The right hand column marks where cryptographic keys, identities and accounts enter the picture, because that is where most of the security story is decided.

Steps 6 and 12 are the two moments that decide most of the device's security. Step 6 is where a manufacturer either gives each unit a unique identity and enables update verification, or ships every unit with the same secrets. Step 12 is where your home network credentials and your account become part of the device.

What is inside a robot vacuum?

Open a mid range robot and you find the same parts in roughly the same places, whichever brand made it.

Chassis, wheels and drive

Two independently driven wheels sit near the centre line, with a caster at the front. Driving the wheels at different speeds turns the robot, which is why this layout is called differential drive. Each wheel module usually combines a small DC motor, a reduction gearbox and a wheel encoder that counts rotations. The encoder counts are the robot's odometry: an estimate of how far it has moved and how much it has turned. Odometry drifts, especially on carpet and when a wheel slips, which is the whole reason a robot needs SLAM.

The wheels are on spring loaded arms. A small switch on each arm, the wheel drop sensor, tells the robot when a wheel is hanging in the air, for example when it is picked up or has driven half off a step.

Cleaning head

The cleaning head is a main brush roll (bristle, rubber, or a mix), one or more side brushes that flick debris from edges into the path of the main brush, and a suction fan that pulls air through the dust bin and a filter. Hybrid models add a water tank and a mop pad, sometimes with a lift mechanism so the pad rises over carpet. Docks on higher end models empty the bin by suction, wash and dry mop pads, and refill water.

Sensors

• Navigation sensor. Either a lidar (a laser distance sensor that spins in a turret on top or is recessed in the front) or one or more cameras, sometimes paired with structured light for depth. Some robots use both: lidar for mapping and a front camera for recognising obstacles such as cables, socks and pet waste.
• Bumper. A floating front shell with microswitches or optical sensors behind it. A press means "I hit something."
• Cliff sensors. Downward facing infrared emitter and receiver pairs around the underside. When the reflected light drops sharply, the floor has gone, and the robot stops before a stair edge.
• Wall or edge sensor. A side facing range sensor that lets the robot follow a wall at a fixed distance.
• Inertial measurement unit. A gyroscope and accelerometer that measure rotation and tilt, used with the wheel encoders to estimate motion.
• Dirt detection. On some models, an acoustic or optical sensor in the airflow path that notices when more debris is passing.
• Microphones. Some newer robots include microphone arrays for voice control. The Valetudo project's documentation raises this explicitly when it argues for keeping robot data off the cloud.

Compute

Most lidar robots carry two processors. An application processor, typically a multi core ARM system on chip with external RAM and flash, runs Linux and the robot's main program: mapping, path planning, the network stack, the cloud client and the update agent. A microcontroller handles the real time work: reading the bumper and cliff sensors, running the motor control loops, managing charging and stopping the robot in milliseconds if a cliff sensor fires.

You can see this split in public documentation for local firmware. The Valetudo firmware update guide talks about getting a shell over SSH or a debug interface, writing to a tmpfs /tmp or a data partition such as /data, and A/B system partitions, all of which are Linux concepts. The microcontroller side does not appear in those instructions because the vendor firmware on it is normally left alone.

Connectivity

A 2.4 GHz Wi-Fi radio is standard. Some robots add 5 GHz Wi-Fi, and many use Bluetooth Low Energy during setup to pass Wi-Fi credentials from the phone. The robot talks out to the vendor cloud; the phone app usually talks to the cloud too, not to the robot directly.

Power and dock

The battery is a lithium-ion pack with a battery management circuit that protects cells from overcharge, overdischarge and short circuits. The dock provides charging contacts and an infrared beacon so the robot can find its way home. On self emptying docks, a second fan and a dust bag sit in the base.

Comparison: lidar, camera and lidar plus camera

How do lidar and visual SLAM build a map?

SLAM stands for simultaneous localisation and mapping. The robot must build a map of an unknown room while working out where it is on that map, using sensors that are noisy and wheels that slip. The way open source projects solve this is well documented, and consumer robots use the same family of techniques.

The ingredients

1. Odometry. Wheel encoder counts plus the gyroscope give a rough guess of motion between scans.
2. Laser scans. Each lidar revolution produces a ring of range readings. A single scan is a slice of the room's outline as seen from where the robot was standing.
3. Scan matching. The new scan is aligned against previous scans or the map built so far, to refine the odometry guess.
4. A pose graph. Each robot position (pose) becomes a node; each measured relationship between poses becomes an edge.
5. Loop closure. When the robot returns to a place it has seen before, matching the current scan against the old part of the map adds a constraint that ties the two together, and an optimiser corrects the whole trajectory.
6. An occupancy grid. Finally, every scan is drawn into a grid of cells, each marked free, occupied or unknown.

How slam_toolbox describes the loop

The slam_toolbox project, which its README calls the currently supported ROS 2 SLAM library, describes its synchronous pipeline in four steps. The node subscribes to laser scan and odometry topics. Each laser callback produces a pose (from odometry) with a scan tied to it, and these posed scans form a queue. The queue builds a pose graph in which "odometry is refined using laser scan matching," and the graph is used to find loop closures; when one is found, the graph is optimised and pose estimates are updated. Last, the scans attached to each pose are used to build and publish the map.

The same README notes that the project is built on a heavily modified open_karto library whose scan matcher is "well known as an extremely good matcher for 2D laser scans," and that it uses a Google Ceres based optimiser plugin. It also supports what it calls lifelong mapping: saving the pose graph and metadata, reloading it later, and continuing to refine the map. That is the open source equivalent of a robot that remembers your floor plan between runs and quietly updates it when you move a sofa.

slam_toolbox also has a localisation mode. Its README describes "elastic pose-graph localization", which takes an existing pose graph and localises within it using a rolling window of recent scans, without updating the stored map long term. A consumer robot does the same thing on every cleaning run after the first: it loads the saved map, matches the first scan against it, and works out where it has been placed.

How Cartographer describes local and global SLAM

Cartographer's documentation splits the problem into two subsystems. Local SLAM, the front end, builds "a succession of submaps", each meant to be locally consistent while accepting that local SLAM drifts over time. Global SLAM, the back end, runs in background threads and finds loop closure constraints by scan matching scans against submaps.

The walkthrough explains how submaps store range data. The most common structure is a probability grid: space is cut into fixed size cells, and each cell holds the odds of being obstructed. Odds are updated by "hits" (where a range reading ends) and "misses" (the free space the laser beam passed through on the way). For loop closure, a fast correlative scan matcher explores candidate poses with a branch and bound search, and a good enough proposal is then refined by a Ceres scan matcher.

That hit and miss rule is worth remembering when you look at your robot's map in the app. The dark outline is where laser beams stopped. The light area is everywhere a beam passed through. The grey around the edges is where no beam has gone yet.

The occupancy grid, concretely

ROS defines a standard message for a 2D grid map, nav_msgs/OccupancyGrid. Its definition says the data is stored in row major order starting at cell (0, 0), that cell (1, 0) comes next in the x direction, and that values are application dependent, but frequently 0 represents unoccupied, 1 represents definitely occupied and minus 1 represents unknown. Other mapping software may use a different value scale, so check the convention of whatever produced the map. Each value is a signed 8 bit integer, and metadata records the resolution (metres per cell) and the grid's width, height and origin.

A consumer robot's map format is proprietary, but it carries the same kind of information, plus layers the vendor adds: room boundaries, room names, no go zones, docking position, cleaning history and, on some models, the positions of detected objects.

Worked example 1: how big is a home map? (illustrative)

Take a single floor apartment that fits in a rectangle 12 metres by 10 metres, mapped at 5 centimetres per cell.

• Cells across: 12 / 0.05 = 240
• Cells down: 10 / 0.05 = 200
• Total cells: 240 × 200 = 48,000
• At one signed byte per cell, as in the ROS message: 48,000 bytes, about 47 KB uncompressed

Most of those cells are either free floor or unknown space outside the walls, so the grid compresses well. The point is that a floor plan of your entire home is a small file. It is trivial to upload, store and keep indefinitely. The size of the data is not what limits collection; policy is.

Worked example 2: how much does odometry drift? (illustrative)

Suppose wheel odometry has a heading error of 1 degree after the robot has turned through a few corners, and the robot then drives 8 metres down a hallway.

• Lateral error ≈ distance × sin(heading error) = 8 m × sin(1°) ≈ 8 × 0.01745 ≈ 0.14 m

Fourteen centimetres is enough to put a wall in the wrong place on the map, or to make the robot think a doorway is closed. Scan matching corrects this continuously by aligning each scan with the map, and loop closure corrects it globally when the robot comes back to the hallway's start. This is why robots without any external sensing (early random bounce models) never built usable maps: odometry alone always drifts.

Visual SLAM

Camera based robots replace laser scans with visual features: corners, edges and textured patches on the ceiling, walls and furniture. The robot tracks how those features move between frames to estimate its own motion, and recognises a previously seen set of features to close loops. The map is still turned into a 2D grid for planning, but the robot also holds visual landmarks, and that is the reason camera robots carry more privacy risk. A lidar scan cannot tell who is in the room. An image can.

How is a robot vacuum manufactured and tested?

Manufacturers keep line details private, so this section describes the typical flow for consumer electromechanical products, and points to the standards each step has to satisfy.

Motors and gear trains

Wheel motors are usually small brushed or brushless DC motors with a plastic or metal gear reduction. Suction fans are increasingly brushless DC motors driven by an electronic controller, because brushless designs spin fast and last longer. Motor assembly involves winding coils, fitting magnets and bearings, balancing the fan impeller, and pressing gears onto shafts. End of line checks on a motor typically measure current at no load and under a set load, speed, and noise.

Circuit boards

The main board and the motor control board go through standard surface mount assembly: solder paste is printed through a stencil, components are placed by machine, the board passes through a reflow oven, and automated optical inspection looks for missing or misaligned parts. Boards are then tested with a fixture that powers them up, checks rails and runs a short self test. This is also the stage where the factory writes the bootloader and later the full firmware image.

Sensor calibration

Every sensor that measures distance or angle has to be checked against a reference. Lidar modules are typically checked against targets at known distances. Cliff sensors are checked against reflective and dark surfaces so the threshold works on both a white tile and a black rug. The inertial sensor's bias is measured at rest. Calibration constants are written to a protected area of flash so a firmware update does not overwrite them.

Run in

A finished robot is typically driven around a test arena, sent back to its dock, charged and run with brushes and fan under load. This catches loose connectors, noisy gearboxes and docking misalignment before the box is sealed.

Laser safety

Lidar modules contain a laser, so they are classified under IEC 60825-1, the international standard for the safety of laser products. The 2014 edition, according to the IEC's own summary, covers laser products emitting in the wavelength range 180 nm to 1 mm and introduced a new class, Class 1C. Consumer robots are designed so the laser is in an eye safe class under normal use; check the label on your robot or its manual for the exact class.

Radio certification

In the US, any device with a radio transmitter needs FCC equipment authorization before it is marketed. The FCC's guidance lists the steps: determine which rules apply, determine whether the device needs Certification or a Supplier's Declaration of Conformity, test with an accredited lab, and keep compliance records. It also notes that later design changes may need a further approval. A Wi-Fi robot uses a certified radio module or is certified as a whole. In the EU, radio equipment must meet the Radio Equipment Directive before it can carry the CE mark.

Battery

Lithium-ion packs must pass transport tests before they can ship, and the product's battery management system must prevent overcharge and overheating. Our lithium-ion battery build covers the cell and pack steps in depth.

Provisioning identity

The security relevant step is when each unit receives its identity. A well designed line gives each robot a unique key or certificate for its cloud connection, generated in a hardware security module or in the device itself, and records the public part against the serial number. A poorly designed one ships the same key in every image. ETSI EN 303 645 provision 5.1-1 requires that passwords used to authenticate against the device, in any state other than the factory default, are unique per device or set by the user, and section 5.4 asks manufacturers to store security parameters securely. You cannot audit this from the outside, but you can ask a vendor, and labelling schemes are designed to make them answer.

What firmware and cloud services run a robot vacuum?

Bootloader and Linux on the application processor

When the robot powers on, a boot ROM in the system on chip loads a bootloader from flash, which loads the Linux kernel and a root filesystem. On a robot, the root filesystem holds the vendor's robot application (mapping, planning, scheduling), a cloud client, an update agent, and common open source components: a C library, a TLS library, a Wi-Fi supplicant, a DHCP client, compression libraries, and often a lightweight web server or message broker used internally.

Many robots use A/B partitions: two copies of the system, one active and one standby. An update is written to the standby slot and the robot switches slots on the next boot, so a failed update can fall back. The Valetudo update guide mentions that most supported robots have "multiple system partitions in an A/B configuration."

Real time firmware on the microcontroller

The microcontroller runs either bare metal code or a small real time operating system. It reads sensors at a fixed rate, runs the motor control loops, and acts on safety inputs locally: if a cliff sensor or wheel drop switch fires, it stops the wheels without waiting for Linux. The application processor sends it high level commands (drive at this velocity, run the main brush at this speed) over a serial link and receives sensor data back.

Over the air updates

The update agent checks the vendor cloud for new firmware, downloads it, verifies it and installs it. ETSI EN 303 645 sets the expectations clearly. Provision 5.3-2 says the device shall have a secure update mechanism unless a resource constraint prevents it. Provision 5.3-10 says that where updates are delivered over a network interface, the device shall verify the authenticity and integrity of each update via a trust relationship. Provision 5.3-13 says the manufacturer shall publish the defined support period in an accessible, clear and transparent way.

Cloud accounts and the app

The robot holds a long lived connection to the vendor cloud. Your phone app talks to the same cloud, which relays commands ("clean the kitchen") and returns status, maps and history. This is what makes remote control work when you are away, and it is also why the map, cleaning logs and any images flow through the vendor's servers. Voice assistant and smart home integrations add another account link, and another party, to that flow.

Comparison: where each piece of software runs

What data does a robot vacuum collect, and where can it go?

Categories of data

Across the industry, robots can produce the following:

• Maps and floor plans. Room outlines, room names, doors, no go and clean zones, dock position.
• Object and camera data. On camera models, labels of detected objects and sometimes the images used to detect them.
• Network data. Your Wi-Fi network name, signal strength across the home, and on some models the positions of other Wi-Fi devices.
• Usage data. Cleaning schedules, mission history, battery health, error codes, app usage.
• Account data. Your email, name, location, and links to voice assistants or smart home platforms.

What one manufacturer's policy says

To make this concrete, here is what iRobot's privacy policy says, from the version we fetched (marked "Last Updated: November 6, 2024"). It is used here as a documented example, not as a comparison with any other maker.

The policy lists a category called device environment information, described as "information about the spaces where you use your device, such as floorplans, keep out zones and clean zones," together with types of objects detected using the robot's camera, the presence of pets and people with a confidence factor and location, the location and confidence factor of Wi-Fi devices connected to your local network, and Wi-Fi heat maps. The stated purposes include diagnosing problems, providing device features and developing new products and features.

On choices, the same policy says that through the app settings "you may choose to not transmit map data to us", and that you can use its devices without Wi-Fi or Bluetooth data transmission by never connecting them or disconnecting them. For camera images, it describes a category of images from certain connected robots produced before 2025 with camera based navigation: if you opt in to image collection, the robot collects images, and the policy says they will not be viewable by the company unless you opt in both to image collection and to sharing each image. It also says you can opt in or out of that collection in the app at any time.

On deletion, the policy says you can request deletion in the app or on the website and gives the in app path: Account, your name or email, the three dot menu, then "Request to delete account." Policies change, so read the current version for your own robot before relying on any of this.

The general lesson applies to every brand. Before you buy, read the maker's privacy policy for the words map, floor plan, image, camera, Wi-Fi and third party. Note what is collected by default, what is opt in, what can be turned off in the app, and how deletion works.

Where the data can go

What do ETSI EN 303 645 and the US Cyber Trust Mark expect?

ETSI EN 303 645

ETSI EN 303 645 is the European standard for cybersecurity of consumer internet of things devices. The current version in the ETSI archive is V3.1.3, dated September 2024. It has thirteen groups of security provisions and a data protection section. The ones that matter most for a robot that maps your home are:

The standard's note on 5.11-1 is useful: user data includes personal data, user configuration and cryptographic material such as passwords or keys. For a robot, that clearly covers the map, room names and stored Wi-Fi credentials.

The US Cyber Trust Mark

The FCC adopted rules for a voluntary cybersecurity labelling programme for wireless consumer IoT products on 14 March 2024 (released 15 March 2024). According to the FCC's programme page, qualifying products will carry the US Cyber Trust Mark logo with a QR code that links to a registry with details such as the product's support period and whether security updates are automatic. Products are tested by accredited labs, and third party label administrators review applications. The FCC says the programme is based largely on criteria established by NIST and applies to wireless consumer IoT products; its examples include smart appliances and home security cameras. The page also says the FCC is "in the process of standing up" the programme, so check the FCC page for its current status before looking for the label on a box.

The NIST document behind the criteria is NIST IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products, published in September 2022. NIST describes it as a set of cybersecurity outcomes intended to apply to the entire IoT product, which for a robot means the device, the app and the cloud service together, not just the hardware.

EU Cyber Resilience Act

In the EU, the Cyber Resilience Act will add mandatory cybersecurity requirements for products with digital elements, including connected appliances. According to the European Commission, it entered into force on 10 December 2024, its reporting obligations apply from 11 September 2026, and its main obligations apply from 11 December 2027.

Comparison: the three regimes

How does Matter support robotic vacuum cleaners?

Matter is the smart home standard maintained by the Connectivity Standards Alliance. Robotic vacuums were added in Matter 1.2, announced by the Alliance on 23 October 2023 as one of nine new device types. The Alliance described the support as going beyond remote start and progress notifications to include cleaning modes (dry vacuum versus wet mopping) and additional status details such as brush status, error reporting and charging status. The Matter 1.4 announcement (7 November 2024) focused on multi admin improvements, home routers and access points, and energy management device types; it does not list robotic vacuums as new.

What local control changes

Matter devices are controlled over the home's IP network, and Matter's multi admin model lets one device join more than one smart home system. For a robot vacuum, that means:

• Start, stop, mode changes and status can flow on your local network between the robot and your smart home controller, rather than through a voice assistant's cloud to the vendor's cloud and back.
• You can use the robot with a smart home platform without linking your vendor account to that platform's account, depending on how the maker implements it.
• It does not by itself stop the robot talking to its maker's cloud. The vendor app, the map viewer and firmware updates usually still use the vendor cloud. Matter changes how you control the robot, not necessarily where its map is stored.

Read the Matter announcement as a list of what the standard can carry, and check your robot's documentation for which Matter features it actually implements.

What do open source local control firmware projects do?

The best known open source project in this space is Valetudo. Its documentation describes it as "an opinionated software solution for cloud-free vacuum robots", started in 2018 and licensed under Apache 2.0. Its stated goals include no cloud connectivity, no account requirement, no phone app requirement and integration with open source smart home systems over MQTT and Home Assistant. Its argument for local control is about data: the project points out that with camera based obstacle avoidance, what used to be a floor plan could now be an image from inside the home, and that many new robots also have microphone arrays.

Its documentation is equally direct about the costs, and you should read them before you consider it:

• It replaces the cloud. The project says it stops all connectivity to the vendor cloud, so the vendor app stops working, and you cannot use both.
• It is permanent. The project's own words: "Rooting and installing Valetudo is a permanent change. There is no way back." It adds that if you are unsure whether to install it, the answer is no.
• Vendor updates stop. The firmware update page says a rooted robot no longer receives OTA firmware updates through the vendor's cloud, so you do not get bug fixes while you sleep. Updates become a manual process that you are responsible for.
• Only supported robots are supported, and feature parity with the vendor app is a non goal.

Beyond the project's own statements, the general risks of replacing device firmware apply: it can void the warranty, a failed flash can brick the device, and you take on the job of tracking security fixes for the software on it. We do not cover installation steps here. If local only control matters to you, the honest decision tree is to choose a robot whose maker supports local control and publishes a support period, or to accept the trade offs that a project like Valetudo spells out.

Comparison: three ways to run a robot

Step by step: isolate the robot, review permissions and check updates

These steps are defensive and apply to any robot. Commands use OpenWrt as the example router firmware; other routers have equivalent settings under names like "IoT network", "guest network" or "VLAN". Check your own router's documentation before changing network settings, because a mistake can disconnect devices.

1. Plan an isolated IoT network

Decide on a separate subnet for smart home devices, for example 192.168.30.0/24, with its own Wi-Fi network name. Devices on it can reach the internet but cannot open connections to your laptops and phones on the main network.

2. Create the network and Wi-Fi on OpenWrt (example)

Back up your router configuration first. On OpenWrt, sysupgrade -b /tmp/backup.tar.gz writes a backup archive you can download.

# Example only: adapt names, radio and addresses to your router
uci set network.iot=interface
uci set network.iot.proto='static'
uci set network.iot.ipaddr='192.168.30.1'
uci set network.iot.netmask='255.255.255.0'

uci set wireless.iot=wifi-iface
uci set wireless.iot.device='radio0'        # the 2.4 GHz radio on many routers
uci set wireless.iot.mode='ap'
uci set wireless.iot.network='iot'
uci set wireless.iot.ssid='home-iot'
uci set wireless.iot.encryption='psk2'
uci set wireless.iot.key='use-a-long-unique-passphrase'

uci set dhcp.iot=dhcp
uci set dhcp.iot.interface='iot'
uci set dhcp.iot.start='100'
uci set dhcp.iot.limit='50'
uci set dhcp.iot.leasetime='12h'

3. Add a firewall zone that blocks the IoT network from the rest of the home

uci add firewall zone
uci set firewall.@zone[-1].name='iot'
uci set firewall.@zone[-1].network='iot'
uci set firewall.@zone[-1].input='REJECT'
uci set firewall.@zone[-1].output='ACCEPT'
uci set firewall.@zone[-1].forward='REJECT'

uci add firewall forwarding
uci set firewall.@forwarding[-1].src='iot'
uci set firewall.@forwarding[-1].dest='wan'

# Let IoT devices get addresses and resolve names from the router
uci add firewall rule
uci set firewall.@rule[-1].name='IoT-DHCP'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].proto='udp'
uci set firewall.@rule[-1].dest_port='67-68'
uci set firewall.@rule[-1].target='ACCEPT'

uci add firewall rule
uci set firewall.@rule[-1].name='IoT-DNS'
uci set firewall.@rule[-1].src='iot'
uci set firewall.@rule[-1].proto='tcp udp'
uci set firewall.@rule[-1].dest_port='53'
uci set firewall.@rule[-1].target='ACCEPT'

uci commit
service network reload
wifi reload
service firewall restart

There is deliberately no forwarding from iot to lan. If you want your phone on the main network to control the robot locally (for Matter or a local integration), add a narrow rule from lan to the robot's address only, rather than opening the whole zone.

4. Move the robot to the new network

Most robots only accept new Wi-Fi details through the app's setup flow. In the app, use the option to change Wi-Fi or re-add the device, and give it the home-iot network. Some robots only support 2.4 GHz, which is why the example uses that radio.

5. Confirm what the robot exposes on your network

From a computer on the IoT network (or temporarily allowed to reach it), find the robot's address in the router's DHCP lease list, then check which ports it listens on. Only do this on devices you own.

# On OpenWrt: list current DHCP leases to find the robot
cat /tmp/dhcp.leases

# From a computer you own: list open TCP ports on your own robot
nmap -sT -p- 192.168.30.120

Write down what you see. A robot that listens on no ports, or only on ports its documentation explains, is what you want. Anything unexplained is a question for the vendor's support or vulnerability disclosure contact.

6. See where the robot connects

Turning on DNS query logging for a day shows which hostnames the robot looks up. On OpenWrt, dnsmasq can log queries:

uci set dhcp.@dnsmasq[0].logqueries='1'
uci commit dhcp
service dnsmasq restart
logread -e dnsmasq | grep 192.168.30.120

Turn logging off again afterwards (uci set dhcp.@dnsmasq[0].logqueries='0', then commit and restart), because query logs are themselves sensitive.

7. Review the app's permissions on your phone

On Android, open Settings, Apps, the robot's app, Permissions. On iOS, open Settings, Privacy and Security, and check Location, Bluetooth, Local Network, Microphone and Camera for the app. Setup often asks for Location and Bluetooth; after setup you can usually reduce Location to "only while using" or turn it off and see whether the app still works.

8. Review data settings in the app

Look for, and decide on, each of these:

• Map saving and map upload (some apps let you keep maps off the cloud, as iRobot's policy describes)
• Image collection, image sharing and "help improve" programmes
• Voice assistant and smart home links you no longer use
• Marketing and analytics sharing
• Beta or experimental programmes

9. Know how to delete your data

Find two paths before you need them: deleting a map in the app, and deleting your account and associated data. ETSI EN 303 645 provision 5.11-2 says consumers should be able to delete personal data from associated services in a simple manner, so a well designed app has this in its settings. For the device itself, find the factory reset procedure in the manual.

Warning: a factory reset erases maps, schedules and Wi-Fi credentials on the robot and cannot be undone. Before running it, check that you are holding the right robot (compare the serial number on the label with the one in the app) and that you have removed it from your account first if you are selling or giving it away. Do both steps, in that order: remove from account, then factory reset.

10. Check firmware update status and the support period

In the app, find the firmware version and whether automatic updates are on. Note the version, then check again in a month to confirm updates actually arrive. Look on the maker's website for a published support period, which ETSI EN 303 645 provision 5.3-13 requires; if the robot carries the Cyber Trust Mark, the label's registry is meant to show it too. A robot that has stopped receiving updates should stay on the isolated network.

Common mistakes

• Putting the robot on the main home network. It then sits next to laptops, phones and network storage. A separate IoT network costs nothing and limits what a compromised or misbehaving device can reach.
• Assuming the map is "just a map." On camera models, the data can include images and detected objects, and some policies describe pets, people and Wi-Fi device locations. Read the policy for your model.
• Opting in to every "help improve" prompt during setup. Setup screens are designed to be tapped through. Go back to the settings afterwards and decide deliberately.
• Selling or gifting a robot without removing it from your account. The next owner's robot may still be linked to you, and your map may still be on the device. Remove it from the account, then factory reset.
• Treating Matter as a privacy switch. Matter changes how you control the robot. It does not on its own stop vendor cloud sync.
• Installing replacement firmware casually. The leading project's own documentation says it is permanent and stops vendor updates. Decide based on that, not on a forum thread.
• Never checking whether updates arrive. Automatic updates can fail silently, and support periods end. Check the version every few months.
• Leaving old smart home integrations linked. Every linked account is another place your robot's status, and sometimes its map, can go.
• Opening the IoT zone wide to make local control work. Allow the one address and port your controller needs, not the whole network.
• Leaving DNS query logging on. It is useful for a day of inspection and a privacy liability after that.

FAQ

How is a robot vacuum made?

Plastic housings are injection moulded, motors and gear trains are assembled, circuit boards are built by surface mount assembly, and a lithium-ion pack is welded and fitted with a protection circuit. Firmware and a unique device identity are written to flash, sensors are fitted and calibrated, and the finished robot is run in on a test course before packing. The radio design must be approved (FCC equipment authorization in the US), and the lidar laser is classified for eye safety under IEC 60825-1.

What parts are inside a robot vacuum?

Two drive wheels with motors and encoders, a caster, a main brush, side brushes, a suction fan, a dust bin and filter, often a mop module, a bumper, cliff sensors, wheel drop switches, an inertial sensor, a lidar or camera, an application processor running Linux, a microcontroller for real time control, a Wi-Fi radio and a lithium-ion battery, plus a dock with charging contacts and an infrared beacon.

How does a robot vacuum map a room?

It uses SLAM. Wheel odometry gives a rough motion estimate, each new lidar scan or camera frame is matched against the map built so far to refine it, and loop closure corrects drift when the robot recognises a place it has seen before. The result is an occupancy grid where each cell is free, occupied or unknown.

What is the difference between lidar and camera robot vacuums?

Lidar robots measure distances with a spinning laser, work in the dark and build accurate maps, but see only one height slice. Camera robots track visual features and can recognise objects, but need light and capture images of your home. Many robots now combine lidar for mapping with a front camera for obstacle avoidance.

Do robot vacuums send maps to the cloud?

Most cloud connected robots sync the map so the app can show it, and some policies describe more than the map. iRobot's privacy policy, for example, lists floorplans, keep out zones, detected objects, presence of pets and people, Wi-Fi device locations and Wi-Fi heat maps, and says you can choose in the app not to transmit map data. Check your own robot's privacy policy and app settings.

Can a robot vacuum take pictures of my home?

Camera equipped robots use images for navigation and obstacle detection. Whether any images leave the device depends on the model and the maker's policy. iRobot's policy, for instance, describes image collection from certain camera robots as opt in, with a further opt in to share each image. Read your maker's policy and check the image settings in the app.

Does Matter support robot vacuums?

Yes. Robotic vacuums were added as a device type in Matter 1.2, announced in October 2023, with support for remote start, progress notifications, cleaning modes and status details such as brush status, errors and charging. Check which Matter features your specific robot implements.

How do I delete my robot vacuum's map and data?

Delete maps in the app, then use the app's account deletion option to remove data held in the cloud. Before selling or giving the robot away, remove it from your account and run a factory reset. ETSI EN 303 645 expects devices to let users erase all user data simply and to delete personal data from associated services.

Is it safe to put a robot vacuum on a guest or IoT network?

Yes, and it is a good idea. The robot only needs outbound internet access to its cloud and DNS and DHCP from the router. Blocking it from your main network limits what it can reach. If you use local control from your phone or a smart home hub, allow only that specific connection.

What is Valetudo and should I use it?

Valetudo is an open source, cloud free replacement for the software on certain supported robot vacuums, licensed under Apache 2.0. Its own documentation says installation is permanent, the vendor app stops working, vendor OTA updates stop, and if you are unsure you should not install it. It suits people who want local only control and accept those trade offs, including the warranty and bricking risk.

Where Safeguard fits, honestly

Safeguard does not analyse robot hardware, scan firmware images, manage devices or produce hardware bills of materials, and it has nothing to say about lidar calibration or motor control. The honest overlap is the software around the robot. Companion apps, smart home integrations, MQTT bridges, map viewers and the backend services that store maps are code that teams write and ship with open source dependencies. If that code lives in a repository or a container image, Safeguard can scan it (for example safeguard scan --dir . on a checkout, or safeguard scan --image followed by an image name), match components against vulnerability databases, rank findings with reachability analysis, and open fix pull requests when you switch autonomous remediation on. It does not replace the network, privacy and update steps above for the robot itself.

A robot's Linux image carries a TLS library, a Wi-Fi supplicant and dozens of other open source components, and the cloud that stores your floor plan is built from open source packages too. The same supply chain hygiene that protects any web service applies to the services that hold home maps, which is where the section below comes in.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow fits a smart home dashboard, a map viewer or a companion web app your team maintains in a JavaScript repository.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits a team that builds a home automation bridge or an MQTT integration and prefers to scan its repositories locally.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It fits an engineer who is away from the desk when a dependency fix for a device backend is ready to run.

Click through it at your own pace, or open it full screen.

To try the CLI yourself, download it from safeguard.sh/download and follow the CLI documentation.

Quick check

Sources

• ETSI EN 303 645 V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements
• ETSI deliverable archive for EN 303 645
• FCC, U.S. Cyber Trust Mark
• FCC, Report and Order FCC 24-26, Cybersecurity Labeling for Internet of Things
• FCC, Equipment Authorization
• NIST IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products
• European Commission, Cyber Resilience Act
• Connectivity Standards Alliance, Matter 1.2 Arrives with Nine New Device Types and Improvements Across the Board
• Connectivity Standards Alliance, Matter 1.4 Enables More Capable Smart Homes
• slam_toolbox README
• Cartographer documentation
• Cartographer ROS, Algorithm walkthrough for tuning
• ROS 2 common_interfaces, nav_msgs/OccupancyGrid.msg
• IEC 60825-1:2014, Safety of laser products, Part 1
• Valetudo documentation, home
• Valetudo, Why Valetudo?
• Valetudo, Why not Valetudo?
• Valetudo, Firmware Updates
• iRobot, Cookie and Privacy Notice

Last reviewed: 24 October 2026.