CHAPTER 1 INTRODUCTION Wildlife monitoring andhuman–wildlife conflict

mitigation require timely. detection and alerting of animal presence near human
settlements, farms, or protected zones.
Traditional monitoring methods (manual patrolling, trap cameras) struggle with
scalability, latency, and real-time responsiveness.
• Modern computer vision, powered by deep learning, enables automatic detection
of animals in camera feeds, providing immediate feedback to stakeholders.
• This project implements a real-time wild animal detection system using the
YOLOv8 object detection model wrapped in a Flask web application.
• The system captures frames from a webcam, detects pre-configured target
animals (e.g., lion, leopard, tiger, elephant, hyena, cheetah, bear, horse), and streams
the annotated videos to users via a web UI.
• In addition, it logs detection timestamps and captures simple temporal patterns
(for example, most active hours), and can trigger audio/visual alerts.
• Key contributions include • Integration of a production-grade object detector
(YOLOv8) with a lightweight, accessible web stack (Flask + Jinja templates).
• • Real-time streaming of annotated frames over MJPEG for low-latency user
response.
• • Retaining lightweight temporal detection history in memory for exploratory
pattern analysis.
• • A modular structure that allows configurable target classes and warning
mechanisms.
• Expected applications include peri-urban security, farm perimeter monitoring,
protected area research and education/training in computer vision for wildlife.
• Chapter 2 Literature Survey • Traditional surveillance and trap-camera workflows
rely on periodic human review.
• While reliable, they are laborious and delayed.
• Motion sensors improve efficiency but still require manual verification.
• • The deep learning-based detectors YOLO (You Only Look Once) series
(YOLOv3–v8) achieved strong real-time performance by formulating detection as a
single-step regression problem.
• YOLOv8 improves the accuracy-speed trade-off with an improved backbone,
enhancements, and training best practices.
• • Two-stage detectors (for example, Faster R-CNN) often yield higher accuracy.
Stream annotated frames with bounding boxes and labels to authenticated users •
Serve an MJPEG stream that updates continuously without manual refresh.
• Ensure that annotated frames reflect current inference output with minimal delay.
• Support at least one concurrent session reliably on typical developer hardware.
• Log per-animal detection timestamps and compute simple time-of-day patterns •
Record timestamps for each detection event per animal.
• Summarize distributions (eg, hourly histograms) to identify peak activity periods.

• Highlight history summaries through dedicated pages (animal time, animal patterns).
• Provide visual and audio alerts when detected • Show specific visual reaction near
the live feed when detected.
• Allow the user to select or trigger an audio alert; The alert must respond to the first
valid detection in the frame.
• Respect browser autoplay constraints by postponing audio until user interaction ends.
Deliverables for Functional Scope • Authenticated web pages for login, identity, time
and pattern visualization.
• A running backend that loads AnimalDetection_Yolov8pt and performs inference per
frame.
• A route that streams annotated frames as a multipart JPEG.
Acceptance Testing (Functional) • When fed a test image or recorded video known to
contain a target species, the system must display at least a correct bounding box and a
label with non-zero confidence.
• Opening the detection page after login must show a live, updating stream within 5
seconds.
• The Animal Timing page must list at least one timestamp after an observed detection.
• Toggling the selected animal filter must restrict detections to the chosen species.
• Non-Functional Objectives • Low latency from camera capture to browser display •
Target end-to-end latency under 300–500 ms on a mid-range CPU; under 200 ms with
GPU acceleration (aspirational).
• Stream should maintain at least ~10–15 FPS on CPU-only systems; higher with GPU.
• Maintainability through clean separation of concerns • Separate inference logic,
streaming generator, and route handlers for clarity.
• Keep templates decoupled from logic; avoid heavy embedded scripts in templates.
• Provide clear variable naming and self-explanatory structures for future contributors.
• Configurability of detected classes and alert preferences • Expose the
selection of animal classes via UI or route; default to “all” • Allow the user to
choose/audio file options that reside in static/.
• Keep configuration localized and easy to extend for new species.
• Usability via a minimal, clear web UI • Provide intuitive navigation with a
persistent navbar and clear page titles.
• Keep detection status and alert indicators prominent but unobtrusive.
• Ensure layouts remain usable across typical laptop screen sizes.
Acceptance tests (non-functional) • System must not crash if the webcam is briefly
unavailable; it should log an error and recover or notify the user.
• The UI must render correctly on current versions of Chrome/Edge/Firefox.
• Switching between pages should not disrupt an active stream more than necessary.
• Research/Educational Objectives • Demonstrate end-to-end integration of
YOLOv8 with a web service • Show a complete pipeline capture → inference →
annotation → streaming → UI interaction.
• Provide a baseline that students can modify (eg, thresholds, NMS, model variants).
• Provide a baseline system that can be extended • Enable future work on
persistence (SQLite/PostgreSQL), multi-camera inputs, and improved analytics
(trend analysis, false-positive/negative review).
• Offer a practical example for experimenting with domain adaptation, transfer
learning, and active learning in wildlife contexts.
Evaluation criteria (research/education) • Clarity of architecture and code organization for
teaching purposes.
• Ease of integrating new datasets or models with minimal plumbing changes.
• Ability to reproduce results across machines following the READMEmd.
• Measurable KPIs and Targets • Latency median end-to-end latency ≤ 500 ms
(CPU); ≤ 300 ms with GPU (stretch).
• Throughput stable stream at ≥ 10 FPS on CPU; ≥ 20 FPS with GPU (hardware-
dependent).
• Detection logging integrity 100% of frames with at least one detection
append a timestamp entry for the respective species.
• Uptime during a 30-minute continuous session no unhandled exceptions;
acceptable memory growth bounded and stable.
• Constraints and Assumptions • Constraints • Commodity hardware; GPU may not be
available.
• Browser autoplay policies may block audio until the user interacts.
• In-memory logging is volatile; data is lost on restart.

