- Status Report 4 Requirements: Part A was written by Chris, B was written by Simon, and C was written by Gene.
Project Risks and Mitigation
One of the biggest risks for the LumiKey project is inconsistent Optical Music Recognition (OMR) results when processing phone photos of sheet music. Phone images can have shadows, glare, skew, or uneven lighting, which can make it difficult for the OMR engine to correctly detect notes. To manage this risk, the Scan Layer preprocessing pipeline performs several normalization steps such as lighting correction, adaptive thresholding, and skew detection. The system also includes a quality check stage that detects problems like blur or glare before running OMR. If the scan quality is too poor, the system can flag the input rather than producing incorrect results. As a contingency plan, if phone photos remain unreliable, the system can restrict input to higher-quality images or PDF sheet music.
Another risk is latency between the software and the ESP32 hardware. If the system takes too long to respond to a key press, the LED feedback may feel delayed or out of sync with the music. To reduce this risk, the latency budget was divided across sensing, processing, Bluetooth transmission, and LED actuation. The system also uses buffered communication so that the ESP32 always has upcoming notes ready to display. If communication delays become an issue, a fallback solution is to preload larger sections of the music sequence onto the microcontroller.
A third risk involves reliable key press detection using force-sensitive resistors (FSRs). Because FSR sensors measure pressure, they can sometimes produce noisy signals depending on how the user presses the key. To manage this, the firmware uses threshold filtering and debounce logic to reduce false triggers. If sensor readings remain inconsistent, thresholds can be adjusted or the sensor placement can be refined without redesigning the hardware.