Child Safety Wearable Device

Name	GitHub
Yussuf Abdelkarim	Youssefibrahim03
Ismail Dahshan	ismaileldahshan1
Amr Eid	GH_UID2

Github Repo: https://github.com/YoussefIbrahim03/Child-Wearable-Safety-Device.git

1. The Proposal

Abstract / Elevator Pitch:

Child safety in public spaces remains a major concern for parents, particularly in crowded environments such as parks, malls, and school campuses. Young children are prone to wandering off, and parents cannot maintain constant visual contact at all times. Current solutions rely on smartphone apps or expensive GPS trackers that require cellular subscriptions and lack immediate local alerts. This project proposes a wearable child safety device built around a Nucleo STM32 / Tiva C microcontroller running FreeRTOS. The device uses a GPS module (NEO-6M) to continuously monitor the child's location against a pre-configured safe zone (geofence). If the child exits the boundary, an audible buzzer and LED alert activate immediately on the device itself. Additionally, an ultrasonic sensor (HC-SR04) provides a stranger proximity alert — if an unknown person remains too close to the child for a sustained period, a separate alarm pattern is triggered. The system provides real-time location logging over UART for parental review.

Project Objectives & Scope:

MVP:

• Continuous GPS position tracking with NMEA sentence parsing
• Geofence boundary detection with configurable safe zone (center coordinate + radius)
• Audible and visual alerts (buzzer + LEDs) when the child exits the safe zone
• Ultrasonic-based proximity detection for stranger alerts
• Vibration motor feedback for the child
• Push button to acknowledge/silence alarms
• UART serial logging of GPS coordinates and events
• FreeRTOS task architecture with queues and semaphores for inter-task communication

Stretch Goals:

• Multiple pre-stored geofence zones (home, school, park) switchable via button
• Distance-graduated alert levels (warning zone before the hard boundary)
• Event history logging with timestamps over UART

2. System Architecture

2.1 High-Level Block Diagram:

Hardware Architecture connections:

Subsystem Breakdown:

The system is organized around four input modules and four output modules, all managed by the MCU running FreeRTOS. Inputs: The GPS module (NEO-6M) communicates over UART, continuously feeding NMEA sentences that the MCU parses to extract latitude and longitude. The HC-SR04 ultrasonic sensor uses two GPIO pins (trigger and echo) to measure the distance of nearby objects. Two push buttons connect via GPIO interrupts — one for switching between geofence zones, and one as a dedicated panic alarm trigger. Processing: The MCU runs FreeRTOS with separate tasks for GPS parsing, distance measurement, geofence calculation, alert logic, and button handling. Tasks communicate through FreeRTOS queues (sensor data → alert logic) and semaphores (shared geofence configuration). Outputs: The buzzer uses PWM to produce different alarm patterns — a fast beep for stranger proximity and a continuous tone for geofence breach. The vibration motor uses PWM for variable-intensity haptic feedback. The RGB LED provides visual status via GPIO (green = safe, yellow = near boundary, red = breach). The UART log outputs GPS coordinates and event timestamps to a serial terminal for parental review.

3. Hardware Design

Component Selection:

Schematics & Wiring:

Circuit diagrams, pinout tables, and breadboard layouts.

Bill of Materials (BOM):

A table listing component names, part numbers, quantities, costs, and links to datasheets.

Power Budget:

Calculations ensuring your power supply can handle the peak current draw of all components combined.

4. Software Implementation

4.1 Software Architecture:

Description of the firmware design (e.g., Bare-metal Superloop, Interrupt-driven, or RTOS).

4.2 Flowcharts & State Machines:

Visual diagrams mapping out the core logic, state transitions, and interrupt service routines (ISRs).

4.3 Key Algorithms:

Explanations of any complex logic used (e.g., PID control loops, digital filtering, sensor fusion).

4.4 Development Environment:

Compilers, IDEs, and toolchains used (e.g., Keil, PlatformIO, STM32CubeIDE).

5. Testing, Validation & Debugging

5.1 Unit Testing:

How individual hardware components and software functions were tested in isolation.

5.2 Integration Testing:

How the system was tested as a whole.

5.3 Challenges & Solutions:

A log of major bugs, hardware failures, or design flaws you encountered, and the engineering steps you took to solve them.

6. Results & Demonstration

6.1 Final Prototype:

High-quality photos of the completed build.

6.2 Video Demonstration:

A link to a short video showing the system working in real-time under various conditions.

6.3 Performance Metrics:

Data showing how well the project met its initial objectives (e.g., "Response time was measured at 12ms, well within our 50ms goal").

7. Project Management

7.1 Division of Labor:

Ismail — GPS subsystem and UART communication. Responsible for interfacing the NEO-6M GPS module with the STM32, writing the NMEA parser, implementing the Haversine geofence calculation, and the UART serial logging task. Also handles FreeRTOS task architecture setup (task creation, queue and mutex configuration).

Youssef — Ultrasonic sensor subsystem and alert outputs. Responsible for the HC-SR04 driver (trigger/echo timing), the stranger proximity detection logic, buzzer PWM control, vibration motor PWM control, and RGB LED status indicator. Implements the Alert FreeRTOS task and its queue-based communication with the other tasks.

Amr — Button input handling, system integration, and testing. Responsible for GPIO interrupt handlers for both buttons (mode switch and panic), the shared geofence configuration with mutex protection, power supply design, and overall system integration. Also leads documentation (wiki page, presentation slides) and demo preparation.

Shared responsibilities: All three members contribute to debugging, FreeRTOS tuning (task priorities, stack sizes), and the final demo.

7.2 Timeline:

Date	Milestone	Deliverable
Mon, Mar 30	Project kick-off	Brainstorming ideas, team formation begins
Tue, Apr 14	Milestone 1: Team formation	Team finalized (Ismail, Youssef, Amr)
Wed, Apr 15	Milestone 2: Proposal presentation	In-class proposal slides, wiki Sections 1, 2.1, and 7
Apr 16–19	—	Order NEO-6M GPS module. Set up FreeRTOS project on STM32. Assign subsystems
Mon, Apr 20	Checkpoint A: Wiki/page setup	Full proposal on course wiki with block diagram, objectives, labor division, and timeline
Apr 21–28	Development sprint 1	Ismail: GPS UART working, NMEA parsing on serial terminal. Youssef: HC-SR04 distance readings verified, buzzer and vibration motor responding. Amr: Button interrupts working, FreeRTOS tasks created and scheduled
Wed, Apr 29	Milestone 3: Progress demo	Live demo of at least one major subsystem (GPS reading coordinates or HC-SR04 triggering alerts). In-class progress presentation
Apr 30–May 5	Development sprint 2	Geofence Haversine logic integrated with GPS task. Stranger proximity detection with sustained-presence timer. All tasks communicating via queues and mutexes. Full system integration begins
Wed, May 6	Checkpoint B: Integration update	Wiki update with integration status, testing evidence (screenshots, serial logs), and remaining issues
May 7–12	Final sprint	Outdoor GPS testing. Alert pattern tuning. Edge case handling. Demo rehearsal. Wiki page completed with all sections. Code cleaned up
Wed, May 13	Milestone 4: Final demo	Final in-class presentation, live demo, final code submission, completed wiki page

8. Appendices & References

8.1 Source Code Repository:

Link to your GitHub/GitLab repo.

8.2 References:

Links to datasheets, tutorials, academic papers, and course materials used during development.