How Can a PC Control a Fleet of Small Mopping Robots?

• Mopping robots
• Wi-Fi and router
• Broker or agent in the middle
• Computer running the control program
• Phone receiving alerts

What you will learn

• Draw the chain of robot, Wi-Fi, broker or agent, and a program on the computer, and give each block its jobs.
• Compare MQTT with micro-ROS as the path between robots and the computer, and choose a delivery mode for each kind of message.
• Name three failure points of the chain, namely a sleeping computer, a Wi-Fi access point change and overload, together with the signal that reveals each.

Before you start

Read the article comparing central and onboard control and the article on MQTT to be comfortable with publish and subscribe.

Which jobs run on the computer and which on the robot?

The computer keeps the jobs that need a view of the whole home, and the robot keeps the jobs that must not wait. This split follows the hybrid style chosen in the comparison article above. The table is an illustrative design, not a tested result.

Messages between the two sides fall into three groups. Status is small and regular, so only the newest sample is useful. Commands need an application acknowledgment before the controller considers them accepted. Images are heavy, so the robot sends them only when the central program asks, instead of streaming them. This is design reasoning; real sizes and rates must be measured on the actual system. Estimate load by multiplying each robot’s message size by its send rate and summing across the fleet, then include images and protocol overhead. Measure actual receipt rate, sample age and command-to-acknowledgment time as load rises; reduce image traffic before slowing control feedback. Computer specifications alone do not establish a maximum fleet size.

• Mopping robot
• Short reflex loop inside the robot
• Sensor beams to the floor edge
• Laptop with the map and coverage path
• Object detection
• Log
• Commands going down to the robot
• Status going up to the computer

MQTT or micro-ROS: which links the robot to the computer?

MQTT fits when you want a simple link; micro-ROS fits when the computer side already runs ROS 2 nodes. Both put an intermediary between robot and computer, but the intermediary does different work.

According to the micro-ROS documentation on MQTT, MQTT is a lightweight message protocol used over TCP, with a simple publish/subscribe interface. Clients connect to an MQTT broker, and the broker orchestrates the exchange of data. A client must know the broker address before its first connection. The MQTT standard does not define how a topic relates to a data type, so understanding the messages is left to the user. A robot can use Espressif's ESP-MQTT, an implementation of an MQTT client.

For micro-ROS, the Micro XRCE-DDS documentation describes the XRCE Client as a low-resource device. It connects to an XRCE Agent, which acts on the client's behalf in the DDS global data space. micro-ROS uses Micro XRCE-DDS as its default middleware layer. In contrast to an MQTT broker, the XRCE Agent does not manage the publication and subscription of topics. DDS communication proxy state can reside in the agent; this does not remove the robot’s task state or the local data it needs to return.

On delivery, the MQTT specification states that QoS 0 delivers a message once or not at all, while QoS 1 ensures it arrives at least once. ROS 2 also offers delivery reliability choices, without a complete equivalence between the protocols: best effort tries to deliver but may lose samples, while reliable guarantees delivery and may retry. The illustrative design chooses as follows:

• Status uses QoS 0 or best effort, because a new sample replaces the old one.
• Commands use QoS 1 or reliable. Since one may arrive twice, each command carries its own identifier so the robot can drop the duplicate.
• The zone currently assigned uses a retained message. When a client sends a PUBLISH with the RETAIN flag, the broker replaces the existing retained message of that topic. A later subscriber can therefore receive the stored zone. In the illustrative design this describes an allocation, not permission to start moving: after reconnecting, the robot checks the control session and validity and waits for controller confirmation.

• Robots
• MQTT broker with messages
• Program on the computer
• XRCE Agent
• Robot stand-ins held by the agent
• DDS data ring that includes the computer
• Boundary between the two ways

How do you know each link is alive and the clocks agree?

In the illustrative model, an application heartbeat shows the processing loop recently ran, while a shared clock helps correlate events. A connection to the broker alone does not prove the controller is still processing commands. Each mechanism has its own signal.

In MQTT, Keep Alive is the maximum interval allowed between the control packets a client sends. If Keep Alive is non-zero and the broker receives no packet within one and a half times that interval, it must close the connection. When there is no other packet to send, the client must send a PINGREQ. If it receives no PINGRESP within a reasonable time, the client should close the network connection. After an abnormal disconnection, a running broker can publish the robot’s Will Message according to its configuration. It reports a lost connection, not the robot’s physical position or condition. If the broker also sleeps or fails, it cannot be relied on to issue that alert.

In ROS 2, the lease duration is the maximum time a publisher has to indicate it is alive. After that, the system considers it to have lost liveliness. Nodes also advertise their presence periodically and when they go offline. Two nodes connect only if their Quality of Service settings are compatible. A mismatched pair may fail to connect even though both nodes are running.

