A DIY sensor to measure handle speed

[Nomath]

Thanks for the comments.
Since my last post, Jan-2021, the measuring set-up has been improved considerably :

• 4 magnets on the CD disc, which increases the resolution

• Hall effect sensor instead of the reed-switch sensor

• a much faster data logger samping at 1440 Hz instead of 240 Hz

All these items are still within the amateur DIY range and pocket, but the volume of data points were streching my software tools to the limits.
Here is an example of the quality of the results I could get. Compare it with the graph I posted on Jan-23, 2021.
The human rower was a near-elite, pulling some 700W during 10 consecutive strokes.



Most scientific investigations on the C2 erg, e.g. the Ulm setup, use a much better tool to measure the speed of the chainwheel axis : an optical rotary encoder that can produce 24-256 pulses per rotation and show the direction of the rotation.

I am not going to continue with this topic. This is the state of my DIY set-up as for now.

[Slidewinder]

When tests on the Ulm device that must be done, are done, and if the results show that the magnitude of the effect of variations in bungee cord strength on user times is unacceptably large, then measuring handle speed could be part of a corrective electro-mechanical strategy. The other part would be to precisely measure force at the handle/chain juncture. The acquired force and speed data would (by force X speed = power) enable the PM to do all of the necessary calculations and displays. These would be based on the user's total power output (that to the flywheel and to the elastic cord), so variations in elastic cord strength would be irrelevant. The PM connection to the flywheel would only be used to collect data to enable calibration of the monitor with respect to DF. Assuming other Ulm test rig results verify that DF is sufficiently accurate, then there will finally be a guaranteed level playing field in indoor rowing competitions.

[HornetMaX]

Most scientific investigations on the C2 erg, e.g. the Ulm setup, use a much better tool to measure the speed of the chainwheel axis : an optical rotary encoder that can produce 24-256 pulses per rotation and show the direction of the rotation.

From what I've read the Ulm thing does not measure the chainwheel axis speed, they have a linear magnetic odometer on the sledge position (which corresponds to the handle position, in their setup). And they work at 100Hz for both the load cell and the linear odometer. 1440Hz seems a lot of logging.

[JaapvanE]

And they work at 100Hz for both the load cell and the linear odometer. 1440Hz seems a lot of logging.

Without looking too deep at Nomath's specific setup, it depends on your setup. When using "intelligent" measurement equipment, 100Hz is fine as it provides 100 measured datapoints per second and accuracy is handled internally.

When using reed switches and general equipment, such frequency typically is the polling frequency, which translates to measurement accuracy. For example, in ORM we can poll the incomming signal state at 1 MHz on a Raspberry Pi 4B. This means we see changes with 1us accuracy. We still get around 100 datapoints per second, but as we use the timing between magnets to calculate speed, this accuracy is quite relevant. I experimented with the measurement resolution, and this accuracy is quite relevant for the results.

An even more elegant setup is Arduino's approach, which has hardware interrupts, and thus doesn't need to poll. However, these might not be powerful enough for further data processing.

[Nomath]

From what I've read the Ulm thing does not measure the chainwheel axis speed, they have a linear magnetic odometer on the sledge position (which corresponds to the handle position, in their setup). And they work at 100Hz for both the load cell and the linear odometer. 1440Hz seems a lot of logging.

You are correct! I wrote it down from memory without checking the paper, which is not good practise. Most scientific studies used a rotary encoder mounted on the C2 axis for measuring handle displacement. E.g. by Ingham at the University of Wolverhampton (2002), by Cerne at the University of Ljubljana (2011) and by Sarabon at the University of Primorska (2019).

1440 Hz is a lot, but it was needed for measuring high-power sprints. Mounting 4 magnets on the rotating CD gives me a spatial resolution in the handle displacement of 2.2 cm (chain 1/4 in ; chainwheel 14t ; hence resolution 14*0.632/4). As the above graph shows, chain speeds can get to 3 m/sec. One meter chain displacement produces 11.2 rotations of the flywheel axis. So 3 m/sec and 4 magnets results in roughly 132 pulses/sec. Pulses are broadened because of the size of the magnets and the reaction time of the sensor. To accurately time a pulse, I need 5 points/pulse, hence about 650 Hz sampling. OK, oversampling by a factor of 2...

[HornetMaX]

Right. Guess a better sensor would save you a lot of hassle (and logging). Shouldn't be very expensive either.

