Skip to content
← Back to Universal ESP32-C3 Combat Robot Controller

Universal ESP32-C3 Combat Robot Controller · 2024-12-15 · 3 min

Universal ESP32-C3 Combat Robot Controller (V1)


A universal, weight-conscious ESP32-C3 control board for 1lb and 3lb combat robots — BLE-linked to an Xbox gamepad, with brushed motor H-bridges and high-current outputs for ESCs and weapons. Version 1 was the first attempt; this post documents what worked, what didn’t, and why the next revision took the shape it did.

Project overview

In 1lb and 3lb combat robotics, every gram counts, so I prefer to build custom control boards to minimize weight. However, designing a new board for each robot became tedious, especially when most share the same fundamental requirements: receiving commands from a handheld controller and driving motors—both for movement and a high-current ESC/BLDC weapon system.

To streamline future builds, I designed a compact, universal control board that integrates these core functions, making it adaptable to any new robot design.

At its heart is a custom-programmed ESP32-C3-MINI, which communicates via BLE with an Xbox gamepad for seamless wireless control.

Design spec (V1)

  • EDA tool: EasyEDA
  • Manufacturer and assembly: JLCPCB
  • Microcontroller: ESP32-C3-Mini
  • 1 high current LiPo input
  • 1 master safety switch
  • 2 high current outputs for ESC’s or others
  • 2 Servo/ESC/PWM outputs
  • 2 DRV8870 Brushed Motor H-Bridge Outputs
  • 1 Debug LED
  • 1 user programable button
  • Native USB connection
  • UART (TX/RX) optional connection (can be repurposed for additional I/O)
  • 1 additional I/O port that can be soldered to
  • WIFI and BLE support with the ESP32-C3-Mini preassembled PCB antenna

What changed

Version 1 was the first attempt at a versatile control board. As I started designing my first robot around it, several real-world issues showed up: connector placement, switch accessibility, motor driver thermal performance, and a debug LED that wasn’t doing enough work. The next revision addresses each of these directly.

Connector placement

The XT30 connectors for the LiPo battery made board installation more difficult than expected. The additional space required for both the connectors and their wire leads took up valuable real estate on the PCB. I realized that using solderable pads instead of through-hole connectors would allow wires to be soldered at a more convenient angle, simplifying routing and making push connections easier to manage.

V1 board showing XT30 connector placement
XT30 connectors for the LiPo input — replaced with solderable pads in V2 to free up PCB real estate and simplify routing.

Master power switch accessibility

The placement of the master power switch also posed an issue. It needed to be easily accessible with a tool, without requiring the robot to be disassembled. This meant ensuring that no batteries or other components were mounted above or below the board, as a screwdriver needed a clear path to torque down the switch. This wasted a lot of potentially usable volume to house other peripherals.

V1 board showing master switch position
Master power switch placement in V1. V2 moved this to an external solder-pad header so the on-board switch could be omitted in tight builds.

Motor driver and thermal issues

The DRV8870 motor drivers were non-functional, and I discovered that the GND plane beneath the IC was not exposed—an important reminder to always double-check footprint details from EasyEDA/LCSC! Without proper thermal dissipation, the ICs likely entered rapid thermal shutdown during testing. Additionally, the current sense resistor was oversized, while the power input capacitors for the DRV8870 were undersized.

To address these issues and improve performance, I decided to switch to the DRV8871 in the next revision, as it offers better built-in features and should handle heat dissipation more effectively when I actually include proper grounding.

V1 board with motor driver footprint issue highlighted
The DRV8870 footprint from EasyEDA/LCSC had a missing GND pad on the thermal pad. V2 corrects this and switches to DRV8871.

Debugging and status indicators

The single debug LED provided minimal visual feedback for board status. To make fault detection and battery level monitoring more intuitive, I plan to replace it with a WS2812 RGB LED, allowing for clearer visual indicators.

V1 board single debug LED position
V1’s single debug LED. V2 swaps this for a WS2812 RGB LED to support color-coded status.

Next steps

Changes have been made to the board based on the concerns described here along with a few other improvements. The V2 writeup lives here.