Motion Telemetry for Hydrawav3

About the Project

Most fitness and recovery tools either overwhelm users with raw data or provide vague, non-actionable feedback. You might get joint angles, symmetry scores, or posture metrics, but there’s no clear answer to a simple question: What should I actually do with this?

This project was built to close that gap. The goal was to take biomechanical movement data and convert it into clear, structured outputs:

detection of movement imbalances
automated hardware settings for the Hydrawav3 wellness device
clear visual pad-placement guidance

All within a short, frozen interaction window.

Inspiration

The idea came from observing how difficult it is for people to understand their own bodies without expert guidance. Even with modern pose tracking and wearable data, users are left interpreting numbers without context.

The core realization was that the real problem is not data collection, but interpretation.

We set out to build a system that transforms raw movement signals into actionable insight.

How We Built It

The system is designed as a two-layer architecture that separates decision-making from explanation.

1. Deterministic Biomechanical Engine

At the core is a rule-based system that:

computes asymmetry between left and right sides
identifies the weaker side
classifies severity

Asymmetry is calculated as:

$$ \Delta = |L - R| $$

Where:

(L) is left-side performance
(R) is right-side performance

Severity is classified as:

$$ \text{severity} = \begin{cases} \text{none} & \Delta < 5 \ \text{moderate} & 5 \le \Delta \le 15 \ \text{severe} & \Delta > 15 \end{cases} $$

This layer ensures all outputs are consistent, explainable, and not dependent on probabilistic behavior.

2. Joint-to-Muscle Mapping

To generalize beyond a single movement type, we introduced a mapping between joints and muscle groups:

Knee → quadriceps (primary), hamstrings (secondary)
Hip → glutes (primary), hip flexors (secondary)
Shoulder → deltoids (primary), rotator cuff (secondary)
Elbow → biceps (primary), triceps (secondary)

This allows the system to produce meaningful recommendations across different parts of the body rather than relying on hardcoded logic.

3. Protocol Recommendation Engine

Based on detected imbalance and severity, the system generates hardware settings for the Hydrawav3 device to guide the practitioner:

the weaker side receives activation (primary muscle)
the stronger side receives stabilization (secondary muscle)

Mechanical frequency (Hz) is adjusted as:

$$f = \begin{cases} 20 & \text{none} \ 32 & \text{moderate} \ 40 & \text{severe} \end{cases}$$

Thermal Cycle duration ($t$ in seconds) is scaled dynamically based on the asymmetry delta ($\Delta$):

$$t = \begin{cases} 60 & \Delta < 5 \ 90 & 5 \le \Delta \le 10 \ 120 & \Delta > 10 \end{cases}$$

Photobiomodulation (light therapy wavelengths $\lambda$ in nm) is intelligently targeted based on the tissue type:

$$\lambda_{red} = \begin{cases} 660 & \text{target} \in \text{Large Muscle (e.g., Quadriceps)} \ 630 & \text{otherwise} \end{cases}$$

$$\lambda_{blue} = \begin{cases} 470 & \text{target} \in \text{Joint/Tendon (e.g., Knee)} \ 450 & \text{otherwise} \end{cases}$$

4. AI-to-Hardware Translation & Safety Clamping

Rather than using the LLM as an open-ended chatbot, we constrained it to act as a strict data translator. It takes complex array data (like the angle series of a knee joint) and computes a structured JSON payload containing the exact, personalized settings a practitioner needs to apply to the Hydrawav3 device.

Because LLMs can hallucinate, we implemented a deterministic "Safety Clamping" layer that intercepts the AI output before it is ever displayed as a hardware instruction. All AI suggestions are mathematically forced into safe operating bounds:

Thermal Cycle: Clamped strictly between 60s and 120s.
Mechanical Frequency: Clamped between 20Hz and 40Hz.

If the AI fails or hallucinates outside the expected schema, the system deterministically falls back to the user's last successful historical session. If the user is brand new and has no history, it safely degrades to a hardcoded baseline protocol. This multi-layered fallback guarantees the practitioner always receives safe, reliable instructions.

5. Interaction Model

One major design decision was abandoning continuous live feedback.

Instead, the system follows a structured flow:

User starts a protocol
Movement is captured over a short time window
Data is frozen
Analysis is computed
Results are displayed

This avoids the instability of constantly changing data and makes the output interpretable.

Built With

Frontend: Next.js, React, Tailwind CSS
Computer Vision: Google MediaPipe Pose (WebAssembly accelerated)
Database & Auth: InsForge (PostgreSQL with Row Level Security)
AI Gateway: Anthropic Claude (claude-sonnet-4.6) (JSON-constrained)

Challenges

Live Data vs Readability

Early versions attempted real-time updates, but this led to:

rapidly changing values
poor user comprehension

The solution was to separate capture from analysis and present results only after processing.

Hardcoded Logic

Initial implementations relied on fixed outputs (e.g., always targeting quadriceps), which made the system appear intelligent without actually being so.

This was resolved by introducing joint-aware mappings and real calculation logic.

LLM Integration

We encountered issues with:

failed API calls
unsupported models
fallback responses triggering too often

Fixing this required:

switching to supported models
improving error handling
ensuring deterministic fallbacks

Schema Constraints

We had to maintain strict backend schemas while expanding functionality. This forced us to improve internal logic without changing external contracts, which increased system robustness.