Better Stroke Detection Method With Hardware( Much lower computational requirement!)

[qchen98]

Upon opening up my Chinese concept 2 clone, I was surprised to discover that the original junk monitor uses two magnetic sensors instead of one.

I thought that the purpose of the two magnetic sensors was to calculate currentDt (time between impulses) with only one magnet attached to the flywheel, though the implementation is rather poor. Later it was found that the magnet is installed the fixed axle where the chain sprocket is attached to. It is also unlikely that the cheap monitor can perform any computational extensive work.

Therefore it seems that the two sensors are measuring the speed of the handle being pulled, thus giving an approximation of the rower's power. Furthermore, it also can be assumed that the two closely spaced sensors are well capable of detecting the direction of rotation( using the time difference between the impulses, we can conclude whether the axle is moving counterclockwise or clockwise).

Since those two sensors are pre-installed in most concept 2 clones, could we take advantage of those two sensors to get a more robust stroke detection method? The reduction in computational load seems to be very significant.

[JaapvanEkris]

Therefore it seems that the two sensors are measuring the speed of the handle being pulled, thus giving an approximation of the rower's power. Furthermore, it also can be assumed that the two closely spaced sensors are well capable of detecting the direction of rotation( using the time difference between the impulses, we can conclude whether the axle is moving counterclockwise or clockwise).

Yeah, we see this approach more often.

Since those two sensors are pre-installed in most concept 2 clones, could we take advantage of those two sensors to get a more robust stroke detection method? The reduction in computational load seems to be very significant.

I follow your thinking. Yes this approach will reduce computational load, but at the huge cost of metrics reliability. There are two major issues here:

• The sensor approach used by your machine indeed detects the direction of the handle. But as a good catch of the flywheel is far from guaranteed, it is unreliable to detect strokes. When combined with our stroke detection, which some academics have done, you can actually calculate "catch slip": the time between the rower changing direction and the flywheel being caught. But in itself it is far from a useable metric. You need to know what the effect of the handle pull is on the flywheel to get to true stroke detection.
• Stroke detection in itself isn't as important as many think. Current branches of OpenRowingMonitor can handle missed strokes easily. More important metrics are "angular velocity" and "dragfactor", which can only be measured on the flywheel directly (or the impellor on water rowers). When you have those, all other metrics can easily be calculated (like linear velocity, force curve, etc.). The math to do this on machines with measurement noise is the key driver of computational complexity. The math used for these algorithms essentially gives you stroke detection for free as we can look for behavior in those metrics that resemble a recovery.

Please note, the approach used by your manufacturer isn't as common as you think. Most cheap manufacturers basically make a pulse counter and add it to the flywheel. An approach shared with bike computers. It is inaccurate under most conditions as it completely disregards dragfactor, but at least it mimics what physically is going on to a better degree than handle movement.

PS: I advise you to switch to https://github.com/JaapvanEkris/openrowingmonitor as laberning's branches haven't been updated in almost three years, and I together with several other developers brought the code to much further.

[Abasz]

I have exactly the same clone which I changed to be compatible with flywheel detection: https://www.printables.com/model/442340-generic-air-rower-flywheel-magnet-holder#preview.axVlo

I kept the two sensor as well. I played with it back in the day when I started with ESPRM. When I had one magnet on the flywheel detecting the stroke start and the end of drive (mostly the latter) could have provided some advantage as it detected these events more accurately. Though there were quite a few issues:

1. At the catch when the magnet had to do a full rotation it was slower than the algorithm (with more magnets it was defiantly slower)
2. when you stop for a split second at the end of the recovery this method was late always regardless of magnet numbers
3. when you did not have a clear drive (e.g. you stop or the your movment is not perfect and the handle goes a bit back) and the magnet was close to the two sensor it completely messed up stoke as it detected a ghost stroke

Overall my experience was that it caused more complications than benefit. so now I only use these for powering on the device i.e. as a switch.