TorqIt

Inspiration

Our journey began years ago when one of our team members had torn their ACL during a soccer match. Throughout the recovery process, we experienced firsthand the significant disparity in treatment quality and the lack of objective data available to both doctors and physical therapists. Despite receiving clearance to return to play, reinjury occurred, highlighting a critical gap in the rehabilitation process: the absence of reliable, quantitative metrics to assess recovery readiness.

The standard of care relies heavily on subjective assessments and expensive equipment like the Biodex System 3 dynamometer, which costs approximately $60,000 and are often inaccessible. This creates a barrier that prevents many athletes, especially those in rural or low-income areas, from accessing professional-grade rehabilitation metrics. We realized that without objective data on knee torque, muscle activation patterns, and time to peak torque, athletes are essentially flying blind when making return-to-play decisions.

The Research Foundation

During our research, we came across a pivotal study published in PLOS ONE: "Examining isokinetic knee peak torque and time to peak torque as predictors of vertical jump height in division I men's basketball players" by Westwood et al. (2025). This paper demonstrated that time to peak torque at 300°/s was a significant predictor of vertical jump performance, explaining 23% of the variance in jump height. More importantly, it revealed that the ability to rapidly generate torque is more critical than maximal torque production for athletic recovery performance.

This research validated our hypothesis that objective metrics matter, and it provided the clinical foundation for our approach. The paper showed that isokinetic testing at high angular velocities (300°/s) closely matches the knee joint angular velocity during athletic movements, making it a more relevant predictor than slower-speed testing. This insight directly informed our methodology for calculating time to peak torque from the start of contraction in a real vertical jump, creating the need for a wearable device, rather than from arbitrary time points.

What We Learned

Building TorqIt was an intensive learning experience that spanned multiple domains:

Hardware and Electronics: We learned to work with IMU sensors, understanding how to interface them with microcontrollers, calibrate them for accurate angle measurements, and handle serial communication. We purchased IMU sensors from Microcenter and spent considerable time learning soldering techniques to properly connect components and create reliable circuits. This hands-on experience taught us the importance of proper grounding, signal filtering, and power management in embedded systems.

Signal Processing: Processing EMG and IMU data required us to use digital signal processing techniques. We implemented bandpass filtering (20-450 Hz for EMG), lowpass filtering for envelope extraction, and learned about the Nyquist theorem and sampling rates. We discovered the critical importance of proper signal alignment, as even small timing discrepancies between EMG and IMU data could lead to significant errors in torque estimation.

Biomechanics: We delved into the biomechanical models for estimating knee joint torque from muscle activations. This involved understanding moment arms, muscle force-length relationships, and how to combine data from multiple muscle groups (vastus lateralis, rectus femoris, and biceps femoris) to estimate net joint torque. We learned about the clinical significance of metrics like time to peak torque and torque symmetry index.

Data Science: Working with real sensor data taught us about data cleaning, outlier detection, and the challenges of working with noisy biological signals. We implemented robust algorithms for detecting activation onsets and torque generation starts, which required careful threshold selection and baseline correction.

Software Development: We built a full-stack application with a Python backend for data analysis, a Node.js server for real-time sensor streaming, and a React frontend for visualization. This required understanding WebSocket communication, serial port handling, and creating intuitive user interfaces that present complex biomechanical data in an accessible way.

How We Built It

Our development process was iterative and resource-constrained:

Hardware Constraints: Initially, we planned to use surface EMG (sEMG) sensors to capture muscle activation data directly. However, we were unable to procure sEMG sensors (~$30 a piece) within our timeline and budget constraints. Instead, we pivoted to using publicly available EMG datasets that were collected under vertical jumps but had not been applied to these types of torque calculations of course. This decision actually proved beneficial, as it allowed us to validate our algorithms against high-quality reference data while focusing our very limited hardware budget on IMU sensors.

