Biofeedback Rehab Study

Three athletes across fifteen kick trials is enough to validate that the system fires correctly and that a cue can be delivered mid-kick without disrupting the athlete's rhythm. It is not enough to claim that audio biofeedback improves outcomes. I was careful not to overclaim in the final report, but the study design itself was underpowered for any statistical claim about performance. If I ran it again, I'd either recruit ten participants or reframe the study explicitly as a usability and feasibility pilot, not a performance study. I also wouldn't pick kicks. I'd pick a slower, more controllable movement where a larger sample could be run in a single afternoon.

The cues were designed for and tested on Taekwondo athletes who already had strong body awareness. A rehab patient recovering from ACL surgery has much less body awareness, much more fear of pain, and very different expectations about what sound means during movement. A beep that feels like a helpful nudge to a trained athlete might feel like a judgment to a post-op patient. I should have tested the cue design with a few non-athletes, including someone who had recently had a knee injury, to see whether the sound was interpreted the way I hoped. That would have caught the emotional tone of the feedback as an issue early, not late.

Every trial produced OptiTrack marker files, EMG channels, and a Max/MSP trigger log. I saved them all but I didn't build a consistent naming convention or a manifest file tying them together. Six months later, when I wanted to look back at a specific trial to pull a figure, I had to open three folders and manually cross-reference timestamps. A fifteen-minute investment in a file naming scheme and a CSV index at the start of the study would have saved hours of reconstruction work. Same lesson I learned on the capstone pneumothorax project, just earlier this time.

Because the primary question wasn't "do these athletes move differently with the cue" in any sports-performance sense. The primary question was "can this system deliver feedback the athlete understands and acts on, in the middle of a complex movement, without disrupting the movement." That's a human factors question about the usability of the biofeedback device. Framing it as sports biomechanics would have oversold what a three-athlete study can actually conclude. Framing it as usability testing is honest about what we were doing and maps directly onto how I'd evaluate a real rehab product before handing it to patients.

As a research rig, it would not pass as a device. No risk analysis per ISO 14971, no formal software verification, no labeling, no clinical validation. That's expected for a coursework study. But the architecture separates the parts that would matter: the motion capture subsystem, the feedback logic, the audio delivery subsystem, and the data logging are all cleanly decoupled. If I were formalizing this into a device candidate, each block has a clear analog in 62366-1 usability evaluation, and the audio delivery channel has a clean failure mode analysis (missed cue, false cue, wrong-timing cue) that maps onto an FMEA. The research rig is not the device. It's the first iteration of the thinking that would eventually become one.

Because the interesting part, for an employer evaluating engineering fit, is how the system was architected and validated, not the sports physiology result. I ran an end-to-end pipeline from motion capture through signal processing, trigger logic, real-time actuation, and logging. I led a four-person team through study design, execution, and analysis. I applied the same validation mindset I'd apply to a formal device (instrument first, intervention second, log everything, fail safely). That's the story an R&D or human factors or validation hiring manager cares about. The fact that it happened inside a kinesiology course is incidental.