The problem
Drowning is silent and fast: a struggling swimmer cannot call for help, and a lone lifeguard cannot watch every corner of a busy pool at once. Automated pool monitoring is an active research area, but the honest framing for a student project is an alert aid, not a safety device — a vision system that flags suspicious motion patterns for a human to check, with documented failure modes and no life-safety claims. This project builds that aid: OpenCV frame differencing produces motion maps from pool camera feeds, pose cues from MediaPipe track swimmer movement, and a lightweight classifier scores motion sequences over a time window for distress-like patterns such as prolonged struggling or bobbing without net displacement. The alert logic requires sustained patterns so passing splashes and normal play do not become alerts, and every alert candidate is logged with a timestamp and snapshot for human review. The evaluation procedure runs on buyer-staged footage with volunteers acting out scenarios, because real drowning footage is neither available nor ethical to collect.
How it works
- Pool camera frames are sampled and background subtraction with frame differencing produces per-frame motion maps.
- Motion regions are filtered by area and persistence; static water ripple noise is suppressed with temporal smoothing.
- MediaPipe pose landmarks track swimmers, measuring vertical bobbing and displacement over the time window.
- A lightweight classifier scores each motion sequence for distress-like patterns — sustained struggling motion without net displacement.
- Patterns persisting across the time window become confirmed alert candidates logged with timestamp and snapshot; isolated blips are discarded.
- The notebook runs the buyer-staged evaluation: labeled scenarios are replayed through the pipeline and the alert rule's precision and recall are computed.
Tech stack:
- Python 3.10, OpenCV (frame differencing, motion maps)
- PyTorch (motion-sequence classifier training)
- MediaPipe pose (body landmarks and motion cues)
- NumPy, pandas (motion features and alert logs)
- Jupyter notebook (staged-footage evaluation procedure)
- Matplotlib (motion timelines and evaluation plots)
- Flask demo app with camera-feed upload interface
| Parameter | Value |
|---|---|
| Detector | Frame-differencing motion maps plus a motion-sequence classifier |
| Pose cues | MediaPipe body landmarks for bobbing and struggle-like motion |
| Alert logic | Distress-like motion sustained over a time window; single blips ignored |
| Evaluation | Precision and recall of the alert rule on buyer-staged footage, computed by the notebook |
| Input | Overhead or side-view pool camera feeds or video files |
| Output | Timestamped alert log with frame snapshots |
| Status | Educational prototype — not a safety device, never replaces supervision |
Project features
- Frame-differencing motion maps from pool camera feeds via OpenCV
- MediaPipe pose cues tracking swimmer movement across frames
- Motion-sequence classifier scoring struggle-like patterns over a time window
- Distress heuristics: prolonged splashing, bobbing without displacement
- Time-window alert rule suppressing single-blip false alerts
- Timestamped alert log with annotated frame snapshots
- Buyer-run evaluation procedure on staged footage (volunteers acting out scenarios)
- Notebook computing the alert rule's precision and recall on the staged set
What is included
- Complete source code (motion pipeline, pose cues, classifier, alert logic, demo app)
- Jupyter notebook with the buyer-run staged-footage evaluation procedure
- Project report PDF (background, motion methodology, evaluation, honest safety limits)
- PPT presentation for final review
- Viva Q&A preparation document (frame differencing, pose cues, time-window alerts, evaluation design)
- Setup guide (environment, camera placement, staging the evaluation footage, running the pipeline)
Limitations & prerequisites
- This is a prototype only, NOT a safety device: it never substitutes lifeguards or supervision, and it must not be deployed where people depend on it — not for real deployment.
- False negatives are the critical failure mode — a still, submerged victim produces little motion, so the system can miss exactly the cases that matter most; the report states this limitation explicitly.
- Busy pools, glare, reflections and swimmers outside the camera's view degrade detection; evaluation is on buyer-staged footage with volunteers, never on real incidents, for ethical reasons.
Frequently Asked Questions
How does it tell play from distress?
It doesn't understand intent — it scores motion patterns. Sustained struggling or bobbing without displacement over a time window triggers an alert candidate; normal play produces different motion signatures. Every alert is for human review, and the staged evaluation measures exactly this discrimination.
Why is the evaluation staged?
Real drowning footage is unavailable and unethical to collect. The notebook procedure replays buyer-staged scenarios — volunteers acting out normal swimming, play and distress patterns — and computes the alert rule's precision and recall on that labeled set.
What is the most dangerous limitation?
False negatives: a still, submerged swimmer generates almost no motion, which is precisely what this motion-based pipeline can miss. The report documents this openly — it is why the system must never be treated as a safety device.
Can it work at night?
Poorly. The pipeline depends on visible-light camera frames; night conditions, glare and heavy reflections degrade motion maps, and these coverage limits are documented in the report.
What camera setup does it need?
An overhead or side-view camera covering the pool area with a stable mount. Camera placement guidance, including coverage and mounting advice, is part of the setup guide.
Could this be used in a real pool?
No. It is an educational prototype for demonstrating vision-based motion analysis. Real pools need trained lifeguards, supervision and certified safety equipment — software like this must never be part of that equation. Suitable for B.E./B.Tech final-year projects in Computer Science, AI/ML and Data Science.
Components & software requirements
- Python 3.10, OpenCV (frame differencing, motion maps)
- PyTorch (motion-sequence classifier training)
- MediaPipe pose (body landmarks and motion cues)
- NumPy, pandas (motion features and alert logs)
- Jupyter notebook (staged-footage evaluation procedure)
- Matplotlib (motion timelines and evaluation plots)
- Flask demo app with camera-feed upload interface
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.