I just published a new scientific study—this paper was basically the centerpiece of my PhD dissertation, and the title more or less gives away the premise: “Predicting Achilles tendon and patellofemoral joint forces during running with consumer-grade wearable sensor data.”
In this study, “consumer-grade wearable sensor data” means RunDynamics from a chest-worn Garmin heart rate monitor and similar data from a Stryd foot pod. If you aren’t familiar with these devices, they use on-board sensors to estimate biomechanical parameters like your cadence / stride length, vertical oscillation, ground contact time, and so on.[1]
There are a few issues with the gait metrics you get from these kinds of devices, though. First, are they accurate? And second…do they actually tell you anything about what’s going on inside your body?
The main driver of the tissue damage that causes running injuries is internal biomechanical loading—the high-magnitude forces inside your Achilles, knee, shin, hip, etc., which cause microscopic amounts of damage with every step you take while running. So, if we want to go beyond just tracking mileage as a way to monitor your injury risk, we should be looking at these internal biomechanical forces.
Estimating biomechanical forces during running in the lab
There’s just one problem: estimating these biomechanical forces is really hard! You can’t just measure the force going into the ground (e.g. with a pressure-sensing insole) because that “external loading” can be very different from the internal loading your tissues actually experience, and the two are not even very well-correlated.
So, figuring out those internal biomechanical forces is tricky. Here's one straightforward way to do it: surgically implanting a force gauge into a tendon or bone (raise your hand if you want to volunteer for that study! Any takers?).
Barring that, the second-best option we have is musculoskeletal modeling—creating a “digital twin” of a runner, then running a computer simulation that’s consistent with the laws of physics and the principles of muscle physiology. Here’s a sketch of what that looks like:
- A runner comes into a motion capture lab
- We outfit the runner with reflective markers at key anatomic landmarks and take a “snapshot” of their body while standing still
- They run on a force-sensing treadmill while we record the force data + motion capture data from the reflective markers
- We create a “digital twin” of the runner by scaling a generic model of the musculoskeletal system to match the runner’s height, weight, limb length, approximate muscular strength, and so on
- In a computer simulation, we make the digital twin of the runner move the same way and encounter the same forces that the real runner encountered, while also constrained by the laws of physics and the principles of biomechanics
- This computer simulation estimates the actual muscular forces the real runner produced, which are consistent with the actual motion and forces we measured
- Summing up these muscle forces acting on a particular tissue gives us the internal force we’re interested in (e.g. adding up the calf muscle forces gives us the tensile force in the Achilles tendon)
This procedure does result in pretty accurate results, but in case it isn’t obvious, this modeling pipeline is incredibly laborious and time-consuming.[2] Not to mention expensive. And then there’s the fact that it requires all your running to be done in a gait lab! Real runners do their training in the real world, so we need a better solution.
Maybe wearable sensors can shortcut around biomechanical modeling
The rationale for this project was pretty straightforward: the gait metrics you record from a Garmin or Stryd sensor may not capture everything about how you move, but they do tell you a lot—for example, “a 70 kg athlete is running at 4:40/km with a cadence of 175 spm, a ground contact time of 290 ms, and a vertical oscillation of 12.1 cm.”
Maybe that gait data contains enough information about the runner’s movement pattern to accurately predict what kind of internal forces we would measure if the athlete was running in the lab, and we went through that whole seven-step procedure above.
If we could build a predictive model that could take wearable sensor data as input, and predict internal forces (at, say, the Achilles tendon) as an output, we could avoid the entire modeling pipeline and just immediately go from sensor data to internal force estimates. Whether or not this procedure will work depends on (a) how powerful our predictive model is, and (b) whether the wearable sensor data contain enough information about gait to make an accurate prediction.
My paper set out to find answers on both of these points.
Getting the input data and the output data for a predictive model
To gather the data to build a predictive model, I made a small modification to the standard biomechanical modeling pipeline above (steps 1–7). In step 2, I also outfitted the runner with a Garmin HRM strap and a Stryd foot pod, in addition to the reflective markers.
That way, after going through the whole pipeline, I had “synced” sensor data—for each step the runner took, I also had the cadence, vertical oscillation, ground contact time, etc., as recorded by the Stryd and Garmin devices, at that exact same point in time.
That way, I had thousands (really, hundreds of thousands) of training examples—pairs of (input, output) data—to train a predictive model.[3] By comparing the predictive model’s output against the real ground-truth data from the musculoskeletal modeling pipeline, I was able to measure the accuracy of the model’s predictions. Importantly, these accuracy metrics were assessed on new runners, whose data had not been used to train the predictive model.
Gait metric accuracy versus predictive model accuracy
At this point, an obvious question comes up: are the gait metrics from a Garmin HRM or Stryd pod accurate? The “official” answer is, well, it depends—the speed and cadence data are great; vertical oscillation and ground contact time are a little iffy, and it varies for some of the more obscure metrics—but that’s actually not quite what we want to know when trying to predict internal forces.
We don’t want to know if the gait metrics are accurate in some global sense; we just want to know if they are accurate enough to predict the outcome we care about (e.g. Achilles tendon force). In fact, moderate-sized inaccuracies are not that big of a deal for a sufficiently powerful predictive model; it could simply learn to correct for them, if trained on enough data.
The bigger question is whether these gait metrics are accurate enough to predict internal forces well. That question gets tangled up in whether the gait metrics themselves—setting aside any inaccuracies—contain enough information to accurately predict a runner’s internal forces.
Maybe you need more information (for example, information on footstrike angle, knee flexion, torso lean, …) that’s not captured by the Garmin HRM or the Stryd pod. In that case, even if the sensor data you have are perfectly accurate, your predictions would not be very good.
Using gold-standard gait metrics to tease apart model error and measurement error
This sounds like a complicated situation, but the data we collected already contains the key to tease apart these two different factors. To identify whether predictive accuracy is being degraded by low-quality gait metrics (i.e. measurement error in the sensors), we can train the same predictive model, but replace the sensor-measured gait metrics with their true value, as measured by the motion capture system.[4]
Concretely, we replace ground contact time from the Stryd pod with ground contact time measured by the force-sensing treadmill; we replace vertical oscillation measured by the Garmin HRM strap with vertical oscillation measured by the motion capture cameras, and so on. Then retrain the predictive model. If the model gets much more accurate, that indicates that inaccuracies in the sensor-measured gait metrics are degrading the performance of our predictive model.
To identify whether we are missing important information about the runner’s biomechanics, we can again train a new model, this time adding more data from a “hypothetical sensor” that also knows about the runner’s joint angles, ground reaction forces, and so on, then retrain the predictive model. If this predictive model is significantly more accurate than the model trained on only the gait metrics that are actually available on the Stryd and Garmin devices, that tells us there are important features of gait that are relevant to internal biomechanical forces that are not being captured by Garmin or Stryd devices.
A baseline for sanity: running speed
In any predictive modeling study, you want to have some reasonable “baseline” model to give yourself a sanity check. Maybe predicting internal forces is just really easy, or really hard, and all those fancy gait metrics don’t make any difference! In our case, there’s an obvious choice for a sane baseline—a predictive model that uses only running speed to predict internal forces. That’s a great choice because (1) running speed is clearly a major driver of internal forces, and (2) you can measure running speed with a garden-variety GPS watch; no need for fancy sensors.
Results: pretty good, but sensors are still missing some key info about biomechanics
Here’s the centerpiece figure, for the two injury locations we looked at: the patellofemoral joint and the Achilles tendon (which are the two most common locations of running injury):
Note there are some additional "moving parts" in the figure here that I'm not going to discuss
Here are the three top-line-results:
First, our predictive models did significantly better than the speed-only baseline at both injury locations. So, we really are able to use gait metrics to make more accurate predictions about internal biomechanical loading.
Second, replacing the actual sensor data with perfectly accurate versions of the same metrics did not significantly improve our predictive model’s accuracy. Therefore, our model is not being limited by measurement errors in cadence, ground contact time, and so on. Another way of thinking about this same finding: if Stryd and Garmin improved their algorithms to measure these same gait metrics more precisely, it would not tell you anything more about internal biomechanical loads.
Third, we did see a significant improvement in accuracy when we added new metrics from a “hypothetical sensor” that had more information about the runner’s gait: knee flexion angle, ankle angle, etc. That means there are important aspects about gait mechanics that are not being captured by the Garmin RunDynamics and the Stryd pod’s metrics.
So, if we want to make better predictions about internal biomechanical loading (at least at the Achilles and the knee), we need additional information about the runner’s gait mechanics—and based on the variables we analyzed, that probably means ankle mechanics, knee mechanics, and vertical ground reaction forces.
Conclusions and takeaways: bearish on sensors, bullish on smartphones
This project was essentially a bet on the example I gave earlier:
Suppose a 70 kg athlete is running at 4:40/km with a cadence of 175 spm, a ground contact time of 290 ms, and a vertical oscillation of 12.1 cm. Given that information, what can you say about the force in their Achilles and in their knee?
My bet was that you’d be able to say quite a lot—i.e. predict those forces very accurately. Or, from another perspective, the space of possible gait patterns that meet all of those constraints would be very small.
It turns out that you can predict those forces somewhat accurately, but still with a noticeable gap to what’s possible with a more comprehensive view of a runner’s biomechanics. Or in other words, even considering an athlete’s speed, cadence, ground contact time, etc., there is still a pretty wide space of possible gait patterns to select from, and ankle and knee mechanics differ as you traverse within this space.
Given these results, I’m somewhat less enthusiastic about my original long-term vision: scaling this system to analyze the data of thousands of runners who train with Garmin HRMs or Stryd pods.[5] The fact that these sensors don’t capture some important aspects of gait seems like something to get sorted out first, before “going big.”
One development I am more enthusiastic about now is smartphone-based gait analysis, e.g. as implemented in the OpenCap project, among others.
The idea here is to leverage advances in computer vision to get knee angles, ankle angles, etc., and make predictions about internal biomechanical loading that way. This approach would yield exactly the kind of gait data that sensors are missing (knee angles, ankle angles, …) with pretty good accuracy, and is still tractable-ish to scale to thousands of runners, with some clever tricks. The technology isn’t quite there yet, but I have some ideas.
In terms of real takeaways for regular runners, these findings reinforce my idea that, with the exception of cadence, most of the gait metrics that come out of a wearable sensor are not all that useful for most runners—at least for now. I actually have another paper in the works related to that idea, but the explainer for that one will have to wait until it’s published!
Open data / open code
When possible I try to make my scientific data and code freely available, and this paper is no exception. You can get the data + code from this project here on my GitHub if you are interested.
Learn more about the science of running
If you enjoyed this article, subscribe to my email list below! It’s the best way to find out when I’ve got a new article on training, a new comprehensive review of the science of running, or a new web app coming out.
I'm also on Instagram at @jdruns, and I have a YouTube channel as well, but the best way to stay in touch is my email list!
If you're training for the marathon, be sure to check out my book, Marathon Excellence for Everyone: it is the comprehensive guide to marathon training, and it covers all three of the modern ways to improve tendon stiffness: plyometrics, weight lifting, and hill sprints.
Learn more about Marathon Excellence here, or get the book now on Amazon. If you live outside of the United States, Marathon Excellence is also available in a Metric Edition with all workouts in kilometers!
If you aren't up for the marathon just yet, I published a shorter book in 2013 on a simple scientifically based approach to 800m to 10k training, Modern Training and Physiology.
Footnotes
[1] On conflicts of interest: Stryd gave us a few free devices to use for this study, but they had no input on the design, analysis, or publication of the paper, and I have no affiliation with them today. We got no other material or financial support from other companies. I did get grants from the American Society of Biomechanics, the American College of Sports Medicine, and World Athletics to support various parts of this project. I have no involvement, affiliate links, or sponsorships from Stryd, Garmin, or any other company.
[2] The gait lab equipment you need for this pipeline costs around $300k, maybe more these days. And I’m somewhat glossing over just how much expertise you need to run these musculoskeletal simulations: there are maybe a few dozen biomechanics labs in the entire world that can run this kind of pipeline.
[3] The exact kind of model I built was a gradient-boosted regression tree, which is a powerful “classical” machine learning model (meaning, not the kind of deep neural net used for ChatGPT or Claude). As I show later on in the blog post (and the paper), this type of model was sufficiently powerful to predict internal forces very accurately if given sufficiently good input data.
[4] In the machine learning literature this is a twist on the idea of an “ablation study.” Instead of removing features and seeing what breaks; we add new sources of information and see what improves.
[5] Why would you need to scale up such a system to thousands of runners? Because when you run the numbers, it turns out that’s about how many subjects you need for really robust results on the training-related factors that cause injury. Small-ish studies on a few dozen or a few hundred runners just are not precise enough to tease out the multifactorial roots of injury.
Related articles
New web app: Predicting LT1 pace and Zone 2 pace from 5k time
Designing a plyometrics program for improving bone strength in young runners
Three theories of tissue damage accumulation during running
Lecture: The science behind modern marathon training
What assumptions are baked into your race prediction model?
Tendons do not store energy for free
In windy conditions, running at a constant effort is usually better than running at a constant speed
Really interesting article! I'm a little sad that the actual study is behind a journal paywall, because I'm sure it would be a really interesting read, but I recognize that's not your fault
Question re: your conclusions and implementing this stuff in practice:
You say these are definitely better than the speed-only model:
> First, our predictive models did significantly better than the speed-only baseline at both injury locations
But that obviously they aren't as good as they could be with better inputs
> It turns out that you can predict those forces somewhat accurately, but still with a noticeable gap to what’s possible with a more comprehensive view of a runner’s biomechanics.
Most of us don't have a Garmin or Stryd for these metrics; we have it for the basic functionality of tracking distance and time, and these are nice add-ons.
Do you think that these inputs are good and consistent enough that they're worth using to as a proxy for biomechanical load, even with the knowledge that they aren't perfect? Would taking these models and publishing them somewhere to allow coaches/tech savvy users to utilize their force/load predictions be enough of an incremental improvement over just looking at speed distribution and winging it that it's worth it?
I'm not sure if that question fully makes sense, but it's where my head went. They're "better", but are they "better enough"?
Ah yes, that's the real question -- is it "good enough"? In the actual paper I more or less punted on that, since the real answer is that you need to do another study to see if the predictive power (in terms of who gets injured, for example) is better than just using speed. One of my other takeaways is that I was surprised how WELL speed alone performed; I was expecting a bigger gap between the speed-only model and the sensor data. Ironically the one thing that can appreciably help beyond just knowing how fast a person is running -- their cadence -- is also the one other thing a watch can measure quite accurately.
Are you planning to twist things a bit more and go into muscular fatigue (or just muscle behavior in general)?
Isn't it pretty accepted that the risk of injury increases with fatigue? Then part of it would be explained by the breakdown of running mechanics and because, as you explain and this article and the mechanical training load one, injury risk increases with the amount of times you pound any given tissue at a given load. But if a runner was able to hold running form exactly equal across a workout, wouldn't tendon load increase anyways over a workout/race just due to the muscles fatiguing and taking a lower share of the load? Are there studies setting gauges on tendons and the muscles next to them?
I should write something about muscular fatigue - I think my views on it are pretty far from the typical runner's. I get a lot of pushback when I argue that 8 x 1k is basically the same biomechanical load on your body as 4 x 2 km (if the speed is the same). The short version of why I think that is that gait does change with fatigue, but it does not change in a predictable way, and it does not always change in a way that increases stress on your body. Also, even in a very hard workout, the bulk of the workout is done in a non-fatigued state anyways.
Is there any way to use OpenCap with Android devices?
Not yet, as far as I know! The actual tech not iOS-dependent so it's probably more a matter of porting the app. Maybe some intrepid grad student will get around to it in a few years?
Is the data good enough to help model biomechanical training load? I ask because as a much heavier runner (110kg, but down from 128kg the start of the year) I have found that the TSS type model is sometimes lacking in modelling the muscular impact of different training sessions, but I found that using the "Lower Body Stress Score" (LBSS), that Stryd put out, was a bit more helpful.
For example, I'm following the Norwegian Singles Method and very slowly increasing my load. I got to a point where I found that increasing my easy day runs by just 5min, which is minimal TSS would bring on signs of overtraining. But increasing some of the harder sessions or long runs didn't. When I looked using the LBSS I noticed that adding those 5mins on to my easy runs was bumping up the LBSS to level with the 42day average (and maybe blocking my muscular recovery), but without it they were just below. Both were well below when looking at TSS/RSS. So I wondered whether the LBSS was picking up the impact on my muscles a bit better than simple TSS.
Basically my theory is that even at slow paces and wearing protective shoes, my body weight means that at impact my quads are very briefly doing much more intense efforts than a lighter runner might, and that even after a year of running and some weight loss that brief period of impact still remains outside of what my muscles can cope with and so damage is much greater than it would seem from usual models.
Unfortunately Stryd don't really have any good information on what their "Lower Body Stress Score" is? I can't find a description mentioned in their (slightly lacking) documentation. So although it seems to be useful, I have no idea what it is even measuring or how it is calculated or whether it might be accurate and my experience is just n=1 and could what I'm experiencing easily be something else.
I'm just curious whether you've looked at a muscular strain/fatigue like model for managing load in terms of overtraining etc as well as for injury prevention? Sorry if this is a bit of an info dump, hopefully you're able to interpret my ramblings.
Ah, "good enough" is the real question right? One of the reasons I did this project was because I was seeing all of these "impact scores" and "lower body stress" scores pop up, often without any real documentation on what they were actually trying to measure (Stryd's included!). This article of mine: https://runningwritings.com/2025/12/tissue-loading-and-damage-in-running-injuries.html is my best stab at the problem from a direct "tissue damage" perspective -- I think, partly informed by this Garmin/Stryd project, speed is the main driver of tissue loading, so a speed-weighted training stress core is the way to go. But the SHAPE looks very different from traditional TSS/RSS -- tissue load ramps up much more quickly as a function of speed. Overtraining is different and should be approached differently (probably with a different cumulative training load metric) -- it's easy to design a protocol that has a high injury risk but low overtraining risk, and vice versa, which should tell you they operate under different characteristics.