• Assumptions • A compatible YOLOv8 weight file is provided at startup.

• Environmental lighting is sufficient for detection; camera placement is reasonable.
• Single camera input is adequate for the initial scope.
• Stakeholders and Scope • Stakeholders • End users researchers, farmers, security
personnel, students.
• Developers/maintainers course staff, lab members, contributors.
• In-scope • Single-camera, local webcam streaming.
• Real-time detection, visual overlays, basic alerting and time-based summaries.
• Out-of-scope (for this phase) • Multi-user role-based access control, fine-grained
permissions.
• Persistent databases, large-scale analytics dashboards.
• Multi-camera orchestration and distributed processing.
• Automated notifications via SMS/email/IoT.
• • Success criteria and validation plan • Functional purity Found animals are visible
with bounding boxes and labels; Recorded timestamps per event; Pattern views represent
logged data.
• • The display stream remains responsive and visually smooth on target hardware.
• • Usability Users can navigate between login, identity, time and pattern pages without
any confusion; The alerts are noticeable and helpful.
• • The robustness system handles camera errors and model load failures beautifully
with clear feedback.
• • Risk and Mitigation • False positives/negatives in challenging scenes • Mitigation
offers class filtering; Add threshold tuning UI later; Consider fine-tuning.
• • Browser audio restrictions • Minimizing prompt user action to enable audio; Provide
clear UI cues.
• • Model size/performance trade-offs • Mitigation allows swapping in smaller YOLOv8
variants for CPU usage only.
• • Volatile logging • Mitigation plan for database integration in future
iterations.
• This objectives section defines what the system does, how well it should do it,
who it serves, and how success will be measured, ensuring a clear basis for
implementation and evaluation in the subsequent methodology and results
sections.
• Chapter 4 Problem Statement This section formalizes the real-world problem,
context, and limitations for the wild animal detection system, establishing
measurable success criteria and risks to guide implementation and evaluation.
• 41 Key Problem • Detect the presence of specified wild animals in a live
video feed with minimal latency and sufficient accuracy using commodity
hardware and a lightweight web interface and alert human operators.
• • Provide immediate, understandable feedback (visual/audio) to support
temporal analysis (for example, peak hours) and record detection events.
• 42 Context and Rationale • Manual monitoring (guards, post-hoc review of
footage) is labor-intensive and slow, increasing the risk of human-wildlife
conflict and property damage.
• • A practical, real-time solution with a clear UI and basic analytics can
improve feedback, awareness and evidence collection for decision making,
training and research.
• 43 Users and Environment • Primary users are farmers, security personnel
along wildlife corridors, conservation field teams, and students learning CV
deployment.
• • Operating environment farm perimeter, reserve edge, low light or variable
weather; Typical constraints include intermittent connectivity and limited
computing resources.
• 44 Formal Problem Definition • Input continuous frames from a local
webcam. Output for each frame, a set of detections D = {(class, bbox, score)}
filtered to target species; an annotated stream; logging of per-detection
timestamps.
• • The objective is to minimize end-to-end latency while
maintaining acceptable detection performance and stable user
experience.
• • System Behavior Authenticated users can view live
annotated streams, view alerts, and browse time-based
summaries.
• 45 Constraints • Hardware Consumer-grade CPU; Optional
GPU is not guaranteed.
• • Audio autoplay may be restricted until user interaction as
per browser policies.
• • Data persistence The initial design uses in-memory logging
(unstable across restarts).
• • Single camera source for scope; Limited concurrency.
• 46 Validations • A compatible YOLOv8 weight file
(animaldetection_yolov8pt) is available.
•
• • Camera placement and lighting are appropriate for
identification.
• • Users can access the system over the local network and
authenticate through session-based login.
• 47 In-Scope vs.
• Out of Scope • In Scope • Real-time detection of predefined species with a webcam.
• • MJPEG streaming with bounding boxes/labels and basic alerts.
• • Per-animal timestamp logging and simple day-to-day time pattern summaries.
• • Out of scope (current stage) • Multi-camera orchestration, cloud scaling, or
distributed processing.
• • Continuous database and advanced analytics dashboard.
• • Role-based access control, HTTPS/TLS, and compliance [Link]
off-platform notifications (SMS/email/IoT).
48 Success Criteria • Functional • Correct rendering of live annotated frames after login;
Identification appears with labels and boxes.
• Record timestamp for detected species; Time/Pattern pages show non-blank summaries
after events.
• Alerts are visible (and audio where allowed) in the stream context.
• Performance • Achieve responsive viewing targets ≥10 fps on CPU hardware only; Less
anxiety felt by the user.
• End-to-end latency (capture → display) typically ≤500 ms on CPU; Better with GPU
where available.
• Reliability/Robustness • Handle transient camera read errors gracefully; Log problems
and attempt recovery.
• At least 30 minutes of stable operation without handled exceptions or uncontrolled
memory growth.
• Usability • Clear navigation (login, identity, time, patterns).
• Minimal configuration steps for general use.49 KPIs and Measurable Targets • Latency
median ≤500 ms (CPU); stretch ≤300 ms (GPU).
• Throughput ≥10 FPS sustained on CPU; ≥20 FPS with GPU (hardware-dependent).
• Logging integrity 100% of frames with valid detections append timestamps for those
species.
• Uptime 30-minute continuous session with zero unhandled exceptions and
memory usage within acceptable bounds.
410 Risks and Mitigations • False positives/negatives due to occlusion, motion blur,
night scenes • Mitigate via class filtering, threshold tuning, and future fine-tuning on
local data.
• Audio blocked by browser policies • Prompt user interaction; provide visible alerts as
fallback.
• Volatile in-memory history • Plan DB integration (SQLite/PostgreSQL) in future
iteration.
• Performance variance across devices • Allow swapping to smaller YOLO variants;
document expected specs.
• Security limitations (basic session auth) • Scope acknowledged; future work
to add HTTPS and RBAC. 411 Ethical and Privacy Considerations • Ensure
feeds are used for safety and conservation, not invasive surveillance of
individuals.
• If extended to public areas or multi-user access, implement consent and data retention
policies.
• Avoid logging personally identifiable information; store only necessary metadata.
412 Representative Use Cases • Farm perimeter monitoring alert when elephants or big
cats approach at night.
• Conservation research quantify species activity peaks to inform patrol schedules.
• Education live demonstration for courses on CV deployment and streaming inference.
413 User Stories • As a logged-in user, I want to see a live, annotated stream so I can
immediately recognize animal presence.
• As a user, I want clear alerts when detections occur so I don’t miss critical events
while watching.
• As a user, I want to view timestamps and hourly patterns so I can understand peak
activity times.
• As a user, I want to filter by species to focus on high-risk animals.
414 Evaluation Plan • Functional tests with known images/videos for each target class
to verify correct detection and labeling.
• Latency and
FPS benchmarking
on CPU vs. GPU
(if available).
• Long-run stability test (≥30 minutes) to monitor errors, memory growth, and
responsiveness.
• UX checks across modern browsers (Chrome/Edge/Firefox) for stream and alert
behavior.
This problem statement frames an end-to-end, real-time detection and alerting
challenge constrained by commodity hardware and simple web delivery, with explicit
success metrics and a clear boundary between