IMU Integration: We purchased IMU sensors from Microcenter and integrated them with Arduino Uno R3 microcontrollers. This required learning to solder connections, understanding I2C communication protocols, and writing firmware to read sensor data at appropriate sampling rates. We mounted IMUs on the thigh and shank to measure knee flexion angles, which are essential for calculating joint torque.

Data Processing Pipeline: We developed a comprehensive Python-based analysis pipeline that processes raw EMG and IMU data through multiple stages: filtering, rectification, envelope extraction, muscle activation detection, and torque estimation. The pipeline implements the biomechanical model from the research literature, calculating knee joint torque as a function of muscle activations and joint angles.

Algorithm Development: One of our most significant technical challenges was correctly implementing the time to peak torque (TPT) calculation. Initially, we found that TPT values were identical for both legs despite different underlying data, which revealed a flaw in our onset detection algorithm. Through systematic debugging, we refined our approach to detect the actual start of torque generation (similar to isokinetic testing) rather than using arbitrary time points or overly sensitive activation thresholds. This required implementing baseline-relative threshold detection and ensuring that our calculations matched the clinical methodology described in the research paper.

Frontend Development: We created a modern, dark-themed web interface using React, TypeScript, and Tailwind CSS. The frontend visualizes muscle activations, knee torque curves, and clinical metrics in a format that matches professional medical equipment displays. We integrated the generated visualizations into the application, replacing placeholder content with actual analysis results.

Challenges We Faced

Data Alignment: One of our earliest challenges was synchronizing EMG and IMU data streams. These sensors operate at different sampling rates and may have different start times. We developed alignment algorithms that use cross-correlation and temporal markers to ensure accurate synchronization, which is critical for accurate torque estimation.

TPT Calculation Accuracy: As mentioned, we initially encountered a problem where time to peak torque was identical for both legs despite clearly different torque profiles. This led us to investigate our onset detection methodology. We discovered that our threshold-based activation detection was too sensitive to relative signal characteristics rather than absolute torque generation. We solved this by implementing a more robust algorithm that detects when torque actually begins to rise from baseline, matching the clinical definition used in isokinetic testing.

Signal Quality: Working with biological signals means dealing with noise, artifacts, and variability. We spent significant time tuning filter parameters, adjusting threshold values, and implementing robust baseline correction. We learned that what works for one dataset may not work for another, requiring flexible, parameterized algorithms.

Hardware Reliability: Early in development, we encountered issues with sensor connections, power supply stability, and serial communication reliability. Learning proper soldering techniques and understanding circuit design principles was essential. We also had to implement error handling and reconnection logic in our software to handle intermittent hardware issues gracefully.

Integration Complexity: Combining multiple data streams (EMG from public datasets, IMU from our hardware, real-time processing, and visualization) required careful architecture. We had to ensure that our Python analysis scripts could work with both historical data files and real-time streams, while maintaining consistency in calculations and visualizations.

Clinical Validation: Ensuring that our metrics match clinical standards was challenging. We had to carefully study the research literature to understand how professionals calculate metrics like time to peak torque, torque symmetry index, and peak torque. Implementing these correctly required multiple iterations and validation against the methodologies described in academic papers.

Despite these challenges, we successfully created a system that delivers professional-grade ACL recovery metrics at a very small fraction of the cost of traditional equipment, making objective rehabilitation tracking accessible to athletes everywhere.

Built With

adafruit-icm20948
arduino-uno-r3
cors
eslint
express.js
filtering)-**matplotlib**-data-visualization-and-plotting-##-hardware-**arduino-uno-r3**-microcontroller-**adafruit-icm20948**-9-dof-imu-sensors-(accelerometer
framer-motion
git
gyroscope
i2c
matplotlib
node.js
numpy
pandas
postcss
python
radix-ui
react
react-router
react-three-fiber
scipy
serialport
shadcn/ui
tailwind-css
three.js
typescript
vite
websocket