Rankings

[gvcormac]

Unless you want things like...

Basic physics would seem to be much simpler: if we know the flywheel speeds and times at release and catch, knowing its inertia we know the amounts of energy lost to air by the flywheel and don't even have to measure drag.

The energy lost to air is drag. Distinction without a difference. But you can only measure it in coast down. So you have to estimate it during the stroke. The end points are the same but the shape of the curve is different. You can get a few data points for the force curve, which the PM captures and plots for you if you like.

Concept 2 are locked into area-under-the-curve approximations they chose 30+ years ago when they implemented their first PMs on rudimentary hardware. They have more computing power now, but are locked in to the legacy calculations. That said, the legacy calculations are pretty good.

[JaapvanE]

Unless you want things like...

I certainly do, which is why I use a C2 with a PM5 and Ergdata. Otherwise we can't know what we are actually doing nor how.

With OpenRowingMonitor we produce these as well. Then you need to do specific calculations done every impulse, which is doable, even on a simple Raspberry Pi.

Clearly if we count the impulses and know the time, release to release, we can calculate the average flywheel speed. We must also find and use an "average" drag torque; taking account that drag torque has a cubic relationship with speed. Does that lead to complications?

It does lead to complications, but not in the way you'd think. Because the drag is a function of the angular velocity (ω) you end up with pretty nasty math. Annu Dudhia provides two formulae for the drag
k = - I ( dω / dt ) (1 / ω^2 )
k = I d(1/ω) / dt
where the first formula can be used rotation for rotation (no explanation given here) and the second accross the entire recovery.

The second formula comes closest to your statement: you need the velocity ω at the begin and end of the recovery.

However, while this is sound in theory, it is a bad approach in practice, as it is based in math that isn't robust against noise and outliers. The newer C2's pulses fluctuate a bit through the rotation (we tested across devices, it is systematic), leading to a sine-like pattern when the flywheel is in a constant velocity. So this throws in some noise in the data in both t and ω. As ω is calculated by dividing angular displacement by the (rather small amoumt of) time between two impulses, errors tend to be enlarged significantly. This makes this approach unstable by definition.

Another source of noise is stroke detection: if you are not carefull there, flanks of the drive are included, thus leading to errors when using just the start- and endpoint of the recovery for that. As the flywheel is a discrete pulse generator (at least for us, C2 might be much smarter than we and actually use the analoge signal here), we have no clue about the exact position of the drive start. So including a flank is a real issue here, causing additional noise.

With OpenRowingMonitor we tested both formulae, but the results tend to be unstable. Averaging across a significant number of strokes helps, but it isn't flawless from the first stroke in.

Hence our use of linear regression to determine the drag, as with about 150 datapoints in a recovery, it is pretty robust against noise and outliers. Adittional filtering on the R^2 works extremely well, allowing a structural fit of over 0.98.

[JaapvanE]

Concept 2 are locked into area-under-the-curve approximations they chose 30+ years ago

They actually don't use that, and for good reason.

First of all, older PM's knew drag, but AFAIK didd not do a force curve (PM2 if I'm not mistaken).

The math behind force curves is actually pretty difficult to make robust. On a quad core Raspberry Pi, we get it to work, but we are struggling with CPU load to do it. And we use pretty advanced algorithms unavailable at the time of developing the PM3. C2 might perform some tricks we can't, but the lack of robust calculations will hit it regardless. Small errors in measurement or stroke detection will set it off.

A much more robust approach is to use the approach that Annu Dudhia described, Dave Vernooy implemented succesfully and OpenRowingMonitor succesfully validated against a PM5. Simply use the average angular velocity across the stroke. Any small errors will be drowned out, and even a missed stroke detection will not kill it.

They have more computing power now, but are locked in to the legacy calculations. That said, the legacy calculations are pretty good.

With OpenRowingMonitor we have way much more computing power, still use these less precise but more robust approximations as they are way more useable in practice. At some point we implemented both as a cross-check of our math, only to find out that the approximation delivers much more stable results.

[gvcormac]

Concept 2 are locked into area-under-the-curve approximations they chose 30+ years ago

A much more robust approach is to use the approach that Annu Dudhia described, Dave Vernooy implemented succesfully and OpenRowingMonitor succesfully validated against a PM5. Simply use the average angular velocity across the stroke. Any small errors will be drowned out, and even a missed stroke detection will not kill it.

I know I'm being pedantic, but this is an area-under-the-curve approximation.