current scope and planned enhancements.

CHAPTER 5 SYSTEM REQUIREMENTS 5) SYSTEM REQUIREMENTS This
section specifies functional and non-functional requirements, software/hardware
prerequisites, data and interface requirements, constraints, assumptions, and
acceptance criteria for the Wild Animal Detection System.
• 51 Functional Requirements • FR-1 Login and Session • The system shall provide
a login page and maintain session-based authentication for access to identification
and analysis pages.
• • FR-2 Video Capture • The system will capture frames from the local webcam
using OpenCV.
• • FR-3 Model Inference • The system will load a YOLOv8 model from
AnimalDetection_yolov8pt at startup and make inferences per frame.
• • FR-4 Class Filtering • The system will allow users to monitor all supported
species or select a single species for detection filtering.
• • FR-5 Annotated Streaming • The system will render bounding boxes, labels and
(optionally) confidence scores on frames and stream them to the browser via
MJPEG.
• • FR-6 Detection Alert • When an animal is detected the system will display a
clear visual alert and, where permitted by the browser, play an audio alert from
static/.
• • FR-7 Event Logging (In-Memory) • The system will store per animal
identification timestamp in memory during runtime.
• • FR-8 Analytics View • The system will display a • Animal Timing list of
timestamps per animal.
• • Animal patterns simple frequency summaries (for example, by hour).
• • FR-9 Navigation • The system will provide clear navigation between Index,
Login, Detect, Animal_Timing and Animal_Pattern.
• • FR-10 Graceful Shutdown/Stop • The system will release the camera upon
stop/shutdown and handle stream termination cleanly.
• 52 Non-Functional Requirements • Performance • NFR-P1 Latency Mean
Capture→Inference→Encode→Performance Latency ≤ 500 ms on CPU only; ≤ 300
ms on capable GPU (target).
• • NFR-P2 throughput sustained ≥ 10 fps on CPU-only mid-range hardware; ≥ 20
FPS on GPU (hardware-dependent).
• Reliability & Robustness • NFR-R1 The system shall handle temporary camera
read failures by logging errors and attempting r ecovery.
• NFR-R2 The system shall run for 30 minutes without unhandled exceptions or
excessive memory growth.
• • Usability • The NFR-U1 UI will be readable and navigable on standard laptop
screens; The navbar remains on all pages.
• • NFR-U2 alerts shall be visible and understandable without any ambiguity.
• • Security • NFR-S1 pages requiring detection and analytics access will be protected
by session-based authentication.
• • The NFR-S2 secret key will be configurable via environment variables in
production.
• • Maintenance • NFR-M1 separation of concerns estimation, streaming generator and
route handler will be separate.
• • NFR-M2 will use descriptive names and minimal inline arguments in code
templates.
• Portability/Deployability • NFR-D1 The system shall run on Windows/macOS/Linux
with Python 311+.
• NFR-D2 Configuration for model path and alert files shall be environment- or
file- based, requiring no code changes for typical adjustments.
• Compliance/Ethics • NFR-C1 The system shall avoid logging personally
identifiable information and clearly scope usage for safety and conservation
contexts.
53 Software Requirements • Runtime • Python 311+ • Core Libraries • Flask (web
framework, sessions, routes) • Jinja2 (templating) • OpenCV (cv2) for camera capture
and image encoding • Ultralytics YOLOv8 for inference
• Supporting Files • apppy (Flask app, routes, streaming, inference integration) •
Templates in templates/ (basehtml, indexhtml, loginhtml, detecthtml, animal_timin
ghtml, animal_patternhtml) • Static assets in static/ (drummp3, wildanimalpng,
optional audio files) • requirementstxt listing pinned dependencies • Model weights
animaldetection_yolov8pt in project root • Browser Compatibility • Modern
Chromium-based and Gecko-based browsers (Chrome, Edge, Firefox) supporting
MJPEG streams 54 Hardware Requirements • Minimum • CPU 4- core modern CPU •
RAM 8 GB • Camera USB webcam accessible as device 0 • Recommended • GPU
(CUDA- capable) for improved throughput/latency • RAM 16 GB for smoother
multitasking • Storage • Sufficient space

