Drowsiness and Alcohol Detection using Eye Aspect Ratio and Mouth Aspect Ratio

Drowsiness and Alcohol Detection using Eye Aspect Ratio and Mouth Aspect Ratio

Vadlamudi SreeLakshmi

Assistant Professor;

Department of Electronics and Communication Engineering Seshadri Rao Gudlavalleru Engineering College, Andhra Pradesh 521356, India

Matta Harthik, Govathoti Vamsi, Goriparthi Poojitha, Kesana Syam Kumar

U.G Students

Department of Electronics and Communication Engineering Seshadri Rao Gudlavalleru Engineering College, Andhra Pradesh 521356, India

Abstract – 1.35 million people didnt make it home last year. Mostly because someone fell asleep at the wheel, or thought they were fine after a few drinks. We built a device that watches for both. And for the yawning that comes before the actual nodding off. A camera tracks the drivers face. A sensor checks the breath. Step wrong on any front – eyes too heavy, mouth too wide, alcohol on the breath – and the system screams, cuts the engine, and pings the familys phone within seconds. We tested it on February 9th. Every alert worked. Motor stopped in under half a second. Ran for hours without crashing once.

Keywords – driver drowsiness; eye openness ratio; mouth stretch ratio; breath alcohol sensing; embedded IoT alerting; facial landmark detection; real-time mobile notification; vehicle immobilisation

and cloud link. They talk over a wire. The rest of this paper shows exactly what we built, what broke, what we fixed, and what the numbers looked like at the end.

1. SYSTEM DESIGN AND IMPLEMENTATION

   Building this in two layers vision host and embedded controller was partly a design choice, partly forced on us. The first attempt at running face detection on the microcontroller lasted about 40 minutes before the memory ran out. Shifting the vision work to a laptop and sending a single- byte result down the serial port fixed it immediately.

   1. Two-Layer Architecture

      1. INTRODUCTION

         This whole project started because of a phone call. Three months back, a cousin of one team member rang up shaken. Hed been driving home from a night shift, somewhere past the Vijayawada bypass, and woke up in the wrong lane. No warning from the car. No beep. Just drifted. He corrected and kept driving, heart pounding. That shouldnt happen. Nobody should be that close to an accident without the vehicle doing something.

         So we looked at what exists. Cameras that watch your eyes

         • sure, those are out there. Breathalysers sure. But nothing that does both in one unit. And definitely nothing that tells someone at home youre in trouble while its happening. Most of the research either builds a vision system and stops there [1], or builds a sensor system and stops there. The two halves of the problem just dont seem to meet in the published work, and the cloud notification piece is often missing entirely [4][5].

           The landmark-to-ratio approach to eye measurement has been around since a 2016 Czech workshop paper [6]. Its been reproduced so many times that its almost background knowledge. The maths isnt the challenge. The challenge is putting it together with real hardware, a breath sensor, and a live phone notification, and actually having it work outside a controlled lab. Thats the gap we closed.

           Our answer was a split architecture. Heavy computation on a laptop. A small embedded chip handles the sensor, actuators,

           Figure 1 maps the full system. On the left, a PC running Python handles all the facial geometry: acquires video frames, locates the face, drops 68 landmark points across brow, lids, and lips, and computes two ratios every frame. When either ratio crosses its threshold for long enough, one ASCII character goes down the USB serial link to the embedded controller 1 for eyes too closed, 2 for mouth too wide. The embedded chip reads the breath sensor, catches any incoming character, and decides what to do: buzzer, motor relay, LCD update, and cloud push. Figure 1 below shows all three panels of this flow.

           Fig. 1. Complete system architecture. Left panel: PC running Python

           USB camera feed, Dlib face and landmark detection (68 points), eye openness (EAR) and mouth stretch (MAR) computation, threshold decision, serial handoff (COM3, 115200 bps). Centre panel: ESP32 embedded controller breath sensor on GPIO 34, buzzer on GPIO 14, motor relay on GPIO 27, I²C character display (16×2,

           address 0x27), non-blocking alert timer. Right panel: Blynk cloud IoT platform alcohol gauge (V0), sleep/yawn/alcohol LED flags (V1V3), event-driven push notifications to paired smartphone over Wi-Fi.

   2. Measuring Eye Openness

      The eye openness ratio works like this. Six points mark each eye: two corners for the horizontal span, two upper-lid and two lower-lid points for the vertical gaps. The routine averages the two vertical measurements, then divides by the horizontal distance. Eyes wide open: ratio around 0.30. Eyes shut: drops to zero. Drowsy half-lidded eyes: somewhere in between.

      The 0.20 threshold wasnt scientific. We tried 0.25 first too many misses on people with naturally narrow eyes. Dropped to 0.15 too many false alarms from fast blinks. Three days of tweaking with different people sitting in front of the camera landed us at 0.20. A counter then requires this to hold for fifteen consecutive frames about half a second. Isolated blinks never triggered it. Sustained drowsy drooping always did.

   3. Catching Yawns Before They Matter

      Yawning was easier to detect than expected. Same idea as the eye metric but applied to the mouth: vertical opening divided by horizontal width. A genuine yawn pushes that ratio well past 0.30. Normal talking, partial mouth breathing, sneezing they all stay under it, mostly. Ten-frame persistence filters edge cases. Genuine yawns last two to four seconds. They always cleared the threshold. Admittedly, one dramatic sneeze from a team member triggered it once in several hours. Well live with that.

   4. Breath Alcohol Sensing

      Breath sampling is performed using a metal-oxide detector mounted on the dashboard mockup, angled toward the breathing zone. The sensitive element is a tin-oxide surface held at elevated temperature. Ethanol vapour shifts its resistance, which the embedded chip reads as a changing voltage on a 12- bit analog input values from 0 to 4095.

      The 45-second warm-up is annoying. Every time you power-cycle the thing, you wait. We tried shortening it. Readings went haywire at 20 seconds, still unstable at 30. Forty- five gave clean baselines every time. Firmware holds all threshold checks until that window closes.

      The 900 cutoff came from controlled ethanol spray testing. Below that: normal ambient air, hand lotion, the occasional coffee. Above it: deliberate ethanol exposure. We ran calibration three times. Held each time.

      Fig. 2. Metal-oxide breath alcohol sensor module. The domed element houses a tin-oxide surface, which is held at operating temperature by an internal heater. Four pins (VCC, GND, analog out, digital out) connect to ESP32 GPIO 34.

   5. Getting the Firmware Right

      The millis() fix seems obvious now. It wasnt. We spent close to two weeks wondering why notifications stopped after the first alert each session. The cloud platform needs a heartbeat every few seconds to maintain the connection. Our original firmware used a blocking three-second pause during each alarm cycle. That pause killedthe heartbeat. Connection dropped. Notifications vanished. Fix: replace delay() with a timestamp check. Loop runs freely. Heartbeats go out continuously. Simple once you know whats breaking it.

      Each pass through the main loop: read breath sensor, check serial buffer for incoming vision byte, service cloud connection, update LCD. Alert fires: set flag, record time, start buzzer, drop motor. Three seconds elapsed: restore everything, push the breath reading to the archive channel, clear the flag. Thats the whole cycle.

   6. Cloud Notification and Dashboard

      Every alert pushes a notification to a paired phone within about two to three seconds. Three event types are configured on the cloud platform: eye-closure fatigue, yawning, and breath alcohol. A circular gauge shows live breath readings continuously not just during alerts. A second logging channel accumulates those readings for trend analysis across sessions.

   7. Prototype Kit

   We assembled it on plywood. Unglamorous, but it let us swap components, probe voltages, and reroute wires without disassembling anything. Microcontroller board in the middle. Breath sensor forward-left, facing the breathing zone. Motor and driver board upper-right motor running means drive on, motor stopped means the system intervened. Character display lower-right. Buzzer centrally wired. The webcam sits on a small tripod at face height, USB to the laptop. Total component cost: under 1,800.

   Fig. 3. Hardware prototype during functional testing. Microcontroller board at centre-left; breath sensor at top-left; motor with relay driver at top-right; character display at bottom-right.

