2026‐09‐17‐Meeting‐1 - Sajeev-D/driver-monitoring-team2026280 GitHub Wiki
Present: [Names] | Absent: [Names or "None"] | Scribe: [Name]
1. Member Outline
1.1 Christopher — Problem Background & Motivation
- Did: Analyzed Transportation Canada's National Collision Database (TC NCDB) commercial vehicle fact sheet (2012–2021); drafted background/motivation framing and scope rationale.
- Found: Fatigue and distraction are listed separately in the NCDB. Both are among the top factors, but 73–96% of records have no factor listed, so the results show ranking rather than how common each factor actually is. TC also connects inattention with hypovigilance, suggesting they can be treated as different forms of reduced attention.
- Next: Draft the Project Goals and revise Problem Statement (if needed) section of the proposal, and outline viable verification approaches.
- Needs: Team decision on whether distraction is a Requirement or an Objective; confirm user narrowing to long-haul tractor trailer drivers.
1.2 Sally — Definitions of Terms Used for Fatigue, Drowsiness, and Distraction in Literature
- Did: Conducted a literature review on drowsiness, fatigue, distraction, and cognitive load, including established drowsiness rating scales such as the Karolinska Sleepiness Scale (KSS) and Wierwille & Ellsworth Observer Rating of Drowsiness.
- Found: Drowsiness is difficulty maintaining wakefulness, while fatigue is a broader state caused by factors such as insufficient sleep and prolonged time-on-task. Wierwille & Ellsworth measures observable drowsiness indicators like blinking, yawning, and head nodding, while KSS is a more widely recognized baseline. Distraction involves diverted attention and can be visual, manual, or cognitive. Cognitive load is difficult to measure, so we will exclude it from our project scope.
- Next: Draft the Project Goals and revise Problem Statement (if needed) section of the proposal, and outline viable verification approaches.
- Needs: Input on which cognitive states we should prioritize as model outputs (e.g., drowsiness and distraction) and how to distinguish them from the broader concept of fatigue in our project scope.
1.3 Sajeev — Current Approaches to Driver Drowsiness Detection
- Did: Conducted literature review on driver drowsiness detection methods, current commercial Driver Monitoring Systems (DMS) solutions, Electronic Logging Devices (ELD) regulations, causes of fatigue, and formal definitions of drowsiness.
- Found: Current solutions leave two major operational gaps:
- ELDs: Strictly time-based rules that fail to account for pre-drive fatigue or real-time physiological indicators.
- Vision DMS: Rely on rigid, population-wide thresholds (EAR, PERCLOS) that only detect drowsiness reactively ("too late"), and degrade significantly in low-light or dynamic cabin environments.
- Next: Revise Problem Statement (if needed) and draft the Project Goals section of the proposal, and outline viable verification approaches.
- Needs: Supervisor/team sign-off on framing our primary motivation around two specific failure modes: closing the ELD pre-drive fatigue gap and moving from reactive detection to predictive vigilance forecasting.
1.4 Apurva — Metrics for Defined Terms
- Did: Mapped each of Sally's definitions to a measurable signal, a ground-truth reference, and an evaluation metric. Reviewed PERCLOS validation history, published EAR/MAR thresholds, PVT scoring rules, and NHTSA's distraction limits. Wrote up the Glossary and Key Findings Pages.
- Found: A single pre-drive PVT is a calibration point, not ground truth — it only labels alert moments, so a study built that way yields zero drowsy examples to measure detection against. PVT also cannot exist at runtime, so personalised baselining needs its own in-vehicle calibration mechanism. Details and the threshold/scoping findings are on Key Findings Page.
- Next: Produce the mapping table (term → signal → reference → evaluation metric → target) for the proposal, with numeric pass/fail targets where the hardware decision does not block them. Draft the PVT/KSS checkpoint schedule for the REB application.
- Needs: An acceptable false-alarm-per-hour figure from the team, since that one number sets where every threshold lands and therefore what detection rate we can claim.
2. Decisions
- N/A
3. Action Items
| # | Item | Owner | Due |
|---|---|---|---|
| 1 | Christopher | ||
| 2 | Sally | ||
| 3 | Sajeev | ||
| 4 | Apurva |