for Python environment, dependencies, and model weights (~1–2 GB) 55 Data
Requirements • Model Weights • animaldetection_yolov8pt must be present and
compatible with Ultralytics YOLOv8 API.
• Runtime State • In-memory structures • detection_history per species list of
datetime • overall_detection_timestamps list of datetime • selected_animal_filter
string • selected_sound_file string • Persistence (Future) • Optional DB
(SQLite/PostgreSQL) for persistent storage of detections, to be added in later phases.
56 Interface Requirements • User Interface • index landing page with project info and
CTA to login.
• login form leading to authenticated session on success.
• detect page embedding the MJPEG stream and alert UI; controls for animal filter and
sound selection.
• animal_timing listing timestamps per species.
• animal_pattern visualizing frequency summaries (eg, by hour).
• Web/API Endpoints (Illustrative) • GET / → indexhtml • GET/POST /login →
authentication • GET /detect → detection UI • GET /video_feed → multipart MJPEG
stream • POST /select_animal → set selected_animal_filter
• POST /select_sound → set selected_sound_file • GET /animal_timing → timing view
• GET /animal_pattern
→ pattern view • GET /logout → clear session, redirect to / • Media Handling •
MJPEG multipart/x-mixed- replace; boundary=frame with JPEG-encoded frames •
Audio served from static/, playback subject to browser policies 57 Configuration
Requirements • Model path configurable (default animaldetection_yolov8pt).
• Alert sound file selectable via UI; files reside in static/.
• Class filtering via UI or server-side default TARGET_CLASS_IDS.
• Secret key configurable via environment variable in production.
58 Operational Requirements • Start/Stop • The app shall start with a single
command (python apppy) and bind to [Link] by default.
• Monitoring & Logs • Console logs for camera availability, model loading, and stream
status.
• Error Handling • Graceful error messages for missing model file, camera
failure, or permission issues. 59 Constraints & Assumptions • Constraints •
Single-camera support in current scope.
• In-memory event logging (lost on restart).
• Audio playback constrained by browser autoplay policy.
• Assumptions • Users interact locally or within a trusted LAN.
• Adequate lighting and camera placement for target species detection.
• The model is trained on species/classes of interest.
510 Security Requirements • Session-based authentication; detection and analytics pages
require login.
• Secret key shall not be hard-coded in production; loaded from environment.
• No external exposure without HTTPS and further hardening in production contexts.
511 Installation & Deployment Requirements • Install dependencies pip install -r
requirementstxt.
• Place model weights in project root.
• Run via python apppy.
• For production recommend WSGI (eg, Gunicorn) behind a reverse proxy, TLS
termination, environment-based configuration, and proper logging.
512 Acceptance Criteria • AC-1 After login, the detection page begins streaming
annotated frames within 5 seconds.
• AC-2 When a test video/image with a target species is shown to the camera, at
least one correct bounding box and label appears.
• AC-3 Detection timestamps populate the Animal Timing page; the Animal
Pattern page shows non-empty summaries after events.
• AC-4 Latency is visibly responsive and FPS is stable on the target hardware.
• AC-5 System runs for 30 minutes without unhandled exceptions;
camera is released on shutdown. 513 Future (Optional) Requirements •
Database-backed persistence and analytics dashboards.
• Multi-camera and RTSP ingest with UI for switching/tiling.
• Role-based access control, audit logs, and HTTPS by default.
• Advanced alerting (SMS/email/IoT) with configurable rules.
• Threshold and NMS tuning UI; model variant selection; edge deployment
(Jetson)• Added a comprehensive System Requirements section covering
functional, non- functional, software/hardware, data, interfaces,

