Yes . I can structure this as a complete final-year/major IoT project documentation package covering the ESP32 robot, AI object detection, web control, n8n agentic automation, Telegram voice alerts, Google Sheets, ThingSpeak, schematics, flowcharts, and source code.
Proposed project architecture
┌──────────────────────────┐
│ WEB PAGE │
│ Live video + Robot Ctrl │
│ Sensors + AI detections │
└────────────┬─────────────┘
│ Wi-Fi / HTTP
▼
┌──────────────┐ ┌──────────────────┐
│ ESP32-CAM / │◄────────────►│ Wi-Fi / Internet │
│ ESP32 Robot │ └────────┬─────────┘
│ │ │
│ Motors │ │
│ Servo │ ▼
│ Sensors │ ┌──────────────────┐
│ Camera │ │ n8n │
└──────┬───────┘ │ Automation/Agent│
│ └────────┬─────────┘
│ │
│ ┌──────────┼──────────┐
│ ▼ ▼ ▼
│ Telegram Google ThingSpeak
│ Bot/Voice Sheets Cloud
│ │ │ │
│ ▼ ▼ ▼
│ Alerts Logs Dashboard
│
▼
┌──────────────────────────────────────────────────┐
│ AI OBJECT DETECTION │
│ Person / Vehicle / Animal / Object / Intruder │
└──────────────────────────────────────────────────┘
Documentation chapters
I would document it in this order:
-
Project title and abstract
-
Introduction
-
Problem statement
-
Objectives
-
Existing system
-
Proposed system
-
Applications
-
System requirements
-
ESP32/ESP32-CAM
-
Motor driver
-
DC motors
-
Servo
-
Ultrasonic/IR sensors
-
Battery
-
Computer/server for AI inference
-
Wi-Fi
-
-
Hardware architecture
-
Complete circuit/schematic
-
ESP32 pin configuration
-
Robot chassis and motor wiring
-
Camera/video streaming
-
Web-based robot controller
-
Real-time AI object detection
-
ESP32 ↔ web server communication
-
n8n workflow architecture
-
AI-agent decision workflow
-
Telegram bot integration
-
Telegram voice notification generation
-
Google Sheets data logging
-
ThingSpeak cloud dashboard
-
End-to-end data flow
-
Security and authentication
-
Complete ESP32 firmware
-
Web HTML/CSS/JavaScript
-
AI detection code
-
n8n workflow configuration
-
Telegram integration code/configuration
-
Google Sheets integration
-
ThingSpeak integration
-
Testing procedure
-
Test cases and expected results
-
Troubleshooting
-
Advantages and limitations
-
Future enhancements
-
Conclusion
-
Bill of materials
-
Project folder structure
-
Viva/interview questions and answers
End-to-end operation
For example, when the camera detects a person:
Camera
↓
Video frame
↓
AI Object Detection
↓
"PERSON DETECTED"
↓
ESP32 / Web Application
↓
n8n Webhook
↓
AI Agent
↓
Check event + confidence + sensor data
↓
┌───────────────┬───────────────┬────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
Telegram Google Sheets ThingSpeak Robot action
alert event log telemetry if required
│
▼
Text-to-Speech
│
▼
Telegram Voice Alert
A Telegram notification could conceptually be:
🤖 SPY ROBOT ALERT
Object: Person
Confidence: 94%
Location: Zone A
Time: 10:42:18
Distance: 2.1 m
AI Agent Action:
Person detected — monitoring activated.
The project can also support commands such as:
USER → Telegram Bot
"Move forward"
↓
Telegram
↓
n8n
↓
AI Agent / Command Parser
↓
ESP32 API
↓
Motor Driver
↓
Robot moves forward
Recommended software structure
AI-ESP32-SPY-ROBOT/
│
├── esp32/
│ ├── robot_controller.ino
│ ├── camera_server.ino
│ ├── motor_control.h
│ ├── sensors.h
│ └── config.h
│
├── web/
│ ├── index.html
│ ├── style.css
│ └── app.js
│
├── ai/
│ ├── detector.py
│ ├── camera.py
│ └── requirements.txt
│
├── n8n/
│ └── robot_agent_workflow.json
│
├── telegram/
│ └── bot_config.md
│
├── cloud/
│ ├── google_sheets.md
│ └── thingspeak.md
│
├── hardware/
│ ├── circuit_diagram
│ ├── pin_configuration.md
│ └── BOM.md
│
└── documentation/
└── project_report.md
Important design choice: for a practical ESP32 implementation, I would separate robot control/IoT from computationally heavier real-time object detection where necessary. The ESP32 can handle camera capture, motors, sensors and networking, while a PC/Raspberry Pi/edge AI device can perform models such as YOLO; the resulting detection events are sent to n8n. This avoids pretending that a normal ESP32 can comfortably run a large object-detection model.
If you want, I can next produce the complete documentation as a single project report, including the actual ESP32 Arduino code, HTML/JavaScript web controller, Python AI detection code, n8n workflow JSON, Telegram integration, Google Sheets/ThingSpeak configuration, detailed circuit/pin diagram, flowcharts, and testing tables.
Absolutely. I ’ll use exactly this chapter structure and turn it into a formal, detailed project document. The code and circuit will be designed as one coherent system rather than disconnected examples.
Complete Project Documentation Structure
1. Project Title and Abstract
Project Title:
AI Web-Controlled Spy Robot with Real-Time Object Detection, Agentic IoT Automation, Telegram Voice Alerts, Google Sheets Logging and ThingSpeak Cloud Dashboard using ESP32 and n8n
Abstract
This project presents an IoT-enabled mobile surveillance robot based on the ESP32/ESP32-CAM platform. The robot combines wireless web-based control, live camera streaming, sensor monitoring, artificial-int elligence-based object detection, cloud data logging, and automated notifications.
The robot can be remotely controlled through a web interface while its camera provides live visual information. An AI detection module analyzes camera frames and identifies predefined objects such as people, vehicles, animals, or other relevant objects. Detection events are transmitted to an automation layer based on n8n.
The n8n workflow acts as the central automation and agentic-IoT layer. Depending on the incoming event, sensor information, detection confidence, and configured rules, the workflow can record information in Google Sheets, update a ThingSpeak dashboard, and send notifications through Telegram. Telegram can additionally be used to provide voice-based alerts and receive commands.
The proposed system demonstrates how low-cost embedded hardware, computer vision, cloud services, workflow automation, and conversational interfaces can be integrated into a single IoT platform.
2. Introduction
The rapid development of IoT, embedded systems, computer vision, and AI has made it possible to build intelligent robotic systems using relatively inexpensive hardware.
Traditional remotely controlled robots generally provide only basic movement:
User → Remote Control → Robot
An intelligent IoT robot can extend this architecture:
User
↓
Web / Telegram
↓
Internet
↓
n8n Automation
↓
ESP32 Robot
↓
Camera + Sensors
↓
AI Analysis
↓
Automation
↓
Alerts + Cloud Logging
The proposed robot therefore does not simply respond to movement commands. It can also collect information, identify objects, generate events, communicate with external services, and perform predefined automated actions.
3. Problem Statement
Conventional surveillance robots have several limitations:
-
They often require dedicated remote controllers.
-
Camera monitoring and robot control may be separate systems.
-
Sensor information may not be stored systematically.
-
Notifications may require continuous human monitoring.
-
Traditional robots generally do not understand detected objects.
-
IoT data may not be integrated with automation workflows.
-
There may be no centralized event history.
-
Users may have limited remote access.
The proposed system addresses these limitations by integrating:
Robot
+
Camera
+
Sensors
+
AI
+
Web Control
+
n8n
+
Telegram
+
Google Sheets
+
ThingSpeak
4. Objectives
The primary objectives are:
-
Develop a Wi-Fi-controlled mobile robot.
-
Provide browser-based robot control.
-
Provide live camera streaming.
-
Integrate object detection.
-
Detect predefined objects in real time.
-
Monitor distance/sensor information.
-
Send detection events to n8n.
-
Automate responses using n8n.
-
Send Telegram notifications.
-
Generate Telegram voice alerts.
-
Record events in Google Sheets.
-
Display telemetry using ThingSpeak.
-
Provide remote command capability.
-
Maintain an event history.
-
Create a modular platform for future AI-agent functionality.
5. Existing System
A conventional surveillance robot may have:
Camera
↓
Monitor
or:
Remote Controller
↓
Robot
A basic IoT robot may instead use:
ESP32
↓
Wi-Fi
↓
Mobile/Web App
These systems can perform their individual functions but may not provide integrated AI detection, workflow automation, cloud logging, and conversational alerts.
6. Proposed System
The proposed architecture combines all major components.
┌───────────────────┐
│ WEB CLIENT │
│ Control + Camera │
└─────────┬─────────┘
│
▼
┌─────────────┐
│ ESP32 │
│ Robot Node │
└──────┬──────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Motors Sensors Camera
│
▼
AI Detection
│
▼
n8n Webhook
│
┌───────────────────┼──────────────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
│ │ │
▼ ▼ ▼
Voice/Text Logs Dashboard
7. Applications
Potential applications include:
-
Remote surveillance
-
Industrial inspection
-
Laboratory monitoring
-
Educational robotics
-
Smart security research
-
Warehouse monitoring
-
Remote environmental observation
-
Object detection experiments
-
IoT and automation demonstrations
-
AI-agent robotics research
8. System Requirements
8.1 Hardware
| Component | Purpose |
|---|---|
| ESP32 / ESP32-CAM | Main IoT controller/camera |
| Motor driver | Drives DC motors |
| DC motors | Robot movement |
| Robot chassis | Mechanical platform |
| Servo motor | Camera/sensor positioning |
| Ultrasonic sensor | Distance measurement |
| IR sensors | Obstacle detection |
| Battery | Power supply |
| Voltage regulator | Stable power |
| Camera | Video capture |
| LEDs/buzzer | Local status indication |
8.2 Software
Arduino IDE
ESP32 Arduino Core
HTML
CSS
JavaScript
Python
Computer Vision / Object Detection Model
n8n
Telegram Bot
Google Sheets
ThingSpeak
Web browser
9. ESP32 / ESP32-CAM
The ESP32 provides:
-
Wi-Fi connectivity
-
GPIO
-
PWM
-
UART
-
I²C
-
SPI
-
ADC
-
low-cost embedded processing
An ESP32-CAM variant can additionally provide camera functionality.
A practical architecture is:
ESP32
├── Motor control
├── Sensor acquisition
├── Wi-Fi
├── Web/API communication
└── Robot state
ESP32-CAM / Camera
└── Image acquisition
AI Computer/Raspberry Pi
└── Object detection
For heavier computer-vision models, the AI inference should normally be performed on a computer, Raspberry Pi-class edge device, or another suitable accelerator rather than assuming a conventional ESP32 can run a full-size object detector efficiently.
10. Motor Driver
The ESP32 GPIO pins should not directly drive DC motors.
The architecture is:
ESP32 GPIO
│
▼
Motor Driver
│
├──── Motor A
│
└──── Motor B
A suitable H-bridge motor driver can provide:
-
Forward
-
Reverse
-
Stop
-
Speed control using PWM
11. DC Motors
A two-wheel differential-drive configuration can be used.
FRONT
┌─────────────────┐
│ │
│ CAMERA │
│ ▲ │
│ │
M1 │ │ M2
LEFT │ │ RIGHT
│ │
└───────┬─────────┘
│
CASTER
Movement:
| Command | Left motor | Right motor |
|---|---|---|
| Forward | Forward | Forward |
| Reverse | Reverse | Reverse |
| Left | Reverse/Stop | Forward |
| Right | Forward | Reverse/Stop |
| Stop | Stop | Stop |
12. Servo
The servo can rotate:
-
Camera
-
Ultrasonic sensor
-
Sensor mount
For example:
Camera
│
▼
┌────────┐
│ Servo │
└────────┘
← 180° →
This allows the robot to scan different directions.
13. Ultrasonic / IR Sensors
An ultrasonic sensor can provide distance information.
Conceptually:
ESP32
│
├── TRIG ───────► Sensor
│
└── ECHO ◄────── Sensor
Distance can be estimated from the measured echo time.
IR sensors can provide additional close-range obstacle detection.
A combined system is more useful:
Camera
│
▼
AI Detection
Left IR ──┐
Front US ─┼──► ESP32 ──► n8n
Right IR ─┘
14. Battery
A separate power design should be used for:
Battery
├── Motor power
└── Regulated electronics power
Motors can generate electrical noise and voltage drops, so appropriate regulation, grounding, decoupling, and protection are important.
15. Computer / Server for AI Inference
The AI inference computer receives camera frames:
ESP32-CAM
│
│ JPEG/video
▼
AI Server
│
▼
Object Detection Model
│
▼
Detection JSON
Example:
{
"object": "person",
"confidence": 0.94,
"timestamp": "2026-10-03T10:42:18",
"camera": "robot-01"
}
16. Wi-Fi
The ESP32 connects to the local wireless network.
Internet
│
Wi-Fi Router
/ \
/ \
ESP32 Robot AI Server
│
└──────── n8n
The system can operate locally, remotely, or in a hybrid architecture depending on how the server and n8n instance are deployed.
17. Hardware Architecture
┌───────────────┐
│ Battery │
└───────┬───────┘
│
┌────────▼────────┐
│ Power Regulation│
└───────┬─────────┘
│
┌───────────────┴────────────────┐
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ ESP32 │ │ Motor Driver│
└──────┬──────┘ └──────┬──────┘
│ │
┌──────┼──────────┐ ┌───┴───┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
Camera Sensors Servo M1 M2
18. Complete Circuit / Schematic
A generic connection architecture:
+----------------+
| ESP32 |
| |
| GPIO ──────────┼──── Motor Driver IN1
| GPIO ──────────┼──── Motor Driver IN2
| GPIO ──────────┼──── Motor Driver IN3
| GPIO ──────────┼──── Motor Driver IN4
| GPIO ──────────┼──── Ultrasonic TRIG
| GPIO ◄─────────┼──── Ultrasonic ECHO
| GPIO ──────────┼──── Servo PWM
| |
| Wi-Fi |
+-------┬--------+
│
│
Network
│
┌───────────────────┼─────────────────┐
▼ ▼ ▼
Browser n8n AI Server
Important: exact GPIO numbers depend on the specific ESP32/ESP32-CAM board. They should be selected after accounting for camera pins, boot-strapping pins, flash/PSRAM usage, and available GPIOs rather than blindly assigning pins.
19. ESP32 Pin Configuration
The final report will contain a table like:
| ESP32 GPIO | Function | Direction |
|---|---|---|
| GPIO xx | Motor IN1 | Output |
| GPIO xx | Motor IN2 | Output |
| GPIO xx | Motor IN3 | Output |
| GPIO xx | Motor IN4 | Output |
| GPIO xx | Ultrasonic TRIG | Output |
| GPIO xx | Ultrasonic ECHO | Input |
| GPIO xx | Servo | PWM |
| GPIO xx | Status LED | Output |
The exact table should be finalized against the specific ESP32 board model.
20. Robot Chassis and Motor Wiring
LEFT MOTOR RIGHT MOTOR
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ │ │ │
│ O────┴────────────────┴────O │
│ CHASSIS │
│ │
│ ESP32-CAM │
│ ▲ │
│ │ │
│ SERVO │
└────────────────────────────────────┘
21. Camera / Video Streaming
The camera captures frames:
Camera
↓
Frame Capture
↓
JPEG
↓
HTTP/MJPEG stream
↓
Browser
The browser displays:
<img src="/stream">
The actual implementation depends on the ESP32 camera firmware and network architecture.
22. Web-Based Robot Controller
The web interface can contain:
┌─────────────────────────────────────────┐
│ AI ESP32 ROBOT CONTROL │
├─────────────────────────────────────────┤
│ │
│ LIVE CAMERA │
│ ┌───────────────┐ │
│ │ │ │
│ │ VIDEO │ │
│ │ │ │
│ └───────────────┘ │
│ │
│ [ UP ] │
│ │
│ [ LEFT ] [ STOP ] [ RIGHT ] │
│ │
│ [ DOWN ] │
│ │
│ Distance: 1.85 m │
│ AI: PERSON 94% │
│ Status: ONLINE │
└─────────────────────────────────────────┘
JavaScript sends commands:
Browser
│
│ POST /api/move
▼
ESP32
│
▼
Motor Driver
23. Real-Time AI Object Detection
The AI pipeline:
Camera Frame
↓
Image Preprocessing
↓
Object Detection Model
↓
Bounding Boxes
↓
Confidence Filtering
↓
Object Classification
↓
Event Generation
Example:
┌─────────────────────────────┐
│ │
│ ┌─────────────┐ │
│ │ PERSON │ │
│ │ 94% │ │
│ └─────────────┘ │
│ │
└─────────────────────────────┘
24. ESP32 ↔ Web Server Communication
REST-style communication can be used:
POST /api/move
GET /api/status
GET /api/sensors
POST /api/servo
POST /api/stop
Example:
{
"command": "forward",
"speed": 180
}
ESP32 response:
{
"success": true,
"command": "forward"
}
25. n8n Workflow Architecture
n8n becomes the automation layer:
Detection Event
│
▼
┌───────────┐
│ Webhook │
└─────┬─────┘
▼
Validate Event
│
▼
AI / Logic Node
│
┌───────────┼───────────┐
▼ ▼ ▼
Telegram Google Sheet ThingSpeak
│ │ │
▼ ▼ ▼
Alert Log Dashboard
26. AI-Agent Decision Workflow
The agentic layer can receive:
{
"object": "person",
"confidence": 0.94,
"distance": 2.1,
"robot_id": "R01"
}
Decision logic:
IF confidence < threshold
↓
Ignore / log
IF confidence >= threshold
↓
Check object type
↓
Check distance
↓
Generate event
↓
Notify user
↓
Record event
A more advanced implementation can use an AI model to interpret structured events, but safety-critical robot movement should remain constrained by deterministic rules rather than allowing an unconstrained language model to directly command motors.
27. Telegram Bot Integration
Basic architecture:
ESP32 / AI
│
▼
n8n
│
▼
Telegram Bot API
│
▼
User Telegram
Possible commands:
/start
/status
/forward
/backward
/left
/right
/stop
/photo
/scan
28. Telegram Voice Notification Generation
Event:
Person detected
↓
n8n
↓
Create notification text
↓
Text-to-Speech
↓
Audio file
↓
Telegram
↓
Voice notification
Example spoken message:
“Alert. A person has been detected by Robot One with ninety-four percent confidence.”
29. Google Sheets Data Logging
Each event can become one spreadsheet row:
| Timestamp | Robot | Object | Confidence | Distance | Action |
|---|---|---|---|---|---|
| 10:42:18 | R01 | Person | 94% | 2.1m | Alert |
| 10:43:02 | R01 | Vehicle | 89% | 4.3m | Log |
| 10:44:12 | R01 | Animal | 91% | 3.2m | Alert |
This creates a searchable event history.
30. ThingSpeak Cloud Dashboard
Telemetry can include:
Field 1 → Distance
Field 2 → Temperature
Field 3 → Object confidence
Field 4 → Robot state
Field 5 → Motor state
Field 6 → Detection count
Conceptually:
ESP32
↓
Telemetry
↓
ThingSpeak
↓
Charts
31. End-to-End Data Flow
The complete system:
USER
│
┌────────┴────────┐
▼ ▼
Browser Telegram
│ │
└────────┬────────┘
▼
Internet
│
┌───────▼───────┐
│ n8n │
│ Automation │
└───────┬───────┘
│
┌────────┴─────────┐
▼ ▼
ESP32 API AI Server
│ │
┌────┼─────┐ │
▼ ▼ ▼ ▼
Motors Servo Sensors Object Detection
│
▼
n8n
│
┌────────────────┼───────────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
32. Security and Authentication
Security should include:
-
Wi-Fi credentials stored securely.
-
Authentication for web commands.
-
HTTPS where practical.
-
n8n webhook authentication.
-
Telegram bot-token protection.
-
API-key protection.
-
Restricted network exposure.
-
Input validation.
-
Motor command limits.
-
Emergency stop.
Never hard-code secrets into publicly shared source code:
const char* WIFI_PASSWORD = "YOUR_PASSWORD";
const char* TELEGRAM_TOKEN = "YOUR_TOKEN";
Instead, credentials should be supplied through protected configuration.
33. Complete ESP32 Firmware
The firmware will be divided into modules:
setup()
├── Serial
├── GPIO
├── Motors
├── Sensors
├── Servo
├── Wi-Fi
└── Web/API
loop()
├── Read sensors
├── Process commands
├── Update robot state
└── Send telemetry
Example architecture:
void loop() {
readSensors();
processWebCommands();
updateRobotState();
sendTelemetryIfRequired();
}
The final code should be adapted to the exact ESP32 board and motor-driver model.
34. Web HTML / CSS / JavaScript
The project will contain:
index.html
style.css
app.js
JavaScript concept:
async function moveRobot(command) {
await fetch("/api/move", {
method: "POST",
headers: {
"Content-Type": "application/json"
},
body: JSON.stringify({
command: command
})
});
}
Buttons:
<button onclick="moveRobot('forward')">▲</button>
<button onclick="moveRobot('left')">◀</button>
<button onclick="moveRobot('stop')">STOP</button>
<button onclick="moveRobot('right')">▶</button>
<button onclick="moveRobot('backward')">▼</button>
35. AI Detection Code
The AI program will perform:
Read camera
↓
Resize/preprocess
↓
Inference
↓
Extract detections
↓
Filter confidence
↓
Draw boxes
↓
Generate JSON event
↓
POST to n8n
Example event:
{
"robot_id": "R01",
"object": "person",
"confidence": 0.94,
"distance_m": 2.1,
"timestamp": "2026-10-03T10:42:18"
}
36. n8n Workflow Configuration
A practical workflow:
[Webhook]
↓
[Validate JSON]
↓
[Normalize Event]
↓
[Decision / AI Agent]
↓
┌──┴──────────┬──────────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
▼ ▼ ▼
Voice/Text Record Telemetry
Additional branches can include:
Detection
↓
IF confidence > threshold
↓ YES
Telegram Alert
↓ NO
Log Only
37. Telegram Integration Code / Configuration
The workflow will contain:
Telegram credentials
↓
Send message
↓
Optional text-to-speech
↓
Send audio
The bot should not be allowed to execute arbitrary commands from untrusted users. User identity/chat ID validation should occur before accepting robot-control commands.
38. Google Sheets Integration
Workflow:
n8n
↓
Google Sheets node
↓
Append Row
Example mapping:
timestamp → Timestamp
robot_id → Robot
object → Object
confidence → Confidence
distance → Distance
action → Action
39. ThingSpeak Integration
Workflow:
ESP32 / n8n
↓
ThingSpeak API
↓
Channel
↓
Fields
↓
Charts
The final implementation will document API keys, channel configuration, field mapping, and update frequency without publishing private keys.
40. Testing Procedure
Testing will be performed in stages.
Hardware testing
Power
↓
ESP32
↓
Wi-Fi
↓
Motor driver
↓
Motors
↓
Sensors
↓
Camera
Software testing
Web page
↓
ESP32 API
↓
Robot movement
↓
AI detection
↓
n8n webhook
↓
Telegram
↓
Google Sheets
↓
ThingSpeak
41. Test Cases and Expected Results
| Test | Input | Expected result |
|---|---|---|
| T01 | ESP32 powered | ESP32 boots |
| T02 | Wi-Fi available | ESP32 connects |
| T03 | Forward command | Robot moves forward |
| T04 | Stop command | Motors stop |
| T05 | Obstacle detected | Distance reported |
| T06 | Camera active | Video available |
| T07 | Person detected | Detection generated |
| T08 | High-confidence event | n8n receives event |
| T09 | Alert event | Telegram message sent |
| T10 | Voice enabled | Telegram audio generated |
| T11 | Event received | Google Sheets row added |
| T12 | Telemetry sent | ThingSpeak updated |
42. Troubleshooting
ESP32 doesn't connect to Wi-Fi
Check:
SSID
Password
2.4-GHz compatibility
Signal strength
Power supply
Motors behave incorrectly
Check:
Motor-driver wiring
Common GND
Motor polarity
PWM configuration
Battery voltage
Camera stream fails
Check:
Camera model
Camera pin configuration
PSRAM
Power stability
Network address
AI detections are unreliable
Check:
Lighting
Camera resolution
Model
Confidence threshold
Inference hardware
Frame rate
Telegram alerts fail
Check:
Bot token
Chat ID
Internet connectivity
n8n credentials
Telegram API response
43. Advantages and Limitations
Advantages
-
Wireless operation
-
Browser control
-
Live video
-
AI object detection
-
Automated notifications
-
Cloud logging
-
Historical data
-
Modular architecture
-
Expandable IoT platform
Limitations
-
Wi-Fi dependency
-
Battery limitations
-
AI inference may require additional computing hardware
-
Network latency
-
Camera quality affects detection
-
Cloud services may introduce availability/API limitations
-
ESP32 resources are limited
44. Future Enhancements
Possible upgrades:
Current system
│
├── GPS
├── GPS geofencing
├── Thermal camera
├── Night vision
├── Edge AI accelerator
├── SLAM
├── Autonomous navigation
├── Voice commands
├── Multi-robot coordination
├── Battery monitoring
└── Mobile application
An additional safety enhancement would be an independent hardware emergency-stop mechanism so that network or AI failures cannot leave the motors running indefinitely.
45. Conclusion
The proposed AI Web-Controlled Spy Robot demonstrates the integration of embedded systems, robotics, IoT, computer vision, cloud services, workflow automation, and conversational notification systems.
The ESP32 provides the embedded control layer, while the camera supplies visual information for AI analysis. n8n connects the robot to external services and automates event processing. Telegram provides human notifications and remote interaction, Google Sheets provides historical event storage, and ThingSpeak provides cloud-based visualization.
The architecture is intentionally modular, allowing individual components to be upgraded without redesigning the complete system.
46. Bill of Materials
| No. | Component | Qty. |
|---|---|---|
| 1 | ESP32 development board | 1 |
| 2 | ESP32-CAM / compatible camera | 1 |
| 3 | 2WD/4WD robot chassis | 1 |
| 4 | DC geared motors | 2/4 |
| 5 | H-bridge motor driver | 1 |
| 6 | Servo motor | 1 |
| 7 | Ultrasonic sensor | 1 |
| 8 | IR obstacle sensors | 2 |
| 9 | Battery pack | 1 |
| 10 | Voltage regulator | 1 |
| 11 | Jumper wires | Set |
| 12 | Switch | 1 |
| 13 | LEDs | As required |
| 14 | Buzzer | 1 |
| 15 | AI inference computer | 1 |
| 16 | Wi-Fi router/network | 1 |
47. Project Folder Structure
AI-ESP32-AGENTIC-ROBOT/
│
├── firmware/
│ ├── robot.ino
│ ├── motors.h
│ ├── sensors.h
│ ├── camera.h
│ ├── web_server.h
│ └── config.h
│
├── web/
│ ├── index.html
│ ├── style.css
│ └── app.js
│
├── ai/
│ ├── detector.py
│ ├── requirements.txt
│ └── models/
│
├── n8n/
│ ├── workflow.json
│ └── workflow-documentation.md
│
├── telegram/
│ └── telegram-configuration.md
│
├── google-sheets/
│ └── spreadsheet-schema.md
│
├── thingspeak/
│ └── channel-configuration.md
│
├── hardware/
│ ├── schematic/
│ ├── wiring/
│ ├── pinout.md
│ └── bom.md
│
├── tests/
│ ├── hardware-tests.md
│ └── software-tests.md
│
└── documentation/
├── project-report.md
├── architecture.md
└── viva-questions.md
48. Viva / Interview Questions and Answers
Q1. Why is ESP32 used?
ESP32 provides Wi-Fi, GPIO, PWM and sufficient embedded processing capability at low cost, making it suitable for IoT robot control.
Q2. Why use a motor driver?
The ESP32 GPIO cannot directly supply the current required by DC motors. The motor driver provides the required power switching and direction control.
Q3. What is the purpose of n8n?
n8n acts as the workflow automation layer connecting robot events with Telegram, Google Sheets, ThingSpeak, and other services.
Q4. Why is AI inference separated from the ESP32?
Object-detection models can require substantially more compute and memory than a conventional ESP32 can efficiently provide. An external edge/server processor allows more capable models while keeping the ESP32 responsible for real-time robot control.
Q5. What happens when an object is detected?
Camera
↓
AI Model
↓
Detection
↓
Event JSON
↓
n8n
↓
Decision
↓
Telegram + Sheets + ThingSpeak
Q6. What is an AI agent in this project?
The AI-agent layer interprets structured robot events and can select configured workflows/actions. It should operate within predefined permissions and safety rules rather than having unrestricted motor control.
Q7. Why use Google Sheets?
It provides a simple human-readable historical event log.
Q8. Why use ThingSpeak?
It provides cloud-oriented telemetry visualization and time-series data.
Q9. What happens if the Internet fails?
Local robot functions can be designed to continue operating, depending on the implementation, but cloud automation and remote notifications will be unavailable until connectivity returns.
Q10. What is the most important safety feature?
An independent emergency stop and fail-safe motor timeout should be included so that communication, software, or AI failures do not result in uncontrolled movement.
Recommended next stage
The documentation above gives the complete report architecture. The next stage should be the actual implementation package:
Part 1 — Hardware: exact ESP32 board selection, motor driver selection, complete GPIO pinout, power circuit, and a detailed wiring/schematic.
Part 2 — Firmware: complete compilable ESP32 Arduino program for motors, ultrasonic/IR sensors, servo, Wi-Fi, REST API and robot status.
Part 3 — Web: complete index.html, style.css, and app.js with live camera, directional controls, sensor values and AI detection display.
Part 4 — AI: complete Python object-detection server with camera input, bounding boxes and n8n webhook events.
Part 5 — Automation: complete n8n workflow, Telegram text/voice alerts, Google Sheets logging and ThingSpeak telemetry.
Part 6 — Final report: combine everything into a submission-ready document with flowcharts, schematics, screenshots/placeholders, test results, references, and viva questions.
For the actual circuit and code, the one hardware detail that must be fixed first is the exact board: ESP32 DevKit V1 + separate camera, AI-Thinker ESP32-CAM, or another ESP32-CAM board. The GPIO assignments and camera wiring are different between boards.
Project Summary
Title:
AI Web-Controlled Spy Robot with Real-Time Object Detection, Agentic IoT, n8n Automation, Telegram Voice Alerts, Google Sheets & ThingSpeak
Core idea
A Wi-Fi-enabled ESP32 robotic vehicle is controlled through a web interface and equipped with a camera and sensors. Camera data is analyzed by an AI object-detection system, while n8n acts as the automation/agentic layer.
Web Browser
│
▼
ESP32 Robot ─── Camera ───► AI Detection Server
│ │
│ ▼
│ Detection Event
│ │
└──────────────► n8n ◄─────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Telegram Google Sheets ThingSpeak
Text/Voice Event Log Dashboard
Main functions
-
Web-based forward/reverse/left/right/stop control
-
Live camera streaming
-
Servo-controlled camera/sensor positioning
-
Ultrasonic and IR obstacle detection
-
Real-time AI object detection
-
ESP32 ↔ server communication
-
n8n event automation
-
AI-agent-style decision workflow
-
Telegram text notifications
-
Telegram voice alerts
-
Google Sheets event logging
-
ThingSpeak telemetry dashboard
-
Remote Telegram commands
-
Safety/emergency-stop mechanisms
Main hardware
-
ESP32 / ESP32-CAM
-
Motor driver
-
2 or 4 DC geared motors
-
Robot chassis
-
Servo motor
-
Ultrasonic sensor
-
IR sensors
-
Camera
-
Battery and voltage regulation
-
Optional AI inference computer/Raspberry Pi
Main software
Arduino IDE
ESP32 Arduino Framework
HTML / CSS / JavaScript
Python
AI Object Detection Model
n8n
Telegram Bot
Google Sheets
ThingSpeak
Important architecture decision
The ESP32 handles real-time robot control, sensors, Wi-Fi and camera functions, while computationally heavier object detection can run on a PC/Raspberry Pi/edge AI device. This is more practical than expecting a conventional ESP32 to run a large object-detection model.
Documentation chapters
The final report will cover:
-
Abstract and introduction
-
Problem statement and objectives
-
Existing and proposed systems
-
Applications
-
Hardware/software requirements
-
Hardware architecture and schematic
-
ESP32 pin configuration
-
Motor, sensor, servo and camera wiring
-
Video streaming
-
Web robot controller
-
AI object detection
-
ESP32/server communication
-
n8n automation
-
AI-agent workflow
-
Telegram and voice alerts
-
Google Sheets
-
ThingSpeak
-
Security
-
Complete source code
-
Testing and troubleshooting
-
Advantages and limitations
-
Future enhancements
-
BOM and project structure
-
Viva questions and answers
Complete event example
Person detected
↓
AI: Person / 94%
↓
n8n Webhook
↓
Validate + decide
↓
┌────┼───────────┐
▼ ▼ ▼
TG Sheets ThingSpeak
│
▼
Voice Alert
Final implementation should next lock down the exact ESP32 board and motor driver, because the GPIO pinout, camera connections, and firmware depend on those specific components.
