Music-Bike

Music Bike – Product Requirements Document

—

by

Nick
in

1. Project Summary

Music Bike aims to revolutionize the cycling experience by transforming rider actions into a dynamic, real-time musical journey. Using sensors mounted on the bicycle (measuring motion like speed, tilt, and G-force) connected via Bluetooth Low Energy (BLE) to an Android application, the system will adaptively manipulate music playback using the FMOD audio engine. The core goal is to create an intuitive and emotionally resonant connection between the physical act of riding and the auditory experience, making the rider feel like they are conducting the music through their movement.

2. Deliverables

At the conclusion of the project, the team will deliver:

  1. Functional Hardware Prototype: An ESP32-S3 based unit mounted on a bicycle, equipped with an MPU9250 IMU and KY-003 Hall Effect sensor (and potentially a Scosche Rhythm R+2.0 heart rate monitor), capable of collecting sensor data and transmitting it via BLE.
  2. Android Mobile Application: A working Android application that can:
    • Scan for and connect to the hardware prototype via BLE.
    • Receive and interpret sensor data.
    • Integrate with the FMOD audio engine.
    • Adapt music playback based on received sensor data according to defined rules.
    • Provide a basic user interface for interaction (e.g., connection status, potentially music selection/sensitivity adjustment).
  3. FMOD Project: The FMOD Studio project containing the adaptive audio logic and music assets.
  4. Demonstration: A live demonstration showcasing the hardware prototype interacting with the mobile application to produce adaptive music based on simulated or actual riding input.
  5. Project Website: Updated website containing the project proposal, PRD, progress updates, and final documentation/demo video.

3. Critical Features

  • Hardware Sensor Reading: ESP32 accurately reads data from IMU (tilt, G-force) and Hall Effect sensor (speed/cadence proxy).
  • BLE Communication: Reliable, low-latency transmission of processed sensor parameters from ESP32 to the Android app.
  • Android App BLE Reception: App successfully scans, connects, and receives data streams from the hardware prototype.
  • FMOD Integration: FMOD engine successfully integrated into the Android application and capable of playing audio.
  • Adaptive Audio Logic: FMOD parameters are dynamically updated based on incoming BLE sensor data.
  • Music Adaptation: Music playback demonstrably changes (e.g., layers added/removed, tempo shifts, effects applied) in response to sensor data variations.
  • Basic UI Feedback: App displays connection status and potentially basic sensor readings or audio state.

4. Performance Metrics

  • Sensor Polling Rate: ESP32 polls sensors at approximately 100 Hz.
  • End-to-End Latency: Time between physical sensor event and corresponding audio change should ideally be < 100 ms.
  • BLE Connection Stability: Maintain a stable BLE connection during typical usage scenarios.

5. Milestones

  • Week 1-2 (Complete): Project Proposal Finalized, Hardware Components Ordered, Initial FMOD Exploration.
  • Week 3 (Complete): Hardware Prototype Assembled (Breadboard), Basic App Structure Built & Compiling, FMOD Test Case Created.
  • Week 4-5: Implement BLE Output on ESP32, Implement BLE Scanning/Connection in App, Basic Data Parsing in App.
  • Week 6: Integrate FMOD Engine Library into Android App.
  • Week 7-8: Connect BLE Data to FMOD Parameters, Implement Initial Adaptive Audio Rules, Refine Hardware Prototype/Enclosure.
  • Week 9: User Interface Refinements (if time permits), System Testing & Debugging.
  • Week 10: Final Demonstration Preparation, Documentation Finalization.
  • End of Quarter: Final Demonstration & Project Submission.

6. Team Responsibilities

  • App Development & FMOD Integration: Bennett Lahn, Ethan Diep
    • Android application architecture and UI.
    • Bluetooth Low Energy implementation (receiving).
    • FMOD engine integration within the Android app.
    • Mapping sensor data to FMOD parameters.
  • Hardware & Music Development: Matthew H Pham, Nick Baroody
    • Hardware assembly, testing, and enclosure design.
    • ESP32 firmware development (sensor reading, data processing).
    • Bluetooth Low Energy implementation (transmitting).
    • Music composition/selection and adaptive audio design within FMOD Studio.
  • Project Management & Documentation (Shared): All team members contribute to website updates, PRD maintenance, and final documentation.

7. Materials & Outside Help

  • Hardware:
    • ESP32-S3 Development Board
    • MPU9250 IMU
    • KY-003 Hall Effect Sensor
    • Magnets
    • Breadboard, jumper wires, resistors
    • Scosche Rhythm R+2.0 (Stretch Goal)
    • Power source (Battery pack)
    • Bicycle for mounting/testing
  • Software:
    • Android Studio
    • Arduino IDE
    • FMOD Studio
    • FMOD Engine Integration Package for Android
  • Outside Help:
    • Course instructors/TAs for guidance.
    • Online communities (Stack Overflow, ESP32 forums, FMOD forums, AndroidDev Reddit).
    • Potentially university machine shop/3D printing resources for enclosure.

8. Budget

  • ESP32-S3 Dev Board: ~$15-20
  • MPU9250: ~$5-10
  • KY-003 Sensor + Magnet: ~$2-5
  • Breadboard & Wires: ~$5-10
  • Scosche Rhythm R+2.0: ~$80 (Stretch Goal)
  • Battery Pack/Power: ~$10-20
  • Total Estimated Core Cost: ~$37 – $60
  • Total Estimated with Stretch Goal: ~$117 – $140

9. Risks and Mitigation

  1. Risk: Bluetooth Low Energy connectivity issues (instability, high latency, difficult debugging).
    • Mitigation: Start with simple data transmission, use standard BLE libraries, leverage BLE debugging tools (like nRF Connect app), allocate sufficient debugging time, consult online resources/TAs.
  2. Risk: Difficulty integrating FMOD engine with Android/Kotlin.
    • Mitigation: Follow FMOD documentation carefully, start with basic examples provided by FMOD, seek help on FMOD forums, allocate specific time for integration challenges.
  3. Risk: Sensor data accuracy or noise issues.
    • Mitigation: Implement filtering algorithms (e.g., Kalman filter, moving average) on the ESP32, calibrate sensors, test different mounting positions.
  4. Risk: Achieving desired low latency (<100ms).
    • Mitigation: Optimize ESP32 processing loop, ensure efficient BLE transmission intervals, minimize processing overhead in the Android app before updating FMOD, profile code if necessary.
  5. Risk: Adaptive audio rules don’t feel “intuitive” or “musical”.
    • Mitigation: Iterative design process involving both hardware/music developers, test different mapping strategies, get feedback from test riders (even if just simulating input).
  6. Risk: Scope creep / Running out of time.
    • Mitigation: Prioritize critical features, stick to milestones, clearly define Minimum Viable Product (MVP), communicate challenges within the team early. Re-evaluate stretch goals if core functionality is lagging.
  7. Risk: Hardware durability/weatherproofing.
    • Mitigation: Design a protective enclosure, secure wiring, consider basic water resistance measures (though full waterproofing may be out of scope).

Comments

Leave a comment