configuration, ops, constraints, security, deployment, and acceptance criteria, aligned

with your current Flask + YOLOv8 implementation.
• Chapter 6 Motivation This project addresses the practical, social and educational
need for responsive wildlife monitoring by combining modern computer vision
(YOLOv8) with an accessible web interface (Flask). Motivation extends to impact,
feasibility and learning value.
• 61 Social and Practical Motivation • Early detection of human-wildlife conflict
can prevent crop losses, livestock predation and dangerous encounters near farms and
village fringes.
• • Situational awareness A live, annotated stream and alerts increase alertness
during high-risk hours, aiding rapid response.
• • Evidence and accountability log timestamps support incident reporting, patrol
planning and policy-making.
• • Accessibility Low-cost hardware and simple deployment enable community
groups, schools and small conservation teams to adopt otherwise inaccessible
technology.
• 62 Technical Motivation • Real-Time Inference YOLOv8 achieves a strong
accuracy-latency trade-off, enabling near-live response on commodity devices.
• • Lightweight delivery A Flask + MJPEG pipeline reduces complexity (no heavy
streaming infra) while remaining robust and widely compatible with browsers.
• • Modularity Clear separation of concerns (capture → inference → annotation →
streaming → UI) facilitates maintenance and feature development (e.g., persistence,
multi-camera).
• • Extensibility Class filtering, pluggable alert sounds, and structured conditions
pave the way for per-site customization, additional species, and policy rules.
• 63 Academic and Academic Motivation • End-to-end example full-stack ML
deployment demonstrating data capture, model serving, UI, and basic analytics useful
in coursework and capstone projects.
• • Research baseline establishes a reproducible platform for transfer learning,
domain adaptation, and active experiments.
• Skill-building Offers hands-on exposure to computer vision, streaming, web
development, and human–system interaction considerations.
64 User-Centric Motivation • Ease of use Minimal setup, intuitive navigation, and
immediate visual cues reduce operator burden.
• Focus and control Species filter helps users focus on high-risk animals;
alert selection supports different operational contexts (quiet vs.
loud) • Transparency Overlay boxes and labels build trust in system decisions,
fostering faster judgment and corrective action.
65 Design Principles Motivating the Architecture • Simplicity first Prefer MJPEG over
complex streaming stacks for reliability and maintainability.
• Responsiveness Optimize the capture→inference→display loop for perceptual
smoothness and low latency.
• Graceful degradation In-memory logging and single- camera scope deliver a
working baseline today, with a clear path to DB and scaling tomorrow.
• Configurability Keep class lists, alerts, and thresholds easy to
modify without code rewrites. 66 Trade-offs and Rationale • In-
memory vs.
persistent storage Chosen for speed and simplicity; future DB integration is planned to
retain history.
• Single-stage detector (YOLOv8) vs.
two-stage Prioritizes speed and usability in the field over marginal accuracy gains.
• MJPEG vs.
adaptive streaming MJPEG is simpler and cross-browser friendly; advanced protocols
can be added later if needed.
67 Expected Benefits • Operational Faster response to animal presence; improved night-
time vigilance via alerts.
• Analytical Basic activity patterns enable better patrol scheduling and resource
allocation.
• Educational A concrete, modifiable codebase lowers barriers for student projects and
demonstrations.
• Community A template others can fork and adapt for local species and conditions.
68 Risks and Mitigation (Motivational Framing) • False detections in challenging
conditions • Mitigation class filters, threshold tuning, future fine-tuning on local data.

