I Bought a Robot Vacuum, Not a Cloud Spy

Source: Dev.to

Background: Buying a Used Robot

I didn’t buy this robot vacuum because I urgently needed automated cleaning.

• warranty
• the mental barrier of “don’t touch it, you might break something”
• the expectation that it must “work off its price” before you can experiment.

A new device feels like something you’re borrowing from the manufacturer.

Why This Model

The robot is a Xiaomi Robot Mop Essential.

Expectations vs Reality

• The robot does its job well.
• Bumping into obstacles with its bumper.
• Calculating position from wheel encoders.
• Using basic orientation and motion sensors.

No LiDAR. No magic. Just contact, math, and retries. And it works surprisingly well.

Mechanical Issues and Repairs

The Wheel Problem

The robot was used, and the wheel showed wear. My fix was simple but effective:

1. Lubricate the metal bushing.
2. Fill the damaged plastic seat with a small tube of cyanoacrylate glue (superglue).
3. Wait about 2 hours for full curing.
4. Remove the bushing and reinstall.

Result: firm fit, no wobble, wheel restored. This was my first signal that the device is repairable.

Wet Surface Traction (Unsolved)

One mechanical issue still remains: traction on wet surfaces.

• Possible reasons: insufficient downforce.
• I’m experimenting with a goal of reliable traction without overloading the motors.

Wet Cleaning System

The water nozzles were clogged. While I was there, I also repaired the small water pump feeding the mop cloth.

From Buttons to Control: Where the Real Problem Started

After fixing the mechanical issues, the robot worked… almost.

1. Walk up to it.
2. Press a physical button.
3. Watch it desperately try to connect to Wi‑Fi and eventually give up.

Factory resets didn’t help. The robot wanted Wi‑Fi, but it never fully joined.

Inside the Xiaomi Robot Mop Essential

The robot has a clear internal hierarchy: two brains.

Motor‑control brain (MCU)

• Wheel encoders
• Bump sensors
• Gyroscope and orientation
• Navigation logic
• Map building

Based on available technical data and analysis of similar Xiaomi robots, this MCU typically features:

• A 32‑bit RISC core for control logic
• A dedicated DSP core for real‑time sensor processing
• Hardware blocks optimized for navigation and SLAM‑like calculations
• External flash memory for firmware and maps

The MCU doesn’t care about Wi‑Fi; it doesn’t know what a cloud is.

Connectivity brain (ESP32)

• Wi‑Fi connectivity
• Communication with Xiaomi cloud
• OTA updates
• Relaying commands and permissions

It does not drive motors.

Listening Instead of Guessing: UART Sniffing

UART5 RX / TX → MCU
UART7 TX / RX → ESP32

Why not just an ESP32? Because I needed three UART ports simultaneously:

• MCU ↔ ESP32 communication
• ESP32 ↔ MCU communication
• MCU diagnostic port (connected later after freeing UART5)

An Orange Pi quietly sniffed all traffic: no injections, no modifications, just observation. I read both the diagnostic UART and the official ESP32 UART simultaneously in a single terminal window.

Observations

• Wrong command detected.
• The diagnostic UART shows motor currents, encoder values, gyro readings, and internal flags.

Example diagnostic output when starting cleaning:

Oc[3]=410  Ic[3]=-43  k p=101  
Oc[3]=363  Ic[3]=-58  
p offsg 213  
gyrod=10029  
sg 181  
crc=15fb  
STL start clean  
default map enable:1

Commands sent to the MCU via the official UART produce status codes (ok, error…) numerically.

MCU -> ESP32 : platform_name
ESP32 -> MCU : ok
MCU -> ESP32 : firmware_id
ESP32 -> MCU : ok
MCU -> ESP32 : mac_device ?
ESP32 -> MCU : 
MCU -> ESP32 : “Can I request OTA updates?”
ESP32 -> MCU : ok

Once it became clear that the MCU was merely asking for permission from the ESP32, the solution was obvious: a minimal ESP32 firmware architecture with a serial terminal for debugging, a logger to record all UART traffic, and dual‑UART monitoring.

Current Status

The ESP32 firmware is still under development. Most of the core system is functional — about 80 % complete.

• Dual‑UART monitoring works.
• Dispatcher, scheduler, and multicore systems are running.
• Basic MIOT‑like protocol handling (JSON API) is implemented.
• OTA module is integrated, which will simplify future modifications (e.g., connecting a display).

When finished, the robot will have full local control, reliable telemetry, and optional display feedback — all without ever needing the cloud.

Physical Mods: Replacing Buttons with a “Head”

After the software and UART control were in place, the next step was physical accessibility.

• Parallel connection to button / UART to ESP32 and diagnostic port.
• Temporary installation of buttons and LEDs.

This physical modification achieves several goals:

• Makes interacting with the robot intuitive even without an app.
• Keeps visual status indicators simple and visible.
• Allows retention of full MCU control while optionally using the original buttons.

Think of it as a “command tower” — a small cockpit that gives the robot a personality and a clear interface.

What I’d Change if Designing This Robot

If I were designing the Xiaomi Robot Mop Essential from scratch, I would:

1. Make cloud telemetry optional and clearly permission‑based.
2. Expose an official UART or API for advanced users.
3. Allow easy replacement or expansion of LEDs and buttons for custom interfaces.
4. Include a modular design for attaching displays or additional sensors.

These changes would let engineers and hobbyists:

• Understand what the robot is doing.
• Customize behavior safely.
• Avoid turning a simple cleaning robot into an unintended cloud spy. 😁