Issue with stroke detection in old-school mechanical FlyWheel

[JaapvanEkris]

Hi Lars,

I was able to hook up my rower to the Raspberry Pi and OpenRowingMonitor. I have the idea that stroke detection is off somehow as when I rowed 25 strokes, the monitor said over a 100. It also isn't consistent: sometimes it adds just one during a stroke, sometimes four.

I recorded the data and pasted into Excel. The raw datagraphs are showing nice clean breaks. In the excel added some backward-oriented hysteresis to the raw data (i.e. absolute minimum and maximum values, as well as an maximum change of 25% with respect to the average of the last two accepted measurements), and the data looks pretty clean to me.

I did correctly set up the number of magnets (there are four!) and I set the "liquidFlywheel" to false.

To aid your analysis, I add the raw simulation file of the four runs I had, each run has 25 strokes, as well as the processed version in csv, and the resulting data from syslog in debug-mode for the third session. To be complete, I also add the RowingEngine.js. As GitHub doesn't allow me to upload .js and .csv files, I renamed them to a .txt.

RowingEngine.txt
Overview Sessions.xlsx
rx800_First25Strokes.txt
rx800_Second25Strokes.txt
rx800_Third25Strokes.txt
rx800_Third25Strokes_Syslog.log
rx800_Fifth25Strokes.txt

[JaapvanEkris]

Hi Lars,

Compliments for the high quality of coding, and that is from somebody who reviewed code for decades as a professional. I could simulate the algorithm with real data and see where it went off the rails. I'll attach the Excel that helped me understand what was going wrong.

I think I found the cause of the issue: it is in the core of the stroke detection. In essence: your approach for stroke detection is sound from a mathematical perspective, but it has the tendency to fail on the higher rotating air-resistance rowers, especially the ones with more magnets. What happens is that the continuous differentiation, based on currentDt (basically Delta Time), which you translate to Angular Velocity. I'm not certain how omegaVector (angle speed) and omegaDotVector are related, my gut tells me that that is the Angular Acceleration (and not Angular Velocity already). Anyhow, because of the Delta of the omegaVector, this enlarges any measurement errors as frequent measurement also brings subsequent measurements closer together (i.e. the wheel has not time to accelerate/decelerate that much). So basically you are substracting data that is pretty close together, which leaves you a lot of measurement error (see "Fifth 25 Strokes RAW" in my Excel). As the measurement speed is so high, chances of getting measurement errors are also bigger and also that they are significant (as the numbers are smaller). By the repeated differentiation, you mathematically end up with a constant and the measurement errors take over.

When I looked at the data, my idea is that looking at the OmegaVector should work: the splits are easily identifyable.

So what I did to fix stroke detection:

• Add some hysteresis to currentDt by using a buffer: the value of the currentDt may not be 25% off the average of the previous two currentDt's and must be between two cut-off points (in my case 20 and 35 miliseconds). When it is outside bounds, I simply use the previous value.
• I "decide" that a stroke has occured when there are four measurements that confirm a curve: i.e. OmegaVector[0] > OmegaVector[1] AND OmegaVector[1] > OmegaVector[2] (i.e. two measurements show deceleration), and OmegaVector[2] <= OmegaVector[3] AND OmegaVector[3] < OmegaVector[4] (i.e. the next two measurements show we are now accelerating). Here, OmegaVector[4] is the current OmegaVector.

Based on my Excel file, it seems to work: I played with it, you need the hysteresis to make this work (flattening noise at the source) and the flank detection can't be less rigid. See "5th 25 Strokes w hyst, Velocity".
Overview Sessions.xlsx

[JaapvanEkris]

I implemented/hacked something to simulate the behavior of my Excel file. I ran all my files, and this approach handles it much better. I hope you see some inspiration to improve the code.

RowingEngine_MODIFIED.txt

[laberning]

Hi Jaap,

thanks for the compliment and great that you found a solution for the stroke detection on your rowing machine. You are absolutely right with the fact, that the mathematical theory and the reality of measuring real rowing devices have a certain gap.