• Browser audio policies • Mitigation prompt for interaction; maintain strong visual
alerts as fallback.
• Hardware variability • Mitigation allow smaller model variants; document expected
performance ranges.
• Data volatility (no persistence yet) • Mitigation plan DB integration as the next
evolution.
69 Stakeholder Value • Farmers/security Immediate alerts and visual proof; better timing
for patrols.
• Conservation teams Low-cost trial deployments; quick iteration for field constraints.
• Students/educators A realistic, end-to-end ML system to learn and extend.
• Researchers/engineers A lean baseline to prototype, benchmark, and publish
improvements.
610 Ethics and Sustainability • Purpose-limited use Designed for safety and
conservation, not surveillance of individuals.
• Data minimization Store only necessary metadata; add consent and retention policies
when deploying publicly.
• Resource efficiency Runs on modest hardware; improves over time with
selective optimizations and edge accelerators.
611 Illustrative Scenarios • Farm perimeter at dusk System flags elephants early,
triggering lights/human intervention.
• Reserve edge monitoring Patterns reveal peak hours for big cats, guiding patrol routes.
• Classroom demo Students visualize detection latency, tweak filters, and
measure FPS impacts of model variants.
612 Vision for Growth • Persistence and dashboards for trends and heatmaps.
• Multi-camera/RTSP support and multi-user dashboards.
• Robust alerting (SMS/email/IoT), geofencing, and automated deterrence triggers.
• Security hardening, HTTPS, and role-based access control for broader deployments.
• Provided a comprehensive Motivation section covering impact, technical
rationale, educational value, design trade-offs, benefits, risks, stakeholders, ethics,
scenarios, and growth path, aligned with your current Flask + YOLOv8
implementation.
CHAPTER 7 METHODOLOGY 71 System Overview • Purpose Real-time detection
of predefined wild animals from a webcam stream with visual/audio alerts and time-
based summaries.
• Core pipeline capture → inference (YOLOv8) → annotation → MJPEG
streaming → UI alerts → timestamp logging → simple analytics.
72 High-Level Architecture • Client side The browser renders the UI, shows the
MJPEG stream, plays alerts, and sends simple controls (choose animal, choose sound).
• Server side Flask handles routes, sessions, and authentication; a generator yields
JPEG frames; YOLOv8 runs inference; in-memory state stores timestamps, filters,
flags.
• Camera OpenCV pulls frames from the webcam.
• Data flow Camera → Inference → MJPEG generator → Browser; inference
events update state; user controls post back to routes.
73 Processing Flow (Activity) What it shows • Startup Load YOLO weights, user logs in.
• Streaming loop Read frame → run YOLO → if detections, update timestamps and
flags → draw boxes/labels
→ JPEG encode → yield chunk → browser displays frame and (if allowed) plays alert →
loop.
• The decision diamond (“Detections?”) short-circuits updates if a frame has no
detections.
74 User Session Sequence What it shows • Navigation User hits landing, logs in, gets
redirected to the detect page.
• Streaming Browser opens /video_feed; server opens the camera and starts a
loop of read → infer → update state → send JPEG chunks back; browser renders
frames and handles alerts.
• Clear separation
of concerns UI/page
loads vs. the
continuous stream.
CHAPTER 8 CONCLUSION AND FUTURE WORK 81 Conclusion This project
delivers an end-to-end, real- time Wild Animal Detection System that integrates a
modern single-stage object detector (YOLOv8) with a lightweight, accessible web
stack (Flask, Jinja, OpenCV) to provide annotated live streams, basic alerts, and
temporal insights.
From a systems perspective, it demonstrates a clean capture → inference →
annotation → streaming pipeline that keeps latency low while preserving user clarity
through visual overlays and simple UI flows.
Operationally, the system meets the core aims of (i) detecting predefined species from a
consumer webcam, (ii)

