▶ Open the V-LO web app

Velocity-based training for powerlifters and strength-athletes, built on two off-the-shelf Movesense sensors and a web app for athletes and coaches.

▶ Open the V-LO web app

Why VBT · The problem · How it works · The app · Results · Get started · Team

_{Back squat}

_{Front squat}

_{Bench press}

_Deadlift

_{⬇️ Click a section below to open it ⬇️}

🏋️ Why velocity-based training?

Traditional programs prescribe load as a fixed percentage of your 1RM. But your strength changes day to day with sleep, stress and fatigue, so Sunday's spreadsheet may be wrong by Thursday.

Velocity-based training (VBT) uses bar speed instead. As the load gets closer to your max, the bar slows down in a predictable way, which gives a live, objective readout of how hard a set really is.

✅ Autoregulate: load for the day you're actually having
✅ Manage fatigue: stop a set when bar speed drops too far
✅ Estimate 1RM: without testing a true max
✅ Train with intent: a number after every rep makes you push

VBT gives strength gains similar to percentage-based training, at lower training loads.

Velocity zones

Every set is classified by its mean bar speed:

Zones as a table · click to open

Zone	Mean velocity	Typical % 1RM	Training effect
🔵 Starting strength	> 1.30 m/s	bodyweight	Overcoming inertia: jumps and throws
🟢 Speed-strength	1.00–1.30 m/s	20–40%	Speed first, strength second
🟢 Strength-speed	0.75–1.00 m/s	40–60%	Moderately heavy loads, as fast as possible
🟡 Accelerative strength	0.50–0.75 m/s	65–80%	Driving heavy loads as fast as possible
🟠 Absolute strength	< 0.50 m/s	80–100%	Maximal force: heavy triples, doubles, singles

🎯 The problem

Coaches report three barriers to using VBT today:

💸
Expensive
_{The most accurate devices, linear position transducers, cost a lot.}

🔌
Hard to use
_{Cables and setup get in the way of the lift.}

📉
Limited accuracy
_{Cheaper wireless IMUs suffer from drift and bar rotation.}

ℹ️ Our research question: Can two end-mounted IMUs give accurate enough mean concentric velocity for feedback during training, despite irregular barbell rotation?

Why do cheaper sensors struggle? · click to open

Integration drift. Velocity comes from integrating acceleration, so small errors add up over time.
Irregular bar rotation. The bar tilts and rotates mid-lift, so the sensor axes stop lining up with the movement.
One side only. A single sensor can't tell whether the left and right sides of the bar move differently.

⚙️ How it works

V-LO puts one Movesense sensor on each end of the bar. The velocitydrift of both sensors are compared and the data from the sensor with the most linear drift are used for velocity estimations.

From acceleration to velocity

Orientation: the Madgwick filter fuses accelerometer and gyroscope data
Drift correction: The velocity drift is approximated as linear. Estimating a gradient coefficient from the first and last half second of data.
Rep detection: Velocity peaks are identified by comparing number of peaks to the known number of repetitions performed.
Velocity: For each repetition the mean velocity is estimated by integrating the acceleration over time for each repetition. Only the velocity data with a value above the approximated drift is used. The peak velocity is estimated using the velocity curves peak height.

Why Movesense, not a custom board?

A custom IMU would mean building our own firmware, Bluetooth stack and enclosure. That time would come out of the data analysis and the user experience, which are our core contributions.

Movesense is commercially available, with a 9-axis IMU and Bluetooth Low Energy.

Data pipeline in detail · click to open

Save. You press ■ Stop & save. The web app saves the sensor data and adds a row to the sessions table in Supabase.
Trigger. A Supabase webhook fires on the new row and sends the recording to our app on Azure.
Analyze. Azure queues the recording, runs the analysis code (Squats2) and saves the reps and velocities back to Supabase.
Show. The web app checks for results every 2 seconds and shows the set's velocity, whether it hit the target zone, and a suggested next weight. No refresh needed.

Cold start: if Azure has been idle, the first set can take 10–30 s.
Retries: missed sets are resent automatically every minute.
Errors: if a set can't be analyzed, it shows the reason instead of a result.

📱 The app

1. 📍 Place the sensors on the bar ends
2. 📶 Connect in the web app
3. 🏋️ Pick exercise and weight
4. 📊 Lift and get feedback on every rep

After each set you see peak and mean velocity, a rep-by-rep readout, consistency, whether you hit the target zone, and a suggested next weight.

Web-based, so it works on any phone, tablet or laptop.

Coaches get a team view with training volume, average bar speed per lift, and PR leaderboards for each velocity zone.

_{Team dashboard}

_{Top PRs per velocity zone}

➡️ More screenshots: Website walkthrough

📊 Results

We validated V-LO against a GymAware RS linear position transducer, a gold-standard reference that recorded the same reps at the same time.

4

_{participants, 6 squats in each of 3 velocity zones}

< 0.10 m/s

_{error in the zones where powerlifters train}

5.8 s

_{median time from saved set to feedback}

Accurate where powerlifters train

The table shows the mean absolute error (± SD) between V-LO and GymAware, in m/s:

Zone (by peak velocity)	Mean velocity	Peak velocity	Error below 0.10 m/s?
Absolute strength (< 0.5 m/s)	0.03 ± 0.02	0.04 ± 0.02	✅ Yes
Speed strength (0.5–1.3 m/s)	0.05 ± 0.16	0.06 ± 0.03	✅ Yes
Starting strength (> 1.3 m/s)	0.33 ± 0.17	0.21 ± 0.13	❌ No

