Actuator sizing and drive topology selection is the process of matching a motor's torque-speed curve and a driver's current limits to the mechanical load and kinematic requirements of a robotic system. Getting this right dictates your embedded controller's PWM frequency requirements, your power supply's peak current delivery, and the physical payload capacity of the robot, whereas getting it wrong usually results in melted H-bridges or microcontroller brownouts. Hobbyists commonly confuse a motor's stall torque with its continuous rated torque, and assume a motor driver's peak current rating applies to continuous operation, leading to catastrophic thermal failures in otherwise cool robot designs.
The Core Theory: Torque-Speed Curves and Embedded PWM
When building advanced robotics, the microcontroller does not drive the motor directly; it commands a motor driver IC via Pulse Width Modulation (PWM). The MCU outputs a high-frequency digital signal (typically 20 kHz via the ESP32's MCPWM or LEDC peripherals). The driver translates this duty cycle into an average voltage applied to the motor windings. The motor then translates that voltage into rotational speed, and the drawn current into torque.
According to All About Circuits' guide on DC motor torque-speed curves, a DC motor's speed is proportional to the applied voltage minus the voltage drop across its internal resistance, while its torque is strictly proportional to the current. If your mechanical design demands high torque at low speeds, the motor will draw massive current, generating heat that can demagnetize the rotor or melt the driver's silicon if the thermal limits are exceeded.
| Actuator Type | Continuous Torque | Nominal Voltage | Ideal PWM Freq | Common Driver IC |
|---|---|---|---|---|
| Coreless DC Gearmotor (e.g., Pololu 30:1 Micro Metal) | 1.2 kg·cm | 6V | 20 kHz | DRV8833 |
| NEMA 17 Bipolar Stepper | 4.5 kg·cm | 12V-24V | Step/Dir (Pulse) | TMC2209 |
| Outrunner BLDC (Gimbal) | 15 kg·cm | 12V | 20-50 kHz (3-phase) | DRV8313 |
| Digital Servo (e.g., DS3218) | 20 kg·cm | 5V-7.4V | 50 Hz (1-2ms pulse) | Internal |
Worked Numeric Example: Sizing a Differential Drive Base
Let's calculate the exact actuator requirements for a 5 kg indoor rover, a staple among cool robot designs, to ensure our embedded hardware doesn't fail under load.
Robot Mass ($m$): 5 kg
Target Acceleration ($a$): 1.5 m/s²
Wheel Radius ($r$): 30 mm (0.03 m)
Driven Wheels: 2
Step 1: Calculate Required Force
Using Newton's second law ($F = ma$), the total linear force required is $5 \text{ kg} \times 1.5 \text{ m/s}^2 = 7.5 \text{ N}$. Since we have two driven wheels, each wheel must provide $3.75 \text{ N}$ of thrust.
Step 2: Calculate Required Torque
Torque ($\tau$) is force multiplied by the moment arm (wheel radius).
$\tau = 3.75 \text{ N} \times 0.03 \text{ m} = 0.1125 \text{ N}\cdot\text{m}$ (or $11.25 \text{ N}\cdot\text{cm}$, roughly $1.15 \text{ kg}\cdot\text{cm}$).
Step 3: Apply Safety Margin and Select Hardware
Adding a 50% safety margin for carpet friction and minor inclines brings our requirement to 1.72 kg·cm per wheel. We select the Pololu 100:1 Micro Metal Gearmotor HP, which delivers 2.5 kg·cm continuous torque at 6V. At this load, it draws approximately 1.2A.
Step 4: Match the Driver IC
We need a driver that handles 1.2A continuous per channel. The TB6612FNG is rated for 1.2A continuous and 3.2A peak, making it a perfect match. If we had mistakenly chosen the popular L298N (rated for 2A continuous), its BJT-based H-bridge would drop roughly 2V across its transistors. This would starve our 6V motor, dropping its effective voltage to 4V, severely tanking the torque and causing the robot to stall on inclines.
Where You Meet This in Practice
Theory meets reality when you wire the ESP32 to the physical chassis. Here are the specific failure modes and embedded debugging scenarios you will encounter when building these systems.
When a motor stalls or hits a physical jam, it draws stall current (often 5A+). If your 5V buck converter powering the ESP32 shares an input rail with the motor driver without adequate bulk capacitance, the voltage droop will trigger the ESP32's brownout detector, resetting the microcontroller. Fix: Add a 1000µF low-ESR electrolytic capacitor directly at the motor driver's VMOT pins and use separate LDOs for logic and motor power rails.
PWM Frequency Mismatch
Driving a brushed DC motor at 1 kHz causes audible whine and mechanical resonance in the chassis. Driving it at 100 kHz causes massive switching losses in the MOSFETs of your driver, leading to thermal shutdown. The sweet spot for most embedded cool robot designs using modern MOSFET drivers is 20 kHz to 25 kHz. This pushes the switching noise above human hearing while keeping MOSFET switching losses under 5%. For the ESP32, configure the LEDC timer with a 20,000 Hz frequency and 10-bit resolution for smooth low-speed control.
Flyback Diode Destruction
Inductive kickback from the motor windings when the H-bridge switches off can spike to 50V+, instantly destroying the driver IC. While modern ICs like the DRV8871 have internal clamp diodes, high-inertia loads (like heavy robotic arms) generate spikes that exceed internal thermal limits. For these designs, soldering external Schottky diodes (like the 1N5819) across the motor terminals is mandatory to shunt the reverse EMF safely back to the power rail.
FAQ: Debugging Motor Control in Embedded Systems
Why is my L298N overheating even though my motors only draw 1A?
The L298N uses an older BJT-based H-bridge topology with a typical voltage drop of 2V to 3V. At 1A, it dissipates 2W to 3W as heat per channel, requiring a massive heatsink. Switch to a MOSFET-based driver like the TB6612FNG or DRV8871. These have an $R_{DS(on)}$ of roughly 0.5Ω, dissipating only 0.5W at 1A and running cool to the touch without heatsinks.
How do I configure the ESP32 MCPWM for dead-time control?
When driving high-power BLDC motors or custom H-bridges, you must prevent 'shoot-through' (where both high and low side MOSFETs are on simultaneously, shorting the power rail to ground). The Espressif ESP-IDF MCPWM API allows you to configure hardware dead-time insertion via the mcpwm_deadtime_enable() function, typically setting a 500ns delay to ensure one MOSFET fully turns off before the other turns on.
My PID balance bot overshoots and falls over. How do I tune it?
Start with Proportional (P) control only. Increase $K_p$ until the bot oscillates rapidly, then back it off by 20%. Next, introduce Derivative ($K_d$) to dampen the oscillation. Leave Integral ($K_i$) at zero unless you have a steady-state error caused by a persistent physical incline. If you do enable $K_i$, you must implement integral windup clamping in your C++ code, otherwise the accumulated error will cause massive overshoot when the bot returns to level ground.
