Central or Onboard Control for a Mopping-Robot Fleet?

• Control computer
• Mopping robots
• Where decisions are made (diamonds)
• Wireless link

What you will learn

• Compare three control styles on eight criteria: processing power, latency, link dependence, robot count, fault tolerance, bandwidth, map and development effort.
• Explain what happens to each style when the Wi-Fi link drops.
• Split the work between robot and computer for a small mopping-robot fleet, then name the conditions that would change the choice.

Before you start

You only need to know what a robot is, for example from the article What Is a Robot?; other terms are explained the first time they appear.

How do the three control styles differ?

The three styles differ in where decisions are made: one shared unit, each robot, or both. According to a survey of path planning for multiple robots, centralized control gives one central processing unit full responsibility for controlling and managing the system. That unit could be a standalone computer or a robot. The same survey says it processes all data and makes the decisions for the whole multi-robot system.

In the decentralized control style compared here, the survey describes each robot as having its own controller and operating independently on its processed data. Here, onboard autonomy means making decisions locally; a robot in a hybrid system can still have local autonomy while a central unit assigns its tasks. Hybrid control applies these approaches at the same time to use the advantages of each.

In the illustrative design, a mopping robot makes two kinds of decision at very different tempos. Stopping before a step edge needs an instant response, so that loop of sensor, chip and motor stays inside the robot body. Dividing zones or planning a path that covers the floor needs a view of the whole home, so it travels over Wi-Fi to a computer and back. This split resembles the hybrid example in the survey: a central unit generates a high-level plan for the movement of many objects, while each object uses its own sensors and communication to adapt its trajectory to local conditions.

• Mopping robot
• Short reflex loop around the chip inside the robot
• Control computer
• Long planning loop over Wi-Fi
• Floor and step edge
• Wi-Fi link

How do they compare on eight criteria?

No style wins on every criterion. A study comparing control of multi-robot sweep coverage says the goals and constraints of the task should guide the choice between centralized, decentralized or a combination of the two. It reports that fully centralized systems are often high performing and efficient but can suffer from a single point of failure or poor scalability. Fully decentralized systems often scale well and have some inherent fault tolerance through redundancy, but can have lower speed, accuracy or efficiency.

The table below gathers the eight criteria. The Central and Onboard columns summarize the path-planning survey and the sweep-coverage study above; the bandwidth row comes from a study of computation offloading. The Hybrid column and the cell marked "inference" are reasoning of the illustrative design, not conclusions of the sources.

Bandwidth and processing power deserve a closer look because they push up the price of each robot. The offloading study's authors state that resource-constrained robots, like low-power drones, often have insufficient on-board compute resources or power reserves. They describe cloud robotics as letting mobile robots offload computation to centralized servers. The price is the network: sending high data-rate video or LIDAR from multiple robots over congested networks can cause prohibitive delay for real-time applications. A mopping fleet built on inexpensive microcontrollers falls into the resource-constrained group in this design, so heavy recognition stays on the computer.

• Mopping robot with a camera
• Control computer
• Video stream: many frames pile up before the bottleneck
• Wi-Fi bottleneck
• Position and status messages: small and regular
• Heartbeat

What happens to each style when the Wi-Fi link drops?

In the illustrative design, the central style loses its source of decisions, the onboard style keeps deciding but loses reporting, and the hybrid style keeps its safety layer on the robot. For centralized systems, the path-planning survey says that if the central controller becomes overloaded or fails, the entire system could collapse. The sweep-coverage study says the advantages of centralized approaches could be hard to maintain in practice under communication disturbances or failure of a supervisor robot. The same study found the decentralized approaches did not outperform the others as much as expected on fault tolerance and scalability. Better fault tolerance in theory is therefore not enough reason to pick onboard control.

For replaceable sensor samples, a sensible choice for a flaky Wi-Fi link is to accept losing some samples rather than wait for retransmission. The ROS 2 documentation says a best effort policy is more suitable in lossy wireless networks. Best effort means attempting to deliver samples but possibly losing them if the network is not robust. For sensor data, the same page says it is usually more important to receive readings in a timely fashion than to ensure all of them arrive.

This choice does not apply to all commands. In the illustrative model, task commands need acknowledgments, an expiry condition and identifiers to reject duplicates; receiving a message does not mean the robot has completed its task.

So that the controller can tell a robot has gone silent, the illustrative design has each robot send a short message at regular intervals. This message, called a heartbeat, says the robot is still connected. ROS 2 has a close idea: the lease duration is the maximum period of time a publisher has to indicate that it is alive before the system considers it to have lost liveliness.

The diagram follows one incident, a broken link, through three illustrative designs. The centralized robot receives no commands and stops to wait. The onboard robot keeps mopping, but the controller gets no reports. The hybrid robot shuts off its pump and stops mopping. It returns only if it can still localize itself, has a local return route and enough battery; otherwise it stops and records a fault. These are example policies, not automatic properties of every architecture.

