ESP32 And Edge Computing On The Rooftop

Building a robot that operates reliably on a solar rooftop — exposed to direct sun, temperature swings from 15°C to 55°C, monsoon humidity, and the vibration of a moving rail system — is a different engineering problem from building a robot in a controlled factory environment.

The control architecture has to be robust, low-power, remotely manageable, and fault-tolerant. Here is how we approached it.

Why ESP32

The ESP32 is a dual-core 240 MHz microcontroller with integrated Wi-Fi and Bluetooth. It is not the most powerful embedded platform available, but it hits the right combination of capability, power consumption, cost, and ecosystem maturity for our use case.

Key factors in the selection: - Deep sleep current draw under 10 µA, critical for a battery-powered system that may idle for hours between cycles - Mature FreeRTOS support for task scheduling - Native ADC for battery voltage and motor current monitoring - Built-in Wi-Fi for local commissioning and OTA firmware updates

The Control Stack

The primary controller handles motor drive, brush speed control, position tracking via encoder feedback, and safety interlocks. A secondary co-processor manages communication — LTE modem coordination, telemetry packaging, and remote command handling.

The two processors communicate over a high-speed SPI bus. The separation means a communication failure never affects the mechanical control loop — the robot continues its cleaning cycle and logs the event for later transmission.

Scheduling and Remote Management

Each robot unit maintains a local schedule stored in non-volatile flash. Schedules can be pushed remotely via our cloud dashboard or configured locally over Bluetooth during installation. The robot executes cleaning cycles autonomously, with no dependency on a live network connection.

Telemetry — including cycle completion status, battery state of charge, motor current draw, and fault codes — is transmitted at the end of each cycle. Unusual current patterns trigger automated alerts: a blocked brush, a rail obstruction, or a motor bearing degrading ahead of failure.

Fault Detection

One of the more interesting engineering challenges is detecting panel surface anomalies. Our current implementation uses motor current signature analysis — a blocked brush or panel edge obstruction creates a characteristic current spike that the controller can distinguish from normal load variation.

Future versions will incorporate optical sensing to detect panel damage or heavily soiled sections that warrant a repeat pass.

OTA Updates

All firmware updates are delivered over-the-air. The bootloader implements a dual-bank scheme: the update is written to the inactive bank and verified before the active bank is switched. A failed update rolls back automatically, ensuring the robot is never left in an unbootable state at a remote installation site.

This has proven essential — we have deployed firmware improvements to units in the field without a single site visit for software-related issues.