Sensor Theory for Robot Follow-Me Systems: UWB vs ToF Tracking

Robot follow-me tracking is the closed-loop control process where a mobile platform continuously measures the relative distance and bearing to a specific target tag or beacon to maintain a fixed spatial offset. Implementing a robust robot follow system changes your circuit design fundamentally: it forces you to isolate noisy motor power rails from sensitive sensor logic and shifts your microcontroller's workload from simple open-loop polling to high-frequency, interrupt-driven sensor fusion. Beginners commonly confuse raw distance polling (just reading a sensor value) with closed-loop follow tracking (using that reading to dynamically adjust motor PWM via a PID controller), or they conflate optical Time-of-Flight (ToF) with the RF Time-of-Flight used in Ultra-Wideband (UWB) modules.

Sensor Hardware Matrix for Robot Follow Systems

Choosing the right sensor dictates your maximum tracking speed, outdoor viability, and power budget. Below is a data-dense comparison of the three most common sensor technologies used in DIY and prosumer robot follow builds as of 2026.

Worked Numeric Example: PID Tuning for Follow Distance

A robot follow system relies on a Proportional-Integral-Derivative (PID) controller to translate the distance error into a motor PWM signal. Let's walk through a discrete PID calculation for a differential-drive robot trying to maintain a 1.0 meter (100 cm) distance from a target.

The Scenario:

• Target Setpoint (SP): 100 cm
• Current Measured Distance (PV): 140 cm
• Error (e = SP - PV): 100 - 140 = -40 cm (Robot is too far away)
• Previous Error (e_prev): -30 cm (Measured 100ms ago)
• Time step ($\Delta t$): 0.1 seconds

PID Constants (Tuned for a 12V DC gear motor setup):

• $K_p$ (Proportional) = 4.0
• $K_i$ (Integral) = 0.5
• $K_d$ (Derivative) = 1.5

The Calculation:

1. Proportional Term (P): $K_p \times e = 4.0 \times (-40) = -160
2. Integral Term (I): $I_{prev} + (e \times \Delta t) = -5.0 + (-40 \times 0.1) = -9.0$.
   Output: $K_i \times I = 0.5 \times (-9.0) = -4.5
3. Derivative Term (D): $(e - e_{prev}) / \Delta t = (-40 - (-30)) / 0.1 = -100$.
   Output: $K_d \times D = 1.5 \times (-100) = -150

Total PID Output: $P + I + D = -160 + (-4.5) + (-150) = -314.5

Because the error is negative (robot is too far), the negative output indicates the robot needs to drive forward. We map this to our microcontroller's PWM resolution. If using an ESP32 with 8-bit PWM (0-255), we take the absolute value and clamp it: min(255, abs(-314.5)) = 255. The motors receive full forward throttle. As the robot closes the gap to 105cm, the P and D terms shrink, smoothly ramping down the PWM to prevent overshooting the 100cm setpoint.

Where You Meet This in Practice: ESP32 Wiring and Power

Theory falls apart if your hardware layer is unstable. When building a robot follow-me platform on an ESP32-S3, you will encounter three specific hardware bottlenecks.

1. I2C Bus Capacitance and Pull-Up Sizing

If you use a VL53L1X ToF sensor, it communicates via I2C. On a robot chassis, your wires might be 30-50cm long. This adds parasitic capacitance to the SDA/SCL lines. The standard 4.7kΩ pull-up resistors on cheap breakout boards are too weak, resulting in rounded signal edges and I2C timeouts at 400kHz. The fix: Add 2.2kΩ pull-up resistors directly at the ESP32-S3 end of the cable, or drop the I2C clock speed to 100kHz in your Wire.setClock(100000) initialization.

2. SPI Clock Limits for UWB Modules

The DWM1001 UWB module uses SPI. While the datasheet claims support for 20MHz SPI clocks, breadboard parasitics and long ribbon cables will cause bit-flips at that speed. In practice, cap your SPI clock at 4 MHz to 8 MHz using SPISettings(8000000, MSBFIRST, SPI_MODE0). This guarantees reliable payload delivery without sacrificing the 80Hz update rate needed for smooth robot follow tracking.

3. The Motor Brownout Failure Mode

This is the most common reason robot follow projects fail on the bench. When your PID controller commands a sudden PWM spike to correct a large distance error, the DC motors draw stall current (often 2A to 4A per motor). If your motor driver and ESP32 share the same 5V buck converter, this current spike causes a voltage sag. The ESP32's brownout detector (BOD) triggers at ~2.4V, instantly resetting the microcontroller. The fix: Power the motors from a dedicated 3S LiPo (11.1V) through an LM2596 buck converter set to 5V, and power the ESP32 from a separate, high-frequency decoupled 5V rail. Tie the grounds together at a single star point.

Common Confusions and Troubleshooting FAQ