• Broken link
• Robot stops and waits for commands (central)
• Robot keeps mopping, controller loses reports (onboard)
• Hybrid robot cuts pump; returns when conditions allow
• Control computer
• Mopping robot
• Power and water dock

Which style suits a small mopping-robot fleet?

A hybrid suits it: the robot keeps decisions that need a fast response or must survive a lost network, and the computer keeps the jobs that need a view of the whole home. This is inference from the criteria above, not a tested result. Three reasons:

• Pure central control needs continuous communication between robots and the central unit, so every Wi-Fi stutter leaves a mopping robot without a source of decisions.
• Pure onboard control requires each robot to have enough computation and communication to work alone, and that cost multiplies with the robot count.
• A central unit helps ensure consistent and comprehensive information sharing among all entities, which suits keeping one shared map on the computer.

On the robot, the reflex layer runs on an ESP32-class microcontroller. Espressif says ESP32 can work as a complete standalone system or as a slave device to a host microcontroller. The reflex layer covers stopping at a step edge, a bump or a jam, shutting off the pump when stationary, and detecting a lost heartbeat. Returning belongs to local navigation: the robot needs a stored dock location, a return route and localization that survive the lost controller. That capability needs measurement and testing; an ESP32 alone does not establish it. The computer handles zone assignment, coverage planning, recognizing objects in images and alerting the person. The middle band, following a path and avoiding local obstacles, sits on the robot because it needs a fast response.

• Jobs on the robot: obstacle avoidance, return to dock, pump cut-off, edge stop
• Jobs on the computer: alerts, clutter recognition, zone planning
• Wi-Fi boundary between the groups
• Downward arrow: jobs that need a faster response
• Mopping robot
• Control computer

A hybrid is not free. The path-planning survey says it requires efficient communication protocols and coordination mechanisms. A decentralized approach likewise requires sophisticated algorithms and robust protocols to coordinate effectively.

The choice changes when conditions change. The conditions below are inference for an illustrative model:

• Wi-Fi is weak in many corners of the home: move more decisions onto the robot.
• The robot count grows a lot: the survey describes a centralized system in which more robots may cause delays, so split the controller by zone or let robots plan locally.
• A microcontroller can run a small model: the LiteRT for Microcontrollers documentation says it is designed to run machine learning models on microcontrollers and devices with only a few kilobytes of memory. Simple recognition could then move onto the robot.
• Coverage efficiency matters most: the sweep-coverage study reports fully centralized systems are often high performing and efficient, so keep planning on the computer.

Real-world example

A small office has three zones with one mopping robot each, all assigned work from one laptop. This is a design scenario, not a test result. At lunchtime the laptop goes to sleep and the controller stops receiving heartbeats from all three robots.

In the desk zone, the robot gets no reply from the controller within a preset wait. It shuts off its pump, stops mopping and returns using local navigation if it still knows its position and return route. Otherwise it stays still and records a fault. The other two robots do the same. When the laptop wakes, the controller requests each robot’s position and state before reassigning work; it does not assume every robot reached the dock. To find out why the desk-zone robot stopped earlier than planned, an engineer opens the log recorded on the controller. The ROS 2 tutorial says recorded data can be replayed to reproduce the results of tests and experiments.

Common misunderstandings

Onboard control means the robot needs no network. The robot still needs the network to receive its zone and to send alerts about cluttered areas. Onboard control keeps the important work running when the network is lost.

Central control always gives better results. The sweep-coverage study reports that fully centralized systems are often high performing and efficient, but those advantages could be hard to maintain when communication is disturbed. A good result on a stable network may not survive home Wi-Fi.

A hybrid is the average of the two. A hybrid requires its own communication protocols and coordination mechanisms, and the designer must decide where each job lives.

Frequently asked questions

Does a mopping robot need a powerful chip to work on its own?

It depends on which jobs sit on the robot. A reflex layer runs on an ESP32-class microcontroller. Heavy recognition usually moves to the computer because resource-constrained robots often lack the power to run the most accurate models.

Can one personal computer control several mopping robots?

Architecturally yes, because the central control unit can be a standalone computer. The maximum robot count depends on processing load and Wi-Fi quality, so it has to be measured on the real system.

Can I start with central control and move toward onboard control later?

You can, if the reflex layer sits on the robot from the start and the message format between robot and computer stays stable. Moving a decision onto the robot is then a matter of shifting it to the other side of the link. This is design inference and needs testing on a prototype.

Summary

• The three styles differ in where decisions are made; no style wins on every criterion, and the specific task decides the choice.
• In the lost-Wi-Fi example, central control stops and waits, onboard control continues when sufficient local data remains, and the hybrid cuts its pump and returns only when local navigation is available.
• The illustrative design picks a hybrid: reflexes and the return to the dock on the robot, planning, map and recognition on the computer.