2. RESULTS

   1. How This Compares to What Exists

      Table I puts this system next to representative prior single- modality work. Vision-only builds cant check breath. Sensor- only builds cant see the face. Neither typically offers real-time phone notification or vehicle stop.

      TABLE I. CAPABILITY COMPARISON WITH PRIOR APPROACHES

      Feature	Vision-Only	Sensor-Only	This Work
      Drowsiness tracking	Yes	No	Yes
      Yawn identification	No	No	Yes
      Breath alcohol check	No	Yes	Yes
      Vehicle stop response	No	Rarely	Yes
      Remote IoT notify	Rarely	Rarely	Yes
      Live cloud dashboard	No	No	Yes

   2. Live Dashboard Readout

      Figure 4 shows the web console at 5:21 PM on February 9th. The breath reading sat at 795 safely under the 900 cutoff

      • and none of the three warning indicators were lit. Real data. Live session.

      Fig. 4. Live web dashboard at 5:21 PM, February 9th. Breath sensor reads 795 (threshold: 900). All three alert indicator widgets are inactive.

   3. Alert Emergency Notifications

      The most important question was simple: did the phone actually get notified? Figure 5 answers it across all three alert categories simultaneously. The left panel shows six alcohol- detection events at 5:29 PM we were spraying ethanol near the sensor. Smelled like a hospital ward for an hour after. Each alert arrived on the paired device within about two to three seconds. The centre panel shows eye-closure fatigue alerts clustering at 5:14 PM and 5:28 PM, orange indicator bars and a red unread dot confirming genuine delivery. The right panel shows two yawning alerts at 5:28 PM smaller in count but

      clearly present, firing from a completely independent detection channel.

      Alcohol Detected	Drowsiness Alert	Yawning Alert

      Fig. 5. Alert Emergency Notifications all three event types confirmed delivered on February 9th. Left: six Alcohol Detected events at 5:29 PM. Centre: Drowsiness Alert events at 5:14 PM and 5:28 PM. Right: two Yawning Alert events at 5:28 PM. Each notification arrived on the paired smartphone within 23 seconds of trigger.

   4. Full Results Summary

   Table II consolidates every structured test outcome from the February 9th session and the endurance runs that followed.

   TABLE II. MEASURED OUTCOMES BY TEST CATEGORY

   What We Tested	Condition	What Happened
   Eye-closure fatigue	Lid ratio below 0.20 for 15 frames	Buzzer on, motor stopped, cloud pinged
   Mouth-gape fatigue	Mouth ratio above 0.30 for 10 frames	Yawn event logged, phone notified
   Breath alcohol	Sensor reading above 900	Motor off within half a second
   Remote notification	All three event types	Push alert confirmed on paired phone
   Alert self-reset	3-second window	Everything restored automatically
   Long-haul endurance	Multi-hour session	Zero crashes. Not even close.

