Tuesday, 29 September 2026

AI Smart Shoes for Blind People with Obstacle Prediction

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:

  • No obstacle

  • Obstacle detected

  • Obstacle on the left

  • Obstacle on the right

  • Obstacle directly ahead

  • Very close obstacle

  • Repeated obstacle

  • Potentially dangerous situation

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:

  1. Develop a wearable obstacle-detection system using ESP32.

  2. Detect objects in front/left/right of the user.

  3. Estimate obstacle distance.

  4. Identify potentially dangerous obstacles.

  5. Provide immediate local feedback.

  6. Send sensor information to an IoT cloud/automation layer.

  7. Use n8n to automate data processing.

  8. Use an AI agent to interpret sensor events.

  9. Send voice notifications through Telegram.

  10. Record sensor information in Google Sheets.

  11. Visualize sensor data using ThingSpeak.

  12. Provide a web-based monitoring dashboard.

  13. Maintain an event history for analysis.

  14. Reduce unnecessary repeated notifications.

  15. 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:

  • Median filtering

  • Exponential moving average

  • Kalman filtering

  • Sensor fusion


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:

  1. Introduction

  2. Problem statement and objectives

  3. Literature/technology review

  4. System analysis

  5. System architecture

  6. Hardware design

  7. Circuit/schematic

  8. ESP32 firmware

  9. n8n workflow

  10. AI-agent design

  11. Telegram integration

  12. Google Sheets integration

  13. ThingSpeak dashboard

  14. Web dashboard

  15. Testing

  16. Performance evaluation

  17. Results

  18. Limitations

  19. Future scope

  20. Conclusion

  21. 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:

  1. Read sensors.

  2. Calculate distance.

  3. Identify direction.

  4. Classify risk.

  5. Activate local warnings.

  6. Send telemetry.

  7. Process events through n8n.

  8. Generate appropriate alerts.

  9. Store historical data.

  10. 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.

 

No comments:

Post a Comment