How Do Many Mop Robots Split Zones and Share a Dock?

• Meeting-room zone
• Desk-area zone
• Corridor zone
• Shared dock
• Mop robots, one per zone

What you will learn

• Describe how a floor is split into zones and each zone is given to one robot, by central assignment or by auction.
• Explain how several robots share one dock without crowding, and who grants access.
• Follow a zone being handed over after a robot fails, then read the fleet's metrics.

Before you start

This article follows the ones on central control, on covering a whole room and on a single dock visit. You only need to remember that the central controller gathers the state of every robot and each robot keeps its own safety reflexes.

How is the floor split into zones and given to robots?

The controller makes a zone partition: it splits the floor into separate zones, then assigns each zone to one robot. Three splits are common in an illustrative design: by room, by an even grid of cells, or by a graph in which each node is a room or corridor and each edge is a door.

One mathematical split is the Voronoi partition. A study of multi-robot area coverage describes dividing the environment into regions using Lloyd’s algorithm to adjust a Voronoi partition. These are different objects: the partition is the geometric result, while Lloyd is an iterative way to adjust it.

The biggest benefit of separate zones is that robots do not overlap. A survey on task allocation in robotic networks states that when each region is assigned to one robot, there is no overlap between the robots. In this model two robots rarely enter the same floor cell. The shared places are doors, corridors and the dock.

Giving a zone to a robot is a task allocation problem. According to a study of multi-robot task allocation, the problem is usually solved by market-based or optimization-based approaches. The same study describes the market-based approach as a decentralized optimization that uses an auction with bids to reach an assignment. In a typical auction, an auctioneer announces the task to all robots, and the robots compute bids and send them back. The Contract Net Protocol is the classic example: task issuers announce, executors bid.

• Controller doing central assignment
• Three zones, one robot each
• Arrows that assign a zone
• Auctioneer
• Task announcement
• Robots that bid
• Bids sent back

The two assignment styles move the decision to different places, so the table compares them for a mop fleet. The linked cells rest on the sources above; the rest is design reasoning.

With a controller already running on a PC, central assignment is a reasonable starting point. Auctions are worth trying when robots have the compute and the fleet grows large.

How do many robots share one dock?

Only one robot enters the dock at a time, and the controller grants access from a queue. A shared dock saves cost, but it becomes a bottleneck if many robots want to charge at once.

Recharge scheduling addresses exactly this. A study on robot selection and recharge scheduling aims to manage the recharging of robots to avoid conflicts or crowding. Another scheduling protocol has robots return to charge one at a time at the single charging station. If several robots are predicted to arrive at once, it reschedules one to arrive earlier, and it keeps a minimum time gap between charging sessions.

In the illustrative design the flow runs like this:

1. A robot reports low battery or an empty water tank and asks for the dock.
2. The controller puts it in a queue, giving priority to the robot with the least battery reserve.
3. Each waiting robot uses its own holding position outside the approach lane. Only the permitted robot advances to the staging point; release dock access only after confirmed departure, not just a full battery.
4. The dock reports "free", and the controller lets the first robot in the queue enter.
5. After charging, the robot leaves; the dock confirms the approach is clear before the controller grants the next robot access.

To keep the queue short, stagger the start times, because robots that start together drain their batteries at about the same time.

• Robots, one per row
• Waiting at the approach point
• Charging at the dock
• Dock: one robot at a time
• Time axis

Where does a zone go when a robot fails or runs low?

The controller gives the remaining work of that zone to another robot, or holds it until the original robot returns. It notices the problem through heartbeats and stuck reports, as the articles on link loss describe.

The hand-over follows these steps:

1. Hold the zone as unknown when the robot loses contact, preserve progress and revoke the old task permission. Reassign only after confirming that the old robot is stopped, outside the zone, or isolated from it.
2. Pick a robot whose own zone is finished or nearly finished and that has enough battery to do more and still reach the dock.
3. Assign the uncleaned cells to that robot. It cleans only the cells that remain.
4. When the original robot recovers, the controller lets it take the zone back, or gives it a new one.

Equal areas do not guarantee a balanced load. An area coverage study proposes an energy-aware controller that adapts robot weights to their energy dynamics and divides the area accordingly. The idea carries over to a mop fleet: a robot that drains faster should receive a smaller zone.

• Failed robot
• Cleaned and uncleaned cells before hand-over
• Uncleaned cells after assignment
• Robot taking over
• Hand-over path

Which metrics read the fleet, and where does this model stop being valid?

Three metrics are enough to read the fleet's health: fleet finish time, dock waiting time and robot idle time. Fleet finish time is when the last robot finishes, so the slowest zone decides the result. Dock waiting time shows whether the dock is a bottleneck. Idle time shows whether a zone is too small.

• Working time with equal areas
• Slowest robot decides the finish
• Idle time
• Fleet finish time
• Working time with energy-aware sizes
• Earlier fleet finish
• Robots

The model has clear limits. The table shows how the illustrative design handles them.

In the centralized model, the central unit should be able to communicate with all robots. Every zone and dock decision therefore depends on the link, and the reflexes on the robot are the safety net when the link is lost.

Real-world example

A small office has three zones: a meeting room, a desk area and a corridor, one robot each. This is a design scenario, not a test result.

In the morning the controller assigns the three zones and starts the robots at staggered times. The corridor robot reaches its battery reserve first, asks for the dock and enters at once because the dock is free. The meeting-room robot finishes early, charges once and comes back.

The desk-area robot reports a jam under a low desk, then goes silent. After the wait limit the controller keeps the state unknown and locks the zone. Reassignment is allowed only after a person confirms that the robot has stopped and removes it from the zone. Its zone still has many uncleaned cells. The controller picks the meeting-room robot, whose zone is done and whose battery has reserve, and assigns it the uncleaned cells of the desk area. On reconnection, the old robot reconciles its control session and task identifier; the stale zone assignment cannot restart it automatically.

Later the whole fleet uses the dock again, but the queue is short because the three robots are out of step.

Common misunderstandings

Equal areas finish at the same time. A zone with more furniture takes longer than an empty one, and robots drain batteries at different rates. This is why an area coverage study proposes adjusting zones to the robots' energy dynamics.

Adding robots always finishes sooner. Every added robot also adds a dock wait. When the queue grows, the waiting eats the cleaning time that was saved.

Each robot can decide for itself when to dock. With no coordination, two robots can arrive at the dock together. In this design the controller grants dock access, and the cost is that a robot without a link cannot ask for it.

Frequently asked questions

Does each robot clean one zone, or do several robots clean one room together?

The illustrative design gives each zone to one robot so that robots do not overlap. A very large room can be split into several smaller zones, one robot each.

How many robots can one dock serve?

It depends on the charging time and on the gap between two dock visits of each robot. Measure the dock waiting time on the real system and add a dock when the queue grows.

If a robot fails, is its zone abandoned?

No. The controller keeps the map of cleaned cells and gives the remainder to another robot, or holds it until the original robot returns.

Summary

• Split the floor into separate zones, one robot each, so robots do not overlap; assign zones by controller or by auction.
• A shared dock needs a queue granted by the controller, and staggered starts keep the queue short.
• When a robot fails, its zone is handed over with the map of cleaned cells; fleet finish time, dock waiting time and idle time show whether the model still fits.