Simulation to generate Performance Monitor test data

[klamp169]

Simulation to generate Performance Monitor test data

I cooked up a very simple simulation of the concept2 type air-rower using Pathsim, very similar to what Nomath has done.

The purpose is to generate data to test performance monitors (PM) like ORM (but also my PM2 monitor) with well defined and repeatable simulated rowing strokes. (I would not be surprised if the ORM developers already use something similar.)

The model simply describes the dynamics of the flywheel under the influence of the chain force. Details like bungee cord force or rower acceleration to pick-up to the flywheel speed are all left out. The model simply solves the equation: $J\dot\omega=T_{in}-k\omega^2$, where $J$ represents flywheel inertia, $T_{in}$ is given by the input force and sprocket radius $r_s$ , $T_{in}=F_{drive}r_s$ ($F_{drive} = 0 [N]$ during recovery) and $k$ equals the drag factor. Input force curves can be specified as function of time or drive position.

In a post processing step, the flywheel angular position $\phi=\int\omega dt$ is translated into time values (by inverse interpolation) at which $\phi$ reaches the angle of the respective magnets. These time values are stored in a csv file, that can be used directly in ORM and my own rwnp. A similar approach is used to generate an audio file that can be played from regular soundcard output to drive the PM2 monitor (not suited for PM5, obviously!)

As an example, the last three (of 20) parabolic strokes (600 [N] peak, 1.3 [m] drive length, 20 [SPM], $J=0.1001 [kgm^2], k=120\cdot10^{-6} [kgm^2]$ and $r_s=1.415[cm]$) are shown in the figure. The power per stroke can be calculated beforehand to be 173.33 [W]. The steady state simulated stroke distance = 11.77[m] (with magic constant c = 2.8[kg/m]). I include the accompanying csv file with 6 pulses per revolution to play with concept2_3_sim_6p.csv.

If there is any interest in other simulation data (rectangular or triangular force curve, effect of irregular rowing, effect of magnet placement error, effect of (high) friction, linear (for magnetic rower) instead of quadratic damping term, etc.), let me know.

[JaapvanEkris]

That is cool!

I've been doing part of this by hand, but is doesn't scale well.

I have some requests here:

• Could you make this a little over 500 meters (allowing us to test algorithms settling in)
• Could you have another one with a little random noise?
• And one with magnet placement errors?
• And a magnetic rower

This indeed would allow us to experiment with our algorithms.

[JaapvanEkris]

The benefit of the less accurate approach is that it is much more robust against measurement noise.

I tend to neglect this complication. Sorry for that.

It is good you are asking questions. It is a trade-off between precission and robustness and its balance could change if our filtering gets better. Once we stop questioning the status quo, we stop improving.

HOWEVER, this was based on a pre-CEC-filter world. Moving there still is a goal.

You spent a long thread on CEC, but I still do not think I fully get it.

In essence, it is a modified Kalman filter.

The C2 RowErg has a sinoid pattern in its magnet configuration. I suspect they do some analog voodoo magic with frequency modulation, which in theory would provide a constant measurement of angular velocity. Or it is a production tolerance. But their magnet positioning isn't perfect and thus it adds noise to our data.

We know that during the recovery, the time between impulses over time should form a straight line (i.e. the recovery slope, 1/ω over time). This is how we determine the dragfactor. It is also a long line often containing hundreds of datapoints, making it robust against individual datapoint errors.

What we do with the CEC filter is measure the deviation between the raw value and the ideal value expected by the recovery slope. We feed that into a regression algorithm per magnet to find the structural error between raw and ideal value for that magnet. We then use that relation to clean up the new datapoints for that magnet.

It is an additional pre-filter helping the main algorithms. As experimenting with your data shows, the main algorithms are extremely robust against noise. But the CEC filter does help stabilize things.

It works well, we see less issues with noise, and thus a more stable set of metrics.

I will add a csv file with rectangular force curve, no noise, no placement error, 1.3 [m] drive length, 20 SPM, theoretical power: 260 [W], 60 strokes, >800 [m]. Force jumps up and down to 600 [N] in 10 [ms] (which is simulation time step) . I am curious to know what slew rate your CEC filter produces. My filter produces about 10 [N/ms]. c2sim_m0fxp0n0_6p.csv.zip

Interesting, but not sure how this relates to the CEC-filter. CEC learns during the recovery from the recovery slope.

To explain, we have two seperate streams of metrics calculation:

• Basic metrics, like time, distance, pace, power, strokerate, distance per stroke etc., which are always based on (a significant) angular distance travelled, a (significant) time period to do that and a dragfactor using robust math
• Advanced metrics like instantanuous handle force, instant handle speed and instant handle power which are based on angular velocity and angular acceleration using a quadratic Theil-Sen based Savitzky–Golay filter.

There are two streams with different filter mechanisms involved, so there is no reason that calculation of power via the basic metrics should match power via the advanced metrics. In a pure theoretical noisefree environment they should, but in reality it is tough.

PM5: logical choice. Making smooth force curve is easy, but it might become just a Gaussian bell curve blob.

That indeed is a concern. But my own force curves show enough issues to convince me there is enough detail there :)

Could this approach be related to the sometimes (too) long drive lengths? (BTW. rwnp estimates the drive length of the square wave force curve as 1.4[m]. This is obviously due to the fitering in combination with the unrealically steep force curve.)

I suspect it is a side effect of the filtering we do on the force curve. It tends to flatten peaks (as it tends to favour gradual change). So peak force is less high. As torque is used for stroke state transitions, it also tends to lengthen the drive as force fades out a bit slower. So the overall curve is squashed a bit.