I think I understand the disconnect. I said that the [modern] PM would display the force curve. I didn't mean to imply it was used in the power calculation.

[JaapvanE]

I know I'm being pedantic, but this is an area-under-the-curve approximation.

Well,
_P_ = k * _ω_^3
where, _P_ is the average power and _ω_.

I don't see any obvious curve here to calculate an area under to be honest. One could argue this is the same as _P_ = (k * _ω_^2) * θ / t, where k * _ω_^2 represents the dragforce. But that is no obvious graph to make (as a forcecorve also includes the acceleration of the flywheel via I * α).

I think I understand the disconnect. I said that the [modern] PM would display the force curve. I didn't mean to imply it was used in the power calculation.

In theory it could be, as P = F * displacement / time

It should result in the same outcome, but as the _P_ = k * _ω_^3 is a simplified approximation (and flawed, as the Ulm University researchers concluded.

[gvcormac]

I think I understand the disconnect. I said that the [modern] PM would display the force curve. I didn't mean to imply it was used in the power calculation.

In theory it could be, as P = F * displacement / time

It should result in the same outcome, but as the _P_ = k * _ω_^3 is a simplified approximation (and flawed, as the Ulm University researchers concluded.

Of course. If we had instantaneous, noise-free sensors, and unlimited computing power.

[JaapvanE]

Of course. If we had instantaneous, noise-free sensors, and unlimited computing power.

That, and the issue that the power calculation assumes a perfect consistent stroke, so no netto acceleration/deceleration from drive start to the next drive start. That is a tall order for most rowers, and Ulm university has shown that this throws off a PM5 to a certain degree.

In all honesty, I'm not entirely sure this is a thing to change algorithm for. I kind of get the idea of a simple algorithm that "rewards" this stroke to stroke consistency. So far, I made the same decission in ORM, without the huge installed base that goes nuts if the PM5 generates different metrics, with a clear view on the downsides of the algorithm used and data that allowed a more accurate implementation readily available.

[gvcormac]

Of course. If we had instantaneous, noise-free sensors, and unlimited computing power.

That, and the issue that the power calculation assumes a perfect consistent stroke, so no netto acceleration/deceleration from drive start to the next drive start. That is a tall order for most rowers, and Ulm university has shown that this throws off a PM5 to a certain degree.

I don't see this. From the recovery you get a perfect negative force curve. You get a net force curve from the stroke, and subtract the two. Given noise-free instantaneous sensors and unlimited computing power. The only assumptions are that the air resistance as a function of angular velocity remains constant, and the angular momentum of the flywheel remains constant.

[jamesg]

Knowing flywheel speeds at release and catch, we know the energy ER lost to air during that idle time: the difference between the two energy levels.

The energy ES lost to air during the complete stroke is then extrapolated from recovery time R to recovery plus pull time R+P.

This is the total work done by the flywheel on air in each stroke. This is what we want to know, as in any sport: the effects.

It's not accurate, since the data we have on a C is no more than an impulse train at 50 to 70Hz, one every 3cm chain travel. Since this travel is of the order of 120cm, we have at least 2% error ab origine..

[JaapvanE]

It's not accurate, since the data we have on a C is no more than an impulse train at 50 to 70Hz, one every 3cm chain travel. Since this travel is of the order of 120cm, we have at least 2% error ab origine..

I agree with the key message here: the measurement system introduces inaccuracies. The Model D generates a 18V sinoid per magnet, with an overlayed sinoid per 6 magnets (a full rotation). In theory this would allow for analog processing with a lot more accuracy. But even with better sensors and more computing power, inaccuracies will throw off calculations. Somewhere one has to cross from a continuous analoge world into a discrete model, either because the sensor has a reporting frequency or the CPU a scanning frequency. And there, rounding errors are introduced.

And it is these rounding errors that make the use of more accurate formulae difficult: the complete formula for the power in a stroke is _P_ = k * _ω_^3 + I * α, where α is the acceleration across the stroke. The later factor defines the netto acceleration/deceleration of the flywheel, and thus (addition or loss of) the energy stored in it. In essence, C2 (and ORM) assume that α = 0, making this an easy and robust calculation. A notable effect is that at moments of acceleration, the PM5 (and ORM) will underreport the power. So the power at the start of a session is inprecise (as university of Ulm also concluded).

The isssue with the α element in real life is that it highly depends (unlike _ω_) on instantanous ω's measured at the exact begin on the drive. Due to the above points, instantanous ω's fluctuate by nature, and above that the exact point of 'start of the drive' is also inprecise making it also unstable.