The good part is, that the theory is relatively simple (this is a good explanation of it). So far my perception is (from the limited number of rowers that I've seen real measurements of), that the model for simulating power and boat (for speed/ distance) seem to work quite solid with most rowers.

The challenging part is to figure out a stroke detection that works reliable on different rower models. And that is something that I would like to improve in the future. Some challenges seem to be:

• The number of data points is very different for different rower models (something between 3 to 100 data points per stroke)
• The precision of the measurements is different
• For water rowers the speed of the "flywheel" can oscillate, if you apply a strong force (I guess it is because the pedal swirls in the water)
• There seem to be rowers, that attach the measurement device to the pulley of the belt

I think all of these challenges are solvable, but I guess it will take some thoughts and experiments to figure out a parameterizable mechanism that works reliable with most rowers.

And at that point those raw measurements from devices really become valuable - for identifying these different challenges for stroke detection and then later to verify the implementation (and prevent regression by feeding them into unit tests).

The excel that you created will be helpful in further analysis and is quite sophisticated to the one I've created so far 😄. Only thing I would change is the x axis if you want to plot rotational speed over time. Since the rotational speed is measured with a non constant sample rate (sample rate changes linear with the rotational speed), you will end up with a shaky time scale if you plot the data points in even distance. Instead one could use the sum of dt.

If you are interested in contributing on the topic of stroke detection feel free to contact me directly (i.e. linkedin or twitter).

[JaapvanEkris]

Hi Lars,

I am more than happy to help out. I contacted you through LinkedIn.

It is a challenging subject indeed, which makes it interesting. I have some ideas as well, I'll implement a more generalised version of the current implementation and see what it does. I think it will work on a machine with enough datapoints during a stroke, but three is extremely challenging. I think it is important to stay as close as possible to the flywheel: what I see is that split times on the 500M are pretty robust, while the rest is unstable due to measurement errors.

I needed the Excel to get an understanding of what was happening in the first place. I put the measuring point on the x axis as I'm lazy, but also because it is the only thing that is truly fixed: the rowed distance in radians. From there on, it was just recreational maths :).

I think the raw recordings are extremely valuable. The raw data contains a ton of information that normal rower monitors can't produce. For example: from the data I put up here, I learned that my drive is only 0,5 seconds long, and my recovery 1,5 seconds. Perhaps my rhythm needs some improvement (see https://www.rowperfect.co.uk/teaching-rowers-rhythm-and-ratio) Having that kind of detailed feedback is interesting, and could be great to expose through the web-interface to tablets etc.. I think it would be too complex to process that data during the row, but it would allow for great basis for further analysis (especially when combined with heartrate). Doing post-processing has the benefit of using foresight: you can see what happens after the current datapoint, making things like stroke detection much more accurate. I would make it a permanent feature to record them automatically (as soon as you introduce the concept of a session).

[JaapvanEkris]

Hi Lars,

A first solution with decent code and "some" parameters that can be tuned to the machine. I placed the really changed code it in the modified code in the "liquidFlywheel = false" part, as I can't test whether it can be tuned to a waterrower.

First step is the sanity check of the recently gathered currentDt. By simply doing some sanity checks, I was able to reduce the false strokes with 50%. Given the machine it could be less effective, but putting some sane values in there does help. First check is a hard range check (upper and lower), second is a sanity check based on the procentual change with respect to the previous points. When the machine has less datapoints, this can be eased quite far.

Second step is the Phase detection. The main concept op the Phase-detection is that everything on the rower is fixed enough that I can only need to care about time: based on change of the intervals between magnets you can decide whether the wheel is accelerating or decelerating. I feed that flank-detection in a mini-state machine which decides if a Phase can be changed. Here some parameters can be modified as well:

• The MovingFlankDetector, which in its initialisation in the RowingEngine takes some parameters: the length of consecutive decreasing/increasing intervals before the algorithm decides it is accelerating/decelerating, where the minimum is two points (i.e. one interval increase/decrease), the initialisation value of the array (shouldn't be modified by user) and the number of errors allowed in the flank (oddly enough, I got my best results with 0). I tweaked these numbers based on the number of detected strokes. Based on this, I got most of my testtracks to the correct number of strokes.
• The minimum length of a drive (minimumStrokeTime) and the minimum length of the recovery phase (minimumRecoveryTime), which prevents false phase detects in the noisy phase changes. These false detects are easily identified as they are strokes of less than .500 seconds following/proceeding a too short stroke (some stability in the strokes is needed to do this). By tweaking this setting, I could make my drive-time quite stable.

I hope this works for you too!

MovingFlankDetector.txt
RowingEngine_NEW.txt