Fire Fighter Robot Sensor Fusion: Thermal Arrays and Power Derating

A fire fighter robot is an embedded mechatronic system that uses thermal and gas sensor arrays to autonomously navigate hazardous environments and suppress flames via localized actuator control. In a real installation, this concept changes fire suppression from a reactive, human-dependent response into a proactive, sensor-driven intervention, fundamentally altering the power budget and thermal derating requirements of the control circuitry. Beginners commonly confuse simple IR flame sensors (which only detect 760–1100nm light) with true thermal imaging, and mistake open-loop water pumps for closed-loop PID-controlled suppression systems.

The Sensor Fusion Core: IR vs. Thermal Arrays

To build a competent fire fighter robot, you must move beyond the basic KY-026 IR flame sensor modules found in starter kits. Those cheap modules rely on a phototransistor that triggers when it sees near-infrared light. Think of a standard IR sensor as a narrow searchlight: it only tells you if a specific wavelength is hitting it directly, but it gives you zero context about the ambient temperature or the exact spatial location of the heat source.

True autonomous navigation requires a thermal imaging array like the MLX90640. This 32x24 pixel I2C sensor reads far-infrared radiation, giving your ESP32 a low-resolution heat map of the room. This allows the robot to track the thermal gradient (the direction of increasing heat) rather than just reacting to a binary "flame detected" pin.

For a robust build, use the MLX90640 for spatial navigation and keep a cheap IR sensor as a high-speed hardware interrupt fallback in case the I2C bus locks up during a motor stall event. You can read more about interfacing the MLX90640 in the Adafruit MLX90640 Breakout Guide.

Where You Meet This in Practice: Power and Thermal Derating

Where you meet this in practice is at the intersection of high-current actuators and sensitive 3.3V logic. A fire fighter robot requires a water pump or a high-torque fan. These are inductive loads that generate massive voltage spikes and draw heavy stall currents, which can easily brownout your microcontroller if the power architecture is poorly designed.

Let us run a worked numeric example for a standard 12V diaphragm pump powered by a 3S LiPo battery (11.1V nominal, 12.6V fully charged).

• Battery Internal Resistance: ~30mΩ per cell × 3 cells = 90mΩ (0.09Ω) total.
• Pump Stall Current: 2.2A (measured on the bench with a multimeter).
• Voltage Sag Calculation: V = I × R. At stall, the battery sags by 2.2A × 0.09Ω = 0.198V.
• Motor Driver Dropout: A TB6612FNG MOSFET driver has an Rds(on) of about 0.5Ω total for the high and low side. At 2.2A, that is another 1.1V drop across the driver.

If your 12V pump is actually receiving only 11.2V during a stall, it might fail to start if the mechanical load is too high. More importantly, if you are sharing this battery with a cheap buck converter to step down to 5V for the ESP32, the transient inductive kickback when the pump turns off can spike the ground plane by several volts, instantly resetting the ESP32 and killing your navigation code.

Real-World Scenario Walkthrough: The Warehouse Test

Setup

We deployed a prototype fire fighter robot in a 20x20 foot test maze. The brain was an ESP32 DevKit v1, driving a 12V 2A diaphragm pump via a TB6612FNG dual motor driver carrier (see the Pololu TB6612FNG specs). The sensor payload included the MLX90640 and an MQ-2 smoke sensor. Power was supplied by a 3S 2200mAh LiPo.

Numbers

The logic circuit drew a steady 180mA. The drive motors drew 400mA each while cruising. The pump was configured to trigger only when the MLX90640 detected a localized pixel cluster above 85°C. The pump running current was 0.8A.

Outcome

The robot successfully navigated the thermal gradient, located the localized heat source (a controlled propane burner), and triggered the pump relay. Water flow was established, and the flame was suppressed within 4 seconds of actuator engagement.

What Went Wrong

Immediately after the pump disengaged, the ESP32 rebooted. The robot sat dead in the water, losing its I2C sensor state and requiring a manual reset. On the bench, an oscilloscope probe on the 3.3V rail showed a -1.2V ground bounce the exact millisecond the pump MOSFET switched off. The inductive kickback from the pump coil had no path to dissipate, so it dumped into the shared ground plane, pulling the ESP32's ground reference below its brownout detection threshold (BOD) and triggering a hardware reset.

Step-by-Step: Wiring the Suppression Actuator

When wiring high-current suppression pumps to your microcontroller, follow this sequence to ensure clean power delivery and protect your logic gates.

1. Isolate the Ground Planes: Run a thick (14 AWG) ground wire directly from the battery negative terminal to the motor driver's high-current ground pin. Do not route high-current return paths through the breadboard or the ESP32's GND pins.
2. Install the Flyback Diode: Solder a Schottky or fast-recovery diode (like a 1N5819 or 1N5408 depending on current) directly across the pump's physical terminals. This must be done at the load, not at the motor driver board, to suppress the coil's magnetic collapse.
3. Wire the Logic Level Shifters: The TB6612FNG logic pins (PWMA, AIN1, AIN2) require 3.3V logic to match the ESP32. Connect the VCC pin of the TB6612FNG to the ESP32's 3V3 output, ensuring the logic threshold matches.
4. Add Bulk Capacitance: Solder a 470µF to 1000µF electrolytic capacitor across the VM (Motor Voltage) and PGND pins on the motor driver. This acts as a local energy reservoir during pump startup stalls.
5. Verify with a Multimeter: Before connecting the ESP32, power the 12V rail and measure the voltage at the motor driver's VM pin. Trigger the pump manually and ensure the voltage does not dip below the minimum operating voltage of your 5V buck converter (typically 6.5V).

Frequently Asked Questions