Project
| # | Title | Team Members | TA | Documents | Sponsor |
|---|---|---|---|---|---|
| 71 | E-Bike Theft Detection System |
John Paul Hanley Kacper Bakun Paul Harris |
Yulei Shen | other1.pdf |
|
| Student 1: Kacper Bakun(kbakun2) Student 2: John Paul Hanley(jhanley5) Student 3: Paul Harris(pharr6) Problem: Bicycle theft is a problem in large cities and small neighborhoods alike resulting in financial losses for companies and decreased serviceability for users of the company. Companies such as Lyft have had multiple occurrences of their Divvy bikes being stolen by "persistent rattling, shaking, or even brute force" methods. These theft attempts exploit the limitations of mechanical locking systems which do not have real time monitoring and theft deterrence once tampering begins. The attached article below shows a video in which excessive shaking and attempts to dislodge divvy bikes have been successful. While companies try to improve their mechanical locking systems, theft strategies will always change and improve after new designs are put out. Thieves will look to exploit these systems late at night when there is no public supervision and alarm systems to alert the public. https://www.nbcchicago.com/news/local/divvy-bike-theft-video/176532/ Solution: To combat the limitations of mechanical locking systems and address how thieves attempt to steal these Ebikes at night we would implement a system embedded onto our bike which could monitor shaking, rattling, and brute force. The system consists of a custom PCB containing a low-power microcontroller, motion and vibration sensors, and an electronic alarm interface. The microcontroller continuously monitors sensor data to detect abnormal vibration patterns associated with rattling, excessive shaking, or brute-force tampering. Using a Finite State Machine (FSM), the system classifies behavior into normal usage, suspicious activity, and confirmed theft attempts. When activity exceeds predefined thresholds over a set time window, the system escalates its response by triggering a loud electronic alarm to deter the thief and alert nearby pedestrians. Alarm timing and reset conditions are managed by a clocking system implemented in firmware to ensure consistent and predictable operation. Subsystem 1: Tamper Sensing + Event Detection This subsystem is responsible for detecting motion patterns that indicate the bike is being tampered with or moved while it is parked and armed. The design will use an accelerometer and gyroscope (IMU), such as the MPU-6050, to monitor vibration, shaking, lifting, and rotation. The IMU allows the system to detect both: - Shaking/Vibration (repeated rapid acceleration changes typical of someone yanking the bike/lock) - Tilt/Lift/Rotation (gravity direction changes when the bike is lifted or the frame angle changes) - Filtering for noisy data - To improve reliability and reduce false alarms (wind, small bumps, people brushing past), the algorithm will evaluate motion over short time windows rather than triggering on a single spike. An optional vibration/impact sensor can be added as a secondary confirmation source, but the IMU will be the primary sensing method. We will also use a Digital Low Pass Filter that will block any unnecessary background movement to prevent it from having false alarms and unreadable data values. Component: - MPU-6050 Inertial Measurement Unit (IMU) - Digital Low-Pass Filter (DLPF) - Possible Additional Feature: Use a short-time window + RMS (filters out random bumps) - Instead of triggering on a single spike, compute RMS energy over a window Subsystem 2: Control + Finite State Machine (FSM) - This decides whether motion is normal or a theft attempt and controls escalation behavior. We will implement an FSM with set thresholds that decide whether a reading from the accelerometer is safe, suspicious, or alarming. Components: - 1 low-power microcontroller (ESP32 / STM32 / nRF52 / ATmega328P) - Firmware timer/clocking for consistent alarm timing Subsystem 3: Alarm + Public Deterrence - This subsystem makes the theft attempt obvious and unpleasant. Components: - 1 alarm siren reaching 75 dB from 1 meter away - This subsystem produces the physical response when theft is detected. A high-decibel alarm will be driven using a transistor or MOSFET driver so the microcontroller can control it safely. The response will be designed to trigger quickly and be loud enough to deter theft and attract attention. Subsystem 4: Testing and Validation Setup - This subsystem validates system performance through bench and field testing. Bench tests will involve controlled shaking and lifting to verify detection timing and alarm activation. Field testing will include parking the bike in realistic environments to ensure the system reliably detects theft attempts while minimizing false alarms from normal disturbances. Criterion for Success The Smart Bike Theft Detection System will be considered successful if it meets the following performance criteria during bench and field testing: Tamper Detection Accuracy: - The system must correctly distinguish between normal environmental motion and theft-like tampering with an accuracy of at least 90% over 40 test trials. - Normal motion trials include light bumps, wind-induced movement, and brief contact from pedestrians. - Tamper trials include sustained shaking, repeated rattling, lifting, and rotation of the bike frame. - During 30 minutes of continuous normal parking conditions, the system must trigger no more than one false alarm. This ensures the system is practical for real-world deployment without frequent nuisance alerts. Detection Latency: - For sustained theft-like activity, the system must transition from the armed state to the alarm state within 2 seconds of the tampering event beginning. Alarm Effectiveness: - When a confirmed theft attempt is detected, the alarm subsystem must produce a response that is clearly noticeable to nearby pedestrians: - The device must produce a minimum sound pressure level of 75dB measured at a distance of 1 meter. FSM Reliability and Recovery: - The Finite State Machine must correctly transition between idle, suspicious, alarm, and reset states without software crashes or undefined behavior over 10 consecutive alarm cycles, returning to the idle state after reset conditions are met. |
|||||