3. DISCUSSION

   1. What Went Better Than Expected

      Notification latency was the surprise. The chain is not short: serial byte to embedded chip, event logged to cloud, server processes it, push to phone. We expected five, maybe seven seconds. It averaged two to three. Fast enough that a guardian at home could know before the driver has gone more than a hundred metres past the trigger point.

      The yawn detector outperformed expectations too. We built it as a secondary channel, half-expecting noise. The two confirmed yawning events on February 9th both corresponded to genuine, observable yawns. The ten-frame persistence requirement did the filtering work. It just worked.

   2. What Wed Change

   The laptop is the obvious answer. Every other part of this build is genuinely embedded. We tested the vision pipeline briefly on a small single-board processor and got adequate frame rates, but didnt have time to integrate it before the deadline. Thats the next step.

   The breath sensor cant distinguish ethanol from other volatile compounds. During one session a team members hand sanitiser triggered a brief above-threshold reading. Electrochemical sensors solve this. They cost roughly ten times more. Fine for a prototype. Not for a product.

4. CONCLUSION AND FUTURE WORK

We set out to build something that catches a drowsy or impaired driver before an incident happens and tells someone. It does that. Three independent detection channels. Every alert type confirmed on February 9th. Motor stopped in under half a second. Extended sessions with no crashes. Thats the result.

Three things need to happen before this leaves the prototype stage. Laptop replaced by a dash-monted processor. Breath sensor swapped for a chemically selective unit. System tested with drivers who are genuinely tired, not students voluntarily closing their eyes under lab lights. None of those is technically hard. They just take time and resources we didnt have this semester.

ACKNOWLEDGMENT

Vadlamudi SreeLakshmi supervised this project and provided guidance throughout all design and testing phases. Dr. P Sai Vinay Kumar identified the blocking-delay firmware bug during a mid-project review, saving roughly 2 weeks of debugging. The project received no external funding.

REFERENCES

1. S. Sathasivam, A. Sidek, A. K. Mahamad, M. M. Som, S. Saon, and H. A. Ameen, Drowsiness detection system using eye aspect ratio technique, in Proc. IEEE SCOReD, Johor, Sep. 2020, pp. 448452.

2. K. Kaida et al., Validation of the Karolinska sleepiness scale against performance and EEG variables, Clinical Neurophysiology, vol. 117, no. 7, 2006.

3. K. Arai and R. Mardiyanto, Real-time blinking detection based on Gabor filter, Int. J. Recent Trends HCI, vol. 1, no. 3, pp. 33 45, 2010.

4. R. O. Mbouna, S. G. Kong, and M. G. Chun, Visual analysis of eye state and head pose for driver alertness monitoring, IEEE Trans. ITS, vol. 14, no. 3, 2013.

5. A. Dasgupta, A. George, S. L. Happy, and A. Routray, A vision- based system for monitoring the loss of attention in automotive drivers, IEEE Trans. ITS, vol. 14, no. 4, 2013.

6. T. Soukupova and J. Cech, Real-time eye blink detection using facial landmarks, in Proc. 21st CVWW, Rimske Toplice, Slovenia, 2016.

7. P. S. V. Kumar et al., IoT-based integrated health and environmental monitoring using ESP32, Int. J. Eng. Res. Technol., 2026.

8. A. Rosebrock, Eye blink detection with OpenCV, Python, and dlib, PyImageSearch, Apr. 2017.

9. C. B. S. Maior et al., Real-time classification for autonomous drowsiness detection using eye aspect ratio, Expert Systems with Applications, vol. 158, 2020.

10. M. A. Hossain, G. Muhammad, and A. R. Rahman, Cloud- assisted IIoT-enabled framework for health monitoring, IEEE IoT J., vol. 5, no. 2, pp. 896907, 2018.