Project

# Title Team Members TA Documents Sponsor
76 Driver Fatigue System
Julio Cornejo
Vincent Ng
Maanas Sandeep Agrawal design_document1.pdf
final_paper1.pdf
proposal1.pdf
video
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.

Resonant Cavity Field Profiler

Salaj Ganesh, Max Goin, Furkan Yazici

Resonant Cavity Field Profiler

Featured Project

# Team Members:

- Max Goin (jgoin2)

- Furkan Yazici (fyazici2)

- Salaj Ganesh (salajg2)

# Problem

We are interested in completing the project proposal submitted by Starfire for designing a device to tune Resonant Cavity Particle Accelerators. We are working with Tom Houlahan, the engineer responsible for the project, and have met with him to discuss the project already.

Resonant Cavity Particle Accelerators require fine control and characterization of their electric field to function correctly. This can be accomplished by pulling a metal bead through the cavities displacing empty volume occupied by the field, resulting in measurable changes to its operation. This is typically done manually, which is very time-consuming (can take up to 2 days).

# Solution

We intend on massively speeding up this process by designing an apparatus to automate the process using a microcontroller and stepper motor driver. This device will move the bead through all 4 cavities of the accelerator while simultaneously making measurements to estimate the current field conditions in response to the bead. This will help technicians properly tune the cavities to obtain optimum performance.

# Solution Components

## MCU:

STM32Fxxx (depending on availability)

Supplies drive signals to a stepper motor to step the metal bead through the 4 quadrants of the RF cavity. Controls a front panel to indicate the current state of the system. Communicates to an external computer to allow the user to set operating conditions and to log position and field intensity data for further analysis.

An MCU with a decent onboard ADC and DAC would be preferred to keep design complexity minimum. Otherwise, high MIPS performance isn’t critical.

## Frequency-Lock Circuitry:

Maintains a drive frequency that is equal to the resonant frequency. A series of op-amps will filter and form a control loop from output signals from the RF front end before sampling by the ADCs. 2 Op-Amps will be required for this task with no specific performance requirements.

## AC/DC Conversion & Regulation:

Takes an AC voltage(120V, 60Hz) from the wall and supplies a stable DC voltage to power MCU and motor driver. Ripple output must meet minimum specifications as stated in the selected MCU datasheet.

## Stepper Drive:

IC to control a stepper motor. There are many options available, for example, a Trinamic TMC2100. Any stepper driver with a decent resolution will work just fine. The stepper motor will not experience large loading, so the part choice can be very flexible.

## ADC/DAC:

Samples feedback signals from the RF front end and outputs the digital signal to MCU. This component may also be built into the MCU.

## Front Panel Indicator:

Displays the system's current state, most likely a couple of LEDs indicating progress/completion of tuning.

## USB Interface:

Establishes communication between the MCU and computer. This component may also be built into the MCU.

## Software:

Logs the data gathered by the MCU for future use over the USB connection. The position of the metal ball and phase shift will be recorded for analysis.

## Test Bed:

We will have a small (~ 1 foot) proof of concept accelerator for the purposes of testing. It will be supplied by Starfire with the required hardware for testing. This can be left in the lab for us to use as needed. The final demonstration will be with a full-size accelerator.

# Criterion For Success:

- Demonstrate successful field characterization within the resonant cavities on a full-sized accelerator.

- Data will be logged on a PC for later use.

- Characterization completion will be faster than current methods.

- The device would not need any input from an operator until completion.

Project Videos