The reverse direction is needed too: the robot watches a heartbeat message published by the central program. Losing it can indicate a sleeping computer, a stalled program or a broken link, and the robot switches to its safety reflexes.

For time, NTP is widely used to synchronize computer clocks. The offset is the estimated shift of the server clock relative to the system clock, and the delay is the round-trip delay between client and server. SNTP is intended for clients with a single upstream server, so each robot can point at one time source, for example the control computer. On the robot, the lwIP SNTP library in ESP-IDF sets the system time when a response from the NTP server arrives. A shared clock helps correlate events from many robots; synchronization error can still make closely spaced events ambiguous. In the illustrative design, stop deadlines use a local elapsed-time clock that does not move backward, so correcting wall time cannot extend an old command.

Two ROS 2 settings help limit stale data, but do not diagnose overload by themselves: keep last stores only up to a set number of samples according to the queue depth, and messages past their lifespan are silently dropped.

• Two clocks showing the same time
• Heartbeats the robot sends
• Heartbeats that no longer come
• Heartbeats reaching the central program
• Wait counted from the last beat
• Point of expiry
• Will Message

Why start on a laptop and move to a dedicated machine later?

A laptop is already there and lets you write, run and simulate on one machine. But it sleeps, changes networks and leaves the building, so it only suits the trial stage. The table lists the failure points and the signals that reveal them.

A dedicated machine needs sleep disabled, process monitoring and a stable power supply; changing machines alone does not remove that failure. A cable to the Wi-Fi access point removes the computer's own wireless link, but the robot's access point change remains. A fixed address matters even more: an MQTT client must know the broker address, so changing it strands the whole fleet. The chain stays the same (robot, Wi-Fi, broker or agent, program), so moving only changes where it runs, not the protocol.

• Sleeping laptop
• Weak or broken Wi-Fi
• Moving where it runs
• Dedicated always-on machine
• Cable to the Wi-Fi router
• Fixed address

Real-world example

A small office has three robots; the broker and the control program run on one laptop. This is a design scenario, not a test result. The program picks the corridor zone for the third robot. It publishes an assignment on that robot's command topic, with its own identifier and QoS 1.

The broker passes the command to the robot. The robot records the identifier, publishes the status "zone accepted" and starts mopping. The central program sees that status and stops resending. If the wait runs out with no acknowledgement, the program resends with the same identifier, and the robot drops the duplicate.

At lunch the laptop lid closes. The broker stops, all three connections drop, and the computer heartbeat disappears. The robots cut their pumps and return only if they can still localize themselves, have a stored route and enough battery; otherwise they stop and record a fault. When the laptop wakes, the robots reconnect to the broker address they already know. The program requests fresh state and position, reconciles task identifiers, and only then decides whether to continue or reassign; a missing acknowledgment does not prove the old command never ran.

That afternoon the second robot leaves the coverage of one access point and joins another. The old connection drops, and the broker closes it after one and a half times Keep Alive and publishes the Will Message. The program marks the robot lost, waits a preset time, but does not assign another robot to that zone while the missing robot’s position is unknown. In this example, reassignment waits until the old robot is confirmed stopped or isolated from the work area.

Common misunderstandings

QoS 1 guarantees a command runs exactly once. QoS 1 only ensures at least one arrival, so a command can arrive twice. Each command needs its own identifier so the robot can drop the duplicate.

A heartbeat means the robot is mopping correctly. A heartbeat shows that the client and the link are alive. The status message must also carry what the robot is doing.

A powerful computer removes the Wi-Fi worry. Home Wi-Fi can lose packets, so each kind of message must choose between best effort and reliable. Computer power does not replace that choice.

Frequently asked questions

Do I need ROS 2 to control several robots from a computer?

No. MQTT with an ESP-MQTT client on the robot is enough for status, commands and heartbeats. micro-ROS helps when the computer side already uses ROS 2 nodes.

Where should the MQTT broker run?

On a machine that runs all the time and has a fixed address. Running it on the same machine as the control program is simple, but when that machine sleeps, both stop together.

Which delivery mode suits weak Wi-Fi?

It depends on the message. Status tolerates lost samples, so use QoS 0 or best effort; commands must not be lost, so use QoS 1 or reliable, with an identifier to drop duplicates.

Summary

• The computer keeps planning, the map, detection and alerts; the robot keeps its reflexes and heartbeat; they connect through an MQTT broker or an XRCE Agent.
• MQTT with QoS 0, QoS 1, retained messages, Keep Alive and Will Messages is enough for a small fleet; micro-ROS fits when the computer side uses ROS 2.
• A sleeping computer, an access point change and overload each have their own signal; start on a laptop, then move to a dedicated machine with a fixed address.