[klamp169]

For a magnetic rower: I assume the flywheel dynamics can be modeled with: $J_m\dot\omega=T_{in}-k_m\omega-T_{bm}$. Due to lack of data, I assume that the effective inertia $J_m$ equals $0.1001[kgm^2]$ and $T_{bm}=0[Nm]$. I kept everything else the same as for the first simulation we discussed. For $k_m$ I found that a value of $0.015 [kgm^2/s]$ gives reasonable results. I used the parabolic force curve, exactly as before, which should lead again to 173.33 [W] in steady state. see csv file c2sim_m1fxp0n0_6p.csv.zip (no noise, no placement error). rwnp found 175[W]. I did not make any modifications to rwnp, which is of course 'ridiculous', since for instance $\omega = c/(t-t0)$ during recovery does not hold anymore. Coast down follows exponential decay now, not 1/t as for the air-rower (and water rower??). I hope it works for you. Let me know. Of course, I'm open for any suggestion (like magnetic rower parameters) to improve.

[klamp169]

What we do with the CEC filter is measure the deviation between the raw value and the ideal value expected by the recovery slope. We feed that into a regression algorithm per magnet to find the structural error between raw and ideal value for that magnet. We then use that relation to clean up the new datapoints for that magnet.

Clarifying and inspirational. Thanks.

Interesting, but not sure how this relates to the CEC-filter. CEC learns during the recovery from the recovery slope.

I was just curious to what extent ORM 'flattens' the rectangle. I tried it myself in ORM and the resulting force curve looks very similar to what rwnp produces. But I am not 100% sure I use the proper ORM-settings.

To explain, we have two seperate streams of metrics calculation:

• Basic metrics, like time, distance, pace, power, strokerate, distance per stroke etc., which are always based on (a significant) angular distance travelled, a (significant) time period to do that and a dragfactor using robust math
• Advanced metrics like instantanuous handle force, instant handle speed and instant handle power which are based on angular velocity and angular acceleration using a quadratic Theil-Sen based Savitzky–Golay filter.

There are two streams with different filter mechanisms involved, so there is no reason that calculation of power via the basic metrics should match power via the advanced metrics. In a pure theoretical noisefree environment they should, but in reality it is tough.

Now I do understand your worries on internal consistency.

PM5: logical choice. Making smooth force curve is easy, but it might become just a Gaussian bell curve blob.

That indeed is a concern. But my own force curves show enough issues to convince me there is enough detail there :)

Same here!

[JaapvanEkris]

This one is > 691 meter and includes some magnet placement error : [-0.01, 0.1, 0.2, -0.2, -0.1, 0.01][deg] concept2_3_sim_6p.csv.zip. Note that the magnet placement error sums to zero. It is of the order of magnitude I see with my concept2 with optical encoder lines.

Could you create a clean one with variation across the strokes. For example alternating strokes with 500N peak and 700N peak. I want to see how the mathematics handles this.

[klamp169]

Here you go:
c2sim_m0fxp0n0_6p.csv.zip

Parabolic force curve, no magnet placement error, no noise, drive length $l_{drive} = 1.3 [m]$, drag factor = 120, 500/700[N] alternating, starting with 500[N], 20 [SPM], $T_b=0[Nm]$.
This should result in alternating stroke power of 144.44 [W] for the 500[N] stroke and 202.22 [W] for the 700[N] stroke, based on $P_{stroke}=\frac{SPM}{60}\left(\frac{2}{3}F_{max}l_{drive}\right)$ (Holds for parabolic curves only.)
Interestingly (and somewhat annoyingly), since monitors generally leave out the dynamic part of the power, these values will not show up. At 700[N] strokes, the power shown on my PM2 monitor is 161[W] and at 500 [N] strokes the power is 181 [W]. I am very sure you are quite familiar with this phenomenon.
When I run this data through ORM, I see very little power variation between the alternating strokes: 168[W] to 170[W] in steady state.

Let me know if this data is ok for you.

You may also like a simulation with single power strokes every N strokes (say, N=15).

[klamp169]

So, that's what I did:

A power-stroke every 15 strokes.
c2sim_m0fxp0n0_6p.csv.zip
(Apologees for same file name as previous one.)
I have been experimenting with it a bit already and it leads to interesting results:

The curve labels must be interpreted as follows:

• P_dyn is output from rwnp and represents the power calculation including the dynamic term $J\dot\omega\omega$
• P_PM2 is the transcribed power values from the PM2 monitor
• Power (watts) originates from ORM CSV file.
• P_rwnp represents output from rwnp and is defined as $P_{rwnp} = \frac{1}{T}\int\frac{k}{J}\omega^3dt$ integrated over entire stroke.

The power-stroke occurs at stroke number 30.

Some observations:

1. Effect of power-stroke on PM2 output can be seen upto 3-4 strokes later.
2. Peak power value on PM2 occurs at the stroke directly after the power-stroke (annoying, IMHO).
3. Steady state power values are quite close, ORM is slightly lower than other values, as seen before.
4. P_rwnp is in good agreement with P_PM2 and also with the theoretically derived values, given above.
5. The power-stroke power for ORM is considerably higher than for PM2 (or P_rwnp), but the power value for the stroke after the power-stroke is considerably lower.

All this has some effect on the power readout of the various monitors, obviously, but little to no effect on the more important (?) distance rowed.

I hope some aspects may have some value to you. It helped me to understand the various monitor outputs and to pinpoint some significant differences.