_{Mean velocity}

_{Peak velocity}

Why accuracy drops at high speed

V-LO doesn't measure velocity directly. It integrates acceleration over each rep, and that approach works best for slower, heavier lifts:

Fast reps are short. At 104 Hz, a very fast rep contains fewer samples, so each small measurement error carries more weight in the result.
Fast reps have bigger, sharper accelerations. Quick changes in speed and more bar vibration make the signal harder to follow, and errors build up faster during integration.
The drift correction assumes the drift is linear. That holds well over a controlled lift, but less well when the movement is very explosive.

This matters less than it sounds: peak velocities above 1.3 m/s only happen with very light loads, which powerlifters rarely train with. In the zones where powerlifting training happens, the error stays below 0.10 m/s.

Feedback before the next set

5.8 s

_{median processing time}

0.9–7.5 s

_{range over 7 recorded sets}

Measured from the moment a recording is saved until its results appear in the app. Results usually arrive well before the next set starts, since rest between sets in powerlifting is typically a few minutes. The spread comes mainly from the analysis app on Azure: when it has been idle, it needs a few extra seconds to start up. This is a preliminary test.

🚀 Get started

python -m http.server 8080

Then open localhost:8080/vlo.html in Chrome or Edge (they support Web Bluetooth, which connects to the sensors) and log in with your own account.

⚠️ Warning: The analysis runs on Azure, so changes to the analysis code also need a deploy. Check with the team before deploying.

Recording a set

Standing still at the start gives a clean baseline, gaps between reps help separate them, and a firm rack marks the end of the set.

🧭 Limitations and roadmap

Known limitations

Small number of participants
The participants were not professional powerlifters
The evaluation was only done for squats
Unreliable Bluetooth connection
Slow first set after Azure is idle

Next steps

Better drift handling to make fast, light lifts as accurate as heavy ones
Bench press and deadlift analysis, validated like the squat
A larger validation study with powerlifters
Combine both sensors, e.g. to measure left–right balance
Automatic rep detection, so no rep count has to be entered

Longer term

Estimate the 1RM from the athlete's load–velocity profile
Intelligent coach platform with programs and benchmarks
More exercises, including team sports
Other lifting equipment beyond the barbell
Wearable version that tracks the athlete

📁 Repository

.github/
├── README.md                           ← this page
├── code/                               ← all source code
│   ├── analysis/                       ← Azure app that analyses each set
│   │   ├── squat/                      ← squat analysis (Squats2.py)
│   │   ├── function_app.py             ← entry point Azure runs
│   │   └── requirements.txt            ← Python packages
│   ├── database/                       ← Supabase database
│   │   ├── migrations/                 ← changes to the tables, by date
│   │   └── queries/                    ← useful SQL queries
│   └── website/                        ← the V-LO web app
│       ├── css/                        ← styling (vlo.css)
│       └── js/                         ← app logic: sensors, recording, charts
├── data/                               ← recorded sensor data and test results
├── docs/
│   ├── images/
│   │   ├── readme/                     ← banners, diagrams and 3D lifters
│   │   └── website/                    ← screenshots of the V-LO website
│   └── papers/                         ← final paper and presentation
└── Issue_Template/                     ← templates for reporting issues

Path	What's inside
`code/analysis/`	The Azure app that runs after every saved set. `function_app.py` is the entry point, and `supabase_api.py` reads recordings from and writes results back to Supabase.
`code/analysis/squat/`	The squat analysis: `MagdwickFilter.py` (orientation), `ValidatePeaks.py` (rep detection), `VelocityCalculations.py` (velocity) and `Squats2.py`, which ties them together.
`code/database/migrations/`	SQL files that build and change the Supabase tables, named by date so they run in order.
`code/database/queries/`	Saved SQL queries, such as `processing-timing.sql` for checking how long the analysis takes.
`code/website/`	The V-LO web app. Start it with `python -m http.server 8080`.
`code/website/css/`	The styling for the whole app, in `vlo.css`.
`code/website/js/`	The app logic: `sensors.js` (Bluetooth), `recorder.js` (recording sets), `charts.js`, `vbt.js`, `team.js`, `plans.js` and more.
`data/`	Recorded sensor data from test sessions, plus the GymAware reference data used in the validation.
`docs/images/readme/`	The banners, diagrams and 3D lifter images used in this README.
`docs/images/website/`	Screenshots of the V-LO website, with a walkthrough explaining each page.
`docs/papers/`	The final paper and the final presentation.
`Issue_Template/`	Templates for reporting bugs and suggesting features.

👥 Team

Arvid

Greipur

Hugo

Silje

Svanberg

Roles · click to open

🧭 Scrum master

Svanberg (Addi)
Led the sprints and built the data pipeline from Supabase to Azure and back. Worked across both the UI and the code.

🎨 UI / UX

Designed and built the web app: the dashboard, the flow for connecting sensors and picking a lift, and how feedback is shown after each set.

🐍 Data and analysis

Wrote the Python code that processes the sensor data: filtering, orientation, rep detection and velocity estimation.

Navigation Menu

Repository navigation

About

Repository files navigation

▶ Open the V-LO web app

🏋️ Why velocity-based training?