Yes and no. I agree every human is different and thus the optimal curve will be as well. I also agree that the traditional view on the force curve requires a lot of nuance, as people many think a parabola is the perfect curve, but that a flatter (but longer) top is actually more efficient. And peaking earlier isn't too smart either (skewing too much to frontloaded). So, yeah, not an easy task. But, as I see it, we can and should do more to help people understand the thing they are watching (as this thread illustrates). So people like me like to dive into research.Tsnor wrote: ↑November 30th, 2024, 12:21 pmMath has to account for efficiency of various human muscles. At one point math predicted for cycling that lifting on part of the stroke (using clipless pedals) and using elliptical chainrings to get more continuous power was more efficient. Nope, turned out not to be true. For rowing area under curve is not a good measure of efficiency (but it will give total power - just not how efficiently that power was generated). Example: If leg muscles are more efficient then back, the the first part of the force curve should be higher - you'd want more force to come from legs.
For us, it started with the notion that C2 has some examples of known bad force curves. As you said yourself: bad transitions can be visually recognised from the curves. We also saw that RP3 has introduced projecting a parabola in the forcecurve where you can set the peak to a specific point (i.e. frontloaded or backloaded). RP3 can also monitor stroke-by-stroke consistency for the force curve peak. Again, the skewed parabola approach is usefull, but might not reflect a true ideal curve.
So, in a nutshell we wanted to analyze the force curve and give an indication if there is a clear issue. This is because even on a higher resolution curve on a higher resolution screen, it s difficult for the rowing person to do an analysis in-situ, while it matters most. Replicating what RP3 does is easy for ORM: we actually calculate peak force already, so it is just storing where in the stroke it occurs, and finding a way to make the GUI and RowsAndAll understand the parameter. But we also like to push our limits.
So we wanted to recognize specific issues (bad transitions, weak parts, etc.) without throwing a lot of machine learning to it as we are still running on cheap hardware (and we want to keep it that way). That is where the math comes in: if you have an expected progression of a curve, you can detect where you deviate significantly. But there is no research there yet beyond RP3's skewed parabola's, so it is a dead end for us now (but we keep playing with it).
Don't shoot the messenger. As said, I came across the paper by accident. For me, it makes sense from a physics perspective (as it flattens the peak of the combined force curve), although it might actually be practically impossible to train such a team. I haven't dived into the exact study setup (where they novices or elites, etc..) to understand what they did and how they did it. But microseconds difference are difficult to detect without a boat with telemetrics. Top teams probably do, but most of them don't.Tsnor wrote: ↑November 30th, 2024, 12:21 pmSurprised by this. I'm more apt apt to be early following stroke than late, its called "rushing the stroke". There's not even a term for being late (other than late). For elite teams if there was a structural imbalance in catch timing the coaches would fix it. Aside - when catch or release timing is off you really feel it. Catch hits you as you are floating on your slide wheels under zero power (letting the boat run under you), its an obvious change to how fast you are approaching the catch. Something you've done 100s of times that practice is suddenly different in a bad way. You also feel it when back/hip swing gets in sync, feels great.