Smart Helmet

Smart Helmet Application — Complete Documentation

1. Overview and Purpose

The Smart Helmet Application is a comprehensive Internet of Things (IoT) solution designed to enhance the safety of two-wheeler riders. The core purpose of the system is to automatically detect accidents (crashes or severe impacts) and immediately notify emergency contacts with the precise GPS location of the rider.

In real-world scenarios, when a rider wearing the smart helmet is involved in an accident and rendered incapacitated, the system acts as an automated lifesaver. It eliminates the reliance on bystanders to call for help by autonomously triggering a loud buzzer on the helmet and sending an SMS alert with a Google Maps link to predefined emergency contacts via the connected smartphone.

2. Core Features

🔴 Real-Time Monitoring Dashboard

• Functionality: The app features a live dashboard that displays real-time telemetric data from the helmet. This includes the Acceleration parameters (X, Y, and Z axes), the calculated impact force (in Gs), and the current operational state of the system.
• Workflow: The ESP32 reads data from the MPU6050 accelerometer, calculates the magnitude of the gravitational force, and pushes it to the Firebase Realtime Database. The Flutter app listens to this Firebase node (/smart_helmet/data) via a continuous stream and visually updates the UI using fluid animations and dynamic line charts.

🛡️ Helmet Wear Detection

• Functionality: The system ensures that the helmet is actually being worn before activating the crash detection algorithm. It uses an IR (Infrared) sensor placed inside the helmet.
• Workflow: If the IR sensor detects the proximity of the rider's head, the helmet_worn state is set to true. Crash alerts are only processed if the helmet is confirmed to be on the rider’s head. This dramatically reduces false positives (e.g., dropping the helmet from a table).

🚨 Automated Crash Detection and Countdown Alert

• Functionality: When an impact exceeding a critical threshold (e.g., 2.5G) is detected, the app shifts into a full-screen red emergency mode.
• Workflow:
  1. The ESP32 detects the spike in G-force.
  2. If the spike persists for a set duration to rule out simple bumps, the state changes to CRASH_CONFIRMED.
  3. The ESP32 updates the crash_detected flag to true on Firebase.
  4. The Flutter app immediately catches this change and launches a full-screen alert with a visual timer countdown.
  5. The rider has this configured time window to cancel the alert if it was a false alarm. If the timer expires without user intervention, the app triggers the Emergency Dispatch system.

📍 GPS Location Fetching & 📱 SMS Dispatch

• Functionality: Sends precise geographic location data to emergency contacts.
• Workflow: Upon the cancellation countdown expiring, the app utilizes the device's GPS module (via the geolocator package) to fetch precise latitude and longitude coordinates. It formulates an urgent SMS string containing the rider's condition and a direct Google Maps link. This text message is automatically dispatched to all saved emergency contacts.

⚙️ Customizable Settings and Dynamic Synchronization

• Functionality: Users can change settings like the crash alert countdown window (e.g., 10s, 20s, 30s) or manage their emergency contacts directly from their phone.
• Workflow: When the user changes the countdown window in the app, this configuration is instantly updated on Firebase. The ESP32 firmware continuously reads this configuration, ensuring the hardware and software are perfectly synchronized in real time.

3. Uniqueness and Competitive Advantage

Compared to other similar solutions in the market, this app stands out for the following reasons:

• Bi-Directional IoT Sync: Unlike simple Bluetooth apps that lose connection easily or only stream data one-way, this system uses Wi-Fi and Firebase Realtime Database. This means the hardware and mobile app state remain synchronized continuously, and it allows for true bidirectional control.
• Remote Configuration: The app allows the user to change physical hardware behavior directly from the Flutter UI (like tweaking the response timer) seamlessly over the cloud.
• Intelligent False-Positive Rejection: By combining the IR wear detection sensor with a persistent time-based threshold for the accelerometer, the algorithm is highly robust. It can distinguish between dropping the helmet onto the ground and a high-speed accident occurring while the helmet is on the head.
• Premium UI/UX System: The app uses a modern Dark Mode UI with subtle micro-animations, pulsing status indicators, and live fl_chart integration, making it feel like a professional, high-end production product.

4. Development Challenges and Solutions

1. Real-Time State Synchronization Issues

• Problem: Earlier in development, connection states like esp32_online and helmet_worn were desynchronizing. The mobile app would sometimes incorrectly show the helmet as offline or not worn even when the hardware was active.
• Solution: Implemented an optimized continuous loop in the ESP32 firmware incorporating reliable heartbeat signals. Reduced the Firebase write latency by batching IoT variables into a unified JSON update. On the Flutter side, robust StreamBuilders were implemented to ensure the UI immediately repaints upon any remote Firebase data changes.

2. Eliminating False Positives

• Problem: Handling the helmet roughly, taking it off quickly, or riding over a large pothole was mistakenly triggering crash alerts.
• Solution: Developed a sophisticated state-machine-based spike detection algorithm for the ESP32. Instead of a simple hard threshold, the firmware requires the High G-force impact to remain high for a specific duration (persist >= 2000ms) to rule out sudden jarring. The algorithm is entirely locked out if the IR sensor reports the helmet is not currently being worn.

3. I2C Hardware Communication Delays

• Problem: Communicating with the MPU6050 via the I2C bus while simultaneously pushing heavy network requests to the Firebase server occasionally caused the main loop to choke and drop sensor frames.
• Solution: Optimized the I2C polling rate and shifted the Firebase payload execution to a non-blocking timeline. Network calls were minimized by utilizing ArduinoJson to construct a single payload string, drastically reducing the overhead compared to pushing multiple separate HTTP/Firebase writes per cycle.

4. Background Execution & Permissions

• Problem: Fetching accurate GPS location and dispatching automated SMS messages requires stringent runtime permissions on modern Android versions. Triggering alerts while the screen is locked or the app is marginalized poses significant lifecycle challenges.
• Solution: Integrated the permission_handler package gracefully, prompting users to accept critical hardware permissions. The app forces full-screen intents and uses localized sound/vibration alerts to ensure the user’s attention is captured during the critical countdown window prior to dispatching the SMS.