streaming annotated frames to authenticated users, (iii) flagging detections through

visual/audio cues, and (iv) retaining in- memory timestamps for pattern summariesA
key strength is simplicity the MJPEG streaming approach, single-process server, and
in-memory state allow reliable operation and easy debugging without complex
streaming backends or distributed components.
This makes the project particularly suitable for academic use, demos, and small-scale
field pilots where ease of deployment and transparency are prioritized over advanced
scalability features.
• The codebase is modular enough to support future extensions filters,
alternative alert sounds, and model swaps for species without re-architecting
the system. From an educational perspective, the system provides a strong
example for full-stack ML deployment, students and practitioners can explore
how raw frames become model inputs, how detections become human-
actionable overlays and alerts, and how runtime states support simple
analysis.
• It is also a practical basis for research on domain adaptation, active
learning, or benchmarking detector performance under field conditions. The
limitations for this stage are intentional to maintain clarity and focus, logging
is in-memory (no persistence), security is minimal (session authentication),
and the system targets a single video source. Model performance may vary
with lighting and environmental conditions, and browser audio policies may
gate alert behavior until user interaction.
• These limitations inform a clear future roadmap, in short, the project
proves the feasibility and value of a lean wildlife detection pipeline on
modest hardware with a clean web interface and a minimal-yet-meaningful
analysis layer.
• This is a practical baseline to build upon rather than an end-state
enterprise system by design82 Key Contributions • End-to-end, real-time
animal detection pipeline tailored to practical requirements (low latency,
clarity and responsiveness).
• • A maintainable architecture with clear separation of concerns and
straightforward configuration.
• • Browser-delivered user experience with annotated videos, alerts, and
time-based summaries.
• • An academically valuable reference project for teaching,
experimentation and small deployments.
• 83 Evaluative Summary • Live annotated stream after functional success
login; Correct per-frame overlay for targ The display achieves reactive
streaming on the CPU; Potential for significant gains on GPU hardware
(YOLOv8 variants).
• • Usability Simple navigation and understandable feedback; Configurable
class filters and alert sounds.
• • Reliability Clean camera lifecycle handling and secure streaming loops;
Suitable for continuous short sessions with predictable behavior.
• 84 Current Limitations • Volatile storage (in-memory only) detection history
is lost upon restart.
• • Single camera/source No RTSP/multi-camera orchestration yet.
• • Basic security session-based login without TLS, RBAC, or audit trails.
• • Alert Restrictions Browser autoplay policies may prevent automatic audio
playback.
• • Model generalization performance may degrade in low illumination,
occlusions, or domain-shifting environments without fine-tuning.
85 Future Work A.
Product/Engineering Roadmap • Short-term (Weeks 1–3) • Persistence and analytics •
Add SQLite/PostgreSQL for detection events; migrate in- memory logs to durable
storage.
• • Provide simple dashboard with per-species counts, hourly histograms, daily/weekly
aggregates.
• • Configuration and UX • UI controls for detection threshold and per-class
enable/disable.
• • Improved alert configuration (volume, debounce interval, repetition behavior).
• • Stability • Strong error handling for camera reconnect; Structured logging.
• • Medium term (weeks 4-8) • Multi-source support • RTSP ingest and multi-camera
management; UI for switching stream or tile views.
• • Performance • Optional GPU acceleration; Async interpolation and frame buffering
for smoother FPS.
• Model variant selector (YOLOv8n/s/m) with guidance based on hardware.
• Security & operations • Environment-based configuration; env and secrets
management.
• TLS on production servers; WSGI/ASGI deployment behind a reverse proxy.
• Longer-term (Months 2–4) • Intelligent alerting • Event rules engine (eg, alert if
specific species appears during

certain hours).
• Integrations for SMS/email/IoT relays; optional geofencing.
• Advanced analytics • Trend analysis, heatmaps (by time), false-positive review tools.
• Active learning hooks flag uncertain detections for manual review and dataset
curation.
• Scalability • Stream fan-out to multiple clients; caching and rate limiting.
• Containerization (Docker), orchestration (Compose/Kubernetes) for deployment at
scale.
B Research and Model Development • Domain adaptation and fine-tuning • Collect
local footage and annotations to adapt the model; evaluate precision/recall under
local conditions.
• Robustness studies • Benchmark across lighting, weather, camera positions;
introduce augmentation to improve generalization.
• On-device optimization • Quantization/pruning; export to ONNX/TensorRT for edge
accelerators (eg, Jetson).
• Semi-supervised/active learning • Use uncertain detections to drive efficient
labeling and model updates. C Data, Ethics, and Governance • Data lifecycle •
Define retention policies, anonymization (if humans enter frame), and access
controls.
• Consent and transparency • Clear signage or consent processes when deployed near
public spaces.
• Usage policy • Guardrails to ensure the system is used for safety and
conservation, not intrusive surveillance. D Testing, Monitoring, and Quality •
Automated tests • Unit tests for inference/config; integration tests for streaming
endpoints.
• Performance testing •
FPS/latency sampling under CPU
vs. GPU; multi-camera load tests.
 • Observability • Structured logs, metrics (FPS, latency, queue sizes), optional tracing;