[Nomath]

For the record a correction : the above graph of handle speed versus distance was obtained with 6 magnets on the rotating disc, not 4. The spacing on the distance axis is then 1.5 cm and this gives such nicely detailed curves. For example, there are about 6 points in the drop near the finish of the drive. That corresponds to a distance of 9 cm not 'seen' by the PM.
However, with 6 magnets the signal peaks of the Hall sensor get blurred when handle speeds get over 3 m/sec, as was the case in the recoveries
That's why I settled for 4 magnets.
These measurements were done in april 2021, so my recollection got blurred too.

[JaapvanE]

However, with 6 magnets the signal peaks of the Hall sensor get blurred when handle speeds get over 3 m/sec, as was the case in the recoveries

Could it be bouncing of the reed switch? At higher speeds we found that some sensors provide a second signal due to the same magnet.

These measurements were done in april 2021, so my recollection got blurred too.

I know the feeling, but keep up the great and interesting work. You keep teaching many of us and inspriring us with these experiments.

[Nomath]

I used a Hall sensor, not a reed switch.

[HornetMaX]

However, with 6 magnets the signal peaks of the Hall sensor get blurred when handle speeds get over 3 m/sec, as was the case in the recoveries
That's why I settled for 4 magnets.

Maybe magnets are too big ? Too strong ?

Great work in any case !

[JaapvanE]

I used a Hall sensor, not a reed switch.

You are aware that Hall sensors are sensitive to the direction of the magnet field (see https://github.com/laberning/openrowing ... ussions/87)? Knowing you, you probably are aware, but just double-checking.

[Nomath]

You are aware that Hall sensors are sensitive to the direction of the magnet field (see https://github.com/laberning/openrowing ... ussions/87)? Knowing you, you probably are aware, but just double-checking.

I got aware of it when I ordered a batch of Neodymium-magnets and had to discard half of them.
Handle speed readings would be in total disarray when even one magnet on the disc was not 'seen' by the sensor. A small deviation in the circular arrangement of the magnets is causing a big jitter in the curves.

[JaapvanE]

Handle speed readings would be in total disarray when even one magnet on the disc was not 'seen' by the sensor. A small deviation in the circular arrangement of the magnets is causing a big jitter in the curves.

I know, thats why I currently have such huge issues with data not lining up on OpenRowingMonitor: the flywheel seems to wobble, and C2 is going to send a replacement soon.

What really helped me in reducing the effects (as long as you don't miss any signals), is using quadratic regression for the function of the angular distance over t. When using Theil-Senn regression over a set interval, it is pretty robust against noise while providing a responsive function. The first derived function then is the angular speed, the second derived function the angular acceleration.

[HornetMaX]

I know, thats why I currently have such huge issues with data not lining up on OpenRowingMonitor: the flywheel seems to wobble, and C2 is going to send a replacement soon.

What really helped me in reducing the effects (as long as you don't miss any signals), is using quadratic regression for the function of the angular distance over t. When using Theil-Senn regression over a set interval, it is pretty robust against noise while providing a responsive function. The first derived function then is the angular speed, the second derived function the angular acceleration.

Thx, I'll take a look at the data asap.

In the while, just to be sure I understand it right, you're using quadratic Thiel-Sen on angular distance data (vs time, as picked up by the generator/sensor): that means that you're assuming the angular distance evolution is a 2nd order polynomial in t, which means the angular velocity is linear in t and the angular acceleration is constant, right ?

[JaapvanE]

Thx, I'll take a look at the data asap.

In the while, just to be sure I understand it right, you're using quadratic Thiel-Sen on angular distance data (vs time, as picked up by the generator/sensor): that means that you're assuming the angular distance evolution is a 2nd order polynomial in t, which means the angular velocity is linear in t and the angular acceleration is constant, right ?

Yes, but we do it on a limited (moving) segment of 12 datapoints (i.e. two full rotations of the flywheel), so that limits the impact of this assumption. The issue is that a cubic regressor, which in theory is a better fit, might easily overfit the data (as the cyclic sinoid behaviour across two full rotations looks a lot like a cubic function). Moving to a three full rotation buffer to compensate for that issue in combination with a more complex algorithm might exceed the CPU capabilities for real-time processing (there are limits here which can easily be exceeded, as these algorithms tend to be O(n^4)).

So for us it is an active area of reseach what robust cubic regression can be used.