Absolutely
. I can structure
this as a complete final-year/academic IoT + AI project documentation, including the architecture, hardware, circuit/schematic, ESP32 firmware, n8n workflows, Telegram voice alerts, Google Sheets logging, ThingSpeak dashboard, AI-agent logic, webpage, testing, and future scope
.
AI Smart Shoes for Blind People with Obstacle Prediction
Project Title
AI-Powered Smart Shoes for Blind People with Obstacle Detection, Prediction and Agentic IoT Voice Alerts using ESP32, n8n, Telegram, Google Sheets and ThingSpeak
1. Abstract
The
proposed system is an AI-enabled assistive smart-shoe platform designed to help visually impaired people detect obstacles and receive timely audio notifications while walking.
Sensors mounted on the shoe continuously monitor the environment. An
ESP32 collects sensor readings and determines the distance and approximate direction of nearby obstacles. Instead of relying only on a conventional buzzer, the system connects
to an IoT automation platform using n8n.
The n8n workflow acts as an automation and
AI-agent layer:
Sensors
↓
ESP32
↓
Wi-Fi
↓
n8n Webhook
↓
AI Agent
↓
Decision / Classification
↓
Telegram Voice Alert
↓
User
At the same time, measurements
can be stored in Google Sheets for historical analysis and sent to ThingSpeak for graphical IoT visualization.
The system can classify situations such as:
The important design principle is that the AI layer should supplement—not replace—the immediate local safety mechanism. A network connection or AI service should never be required for the shoe to provide its most basic nearby-obstacle warning.
2. Main Objectives
The project has several objectives:
-
Develop a wearable obstacle-detection system using ESP32.
-
Detect objects in front/left/right of the user.
-
Estimate obstacle distance.
-
Identify potentially dangerous obstacles.
-
Provide immediate local feedback.
-
Send sensor information to an IoT cloud/automation layer.
-
Use n8n to automate data processing.
-
Use an AI agent to interpret sensor events.
-
Send voice notifications through Telegram.
-
Record sensor information in Google Sheets.
-
Visualize sensor data using ThingSpeak.
-
Provide a web-based monitoring dashboard.
-
Maintain an event history for analysis.
-
Reduce unnecessary repeated notifications.
-
Build a scalable architecture that can later incorporate computer vision or more sophisticated prediction.
3. Proposed System Architecture
┌─────────────────────────┐
│ SMART SHOE │
│ │
│ ┌───────────────────┐ │
│ │ ESP32 │ │
│ └───────┬───────────┘ │
│ │ │
│ ┌──────┼───────┐ │
│ ↓ ↓ ↓ │
│ HC-SR04 Left Right │
│ /ToF Sensor Sensor │
└──────────┬──────────────┘
│
│ Wi-Fi
↓
┌──────────────────────┐
│ n8n Webhook │
└──────────┬───────────┘
│
┌─────────────┼──────────────┐
↓ ↓ ↓
┌────────────┐ ┌────────────┐ ┌──────────────┐
│ AI Agent │ │ Google │ │ ThingSpeak │
│ │ │ Sheets │ │ Dashboard │
└─────┬──────┘ └────────────┘ └──────────────┘
│
↓
┌───────────────────┐
│ Alert Decision │
│ Engine │
└─────────┬─────────┘
│
↓
┌─────────────┐
│ Telegram │
│ Voice Alert │
└──────┬──────┘
│
↓
USER
4. Hardware
Components
A practical prototype can use the following components.
| Component |
Purpose |
| ESP32 DevKit |
Main microcontroller |
| Ultrasonic/ToF sensors |
Obstacle-distance measurement |
| Left sensor |
Detect left-side obstacles |
| Right sensor |
Detect right-side obstacles |
| Front sensor |
Detect obstacle ahead |
| Vibration motors |
Silent/local tactile warning |
| Buzzer |
Emergency local warning |
| Li-ion/Li-Po battery |
Portable power |
| Battery charging/protection circuit |
Safe charging |
| Voltage regulator |
Stable supply |
| Push button |
Emergency/control input |
| LED |
Status indication |
| Shoe/strap enclosure |
Physical mounting |
Recommended sensor configuration
For a prototype:
USER
↑
│
FRONT SENSOR
│
┌─────┴─────┐
│ SHOE │
LEFT SENSOR ←│ ESP32 │→ RIGHT SENSOR
│ │
└───────────┘
For a more advanced version, replace ultrasonic sensors with ToF sensors, because
multiple ultrasonic sensors can interfere with each other if triggered simultaneously.
5. Why Three Sensors?
A single sensor can answer:
"Is something nearby?"
Three sensors allow the system to estimate:
"Where is the obstacle?"
For example:
FRONT
│
│
[Obstacle]
│
┌───────┴───────┐
│ 👤 │
│ USER │
│ │
LEFT RIGHT
Example readings:
Front = 55 cm
Left = 180 cm
Right = 170 cm
The system interprets this as:
Obstacle direction = FRONT
Distance = 55 cm
Risk = HIGH
Another example:
Front = 180 cm
Left = 45 cm
Right = 170 cm
Result:
Obstacle direction = LEFT
Distance = 45 cm
Risk = HIGH
6. Obstacle-Distance Classification
A simple initial rule system can be:
Distance > 200 cm
↓
SAFE
100–200 cm
↓
CAUTION
50–100 cm
↓
WARNING
< 50 cm
↓
DANGER
These values should be experimentally calibrated because sensor accuracy, walking speed, mounting position, floor conditions, and object shape affect the actual performance.
7. Local Safety Layer
This is extremely important.
Do not design the system so that:
Sensor → Internet → AI → Telegram → User
is the only safety path.
Instead:
┌───────────────┐
Sensor ──────→│ ESP32 LOCAL │────→ Vibration/Buzzer
│ SAFETY LOGIC │
└───────┬───────┘
│
↓
Wi-Fi
↓
n8n
↓
AI Agent
↓
Telegram
If Wi-Fi fails, the shoe should still detect nearby obstacles and activate its local warning.
8. ESP32 Pin Configuration
Example configuration:
| Device |
ESP32 GPIO |
| Front Trigger |
GPIO 5 |
| Front Echo |
GPIO 18 |
| Left Trigger |
GPIO 19 |
| Left Echo |
GPIO 21 |
| Right Trigger |
GPIO 22 |
| Right Echo |
GPIO 23 |
| Left vibration motor |
GPIO 25 |
| Right vibration motor |
GPIO 26 |
| Buzzer |
GPIO 27 |
| Status LED |
GPIO 2 |
| Emergency button |
GPIO 4 |
Important: If using a classic HC-SR04 with a 5 V Echo output, do not connect Echo directly to an ESP32 GPIO. Use an appropriate voltage divider/level-shifting circuit.
9. Basic Schematic
+-------------------+
| ESP32 |
| |
FRONT TRIG -----| GPIO5 |
FRONT ECHO -----| GPIO18 |
LEFT TRIG ------| GPIO19 |
LEFT ECHO ------| GPIO21 |
RIGHT TRIG -----| GPIO22 |
RIGHT ECHO -----| GPIO23 |
| |
VIBRATION L ----| GPIO25 |
VIBRATION R ----| GPIO26 |
BUZZER ---------| GPIO27 |
LED ------------| GPIO2 |
BUTTON ---------| GPIO4 |
| |
+---------+---------+
|
GND
Power arrangement
Li-ion Battery
│
↓
Protection / Charger
│
↓
Voltage Regulator
│
┌─────┴──────┐
↓ ↓
ESP32 Sensors
│
┌──────┴──────┐
↓ ↓
Vibration Buzzer
The exact battery/regulator arrangement should be selected according to the ESP32 board and sensors being used.
10. ESP32 Operating Logic
The ESP32 performs the following sequence:
START
↓
Initialize sensors
↓
Initialize Wi-Fi
↓
Read front distance
↓
Read left distance
↓
Read right distance
↓
Filter readings
↓
Determine closest obstacle
↓
Determine direction
↓
Calculate risk
↓
Activate local warning
↓
Send event to n8n
↓
Repeat
11. ESP32 Firmware
Below is a starting Arduino IDE implementation.
#include <WiFi.h>
#include <HTTPClient.h>
// -----------------------------
// Wi-Fi configuration
// -----------------------------
const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASSWORD = "YOUR_PASSWORD";
// n8n webhook URL
const char* N8N_WEBHOOK =
"https://YOUR_N8N_DOMAIN/webhook/smart-shoe";
// -----------------------------
// Sensor pins
// -----------------------------
#define FRONT_TRIG 5
#define FRONT_ECHO 18
#define LEFT_TRIG 19
#define LEFT_ECHO 21
#define RIGHT_TRIG 22
#define RIGHT_ECHO 23
// -----------------------------
// Output pins
// -----------------------------
#define VIB_LEFT 25
#define VIB_RIGHT 26
#define BUZZER 27
#define STATUS_LED 2
// -----------------------------
// Thresholds
// -----------------------------
const float DANGER_DISTANCE = 50.0;
const float WARNING_DISTANCE = 100.0;
const float CAUTION_DISTANCE = 200.0;
// Measure distance
float readDistance(int trigPin, int echoPin)
{
digitalWrite(trigPin, LOW);
delayMicroseconds(3);
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);
long duration = pulseIn(echoPin, HIGH, 30000);
if (duration == 0)
return 999.0;
float distance = duration * 0.0343 / 2.0;
return distance;
}
// Connect Wi-Fi
void connectWiFi()
{
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());
}
// Determine direction
String getDirection(float front, float left, float right)
{
float minimum = min(front, min(left, right));
if (minimum == front)
return "FRONT";
if (minimum == left)
return "LEFT";
return "RIGHT";
}
// Determine risk
String getRisk(float distance)
{
if (distance <= DANGER_DISTANCE)
return "DANGER";
if (distance <= WARNING_DISTANCE)
return "WARNING";
if (distance <= CAUTION_DISTANCE)
return "CAUTION";
return "SAFE";
}
// Local warning
void localWarning(
float front,
float left,
float right)
{
digitalWrite(VIB_LEFT, LOW);
digitalWrite(VIB_RIGHT, LOW);
digitalWrite(BUZZER, LOW);
float minimum = min(front, min(left, right));
if (minimum <= DANGER_DISTANCE)
{
String direction = getDirection(front, left, right);
digitalWrite(BUZZER, HIGH);
if (direction == "LEFT")
digitalWrite(VIB_LEFT, HIGH);
else if (direction == "RIGHT")
digitalWrite(VIB_RIGHT, HIGH);
else
{
digitalWrite(VIB_LEFT, HIGH);
digitalWrite(VIB_RIGHT, HIGH);
}
}
}
// Send data to n8n
void sendToN8N(
float front,
float left,
float right,
String direction,
String risk)
{
if (WiFi.status() != WL_CONNECTED)
return;
HTTPClient http;
http.begin(N8N_WEBHOOK);
http.addHeader("Content-Type", "application/json");
String json = "{";
json += "\"front\":" + String(front, 1) + ",";
json += "\"left\":" + String(left, 1) + ",";
json += "\"right\":" + String(right, 1) + ",";
json += "\"direction\":\"" + direction + "\",";
json += "\"risk\":\"" + risk + "\",";
json += "\"device\":\"SMART_SHOE_01\"";
json += "}";
int responseCode = http.POST(json);
Serial.print("n8n response: ");
Serial.println(responseCode);
http.end();
}
void setup()
{
Serial.begin(115200);
pinMode(FRONT_TRIG, OUTPUT);
pinMode(FRONT_ECHO, INPUT);
pinMode(LEFT_TRIG, OUTPUT);
pinMode(LEFT_ECHO, INPUT);
pinMode(RIGHT_TRIG, OUTPUT);
pinMode(RIGHT_ECHO, INPUT);
pinMode(VIB_LEFT, OUTPUT);
pinMode(VIB_RIGHT, OUTPUT);
pinMode(BUZZER, OUTPUT);
pinMode(STATUS_LED, OUTPUT);
connectWiFi();
}
void loop()
{
float front = readDistance(FRONT_TRIG, FRONT_ECHO);
delay(50);
float left = readDistance(LEFT_TRIG, LEFT_ECHO);
delay(50);
float right = readDistance(RIGHT_TRIG, RIGHT_ECHO);
String direction = getDirection(front, left, right);
float minimum = min(front, min(left, right));
String risk = getRisk(minimum);
Serial.println("---------------------------");
Serial.print("Front: ");
Serial.println(front);
Serial.print("Left: ");
Serial.println(left);
Serial.print("Right: ");
Serial.println(right);
Serial.print("Direction: ");
Serial.println(direction);
Serial.print("Risk: ");
Serial.println(risk);
localWarning(front, left, right);
// Send only meaningful events
if (risk != "SAFE")
{
sendToN8N(
front,
left,
right,
direction,
risk
);
}
delay(500);
}
This is a prototype firmware, not medical/safety-certified navigation software. For a real assistive product, additional validation, fault handling, environmental testing, and accessibility/user testing would be required.
12. n8n Architecture
The n8n workflow becomes the central IoT automation layer.
ESP32
│
│ HTTP POST
↓
┌──────────────────┐
│ Webhook Node │
└────────┬─────────┘
↓
┌──────────────────┐
│ Validate Data │
└────────┬─────────┘
↓
┌──────────────────┐
│ Calculate Risk │
└────────┬─────────┘
↓
┌──────────────────┐
│ AI Agent │
└────────┬─────────┘
↓
┌─────┴─────┐
↓ ↓
Google Sheets ThingSpeak
│
↓
Event Database
AI Decision
↓
┌──────────────┐
│ Alert Needed?│
└──────┬───────┘
│ YES
↓
Telegram Message
↓
Voice Alert
13. n8n Workflow — Node by Node
Node 1 — Webhook
Method:
POST
Example incoming JSON:
{
"front": 42.5,
"left": 160.2,
"right": 125.4,
"direction": "FRONT",
"risk": "DANGER",
"device": "SMART_SHOE_01"
}
Node 2 — Data Validation
Check:
front exists
left exists
right exists
risk exists
device exists
Reject malformed packets.
Node 3 — Function/Code Node
Example:
const front = Number($json.front);
const left = Number($json.left);
const right = Number($json.right);
const minimum = Math.min(front, left, right);
let direction = "NONE";
if (minimum === front) {
direction = "FRONT";
} else if (minimum === left) {
direction = "LEFT";
} else {
direction = "RIGHT";
}
let risk = "SAFE";
if (minimum <= 50) {
risk = "DANGER";
} else if (minimum <= 100) {
risk = "WARNING";
} else if (minimum <= 200) {
risk = "CAUTION";
}
return [{
json: {
...$json,
minimum,
direction,
risk,
timestamp: new Date().toISOString()
}
}];
14. AI Agent
The AI agent should interpret structured sensor data, not invent sensor measurements.
Example system instruction:
You are the decision assistant for a wearable obstacle
detection system.
Your job is to interpret sensor readings from an ESP32.
Rules:
1. Never invent sensor measurements.
2. Use only the supplied readings.
3. Identify the closest obstacle.
4. Identify its approximate direction.
5. Classify the event as SAFE, CAUTION, WARNING or DANGER.
6. Generate a very short voice-friendly alert.
7. Do not provide unnecessary explanations.
8. Do not claim that the system can see or identify an object
unless an appropriate vision sensor has actually supplied
that information.
9. If sensor data is invalid, return SENSOR_ERROR.
Input:
{
"front": 38,
"left": 160,
"right": 142,
"device": "SMART_SHOE_01"
}
Possible output:
{
"status": "DANGER",
"direction": "FRONT",
"distance_cm": 38,
"alert_required": true,
"voice_message": "Obstacle very close ahead."
}
15. Important Meaning of "AI Prediction"
The phrase obstacle prediction needs to be technically defined.
A distance sensor alone primarily performs:
Obstacle detection and distance estimation.
True prediction could mean:
Current measurements
+
Previous measurements
+
Movement trend
+
Walking speed
↓
Predicted future obstacle proximity
For example:
Time Distance
T1 140 cm
T2 115 cm
T3 90 cm
T4 65 cm
The system detects that the obstacle is getting closer.
A future version could calculate:
Distance rate:
Δd / Δt
and estimate:
Estimated time-to-obstacle =
current distance / closing speed
This is much more defensible technically than claiming that a simple ultrasonic sensor performs AI object prediction.
16. Obstacle Prediction Algorithm
Suppose:
Previous distance = 100 cm
Current distance = 80 cm
Time interval = 0.5 sec
Then:
Closing speed =
(100 - 80) / 0.5
= 40 cm/sec
Estimated time:
80 / 40
= 2 seconds
The system could therefore generate:
"Obstacle approaching in approximately two seconds."
However, noisy sensor measurements must be filtered before making such a prediction.
17. Moving Average Filter
A simple filter:
float smoothDistance(
float oldValue,
float newValue)
{
const float alpha = 0.3;
return
alpha * newValue +
(1 - alpha) * oldValue;
}
This reduces sudden measurement fluctuations.
A more advanced implementation could use:
18. Telegram Voice Alert
The Telegram portion can operate like this:
ESP32
↓
n8n
↓
AI Agent
↓
"Obstacle very close ahead."
↓
Text-to-Speech
↓
Audio file
↓
Telegram Bot
↓
User's smartphone
↓
Voice/audio alert
Example alert messages:
"Obstacle ahead."
"Obstacle very close on your left."
"Obstacle approaching from the right."
"Multiple nearby obstacles detected."
"Sensor error. Please stop and check the device."
For accessibility, messages should be short, unambiguous and consistent.
19. Telegram Conversation Example
SMART SHOE BOT
──────────────
🤖 Smart Shoe:
Obstacle detected ahead.
👤 User:
Status
🤖 Smart Shoe:
Front: 82 cm.
Left: 160 cm.
Right: 145 cm.
Current status: WARNING.
👤 User:
What is the closest obstacle?
🤖 Smart Shoe:
The closest detected obstacle is ahead,
approximately 82 centimeters away.
Another example:
🤖 Smart Shoe:
⚠️ Obstacle very close on your right.
🔊 Voice:
"Obstacle very close on your right."
20. Google Sheets Integration
Google Sheets can act as the project's historical event database.
Example columns:
| Timestamp |
Device |
Front |
Left |
Right |
Direction |
Risk |
Alert |
| 21:30:01 |
SHOE01 |
180 |
170 |
190 |
FRONT |
SAFE |
No |
| 21:30:03 |
SHOE01 |
95 |
170 |
180 |
FRONT |
CAUTION |
Yes |
| 21:30:04 |
SHOE01 |
62 |
160 |
175 |
FRONT |
WARNING |
Yes |
| 21:30:05 |
SHOE01 |
38 |
160 |
175 |
FRONT |
DANGER |
Yes |
This enables later analysis of:
-
Number of obstacles
-
Most frequent direction
-
Average distance
-
Number of danger events
-
Alert frequency
-
Sensor errors
-
Walking-session duration
21. ThingSpeak Dashboard
ThingSpeak can be used as the IoT visualization layer.
Possible channels:
Field 1 → Front Distance
Field 2 → Left Distance
Field 3 → Right Distance
Field 4 → Risk Level
Field 5 → Closing Speed
Field 6 → Battery
Conceptually:
THINGSPEAK
│
┌──────────┼──────────┐
↓ ↓ ↓
Front Left Right
Distance Distance Distance
│ │ │
└──────────┼──────────┘
↓
Trend Graph
22. Web Dashboard
The project can additionally provide an IoT webpage.
Example layout:
┌─────────────────────────────────────────────┐
│ AI SMART SHOE DASHBOARD │
├─────────────────────────────────────────────┤
│ │
│ DEVICE: SMART_SHOE_01 🟢 ONLINE │
│ │
├──────────────┬──────────────┬───────────────┤
│ FRONT │ LEFT │ RIGHT │
│ │ │ │
│ 82 cm │ 165 cm │ 145 cm │
│ │ │ │
├──────────────┴──────────────┴───────────────┤
│ │
│ STATUS: ⚠️ WARNING │
│ │
│ DIRECTION: FRONT │
│ │
│ AI: Obstacle approaching │
│ │
├─────────────────────────────────────────────┤
│ SENSOR HISTORY │
│ │
│ 📈 Distance Graph │
│ │
└─────────────────────────────────────────────┘
23. Example HTML Dashboard
A simple starting webpage:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>AI Smart Shoe Dashboard</title>
<style>
body {
font-family: Arial, sans-serif;
background: #101820;
color: white;
margin: 0;
padding: 20px;
}
h1 {
text-align: center;
}
.dashboard {
max-width: 900px;
margin: auto;
}
.cards {
display: flex;
gap: 20px;
justify-content: center;
flex-wrap: wrap;
}
.card {
background: #1c2b36;
padding: 25px;
border-radius: 15px;
width: 200px;
text-align: center;
}
.value {
font-size: 35px;
color: #00e5ff;
}
.status {
text-align: center;
padding: 25px;
margin-top: 25px;
background: #283b47;
border-radius: 15px;
}
.danger {
color: #ff4444;
}
.warning {
color: #ffaa00;
}
.safe {
color: #00ff88;
}
</style>
</head>
<body>
<div class="dashboard">
<h1>AI Smart Shoe</h1>
<div class="cards">
<div class="card">
<h3>FRONT</h3>
<div class="value" id="front">--</div>
<p>cm</p>
</div>
<div class="card">
<h3>LEFT</h3>
<div class="value" id="left">--</div>
<p>cm</p>
</div>
<div class="card">
<h3>RIGHT</h3>
<div class="value" id="right">--</div>
<p>cm</p>
</div>
</div>
<div class="status">
<h2>Status</h2>
<h1 id="risk">WAITING</h1>
<p>
Direction:
<strong id="direction">--</strong>
</p>
<p id="message">
Waiting for sensor data...
</p>
</div>
</div>
<script>
function updateDashboard(data) {
document.getElementById("front").innerText =
data.front;
document.getElementById("left").innerText =
data.left;
document.getElementById("right").innerText =
data.right;
document.getElementById("risk").innerText =
data.risk;
document.getElementById("direction").innerText =
data.direction;
document.getElementById("message").innerText =
data.message;
}
// Example data
updateDashboard({
front: 82,
left: 160,
right: 145,
risk: "WARNING",
direction: "FRONT",
message: "Obstacle approaching ahead."
});
</script>
</body>
</html>
24. Complete Data Flow
The complete project can be represented as:
┌──────────────────────────────────────────────────────┐
│ SMART SHOE │
│ │
│ Front Sensor Left Sensor Right Sensor │
│ │ │ │ │
│ └───────────────┼──────────────┘ │
│ ↓ │
│ ESP32 │
│ │ │
│ ┌──────────┴─────────┐ │
│ ↓ ↓ │
│ Local Safety Logic Wi-Fi │
│ │ │ │
│ ↓ ↓ │
│ Vibration/Buzzer n8n │
└───────────────────────────────┬──────────────────────┘
│
↓
┌────────────────┐
│ Data Validation│
└───────┬────────┘
↓
┌────────────────┐
│ Risk Algorithm │
└───────┬────────┘
↓
┌────────────────┐
│ AI Agent │
└───────┬────────┘
│
┌──────────────┼───────────────┐
↓ ↓ ↓
Telegram Google Sheets ThingSpeak
│ │ │
↓ ↓ ↓
Voice Alert History Dashboard
│
↓
USER
25. n8n Workflow in More Detail
A recommended workflow is:
[Webhook]
│
↓
[Set / Normalize Data]
│
↓
[Code: Distance Calculation]
│
├──────────────→ [Google Sheets]
│
├──────────────→ [ThingSpeak]
│
↓
[AI Agent]
│
↓
[Structured AI Output]
│
↓
[IF: alert_required]
│
├── NO → END
│
YES
↓
[Text-to-Speech]
│
↓
[Telegram]
│
↓
[Log Alert]
│
↓
END
26. Preventing Alert Spam
A major problem with IoT alerts is:
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
Obstacle
which could result in five Telegram messages every second.
Instead, implement:
Same event
↓
Compare previous event
↓
Same direction + similar distance?
↓
YES
↓
Suppress repeated alert
For example:
21:30:01 Front 45 cm → ALERT
21:30:02 Front 43 cm → suppress
21:30:03 Front 42 cm → suppress
21:30:04 Front 30 cm → ALERT
This can be implemented using an n8n Data Store/database or a local state mechanism.
27. AI Agent Decision Example
Input:
{
"front": 42,
"left": 170,
"right": 150,
"previous_front": 70,
"time_difference": 1
}
AI/logic layer:
Current distance = 42 cm
Previous distance = 70 cm
Obstacle is approaching.
Closing speed ≈ 28 cm/s
Risk = DANGER
Direction = FRONT
Output:
{
"alert_required": true,
"severity": "DANGER",
"direction": "FRONT",
"voice_message": "Obstacle very close ahead."
}
28. Chatbot Command Architecture
The Telegram bot can support commands:
/start
/status
/distance
/battery
/history
/alerts
/location
/stop
/help
Example:
User → /status
Bot →
Smart Shoe Status
Device: SHOE_01
Battery: 78%
Front: 120 cm
Left: 180 cm
Right: 150 cm
Status: CAUTION
29. Emergency Button
An emergency button can provide another useful function.
PRESS BUTTON
↓
ESP32
↓
n8n
↓
Emergency workflow
↓
Telegram notification
Possible message:
🚨 Smart Shoe Emergency Alert
The emergency button on
SMART_SHOE_01 was activated.
Time: 21:35:12
If location functionality is later added, the message can include the device's location.
30. Battery Monitoring
An ADC input can be used to monitor battery voltage through an appropriate voltage-divider circuit.
Conceptually:
Battery
│
├── Voltage Divider
│
↓
ESP32 ADC
│
↓
Battery %
│
├──→ n8n
├──→ Google Sheets
└──→ Dashboard
Example:
Battery > 30% → NORMAL
Battery 15–30% → LOW
Battery < 15% → CRITICAL
The exact battery percentage calculation should be calibrated to the selected battery chemistry and power-management circuit rather than assuming a linear voltage-to-percentage relationship.
31. Software Stack
Hardware
────────
ESP32
Ultrasonic / ToF Sensors
Vibration Motors
Buzzer
Firmware
────────
Arduino IDE
C/C++
IoT
───
Wi-Fi
HTTP/REST
Webhook
Automation
──────────
n8n
AI
──
LLM / AI Agent
Notification
────────────
Telegram Bot
Text-to-Speech
Storage
───────
Google Sheets
Visualization
─────────────
ThingSpeak
Web Dashboard
32. Software Development Flow
Install Arduino IDE
↓
Install ESP32 board support
↓
Connect ESP32
↓
Upload sensor test
↓
Verify distances
↓
Add local warning
↓
Connect Wi-Fi
↓
Create n8n webhook
↓
Send ESP32 JSON
↓
Verify n8n
↓
Add Google Sheets
↓
Add ThingSpeak
↓
Add AI Agent
↓
Add Telegram
↓
Add Text-to-Speech
↓
Test complete system
33. Testing Plan
Test 1 — No obstacle
Front = 250 cm
Left = 240 cm
Right = 260 cm
Expected:
Status = SAFE
No emergency alert
Test 2 — Front obstacle
Front = 80 cm
Expected:
Direction = FRONT
Risk = WARNING/CAUTION depending on configured threshold
Test 3 — Left obstacle
Left = 40 cm
Expected:
Direction = LEFT
Risk = DANGER
Left vibration activated
Telegram alert
Test 4 — Right obstacle
Right = 35 cm
Expected:
Direction = RIGHT
Risk = DANGER
Right vibration activated
Telegram alert
Test 5 — Wi-Fi failure
Wi-Fi = OFF
Expected:
Local sensor detection continues
Vibration/buzzer continues
Cloud alert unavailable
This test is particularly important because the wearable's basic warning capability should not depend entirely on Internet connectivity.
34. Performance Metrics
Your project report can measure:
Detection accuracy
Detection Accuracy =
Correct detections / Total test obstacles × 100
False-positive rate
False Positive Rate =
False alerts / Total observations × 100
Alert latency
Alert Latency =
Telegram alert time − Sensor detection time
Prediction error
For predicted time-to-obstacle:
Prediction Error =
|Predicted Time − Actual Time|
Battery endurance
Operating Time =
Battery capacity / Average current consumption
Actual battery life must be measured experimentally because Wi-Fi transmission and sensor duty cycle significantly affect consumption.
35. Advantages
-
Wearable form factor
-
Hands-free obstacle detection
-
Directional sensing
-
Local vibration feedback
-
Cloud connectivity
-
AI-assisted interpretation
-
Telegram notifications
-
Historical logging
-
IoT visualization
-
Expandable architecture
-
Remote monitoring capability
-
Event-based automation
36. Limitations
The prototype should explicitly document limitations.
For example:
-
Ultrasonic sensors do not identify object type.
-
Sensor readings can be affected by object shape and surface characteristics.
-
Outdoor environments can introduce measurement variability.
-
Internet-dependent functions fail when connectivity is unavailable.
-
AI output should not be treated as guaranteed or safety-critical.
-
The system does not automatically understand complex scenes.
-
A prototype does not replace established mobility aids or trained orientation-and-mobility techniques.
-
Shoe-mounted sensors have a limited field of view.
These limitations are important for an academically credible project.
37. Advanced Version — Computer Vision
A future version could add a camera.
Camera
↓
Edge AI / Vision Model
↓
Object Detection
↓
Person / Vehicle / Stair / Pole / Wall
↓
ESP32 / Edge Computer
↓
Decision Layer
Then the system can potentially distinguish:
Obstacle detected
from:
Person ahead
Vehicle approaching
Staircase
Pole
Wall
Door
A camera-based system would require substantially more compute than a basic ESP32 sensor node, so an ESP32-S3 or a separate edge-AI processor may be appropriate depending on the model.
38. Advanced AI Architecture
A sophisticated version could use:
Sensor Data
│
┌────────────┼────────────┐
↓ ↓ ↓
Distance Motion Vision
Sensor Sensor Camera
│ │ │
└────────────┼────────────┘
↓
Sensor Fusion
↓
AI Perception
↓
Risk Prediction
↓
Agent Planner
↓
┌─────────┴─────────┐
↓ ↓
Local Warning Cloud Alert
│ │
↓ ↓
Vibration Telegram
39. Agentic IoT Concept
Your project can be described as an agentic IoT system if the automation layer performs multiple autonomous steps rather than simply forwarding data.
For example:
1. Receive sensor event
↓
2. Validate measurement
↓
3. Compare with previous measurements
↓
4. Determine risk
↓
5. Ask AI agent to interpret event
↓
6. Decide whether notification is necessary
↓
7. Generate accessible message
↓
8. Send Telegram voice alert
↓
9. Store event
↓
10. Update dashboard
The AI agent therefore becomes part of a larger decision/automation pipeline rather than merely being a chatbot.
40. Complete Project Flow
chart
START
│
↓
Initialize ESP32
│
↓
Initialize Sensors
│
↓
Connect Wi-Fi
│
↓
Read Sensor Values
│
↓
Filter Sensor Data
│
↓
Find Minimum Distance
│
↓
Determine Direction
│
↓
Calculate Risk
│
┌─────────┴─────────┐
│ │
SAFE? NO
│ │
↓ ↓
Continue scan Local warning
│
↓
Send n8n
│
↓
Validate Payload
│
↓
Store Telemetry
│
↓
AI Agent
│
↓
Alert Required?
/ \
NO YES
│ │
↓ ↓
END Generate Voice
│
↓
Telegram Bot
│
↓
USER
41. Project Block Diagram for Your Report
You can use this simplified diagram in the documentation:
┌─────────────────────────────────────┐
│ SMART SHOE │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Front │ │ Left │ │ Right │ │
│ │Sensor │ │Sensor │ │Sensor │ │
│ └───┬────┘ └───┬────┘ └───┬────┘ │
│ └───────────┼──────────┘ │
│ ↓ │
│ ┌─────────┐ │
│ │ ESP32 │ │
│ └────┬────┘ │
│ │ │
│ ┌─────────┴─────────┐ │
│ ↓ ↓ │
│ Vibration Wi-Fi │
│ /Buzzer │ │
└───────────────────────────┼───────────┘
↓
┌───────────┐
│ n8n │
└─────┬─────┘
↓
┌───────────┐
│ AI Agent │
└─────┬─────┘
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Telegram Google Sheets ThingSpeak
│ │ │
↓ ↓ ↓
Voice Alert Data Storage Dashboard
│
↓
USER
42. Suggested Project Modules
For your final documentation, divide the project into these modules:
Module 1 — Sensor Module
Responsible
for:
Distance measurement
Obstacle detection
Sensor filtering
Module 2 — ESP32
Control Module
Responsible for:
Sensor acquisition
Local decision making
Wi-Fi communication
Module 3 — Safety Module
Responsible for:
Vibration
Buzzer
Emergency response
Offline operation
Module 4 — IoT Module
Responsible for:
HTTP
Webhook
Cloud communication
Module 5 — n8n Automation Module
Responsible for:
Workflow
Data processing
Event routing
Notification automation
Module 6 — AI Agent Module
Responsible for:
Sensor interpretation
Risk explanation
Alert generation
Event reasoning
Module 7 — Notification Module
Responsible for:
Telegram
Text-to-speech
Voice alerts
Module 8 — Database Module
Responsible for:
Google Sheets
Event history
Telemetry
Module 9 — Dashboard Module
Responsible for:
ThingSpeak
Web dashboard
Real-time status
Historical graphs
43. Database Design
A more advanced implementation could use:
Device ID
Timestamp
Front Distance
Left Distance
Right Distance
Minimum Distance
Direction
Risk
Closing Speed
Predicted Time
Battery
Alert Sent
AI Message
Example:
SHOE01
2026-09-29 21:35:20
42
160
150
42
FRONT
DANGER
28 cm/s
1.5 sec
76%
YES
Obstacle very close ahead
44. Example AI Alert Logic
IF distance > 200
→ SAFE
ELSE IF distance > 100
→ CAUTION
ELSE IF distance > 50
→ WARNING
ELSE
→ DANGER
Then:
IF risk == DANGER
AND same_event == false
→ Generate voice alert
→ Telegram
→ Log event
For a real implementation, these thresholds should be configurable rather than hard-coded.
45. Security
Because the system communicates over the Internet, security should be included in the report.
Do not hard-code credentials in publicly shared firmware.
Use:
Wi-Fi credentials
↓
Secure configuration
and protect:
-
n8n webhook
-
Telegram bot token
-
Google credentials
-
ThingSpeak API keys
-
AI API credentials
Also consider:
HTTPS
Authentication
Secret management
Rate limiting
Input validation
46. Project Folder Structure
A clean implementation could look like:
AI-Smart-Shoe/
│
├── esp32/
│ ├── smart_shoe.ino
│ ├── sensors.h
│ ├── sensors.cpp
│ └── config.h
│
├── n8n/
│ ├── workflow.json
│ └── ai-agent-prompt.txt
│
├── telegram/
│ └── bot-config.md
│
├── dashboard/
│ ├── index.html
│ ├── style.css
│ └── app.js
│
├── documentation/
│ ├── project-report.md
│ ├── architecture.md
│ └── testing.md
│
└── README.md
47. Final Demonstration Sequence
For a college/project
demonstration, demonstrate it in this order:
STEP 1
Power ON smart shoe
↓
STEP 2
ESP32 connects to Wi-Fi
↓
STEP 3
Dashboard shows ONLINE
↓
STEP 4
Place object 2 meters away
↓
ESP32 → SAFE
↓
STEP 5
Move object closer
↓
ESP32 → CAUTION
↓
STEP 6
Move object to 70 cm
↓
ESP32 → WARNING
↓
STEP 7
Move object to 30–40 cm
↓
ESP32 → DANGER
↓
Local vibration/buzzer
↓
n8n receives event
↓
AI Agent processes event
↓
Telegram voice notification
↓
Google Sheets records event
↓
ThingSpeak updates graph
↓
Web dashboard updates
48. Final System Architecture in One Sentence
Your project can be summarized as:
An ESP32-based wearable assistive system that detects nearby obstacles using directional distance sensors, performs immediate local safety feedback, sends structured telemetry through Wi-Fi to an n8n automation layer, uses an AI agent for event interpretation and alert generation, delivers voice notifications through Telegram, records events in Google Sheets, and visualizes IoT telemetry through ThingSpeak and a web dashboard.
49. Recommended Final-Year Project Chapter Structure
For a full academic report, use:
CHAPTER 1 — INTRODUCTION
1.1 Background
1.2 Problem Statement
1.3 Motivation
1.4 Objectives
1.5 Scope
1.6 Proposed Solution
CHAPTER 2 — LITERATURE / TECHNOLOGY REVIEW
2.1 Assistive Technology
2.2 Smart Wearables
2.3 ESP32
2.4 Distance Sensors
2.5 IoT
2.6 n8n Automation
2.7 AI Agents
2.8 Telegram
2.9 Cloud Dashboards
CHAPTER 3 — SYSTEM ANALYSIS
3.1 Existing System
3.2 Existing-System Limitations
3.3 Proposed System
3.4 Functional Requirements
3.5 Non-functional Requirements
CHAPTER 4 — SYSTEM DESIGN
4.1 Architecture
4.2 Block Diagram
4.3 Circuit Diagram
4.4 Data Flow Diagram
4.5 Flowchart
4.6 Database Design
4.7 AI-Agent Architecture
CHAPTER 5 — HARDWARE IMPLEMENTATION
5.1 ESP32
5.2 Sensors
5.3 Vibration Motors
5.4 Buzzer
5.5 Power Supply
5.6 Physical Shoe Design
CHAPTER 6 — SOFTWARE IMPLEMENTATION
6.1 Arduino IDE
6.2 ESP32 Firmware
6.3 Wi-Fi
6.4 n8n
6.5 AI Agent
6.6 Telegram
6.7 Google Sheets
6.8 ThingSpeak
6.9 Web Dashboard
CHAPTER 7 — IMPLEMENTATION
7.1 Hardware Assembly
7.2 Firmware
7.3 n8n Workflow
7.4 AI Prompt
7.5 Telegram Integration
7.6 Cloud Integration
CHAPTER 8 — TESTING
8.1 Unit Testing
8.2 Sensor Testing
8.3 Integration Testing
8.4 AI Testing
8.5 Alert Testing
8.6 Network Failure Testing
8.7 Performance Testing
CHAPTER 9 — RESULTS
9.1 Detection Results
9.2 Latency
9.3 False Alerts
9.4 Prediction Results
9.5 Battery Results
9.6 Dashboard Results
CHAPTER 10 — CONCLUSION
10.1 Conclusion
10.2 Limitations
10.3 Future Scope
REFERENCES
APPENDIX
SOURCE CODE
50. What I would build next
For the actual implementation, I would use two safety paths:
┌───────────────┐
│ ESP32 │
└───────┬───────┘
│
┌─────────┴─────────┐
↓ ↓
LOCAL SAFETY PATH CLOUD PATH
│ │
↓ ↓
Vibration/Buzzer n8n
│
↓
AI Agent
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Telegram Sheets ThingSpeak
│
↓
Voice Alert
That gives you a much stronger engineering project than making the ESP32 completely dependent on an AI/cloud service.
If you want to turn this into an actual working prototype, the next useful deliverable is a complete implementation package: ESP32 wiring/circuit diagram + finalized Arduino code + exact n8n node-by-node workflow/JSON + Telegram bot setup + Google Sheets setup + ThingSpeak setup + AI-agent prompt + web dashboard + testing procedure + final-year-project report format.
Summary
AI Smart Shoes for Blind People with Obstacle Prediction is an IoT-based assistive wearable
system using ESP32, distance sensors, AI, n8n automation, Telegram voice alerts, Google Sheets, ThingSpeak, and a web dashboard.
Core Workflow
Distance Sensors
↓
ESP32
↓
Local Obstacle Detection
↓
Vibration / Buzzer
↓
Wi-Fi
↓
n8n Webhook
↓
Data Processing
↓
AI Agent
↓
┌────┼──────────────┐
↓ ↓ ↓
Telegram Google Sheets ThingSpeak
↓ ↓ ↓
Voice History Dashboard
Alert
Main Features
-
Front, left and right obstacle detection
-
Distance measurement in centimeters
-
Obstacle direction identification
-
Risk classification: SAFE / CAUTION / WARNING / DANGER
-
Local vibration and buzzer alerts
-
Wi-Fi connectivity using ESP32
-
n8n automation workflow
-
AI-agent-based sensor interpretation
-
Telegram voice notifications
-
Google Sheets event logging
-
ThingSpeak IoT visualization
-
Web-based monitoring dashboard
-
Alert-spam prevention
-
Battery monitoring
-
Optional emergency button
-
Future computer-vision capability
Obstacle Prediction
Basic
sensors provide obstacle detection and distance estimation. Prediction can be added by analyzing
distance over time:
Previous Distance
+
Current Distance
+
Time Difference
↓
Closing Speed
↓
Estimated Time-to-Obstacle
↓
Risk Prediction
Important
Design Principle
The shoe should not depend entirely on the Internet, n8n, or AI for immediate safety.
Sensor → ESP32 → Local Warning
│
└──→ Wi-Fi → n8n → AI → Telegram
Thus, even if Wi-Fi/cloud services fail, the local
obstacle warning can continue.
Project Documentation Structure
The complete project can be documented through:
-
Introduction
-
Problem statement and objectives
-
Literature/technology review
-
System analysis
-
System architecture
-
Hardware design
-
Circuit/schematic
-
ESP32 firmware
-
n8n workflow
-
AI-agent design
-
Telegram integration
-
Google Sheets integration
-
ThingSpeak dashboard
-
Web dashboard
-
Testing
-
Performance evaluation
-
Results
-
Limitations
-
Future scope
-
Conclusion
-
Source-code appendix
In short: the project combines wearable sensing + local safety + IoT automation + AI reasoning + voice accessibility + cloud data logging into one smart-shoe platform.
Yes.
This is a
good structure for a complete technical/project report. Below is the expanded documentation outline,
with what should be written in each chapter.
AI Smart Shoes for Blind People with Obstacle Prediction
ESP
32 + IoT + AI Agent + n8n + Telegram Voice Alerts + Google Sheets + ThingSpeak + Web Dashboard
1. Introduction
1.1 Background
Explain visual impairment, challenges in independent mobility, and how wearable technology and IoT can assist with environmental
awareness.
1.2 Project Overview
Describe the proposed smart shoe:
Sensors → ESP32 → Local Alert
↓
Wi-Fi
↓
n8n
↓
AI Agent
↓
Telegram Voice Alert
1.3 Motivation
Explain why a low
-cost, wearable, connected obstacle-detection system is being developed.
1.4 Objectives
-
Detect nearby obstacles.
-
Determine approximate obstacle direction.
-
Estimate distance.
-
Provide immediate local feedback.
-
Predict approaching obstacles using distance trends.
-
Send remote voice alerts.
-
Store sensor data.
-
Visualize sensor information.
-
Automate decision-making using n8n and an AI agent.
1.5 Scope
Define what the prototype does and does not do.
2. Problem Statement and Objectives
2.1 Problem Statement
Conventional mobility assistance may not provide electronic environmental information or remote event logging. The proposed system attempts
to provide an additional layer of obstacle awareness using wearable sensors and accessible audio/tactile feedback.
2.2 Proposed Solution
The system combines:
ESP32
+
Distance Sensors
+
Vibration/Buzzer
+
Wi-Fi
+
n8n
+
AI Agent
+
Telegram
+
Google Sheets
+
ThingSpeak
+
Web Dashboard
2.3 Functional Requirements
The system should:
-
Read sensors.
-
Calculate distance.
-
Identify direction.
-
Classify risk.
-
Activate local warnings.
-
Send telemetry.
-
Process events through n8n.
-
Generate appropriate alerts.
-
Store historical data.
-
Display system status.
3. Literature / Technology Review
Discuss existing technologies and explain the technology selected for
this project.
3.1 Assistive Technology
3.2 Electronic Travel Aids
3.3 Smart Wearables
3.4 Ultrasonic/ToF Sensors
3.5 ESP32
3.6 Internet of Things
3.7 AI and
Machine Learning
3.8 Agentic Automation
3.9 n8n
3.10 Telegram Bot and Voice Notifications
3.11 Google Sheets
3.12 ThingSpeak
3.13 Web Technologies
A
comparison table can then be included:
| Technology |
Role |
| ESP32 |
Edge controller |
| Ultrasonic/ToF |
Distance sensing |
| Vibration motor |
Tactile warning |
| Buzzer |
Local emergency warning |
| Wi-Fi |
Internet communication |
| n8n |
Workflow automation |
| AI Agent |
Event interpretation |
| Telegram |
Voice/text notification |
| Google Sheets |
Historical storage |
| ThingSpeak |
IoT visualization |
| HTML/CSS/JS |
Web dashboard |
4. System Analysis
4.1 Existing System
Describe traditional approaches
and existing electronic obstacle-detection concepts.
4.2 Limitations
Possible limitations include:
-
Limited directional awareness.
-
Lack of cloud connectivity.
-
Lack of historical data.
-
No automated notifications.
-
Limited personalization.
-
No event-processing layer.
4.3 Proposed System
SMART SHOE
│
┌───────────┴───────────┐
↓ ↓
Sensors ESP32
│
┌────────────┴────────────┐
↓ ↓
Local Safety Wi-Fi
│ │
↓ ↓
Vibration/Buzzer n8n
│
↓
AI Agent
│
┌─────────────────┼──────────────┐
↓ ↓ ↓
Telegram Sheets ThingSpeak
5. System Architecture
5.1 High-Level Architecture
┌───────────────────────────────────┐
│ SMART SHOE │
│ │
│ Front Sensor ─┐ │
│ Left Sensor ──┼→ ESP32 │
│ Right Sensor ─┘ │
│ │
│ Vibration ← ESP32 → Buzzer │
└─────────────────┬─────────────────┘
│
Wi-Fi
│
↓
┌───────────┐
│ n8n │
└─────┬─────┘
↓
┌─────────┐
│ AI Agent│
└────┬────┘
│
┌──────────┼───────────┐
↓ ↓ ↓
Telegram Sheets ThingSpeak
│
↓
User Voice
5.2 Data Flow
Sensor Measurement
↓
Data Filtering
↓
Distance Calculation
↓
Direction Detection
↓
Risk Classification
↓
n8n
↓
AI Interpretation
↓
Alert Decision
↓
Notification + Logging
6. Hardware Design
6.1 ESP
32
Explain:
-
Processor
-
GPIO
-
ADC
-
Wi-Fi
-
Power requirements
-
Programming interface
6.2 Distance Sensors
Use three sensors:
FRONT
↓
[Sensor F]
[Sensor L] SHOE [Sensor R]
6.3 Vibration Motors
Used for directional tactile feedback.
LEFT obstacle → Left vibration
RIGHT obstacle → Right vibration
FRONT obstacle → Both/central warning
6.4 Buzzer
Used for high-priority local warnings.
6.5 Battery
Explain battery, charging, protection and voltage regulation.
6.6 Emergency Button
Optional button for emergency events.
7. Circuit / Schematic
Include a proper circuit diagram showing:
ESP32
│
├── Front Sensor
├── Left Sensor
├── Right Sensor
├── Left Vibration Motor
├── Right Vibration Motor
├── Buzzer
├── Status LED
└── Emergency Button
Example GPIO table
| Component |
ESP32 |
| Front Trigger |
GPIO 5 |
| Front Echo |
GPIO 18 |
| Left Trigger |
GPIO 19 |
| Left Echo |
GPIO 21 |
| Right Trigger |
GPIO 22 |
| Right Echo |
GPIO 23 |
| Left Vibration |
GPIO 25 |
| Right Vibration |
GPIO 26 |
| Buzzer |
GPIO 27 |
| LED |
GPIO 2 |
| Button |
GPIO 4 |
For HC-SR04-type sensors, explain the required Echo voltage-level conversion before connecting to ESP32 GPIO.
8. ESP32 Firmware
This chapter contains the complete Arduino code.
Firmware responsibilities
Initialize
↓
Connect Wi-Fi
↓
Read sensors
↓
Filter readings
↓
Calculate minimum distance
↓
Determine direction
↓
Determine risk
↓
Local warning
↓
Send JSON to n8n
↓
Repeat
Example payload:
{
"device": "SMART_SHOE_01",
"front": 42.5,
"left": 160.2,
"right": 125.4,
"direction": "FRONT",
"risk": "DANGER"
}
The appendix should contain the complete final firmware, rather than only fragments.
9. n8n Workflow
This is one of the main innovations of the project.
Workflow
Webhook
↓
Validate Input
↓
Normalize Data
↓
Calculate Risk
↓
Store Sensor Data
↓
AI Agent
↓
Alert Decision
↓
Text-to-Speech
↓
Telegram
Parallel branches:
n8n
│
┌────────┼─────────┐
↓ ↓ ↓
AI Agent Sheets ThingSpeak
│
↓
Telegram
Explain every n8n node individually in the report.
10. AI-Agent Design
The AI agent receives structured sensor data, for example:
{
"front": 38,
"left": 150,
"right": 165,
"previous_front": 65
}
It determines:
Closest direction
↓
Risk
↓
Change over time
↓
Alert requirement
↓
Short voice message
Example output
{
"severity": "DANGER",
"direction": "FRONT",
"alert_required": true,
"voice_message": "Obstacle very close ahead."
}
The report should clearly distinguish sensor-based detection from genuine AI prediction.
11. Telegram Integration
Explain:
n8n
↓
Generate alert text
↓
Text-to-Speech
↓
Audio file
↓
Telegram Bot
↓
Smartphone
↓
User
Example:
"Obstacle very close on your left."
Include:
-
Bot creation
-
Authentication
-
Chat ID configuration
-
n8n Telegram node
-
Audio generation
-
Testing
12. Google Sheets Integration
Recommended columns:
| Timestamp |
Device |
Front |
Left |
Right |
Direction |
Risk |
Alert |
Explain how each n8n event becomes one spreadsheet record.
This
provides historical data for:
-
Analysis
-
Graphs
-
Testing
-
Event frequency
-
Performance evaluation
13. ThingSpeak Dashboard
Possible fields:
Field 1 → Front Distance
Field 2 → Left Distance
Field 3 → Right Distance
Field 4 → Risk
Field 5 → Closing Speed
Field 6 → Battery
Dashboard:
┌────────────────────────────┐
│ SMART SHOE IoT │
├────────────────────────────┤
│ Front 82 cm │
│ Left 160 cm │
│ Right 145 cm │
│ │
│ Status: WARNING │
├────────────────────────────┤
│ Distance Graph │
└────────────────────────────┘
14. Web Dashboard
The web application displays:
-
Device status
-
Sensor distances
-
Current risk
-
Direction
-
Battery
-
Latest AI message
-
Alert history
-
Sensor graphs
Example
AI SMART SHOE
────────────────────────
🟢 DEVICE ONLINE
FRONT LEFT RIGHT
82 cm 160 cm 145 cm
STATUS: WARNING
DIRECTION: FRONT
AI MESSAGE:
Obstacle approaching ahead.
LATEST ALERT:
21:35:42
15. Testing
Create separate test cases.
| Test |
Input |
Expected Result |
| No obstacle |
>200 cm |
SAFE |
| Front obstacle |
80 cm |
Warning |
| Left obstacle |
40 cm |
Left warning |
| Right obstacle |
35 cm |
Right warning |
| Very close |
<50 cm |
Danger |
| Wi-Fi failure |
Network OFF |
Local warning continues |
| Sensor failure |
Invalid data |
Sensor-error handling |
| Repeated obstacle |
Same event |
Alert suppression |
| Emergency button |
Press |
Emergency notification |
16. Performance Evaluation
Measure actual prototype performance.
Detection accuracy
Accuracy =
Correct detections
────────────────── × 100
Total tests
Alert latency
Alert Latency =
Telegram arrival time
−
Sensor detection time
Prediction error
Prediction Error =
|Predicted time − Actual time|
Battery performance
Measure:
Operating time
Average current
Wi-Fi consumption
Sensor consumption
Do not put invented performance percentages in the final report; obtain them through actual testing.
17. Results
Present experimental results using:
-
Tables
-
Graphs
-
Screenshots
-
Sensor readings
-
Telegram alerts
-
Google Sheets records
-
ThingSpeak charts
-
Dashboard screenshots
Example result table:
| Test |
Distance |
Direction |
System Result |
Alert |
| 1 |
220 cm |
None |
SAFE |
No |
| 2 |
95 cm |
Front |
WARNING |
Yes |
| 3 |
45 cm |
Left |
DANGER |
Yes |
| 4 |
38 cm |
Right |
DANGER |
Yes |
Use your actual measured results in the final version.
18. Limitations
Document limitations honestly:
-
Distance sensors cannot necessarily identify object type.
-
Sensor accuracy varies with environment.
-
Sensor placement affects coverage.
-
Cloud functions depend on network availability.
-
AI interpretation is not guaranteed to be correct.
-
The system should not be presented as a replacement for established mobility aids.
-
A prototype requires extensive real-world validation before safety-critical use.
19. Future Scope
Possible future improvements:
Computer Vision
Camera
↓
Edge AI
↓
Object Detection
↓
Person / Vehicle / Stair / Pole / Door
GPS
Add location information for remote assistance.
IMU
Use accelerometer/gyroscope data to estimate movement.
Better Sensor Fusion
Combine:
ToF
+
Ultrasonic
+
IMU
+
Camera
Advanced Prediction
Use historical sensor sequences to estimate:
Obstacle movement
Closing speed
Time-to-obstacle
Risk trend
Mobile Application
Develop a dedicated Android/iOS interface instead of relying solely on Telegram.
20. Conclusion
The conclusion should explain that the project demonstrates a complete edge-to-cloud assistive IoT architecture:
Physical Environment
↓
Sensors
↓
ESP32 Edge Device
↓
Local Safety
↓
IoT Connectivity
↓
n8n Automation
↓
AI Agent
↓
Voice Notification
↓
Cloud Data
↓
Dashboard
The project combines embedded systems, IoT, automation, AI, cloud data management and accessibility into one integrated prototype.
21. Source-Code Appendix
The final report should include the complete source code organized as:
APPENDIX A
ESP32 Firmware
APPENDIX B
Sensor Library / Functions
APPENDIX C
n8n Workflow
APPENDIX D
AI Agent Prompt
APPENDIX E
Telegram Integration
APPENDIX F
Web Dashboard
APPENDIX G
Google Sheets Configuration
APPENDIX H
ThingSpeak Configuration
Final Deliverable Set
For a complete project submission, the final package should contain:
📁 AI-Smart-Shoe-Project
│
├── 📄 Full Project Report
├── 📐 Block Diagram
├── 🔌 Circuit/Schematic
├── 💻 ESP32 Source Code
├── 🔄 n8n Workflow
├── 🤖 AI Agent Prompt
├── 📱 Telegram Bot Configuration
├── 📊 Google Sheets Template
├── 📈 ThingSpeak Dashboard
├── 🌐 Web Dashboard
├── 🧪 Testing Documentation
├── 📋 Results
└── 📚 References
This structure is suitable for expanding into a full detailed project report with chapter-by-chapter explanations, diagrams, tables, code, n8n workflow configuration, and implementation instructions.