lightweight dashboards.
• Reliability • Soak tests (multi-hour runs), memory/leak checks, auto-recovery routines.
E UX Enhancements • Stream UI • Detection counters, per-class toggles, and live status
banners.
• Accessibility • Color-blind-friendly overlays; keyboard shortcuts; clear error states.
• Visual analytics • Inline charts for recent activity; downloadable CSV/JSON of
detection logs.
86 Expected Impact of the Roadmap • Operational readiness Persistence, multi-camera
support, and robust alerting transform the baseline into a field-usable tool for farms
and conservation edges.
• Scientific value Fine-tuning and active learning workflows create a research-
grade platform for studying detector performance and domain adaptation in
wildlife contexts.
• Educational utility A richer, configurable UI and modular back end make the
system a strong teaching artifact for ML systems engineering courses.
• Ethical deployment Clear policies and secure-by-default configurations lower risk in
real-world use.
87 Closing Remarks The project demonstrates that a thoughtfully engineered, minimal
system can deliver meaningful value in wildlife monitoring while remaining
transparent, teachable, and extensible.
By focusing on clarity (inference-to-UX), responsiveness (real-time streaming), and
practicality (simple architecture), it lays a solid foundation for both academic inquiry
and real deployments.
The outlined roadmap ensures a credible path toward durability (persistence), breadth
(multi- camera), depth (analytics and learning loops), and responsibility (security and
ethics), turning this baseline into a capable and trustworthy tool for stakeholders.
Provided a full “Conclusion and Future Work” section (≈2–3 pages) summarizing
achievements, limitations, and a concrete roadmap across product, research, ethics, testing,
and UX.