Absolutely. Below is a complete, step-by-step project documentation package for the project. I’ll structure it like an engineering final-year project report, including the architecture, working principle, flow diagrams, block/schematic diagrams, database/cloud flow, n8n workflow, Telegram alerts, AI-agent logic, ThingSpeak, Google Sheets, ESP32 firmware, and example web dashboard code.
Important design note: For a real fire-fighting machine, the ESP32 should retain deterministic local safety logic. The AI agent/n8n layer should be used for analysis, logging, notifications and higher-level decisions—not as the sole authority for safety-critical motor/pump control.
AI AUTONOMOUS FIRE FIGHTING ROBOT WITH THERMAL CAMERA DETECTION
ESP32 + AI Agent + IoT Webpage + n8n Automation + Telegram Voice Alerts + Google Sheets + ThingSpeak
1. ABSTRACT
The proposed project is an AI-enabled autonomous fire-fighting robot designed to detect abnormal heat and fire conditions, navigate toward a detected fire, activate a fire-suppression mechanism, and continuously communicate its status to a remote operator.
The robot uses an ESP32 as its primary embedded controller. Thermal sensing, flame detection, temperature monitoring, smoke/gas sensing, obstacle detection, motor control and a water-pump mechanism are integrated into the robotic platform.
A thermal camera is used to identify high-temperature regions. Additional sensors can be used to improve fire confirmation and reduce false detections. When the local controller identifies a high-confidence fire condition, the robot can enter an autonomous fire-response state.
The IoT layer connects the robot to an n8n automation workflow. n8n acts as the orchestration layer between the ESP32, AI agent, Telegram, Google Sheets and ThingSpeak.
The AI agent receives structured sensor information and interprets the event. Based on the event severity, n8n can automatically generate notifications, record the incident, update the IoT dashboard and send a Telegram voice alert.
The system therefore combines robotics, embedded systems, thermal sensing, artificial intelligence, IoT, cloud automation and real-time communication into one integrated platform.
The overall operating principle is:
DETECT → CONFIRM → ANALYZE → ALERT → NAVIGATE → SUPPRESS → MONITOR → VERIFY → LOG
2. PROJECT TITLE
AI Autonomous Fire Fighting Robot with Thermal Camera Detection and Agentic IoT Automation
Supporting Technologies
- ESP32
- Thermal camera
- Flame sensor
- Temperature sensor
- Smoke/gas sensor
- Ultrasonic/ToF obstacle sensors
- DC motors
- Motor driver
- Water pump
- Servo-controlled nozzle
- Wi-Fi
- IoT webpage
- n8n
- AI Agent
- Telegram
- Google Sheets
- ThingSpeak
3. PROBLEM STATEMENT
Fire incidents can develop rapidly and may expose humans to dangerous temperatures, smoke and toxic gases.
Traditional fire-fighting methods require humans or specialized equipment to enter or approach hazardous areas. A small autonomous robotic platform can provide an additional layer of remote sensing and response.
The main challenge is to create a robotic system capable of:
- Detecting abnormal heat.
- Determining whether the heat is likely to represent a fire.
- Determining the approximate direction of the fire.
- Navigating toward the detected source.
- Maintaining an appropriate safety distance.
- Activating a suppression mechanism.
- Monitoring whether the fire condition is decreasing.
- Informing a remote operator.
- Recording the complete incident automatically.
- Providing a web-based IoT monitoring interface.
4. OBJECTIVES
Primary Objectives
- Develop an autonomous fire-detection robot.
- Detect high-temperature regions using thermal sensing.
- Combine multiple sensors for more reliable fire detection.
- Navigate toward a detected fire.
- Activate a water-pump-based suppression system.
- Monitor fire conditions continuously.
- Send real-time alerts through Telegram.
- Generate Telegram voice notifications.
- Record events in Google Sheets.
- Send telemetry to ThingSpeak.
- Develop an IoT web dashboard.
- Integrate an AI agent through n8n.
- Provide remote monitoring and manual override.
Secondary Objectives
- Monitor battery status.
- Detect obstacles.
- Detect communication failure.
- Provide emergency-stop functionality.
- Maintain an incident history.
- Generate AI-generated incident summaries.
- Provide future support for computer vision and advanced navigation.
5. SYSTEM REQUIREMENTS
Hardware Requirements
Controller
- ESP32 development board
Fire Detection
- Thermal camera/thermal sensor
- Flame sensor
- Temperature sensor
- Optional smoke/gas sensor
- Optional RGB camera
Navigation
- Ultrasonic sensors or ToF sensors
- Optional wheel encoders
- Optional IMU
- Optional LiDAR
Robot
- Robot chassis
- DC geared motors
- Wheels
- Motor driver
- Battery
- Power regulators
Suppression
- DC water pump
- Water tank
- Pipe
- Spray nozzle
- Relay/MOSFET
- Optional servo motor for nozzle direction
Safety
- Emergency stop
- Buzzer
- LEDs
- Fuse
- Battery monitoring
6. SOFTWARE REQUIREMENTS
- Arduino IDE or PlatformIO
- ESP32 Arduino framework
- C/C++
- HTML
- CSS
- JavaScript
- REST/HTTP or MQTT
- n8n
- AI model/API
- Telegram Bot
- Google Sheets
- ThingSpeak
- Web browser
7. HIGH-LEVEL SYSTEM ARCHITECTURE
┌───────────────────────┐
│ THERMAL CAMERA │
└───────────┬───────────┘
│
┌───────────▼───────────┐
│ FLAME / TEMP / SMOKE │
│ SENSORS │
└───────────┬───────────┘
│
▼
┌────────────────────────┐
│ ESP32 │
│ │
│ Sensor Processing │
│ Fire Detection │
│ Motor Control │
│ Pump Control │
│ Wi-Fi Communication │
└───────┬────────┬───────┘
│ │
Local│ │Wi-Fi
Logic│ │
▼ ▼
┌──────────┐ ┌──────────────┐
│ Motors │ │ IoT / n8n │
│ Pump │ │ Web Services │
└──────────┘ └──────┬───────┘
│
┌───────────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌───────────┐ ┌───────────┐
│AI Agent │ │ Telegram │ │ ThingSpeak│
└────┬────┘ └───────────┘ └───────────┘
│
▼
┌───────────────┐
│ Google Sheets │
└───────────────┘
8. COMPLETE DATA FLOW
THERMAL CAMERA
│
▼
THERMAL DATA
│
▼
ESP32 SENSOR PROCESSING
│
├──────────────► Obstacle Detection
│
├──────────────► Flame Detection
│
├──────────────► Temperature Detection
│
└──────────────► Smoke/Gas Detection
│
▼
FIRE CONFIDENCE
│
┌──────────┴──────────┐
│ │
LOW VALUE HIGH VALUE
│ │
▼ ▼
NORMAL FIRE EVENT
│
▼
n8n WEBHOOK
│
▼
AI AGENT
│
▼
EVENT SEVERITY
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
│
▼
Voice Alert
9. ROBOT PHYSICAL BLOCK DIAGRAM
FRONT OF ROBOT
┌──────────────────────┐
│ Thermal Camera │
│ Flame Sensor │
│ Ultrasonic Sensor │
└──────────────────────┘
│
┌──────────▼───────────┐
│ │
│ WATER NOZZLE │
│ │ │
│ ▼ │
│ WATER JET │
│ │
│ ┌──────┐ ┌──────┐ │
│ │Motor │ │Motor │ │
│ │Left │ │Right │ │
│ └──────┘ └──────┘ │
│ │
│ WATER TANK │
│ │
│ PUMP │
│ │
│ ESP32 │
│ │
│ BATTERY PACK │
└──────────────────────┘
10. ELECTRICAL SYSTEM ARCHITECTURE
The electrical system should be separated into logical power domains.
BATTERY
│
┌─────────┴─────────┐
│ │
▼ ▼
MOTOR POWER DC/DC REGULATOR
│ │
▼ ▼
MOTOR DRIVER 5V/3.3V
│ │
▼ ▼
DC MOTORS ESP32
│
┌──────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Sensors Servo Relay/
MOSFET Driver
│
▼
Pump
A suitable fuse and protection system should be installed between the battery and high-current loads.
11. EXAMPLE ESP32 PIN PLAN
The following is an example pin allocation. Actual pins must be adjusted according to the selected ESP32 board and the interfaces required by the chosen thermal camera.
ESP32 GPIO Function
--------------------------------
GPIO 21 I2C SDA
GPIO 22 I2C SCL
GPIO 34 Flame Sensor
GPIO 35 Temperature/Analog Sensor
GPIO 32 Smoke/Gas Sensor
GPIO 25 Motor Driver IN1
GPIO 26 Motor Driver IN2
GPIO 27 Motor Driver IN3
GPIO 14 Motor Driver IN4
GPIO 33 Pump Control
GPIO 13 Nozzle Servo
GPIO 18 Ultrasonic TRIG
GPIO 19 Ultrasonic ECHO
GPIO 2 Status LED
GPIO 4 Buzzer
GPIO selection must be checked against the exact ESP32 board and peripherals before building.
12. POWER SUPPLY DESIGN
The battery must be selected according to:
- Motor voltage
- Pump voltage
- Maximum motor current
- Pump current
- ESP32 current
- Sensor current
- Servo current
- Expected operating time
Do not power the pump or motors directly from an ESP32 GPIO.
The ESP32 GPIO should control a suitable driver.
ESP32 GPIO
│
▼
MOSFET / Relay Driver
│
▼
Pump Power Supply
│
▼
Water Pump
The motor driver should similarly isolate the ESP32 logic from the high-current motor supply.
13. FIRE DETECTION ALGORITHM
The fire detection system should use sensor fusion.
Example inputs:
T = Temperature
F = Flame sensor
S = Smoke level
H = Thermal hotspot
R = Temperature rise rate
An illustrative fire-confidence model can be:
FireConfidence =
0.35 × ThermalScore
+ 0.25 × FlameScore
+ 0.20 × TemperatureScore
+ 0.10 × SmokeScore
+ 0.10 × TrendScore
The exact weights should be calibrated experimentally.
Example classification:
0–30% NORMAL
30–60% SUSPICIOUS
60–80% POSSIBLE FIRE
80–100% HIGH-CONFIDENCE FIRE
These values are project parameters, not certified fire-detection thresholds.
14. THERMAL DETECTION PROCESS
Start
│
▼
Read Thermal Frame
│
▼
Find Maximum Temperature
│
▼
Find Hot Region
│
▼
Is Temperature Abnormally High?
│
┌┴───────────────┐
NO YES
│ │
▼ ▼
Normal Check Flame Sensor
│
▼
Check Smoke
│
▼
Calculate Confidence
│
┌───────┴────────┐
│ │
LOW HIGH
│ │
▼ ▼
Monitor Fire Event
15. THERMAL DIRECTION FINDING
The thermal sensor can divide the field of view into regions.
┌──────────────────────────────────────┐
│ THERMAL IMAGE │
│ │
│ LEFT CENTER RIGHT │
│ │
│ 45°C 78°C 51°C │
│ │
└──────────────────────────────────────┘
The robot identifies the region containing the strongest reliable heat source.
LEFT = 45°C
CENTER = 78°C
RIGHT = 51°C
Maximum = CENTER
Robot action = MOVE FORWARD
If the left side is hottest:
LEFT > CENTER > RIGHT
Robot action = TURN LEFT
If the right side is hottest:
RIGHT > CENTER > LEFT
Robot action = TURN RIGHT
16. OBSTACLE AVOIDANCE
Obstacle detection must operate independently of fire detection.
FIRE
↑
│
┌───────────────┐
│ ROBOT │
└───────────────┘
│
Obstacle?
/ \
YES NO
│ │
▼ ▼
Stop/Turn Continue
Example behavior:
Distance > 50 cm
↓
Move normally
Distance 20–50 cm
↓
Slow down
Distance < 20 cm
↓
Stop
↓
Choose alternate direction
The values should be calibrated to the robot chassis and sensor.
17. AUTONOMOUS NAVIGATION FLOW
START
│
▼
Initialize Sensors
│
▼
Check Battery
│
▼
Check Emergency Stop
│
▼
Scan Environment
│
▼
Fire Detected?
┌┴───────────────┐
NO YES
│ │
▼ ▼
Patrol Determine Fire
Direction
│
▼
Check Obstacle
│
┌─────┴─────┐
YES NO
│ │
▼ ▼
Avoid Move
obstacle toward heat
│
▼
Safe distance?
┌──────┴──────┐
NO YES
│ │
▼ ▼
Continue Stop motors
│
▼
Start pump
│
▼
Monitor temperature
│
▼
Fire decreasing?
/ \
YES NO
│ │
▼ ▼
Continue Reposition/
monitoring reassess
18. FIRE SUPPRESSION CONTROL
The suppression sequence should include a maximum pump runtime.
FIRE CONFIRMED
│
▼
STOP ROBOT
│
▼
POSITION NOZZLE
│
▼
PUMP ON
│
▼
MONITOR THERMAL DATA
│
▼
TEMPERATURE FALLING?
/ \
YES NO
│ │
▼ ▼
Continue Reassess
monitor direction
│
▼
Fire cleared?
│
▼
PUMP OFF
The prototype should use a safe, controlled test environment.
19. ROBOT STATE MACHINE
A state machine makes the firmware easier to understand and debug.
┌───────────┐
│ IDLE │
└─────┬─────┘
│
▼
┌───────────┐
│ PATROL │
└─────┬─────┘
│
Fire detected
│
▼
┌───────────┐
│ VERIFY │
└─────┬─────┘
│
Confirmed
│
▼
┌───────────┐
│ NAVIGATE │
└─────┬─────┘
│
Safe distance
│
▼
┌───────────┐
│ SUPPRESS │
└─────┬─────┘
│
Fire cleared
│
▼
┌───────────┐
│ REPORT │
└─────┬─────┘
│
▼
PATROL
Emergency state:
ANY STATE
│
Emergency Stop
▼
┌──────────────┐
│ EMERGENCY │
│ STOP │
└──────────────┘
20. ESP32 FIRMWARE ARCHITECTURE
The firmware can be divided into modules:
main.cpp
│
├── sensors.cpp
├── motors.cpp
├── pump.cpp
├── thermal.cpp
├── navigation.cpp
├── wifi.cpp
├── telemetry.cpp
└── safety.cpp
Logical architecture:
MAIN LOOP
│
┌────────────┼────────────┐
▼ ▼ ▼
Sensors Safety Network
│ │ │
▼ ▼ ▼
Fire Detection E-Stop Telemetry
│
▼
State Machine
│
┌─────┼──────┐
▼ ▼ ▼
Motor Pump Alert
21. ESP32 COMMUNICATION
The ESP32 can communicate with n8n using an HTTP POST request.
Example:
ESP32
│
│ HTTP POST
▼
n8n Webhook
Example payload:
{
"robot_id": "FIREBOT-01",
"temperature": 78.4,
"thermal_max": 81.2,
"fire_confidence": 0.94,
"flame": true,
"smoke": 0.72,
"battery": 82,
"pump": true,
"state": "SUPPRESS"
}
22. n8n ARCHITECTURE
The n8n workflow can be designed as:
┌──────────────────────┐
│ Webhook Trigger │
│ ESP32 telemetry │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Validate JSON │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Code / Set Node │
│ Calculate severity │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ AI Agent │
│ Interpret event │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ IF / Switch │
│ Event severity │
└──────┬─────────┬─────┘
│ │
▼ ▼
NORMAL FIRE
│ │
│ ├────────► Telegram
│ │
│ ├────────► Voice Alert
│ │
│ ├────────► Google Sheets
│ │
│ └────────► ThingSpeak
│
└──────────────► Normal Log
23. n8n STEP-BY-STEP WORKFLOW
Node 1 — Webhook
Create a POST webhook.
Example:
POST /firebot
The ESP32 sends sensor telemetry to this endpoint.
Node 2 — Data Validation
Verify:
- robot_id exists
- temperature is numeric
- battery is numeric
- fire confidence is within valid range
- state is valid
Invalid data should be rejected or logged.
Node 3 — Severity Calculation
Example logic:
IF fire_confidence >= 0.80
severity = CRITICAL
ELSE IF fire_confidence >= 0.60
severity = HIGH
ELSE IF fire_confidence >= 0.30
severity = WARNING
ELSE
severity = NORMAL
24. AI AGENT
The AI agent receives structured information such as:
{
"temperature": 81.3,
"fire_confidence": 0.94,
"flame_detected": true,
"smoke_level": 0.76,
"battery": 72,
"robot_state": "SUPPRESS"
}
The agent can produce structured output such as:
{
"severity": "CRITICAL",
"event": "FIRE_DETECTED",
"summary": "High-confidence fire event detected.",
"operator_message": "Fire suppression is active.",
"requires_notification": true
}
The AI should not be allowed to bypass local hardware safety constraints.
25. AI AGENT DECISION FLOW
Sensor Data
│
▼
Data Validation
│
▼
AI Agent
│
├──► Identify Event
│
├──► Determine Severity
│
├──► Generate Explanation
│
├──► Generate Notification
│
└──► Recommend Next Action
│
▼
n8n
│
┌────────┼─────────┐
▼ ▼ ▼
Telegram Sheets ThingSpeak
26. TELEGRAM ALERT SYSTEM
The Telegram bot receives notifications from n8n.
Example text notification:
🔥 FIRE DETECTED
Robot: FIREBOT-01
Temperature: 81.3°C
Thermal Maximum: 86.1°C
Fire Confidence: 94%
Flame: DETECTED
Smoke: HIGH
Battery: 72%
Pump: ON
State: FIRE SUPPRESSION
27. TELEGRAM VOICE ALERT
The workflow can generate a voice-friendly message:
Warning. Fire detected by FireBot One.
The measured temperature is 81 degrees Celsius.
Fire confidence is 94 percent.
The suppression system is active.
The text can be passed through a text-to-speech service and the resulting audio can be sent to Telegram.
28. GOOGLE SHEETS DATABASE
Suggested columns:
Timestamp
Robot ID
Temperature
Thermal Maximum
Fire Confidence
Flame Status
Smoke Level
Battery
Robot State
Pump State
Severity
AI Summary
Alert Sent
Example:
2026-08-16 16:00
FIREBOT-01
81.3
86.1
0.94
TRUE
0.76
72
SUPPRESS
TRUE
CRITICAL
High confidence fire
TRUE
29. THINGSPEAK
ThingSpeak can store time-series values.
Suggested fields:
Field 1 = Temperature
Field 2 = Thermal Maximum
Field 3 = Fire Confidence
Field 4 = Smoke
Field 5 = Battery
Field 6 = Pump
Field 7 = Robot State
The dashboard can show:
Temperature vs Time
Fire Confidence vs Time
Battery vs Time
Pump Activity
30. IOT WEB DASHBOARD
The web dashboard should provide:
┌─────────────────────────────────────────────┐
│ FIREBOT AI CONTROL CENTER │
├─────────────────────────────────────────────┤
│ │
│ ROBOT STATUS 🟢 ONLINE │
│ BATTERY 82% │
│ │
│ FIRE STATUS 🔥 DETECTED │
│ FIRE CONFIDENCE 94% │
│ TEMPERATURE 81.3°C │
│ │
│ PUMP ON │
│ ROBOT STATE SUPPRESS │
│ │
│ [ START ] [ STOP ] [ AUTO ] [ MANUAL ] │
│ │
│ Temperature History │
│ Fire Confidence History │
│ │
└─────────────────────────────────────────────┘
31. WEB DASHBOARD DATA FLOW
ESP32
│
▼
Backend/API/n8n
│
├────────► Web Dashboard
│
├────────► ThingSpeak
│
├────────► Google Sheets
│
└────────► Telegram
The browser should not expose sensitive credentials such as bot tokens or private API keys.
32. MANUAL CONTROL
The dashboard can provide:
FORWARD
BACKWARD
LEFT
RIGHT
STOP
PUMP ON
PUMP OFF
AUTO
MANUAL
EMERGENCY STOP
A recommended hierarchy is:
Emergency Stop
↓
Safety System
↓
Local ESP32 Logic
↓
Remote Manual Commands
↓
AI Recommendations
This prevents a cloud service from overriding a local emergency stop.
33. SYSTEM OPERATING MODES
IDLE
Robot is powered but not moving.
PATROL
Robot scans its surroundings.
FIRE VERIFY
Possible fire detected; system confirms sensor readings.
NAVIGATE
Robot moves toward the heat source.
SUPPRESS
Pump is activated.
MONITOR
Temperature is continuously monitored.
FIRE CLEARED
Temperature and fire confidence have returned to safe values.
EMERGENCY STOP
All movement and suppression outputs are placed into the safe state.
34. COMPLETE END-TO-END FLOW
START
│
▼
POWER ON ROBOT
│
▼
ESP32 INITIALIZE
│
▼
CONNECT TO WI-FI
│
▼
CHECK SAFETY SYSTEM
│
▼
START PATROL
│
▼
READ THERMAL DATA
│
▼
READ OTHER SENSORS
│
▼
CALCULATE CONFIDENCE
│
┌────────┴────────┐
│ │
NORMAL FIRE
│ │
▼ ▼
PATROL VERIFY FIRE
│
▼
SEND EVENT TO n8n
│
▼
AI AGENT
│
▼
CLASSIFY EVENT
│
┌──────────────┼─────────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
│
▼
Voice Alert
│
▼
NAVIGATION MODE
│
▼
AVOID OBSTACLE
│
▼
APPROACH FIRE
│
▼
SAFE DISTANCE
│
▼
STOP MOTORS
│
▼
PUMP ON
│
▼
MONITOR THERMAL DATA
│
┌────────┴────────┐
│ │
DECREASING NOT DECREASING
│ │
▼ ▼
CONTINUE REASSESS
│
▼
FIRE CLEAR
│
▼
PUMP OFF
│
▼
SEND FINAL REPORT
│
▼
PATROL
35. ESP32 SAMPLE FIRMWARE
The following is a starting prototype illustrating Wi-Fi connectivity, sensor monitoring, motor control, pump control and HTTP telemetry.
#include <WiFi.h>
#include <HTTPClient.h>
const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASSWORD = "YOUR_PASSWORD";
const char* WEBHOOK_URL =
"https://YOUR_N8N_HOST/webhook/firebot";
#define FLAME_PIN 34
#define TEMP_PIN 35
#define SMOKE_PIN 32
#define MOTOR_IN1 25
#define MOTOR_IN2 26
#define MOTOR_IN3 27
#define MOTOR_IN4 14
#define PUMP_PIN 33
float temperature = 0.0;
float fireConfidence = 0.0;
bool flameDetected = false;
bool pumpState = false;
String robotState = "PATROL";
void stopMotors() {
digitalWrite(MOTOR_IN1, LOW);
digitalWrite(MOTOR_IN2, LOW);
digitalWrite(MOTOR_IN3, LOW);
digitalWrite(MOTOR_IN4, LOW);
}
void moveForward() {
digitalWrite(MOTOR_IN1, HIGH);
digitalWrite(MOTOR_IN2, LOW);
digitalWrite(MOTOR_IN3, HIGH);
digitalWrite(MOTOR_IN4, LOW);
}
void turnLeft() {
digitalWrite(MOTOR_IN1, LOW);
digitalWrite(MOTOR_IN2, HIGH);
digitalWrite(MOTOR_IN3, HIGH);
digitalWrite(MOTOR_IN4, LOW);
}
void turnRight() {
digitalWrite(MOTOR_IN1, HIGH);
digitalWrite(MOTOR_IN2, LOW);
digitalWrite(MOTOR_IN3, LOW);
digitalWrite(MOTOR_IN4, HIGH);
}
void pumpOn() {
digitalWrite(PUMP_PIN, HIGH);
pumpState = true;
}
void pumpOff() {
digitalWrite(PUMP_PIN, LOW);
pumpState = false;
}
float readTemperature() {
int raw = analogRead(TEMP_PIN);
// Replace with calibration formula for the selected sensor.
float voltage = raw * (3.3 / 4095.0);
return voltage * 100.0;
}
void readSensors() {
temperature = readTemperature();
int flameValue = digitalRead(FLAME_PIN);
flameDetected = (flameValue == LOW);
int smokeValue = analogRead(SMOKE_PIN);
float thermalScore = 0.0;
float flameScore = 0.0;
float smokeScore = 0.0;
float temperatureScore = 0.0;
if (temperature >= 70.0) {
temperatureScore = 1.0;
} else if (temperature >= 40.0) {
temperatureScore = 0.5;
}
if (flameDetected) {
flameScore = 1.0;
}
if (smokeValue > 2500) {
smokeScore = 1.0;
} else if (smokeValue > 1500) {
smokeScore = 0.5;
}
// Placeholder thermal score.
// Replace with actual thermal-camera processing.
if (temperature >= 80.0) {
thermalScore = 1.0;
} else if (temperature >= 50.0) {
thermalScore = 0.5;
}
fireConfidence =
0.35 * thermalScore +
0.25 * flameScore +
0.20 * temperatureScore +
0.20 * smokeScore;
}
void sendTelemetry() {
if (WiFi.status() != WL_CONNECTED) {
return;
}
HTTPClient http;
http.begin(WEBHOOK_URL);
http.addHeader("Content-Type", "application/json");
String payload = "{";
payload += "\"robot_id\":\"FIREBOT-01\",";
payload += "\"temperature\":" + String(temperature, 2) + ",";
payload += "\"fire_confidence\":" + String(fireConfidence, 3) + ",";
payload += "\"flame_detected\":" +
String(flameDetected ? "true" : "false") + ",";
payload += "\"pump\":" +
String(pumpState ? "true" : "false") + ",";
payload += "\"state\":\"" + robotState + "\"";
payload += "}";
int response = http.POST(payload);
Serial.print("n8n response: ");
Serial.println(response);
http.end();
}
void autonomousControl() {
if (fireConfidence >= 0.80) {
robotState = "FIRE_DETECTED";
stopMotors();
pumpOn();
robotState = "SUPPRESS";
} else if (fireConfidence >= 0.60) {
robotState = "VERIFY";
stopMotors();
pumpOff();
} else {
robotState = "PATROL";
pumpOff();
moveForward();
}
}
void setup() {
Serial.begin(115200);
pinMode(FLAME_PIN, INPUT);
pinMode(TEMP_PIN, INPUT);
pinMode(SMOKE_PIN, INPUT);
pinMode(MOTOR_IN1, OUTPUT);
pinMode(MOTOR_IN2, OUTPUT);
pinMode(MOTOR_IN3, OUTPUT);
pinMode(MOTOR_IN4, OUTPUT);
pinMode(PUMP_PIN, OUTPUT);
stopMotors();
pumpOff();
WiFi.begin(WIFI_SSID, WIFI_PASSWORD);
Serial.print("Connecting to Wi-Fi");
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println();
Serial.println("Wi-Fi connected");
Serial.println(WiFi.localIP());
}
void loop() {
readSensors();
autonomousControl();
sendTelemetry();
Serial.print("Temperature: ");
Serial.println(temperature);
Serial.print("Fire confidence: ");
Serial.println(fireConfidence);
Serial.print("State: ");
Serial.println(robotState);
delay(2000);
}
36. IMPORTANT ESP32 CODE NOTE
The firmware above is a functional architecture example, not a finished thermal-camera driver.
The exact thermal processing code depends on the thermal camera selected.
For a thermal array such as an MLX90640-class device, the firmware needs to:
- Initialize I2C.
- Read the thermal frame.
- Convert pixels to temperature.
- Find the maximum temperature.
- Divide the image into left/center/right regions.
- Calculate regional temperature.
- Detect a persistent hotspot.
- Send the resulting values to the fire-confidence algorithm.
37. THERMAL REGION ALGORITHM
Conceptually:
float leftMax = 0;
float centerMax = 0;
float rightMax = 0;
for each thermal pixel:
if pixel is in LEFT region:
leftMax = max(leftMax, pixelTemperature);
if pixel is in CENTER region:
centerMax = max(centerMax, pixelTemperature);
if pixel is in RIGHT region:
rightMax = max(rightMax, pixelTemperature);
Then:
leftMax > centerMax AND leftMax > rightMax
↓
TURN LEFT
centerMax > leftMax AND centerMax > rightMax
↓
MOVE FORWARD
rightMax > leftMax AND rightMax > centerMax
↓
TURN RIGHT
A persistence check should be added so that one noisy thermal pixel does not immediately cause the robot to react.
38. SAMPLE N8N LOGIC
The n8n workflow can conceptually be:
[Webhook]
|
v
[Normalize JSON]
|
v
[Calculate Severity]
|
v
[AI Agent]
|
v
[Switch]
|
+-------------------+
| |
NORMAL CRITICAL
| |
v v
[Google Sheets] [Telegram]
|
v
[Text-to-Speech]
|
v
[Telegram Voice]
|
v
[Google Sheets]
|
v
[ThingSpeak]
39. EXAMPLE SEVERITY CODE FOR n8n
A Code node can implement deterministic severity classification:
const data = $json;
const confidence = Number(data.fire_confidence || 0);
const temperature = Number(data.temperature || 0);
let severity = "NORMAL";
if (confidence >= 0.80) {
severity = "CRITICAL";
} else if (confidence >= 0.60) {
severity = "HIGH";
} else if (confidence >= 0.30) {
severity = "WARNING";
}
return [
{
json: {
...data,
severity,
timestamp: new Date().toISOString()
}
}
];
40. EXAMPLE AI AGENT PROMPT
The AI agent can be instructed along the following lines:
You are the event-analysis agent for an autonomous fire-detection robot.
Analyze the structured sensor data supplied by the robot.
Your responsibilities are:
1. Identify the current event.
2. Determine severity.
3. Explain the event briefly.
4. Generate an operator-friendly alert.
5. Recommend the appropriate monitoring state.
Never override the robot's hardware safety system.
Never disable the emergency stop.
Never invent sensor measurements.
Use only the supplied data.
Return JSON with:
event
severity
summary
operator_message
requires_notification
41. SAMPLE AI OUTPUT
{
"event": "FIRE_DETECTED",
"severity": "CRITICAL",
"summary": "Multiple sensor readings indicate a high-confidence fire event.",
"operator_message": "FireBot-01 has detected a high-confidence fire and is currently in suppression mode.",
"requires_notification": true
}
42. TELEGRAM MESSAGE GENERATION
Example n8n message:
🚨 FIREBOT CRITICAL ALERT 🚨
Robot: {{$json.robot_id}}
🔥 Fire Status: DETECTED
🌡 Temperature: {{$json.temperature}} °C
📡 Fire Confidence: {{$json.fire_confidence}}
🔥 Flame: {{$json.flame_detected}}
💧 Pump: {{$json.pump}}
🔋 Battery: {{$json.battery}}%
🤖 State: {{$json.state}}
AI Summary:
{{$json.summary}}
43. VOICE MESSAGE GENERATION
A text-to-speech stage can convert:
"Critical alert. FireBot One has detected a high-confidence fire. The temperature is 81 degrees Celsius and the suppression system is active."
into an audio file.
The audio file can then be delivered to Telegram.
44. GOOGLE SHEETS WORKFLOW
n8n
│
▼
Prepare Row
│
▼
Google Sheets
│
▼
Append Row
Recommended fields:
Timestamp
Robot ID
Temperature
Thermal Maximum
Fire Confidence
Flame
Smoke
Battery
State
Pump
Severity
AI Summary
45. THINGSPEAK WORKFLOW
ESP32/n8n
│
▼
Prepare Fields
│
▼
ThingSpeak Update
│
▼
Channel
│
├── Temperature graph
├── Fire confidence graph
├── Battery graph
└── Pump/state graph
46. DASHBOARD SECURITY
The following must not be embedded directly in frontend JavaScript:
Telegram Bot Token
Private API keys
n8n credentials
Google service credentials
Private ThingSpeak credentials
AI API keys
Instead:
Browser
│
▼
Secure Backend/API
│
▼
n8n / Cloud Services
Authentication should be added before exposing robot-control endpoints.
47. REMOTE CONTROL SECURITY
Commands such as:
MOVE_FORWARD
MOVE_BACKWARD
TURN_LEFT
TURN_RIGHT
PUMP_ON
PUMP_OFF
AUTO
MANUAL
STOP
should be validated by the ESP32.
For example:
Internet command
↓
Authentication
↓
Command validation
↓
Safety validation
↓
ESP32
↓
Execute
An invalid or unsafe command should be rejected.
48. FAIL-SAFE DESIGN
If Wi-Fi fails:
Wi-Fi lost
↓
ESP32 detects timeout
↓
Stop remote commands
↓
Continue safe local behavior
If the ESP32 crashes:
Watchdog timeout
↓
ESP32 reset
↓
Outputs initialized safely
↓
Pump OFF
Motor STOP
If emergency stop is pressed:
Emergency Stop
↓
Motor STOP
Pump OFF
↓
Robot remains disabled
49. FIRE EVENT LOGIC
A fire event should ideally require persistence.
For example:
Sample 1 → High
Sample 2 → High
Sample 3 → High
↓
CONFIRMED EVENT
This helps prevent one noisy measurement from generating an emergency alert.
Likewise, fire-clear detection can use several consecutive safe measurements.
50. FALSE POSITIVE REDUCTION
Potential false positives include:
- Sunlight
- Hot metal
- Electronics
- Motors
- Heated surfaces
- Reflections
- Sensor noise
The project should therefore combine:
Thermal data
+
Temperature trend
+
Flame detection
+
Smoke/gas information
+
Visual classification
instead of relying on a single sensor.
51. TESTING PLAN
Test 1 — ESP32
Verify:
- ESP32 boots.
- Wi-Fi connects.
- Sensors provide values.
- Outputs operate correctly.
Test 2 — Motors
Test:
- Forward
- Reverse
- Left
- Right
- Stop
Test 3 — Pump
Verify:
- Pump OFF by default.
- Pump activates only when commanded.
- Maximum runtime protection works.
Test 4 — Thermal Detection
Test several controlled heat sources.
Record:
- Maximum temperature
- Average temperature
- Detection distance
- Detection stability
Test 5 — Fire Classification
Test:
- No-fire condition
- Low-temperature condition
- High-temperature condition
- Controlled flame condition
Test 6 — Obstacle Avoidance
Place obstacles at different distances.
Verify:
- Detection
- Stop
- Turning
- Recovery
Test 7 — n8n
Send test JSON manually.
Verify:
- Webhook
- AI agent
- Telegram
- Google Sheets
- ThingSpeak
Test 8 — End-to-End
Sensor
↓
ESP32
↓
n8n
↓
AI
↓
Telegram
↓
Google Sheets
↓
ThingSpeak
52. TEST DATA TABLE
| Test | Input | Expected Result |
|---|---|---|
| Normal | Normal temperature | Patrol |
| Hot object | Elevated temperature | Warning |
| Flame | Flame + heat | Fire verification |
| Confirmed fire | Multiple sensors | Fire event |
| Obstacle | Object detected | Stop/avoid |
| Low battery | Low voltage | Safe mode |
| Wi-Fi failure | Network unavailable | Local fail-safe |
| Emergency stop | E-stop activated | Motor/pump OFF |
53. PERFORMANCE PARAMETERS
The project can measure:
Detection accuracy
Detection Accuracy =
Correct Detections / Total Test Events × 100
False-positive rate
False Positive Rate =
False Fire Events / Total Normal Events × 100
Notification latency
Notification Latency =
Alert Received Time - Fire Event Time
Response time
Response Time =
Suppression Start - Fire Confirmation
Battery endurance
Operating Time =
Robot Shutdown Time - Robot Start Time
54. PROJECT FLOWCHART
┌──────────────┐
│ START │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Initialize ESP32│
└────────┬────────┘
│
▼
┌─────────────────┐
│ Connect to Wi-Fi│
└────────┬────────┘
│
▼
┌───────────────┐
│ Read Sensors │
└───────┬───────┘
│
▼
┌───────────────┐
│ Fire detected?│
└───────┬───────┘
NO │ YES
│
┌─────────────┘
▼
PATROL
│
▼
FIRE VERIFY
│
▼
FIRE CONFIRMED
│
▼
n8n EVENT
│
▼
AI AGENT
│
▼
TELEGRAM ALERT
│
▼
NAVIGATE TO FIRE
│
▼
PUMP ON
│
▼
MONITOR FIRE
│
▼
FIRE CLEARED?
/ \
NO YES
│ │
▼ ▼
Continue Pump OFF
│
▼
Final Report
│
▼
END/
PATROL
55. COMPLETE PROJECT ARCHITECTURE
┌───────────────────────┐
│ USER │
│ Web / Telegram │
└──────────┬────────────┘
│
▼
┌───────────────────────┐
│ n8n AUTOMATION │
└──────────┬────────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌────────────┐ ┌─────────────┐ ┌────────────┐
│ AI AGENT │ │ TELEGRAM │ │ GOOGLE │
│ │ │ + VOICE │ │ SHEETS │
└────────────┘ └─────────────┘ └────────────┘
│
│
▼
┌────────────┐
│ THINGSPEAK │
└────────────┘
▲
│
TELEMETRY
│
┌─────┴─────┐
│ ESP32 │
└─────┬─────┘
│
┌────────────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
Thermal Camera Fire Sensors Navigation
│ │ │
└────────────────────────────┼────────────────────────┘
│
▼
Robot Logic
│
┌──────────┴──────────┐
▼ ▼
Motors Pump
56. PROJECT MODULES
The complete project can be divided into nine modules.
Module 1 — Fire Detection
Thermal camera + flame + temperature + smoke.
Module 2 — Robot Controller
ESP32 and state machine.
Module 3 — Navigation
Motor driver + obstacle detection.
Module 4 — Fire Suppression
Pump + nozzle + control circuit.
Module 5 — IoT Communication
Wi-Fi + HTTP/MQTT.
Module 6 — AI Agent
Event interpretation and notification generation.
Module 7 — Automation
n8n workflows.
Module 8 — Cloud Storage and Analytics
Google Sheets + ThingSpeak.
Module 9 — User Interface
IoT webpage + Telegram.
57. PROJECT DEVELOPMENT PHASES
Phase 1
Build the robot chassis.
Phase 2
Install motors and motor driver.
Phase 3
Install ESP32.
Phase 4
Test basic movement.
Phase 5
Add thermal sensing.
Phase 6
Add flame/temperature/smoke sensors.
Phase 7
Implement fire-confidence algorithm.
Phase 8
Add obstacle detection.
Phase 9
Add pump and nozzle.
Phase 10
Implement autonomous state machine.
Phase 11
Connect ESP32 to Wi-Fi.
Phase 12
Create n8n webhook.
Phase 13
Connect AI agent.
Phase 14
Connect Telegram.
Phase 15
Implement voice alerts.
Phase 16
Connect Google Sheets.
Phase 17
Connect ThingSpeak.
Phase 18
Develop IoT webpage.
Phase 19
Implement authentication and safety controls.
Phase 20
Perform controlled system testing.
58. EXPECTED OUTPUT
When the robot detects a fire, the final system should produce:
LOCAL ROBOT
────────────
Fire detected
Robot navigates
Pump activated
Thermal monitoring active
CLOUD
─────
n8n receives event
AI analyzes event
TELEGRAM
────────
🔥 Critical fire alert
🔊 Voice notification
GOOGLE SHEETS
─────────────
Incident automatically logged
THINGSPEAK
──────────
Temperature graph updated
Fire-confidence graph updated
WEB DASHBOARD
─────────────
Robot status
Temperature
Fire status
Pump
Battery
Historical data
59. PROJECT INNOVATION
The main innovation is the integration of several layers:
PHYSICAL WORLD
↓
Thermal Sensors
↓
EDGE COMPUTING
↓
ESP32
↓
IOT
↓
n8n
↓
AGENTIC AI
↓
AUTOMATION
↓
TELEGRAM
↓
VOICE NOTIFICATION
↓
CLOUD DATA
↓
GOOGLE SHEETS + THINGSPEAK
↓
WEB DASHBOARD
This turns a simple robotic vehicle into an integrated agentic IoT emergency-response platform.
60. ADVANTAGES
- Autonomous operation
- Real-time thermal detection
- Multi-sensor verification
- Remote monitoring
- Automated alerts
- Voice notifications
- Cloud data logging
- Historical analysis
- AI-based event interpretation
- IoT dashboard
- Expandable architecture
- Modular hardware/software design
61. LIMITATIONS
The prototype may have limitations including:
- Limited battery life
- Limited water capacity
- Thermal-camera resolution
- Sensor calibration requirements
- Wi-Fi dependency for cloud functions
- Difficult navigation in complex environments
- False fire detections
- Limited robot speed
- Pump pressure limitations
- Environmental effects on sensors
The autonomous robot should therefore be considered a prototype and not a replacement for certified fire-fighting systems.
62. FUTURE SCOPE
Future versions can include:
- AI computer vision.
- High-resolution thermal imaging.
- LiDAR.
- SLAM.
- GPS.
- Autonomous mapping.
- Multi-robot coordination.
- Edge AI.
- Offline AI operation.
- Advanced fire classification.
- Predictive maintenance.
- Battery-health prediction.
- Mobile application.
- Voice-command control.
- Digital twin.
- Automatic emergency reports.
- Multi-channel emergency notification.
- Integration with building-management systems.
63. FINAL SYSTEM SUMMARY
The completed system operates as follows:
1. Thermal camera scans the environment.
2. ESP32 reads thermal and environmental sensors.
3. The local controller calculates a fire-confidence value.
4. If the event is suspicious, additional sensor verification is performed.
5. If a high-confidence fire is detected, the robot enters fire-response mode.
6. The robot identifies the approximate direction of the heat source.
7. Obstacle sensors prevent unsafe movement.
8. The robot approaches the fire while maintaining a defined safety distance.
9. The robot stops and activates the suppression system.
10. Thermal data is continuously monitored.
11. ESP32 sends telemetry to the IoT backend/n8n.
12. n8n processes the event.
13. The AI agent interprets the sensor information.
14. Telegram receives an emergency text notification.
15. A voice notification can also be generated and sent.
16. The incident is stored in Google Sheets.
17. Telemetry is sent to ThingSpeak.
18. The web dashboard displays the robot's current status.
19. Once the fire condition clears, the pump is turned off.
20. A final incident report is generated.
21. The robot returns to patrol/standby mode.
64. FINAL ARCHITECTURAL FORMULA
THERMAL CAMERA
+
FLAME SENSOR
+
TEMPERATURE SENSOR
+
SMOKE SENSOR
+
OBSTACLE SENSOR
↓
ESP32
↓
LOCAL SAFETY + FIRE LOGIC
↓
ROBOT NAVIGATION + PUMP
↓
Wi-Fi
↓
n8n
↓
AI AGENT
↓
┌────┼─────────────┐
▼ ▼ ▼
TG Sheets ThingSpeak
│
▼
Voice Alert
+
IoT Web Dashboard
FINAL CONCEPT
The proposed project is therefore a complete AI-powered autonomous fire-fighting IoT robot combining:
ESP32 + Thermal Camera + Sensor Fusion + Autonomous Robotics + AI Agent + n8n + Telegram + Voice Alerts + Google Sheets + ThingSpeak + IoT Web Dashboard.
The core engineering principle is:
Local ESP32 safety and control → Cloud automation → AI interpretation → Human notification → Data logging → Continuous monitoring.
This architecture provides a strong foundation for a final-year engineering project, prototype demonstration, research project, or advanced IoT/robotics implementation.
Recommended project build order
Don't try to build everything simultaneously. Build it in this order:
Stage 1: ESP32 → motor driver → motors → basic movement
Stage 2: ESP32 → flame/temperature/obstacle sensors
Stage 3: thermal camera → hotspot detection
Stage 4: sensor fusion → fire-confidence algorithm
Stage 5: autonomous navigation
Stage 6: pump + nozzle + safety interlocks
Stage 7: ESP32 → n8n webhook
Stage 8: n8n → Telegram
Stage 9: n8n → Google Sheets
Stage 10: n8n → ThingSpeak
Stage 11: n8n → AI agent
Stage 12: IoT webpage
Stage 13: authentication + emergency-stop + fail-safe testing
Stage 14: complete controlled demonstration
Most important hardware point
The thermal camera cannot be treated as a normal analog temperature sensor. The actual firmware depends heavily on the exact thermal camera you select. For example, a thermal array requires frame acquisition and pixel-by-pixel temperature processing.
So the next implementation step should be to lock down the exact hardware.
If you're building this as an actual prototype, I recommend an architecture around ESP32 + MLX90640 thermal array + ultrasonic/ToF sensors + motor driver + DC pump + servo nozzle, with n8n handling the cloud/AI automation. Then the thermal-camera code, complete ESP32 firmware, wiring schematic, n8n workflow JSON, Google Sheets configuration, ThingSpeak setup and dashboard can all be made consistent with the actual hardware.

No comments:
Post a Comment