Project

# Title Team Members TA Documents Sponsor
76 Driver Fatigue System
Julio Cornejo
Vincent Ng
Maanas Sandeep Agrawal proposal1.pdf
Driver Fatigue System

Team Members:
* Julio Cornejo (jcorne23)
* Vincent Ng (vng20)

**Problem**

When driving for prolonged amounts of time, some key body movements and facial changes can be made due to drowsiness. The drowsiness, if unmonitored, can pose dangerous conditions for other drivers and the drivers themselves. Intoxication while driving is also a rampant issue; there is no universal breathalyzer that prohibits driving based on BAC. I propose this device that uses facial recognition and eye-level detection sensors and cameras to detect symptoms of fatigue along the road while also prohibiting intoxicated drivers from proceeding to drive. This device can monitor head position, yawns, and register long blinks. It can also track the driving duration and eventually register all these symptoms if it detects fatigue. Once enough triggers are set, an app interface can assess your tiredness or driving incapability via Wifi transmission. It can suggest and locate the nearest rest stop or call emergency contacts (set by the user). When certain drowsiness scores are reached, the user's BAC and live drowsiness rating will be displayed with in-house buzzer systems.

**Solution**

The system revolves around an algorithm that makes use of a variety of sensors and cameras. One is a breathalyzer that measures the blood alcohol concentration of the driver. Using the software, we monitor the live value and set triggers to call emergency contacts and monitor until a safe concentration for resumable driving. Drowsiness and tiredness can be detected in various ways ranging from yawn frequency, long blinks, and head tilts. They happen suddenly. Most traditional cars use your position in a lane to track tiredness. Tracking head movement and analyzing the face for more key indicators precisely provides more information that can be essential to identify when a driver needs to step away from the wheel and request a ride elsewhere. The PCB can be housed in a small, compact shape like a cube that sits over any dashboard with detachment features to trigger the BAC sensor correctly.

**Solution Components:**

**PCB Controller:**

The device will have operable buttons to measure and clear the sensor and turn on the components and precise data for use. ESP32-S3 is the microcontroller intended for this project since the WiFi connection is crucial.

**Sensor and Device Subsystem**

* OV2640 Camera Module (For eye & head movement detection)
* BNO055 IMU (For head tilt & movement tracking)
* DFRobot Gravity MQ-3 Sensor (For BAC detection)
* OLED DISPLAY (e.g., SSD1306) displays live-drowsiness score calculation and BAC reads.
* BUZZER (if there is a significant change in the drowsiness measure, we ring a buzzer for the first tier of detections).

**Power Subsystem**

Power Management (Li-ion battery) - A rechargeable lithium-ion battery for a recommended runtime of about 10 hours would suffice for long drives.

**Algorithm**

The most ethic-heavy aspect of this project is to design a rationale and fair approach to assess and set triggers for the alerts. Setting criteria for calculating a drowsiness score for periodic yawns, blink duration, and rampant head movements. Not to mention, algorithmically, we have to assess what constraints from the sensors classify a yawn or blink, which can be difficult depending on the light settings. The goal is to be processed within the ESP32-S3 as the algorithm's in-house computation, with the possibility of an out-of-PCB Raspberry PI for additional computation power (if necessary).
To capture blink frequency/length, we will be utilizing Haar cascades, or some sort of pretrained model if we decide to implement the raspberry pi for processing. For drowsiness detection, we will be implementing an Eye Aspect Ratio algorithm to check if the drivers eyes are closed and blink frequency/length will be tracked based on how many frames are in the eye closed EAR threshold and how many frames are in the eyes open EAR threshold.


**Sample Weighted Calculation (idea):**

Fatigue Score = (Weight1 * Blink Score) + (Weight2 * Yawn Score) + (Weight3 * Head Movement Score)
For example, Blink Score could be calculated as:
* Blink frequency (e.g., 0-5 blinks/min → score 0-50).
* Blink length (e.g., >500ms → score 0-50).
* Final Drowsiness Level:
- Score 0-30%: Alert (Buzzer or immediate audio alert)
- Score 30-60%: Warning
- Score 60-100%: Fatigued (Follow user designated-procedure)


**User Interface & Connectivity**

The PCB would send data via WIFI from the microcontroller through the ESP-32. Using HTML and CSS, we can design a mobile application that includes charts and emergency functionality to follow procedures like assigning and calling emergency contacts once a drowsiness or BAC threshold is reached. The focus is on a mobile application, as a driver usually has that in hand.

**Criterion for Success**

1. Accurate measurement of BAC levels: The device should be able to measure the BAC levels of the driver accurately. Having a professional police-enforced measure for comparison can help calibrate.

2. Effective detection of yawns, blinks, and tilting heads: The device should be able to classify and count how many yawns and blinks occur in timed driving intervals while actively updating and displaying the tiredness score for the driver to be wary. We can test this with varying yawn lengths and close-eye durations.

3. Fair Algorithm: The design is intended to save lives. We want the user to be able to set up a procedure when a threshold is set up. This can be calling driving services or an emergency contact once a BAC exceeds this.

4. Updated interface: The web interface should reflect updates and show graphic analytics to predict better when tiredness occurs and optimal driving times for all safety.

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.