Being a weightlifter for 20+ years now, I'm working on a barbell speed and path tracking sensor based on newer IMU hardware technologies, which makes it both more precise and cheaper than camera- or actuator-based systems. Ultimately it helps you lift and train safer and better.
It's an intersection of industrial design, hardware, firmware, and software (and some sport science, of course). This intersection is not yet dominated by LLMs so it's a breath of fresh air.
In an early prototype stage as in "strap a Raspberry Pi to a bar", but it looks promising and I'm happy to move forward, also using connections from my previous 12+ years in China.
Wannabe powerlifter here of about 20 years as well. This sounds like an awesome project! Is bar-path the main metric for safety and "better" lifting? A project I had in mind, once upon a time, was an automatic "Form Check Friday" for myself using a Pi + Webcam.
As someone who has been very deep down this rabbit hole and hacked together multiple path and velocity trackers over the years (specifically for olympic weightlifting), there is no extra information that tracking bar path will give you that simply looking at the video won't, and often just adds more clutter. You don't need to graph bar path to see that the bar is looping too far forward after hip contact in the snatch.
Velocity on the other hand is a great metric to track and is used as a proxy for RPE. Mike Tuchscherer was the first one to systematize it for powerlifting a while back, if you've been lifting for 20 years you're probably aware of the name.
Thanks! I think for "canonical" lifts (squat, deadlift, row, to some extent military press) the vertical bar path is mathematically optimal, and for all kinds of lateral or sagittal movements you do more work with weak stabilizing muscles and load joints laterally too. Is it productive work that strengthens your core? Possibly, but it's hard to quantify. It it something that can lead to injury? Absolutely yes.
For more complicated lifts like bench press (J-shaped) or snatch (S-shaped), for example, I would rather set a "golden sample" path with a coach and compare to that.
It's unlikely to be the sole metric, especially given the inverse kinematics of different body types (long/short femur, etc), but together with bar speed, over time, it can provide a lot of good feedback.
It is not "absolutely" something that can lead to injury. Injury itself is difficult to define, and often the reason one experiences pain sensation is multifactorial. Within lifting contexts, generally the factor which has the strongest evidence for injury prediction is how sharply an athlete increases intensity compared to what they have previously adapted to.
No offense, but this post does come across as you only having a surface level understanding of the field. Especially surrounding injury/pain perception, I would be more careful of what you assume is true, there's far more nuance.
Side note: My LG Watch Sport smartwatch was able to determine what weight training workout I was performing and somehow figured the weight with astonishing accuracy.
Phone accelerometers don't have enough range and sampling frequency to even begin with. Raw, on some rare phones you can sample 800 Hz (enough-ish), but on most 100 Hz max, Web API is capped at 60 Hz, this is all way too low for any quaternion math. They also have much higher noise density which is the silent killer of all kinds of IMU navigation.
I've had the same idea for year. When google released their Fitbit Air few days ago I the first thing I tought was - can it be used as a sensor for weightlifitng and do they have API for that.
i'm curious about how effective path tracking can be in comparison with computer vision based inverse kinematics of the body itself. do all forms of bad form have detectable imu signatures?
i wonder if it would make sense to consider it as a data problem, capture a bunch of high fidelity inverse kinematics data for various forms of bad form/dangerous lifting along with the imu data and then work from there. there could be some interesting and unexpected features that are easier to detect than straying from straight line paths with some tolerance.
Hashing microservice deployment was blocked by random generator microservice stuck in Pending because it needed an UUID from UUID microservice which was blocked by hashing.
Sehr gut! I need to show it to my colleagues. Unfortunately half of them are on vacation currently and another half on sick leave. We decided to make a Teams call in August to discuss how to proceed with this.
I'm team "taking on CUDA with OpenVINO" (and SYCL*), Intel seems really upped their game on iGPU and dGPU lately, with sane prices and fairly good software support and APIs.
I'm not talking gaming CUDA, but CV and data science workloads seem to scale well on Arc and work well on Edge on Core Ultra 2/3.
While I applaud the acumen, this reads like watching a kid standing on the 3rd floor balcony shouting "look what I can do!"
$20/month. Yeah. Great, but why? You get a lot of peace of mind with "real" HA setup with real backups and real recovery, for not much more than $20, if you are careful.
Another half of article is about running "free, unlimited" local AI on a GPU (Santa brought it) with, apparently, free electricity (Santa pays for it).
When I ask Gemini for some purchasing decisions (e.g. "I'm looking for the best medium-end audiophile IEM to buy, compare Campfire Audio Astrolith and 64 Audio U12t"), then go on discussing and spinning the results for a while, after a few days it decides to have a "memory" that I own it (I don't) and starts to inject it everywhere.
"Oh, you ask which dark roast coffee is least acidic, well, since you own Campfire Audio Astrolith, you will enjoy..."
reply