Abilica Winrower 2.0 confirmed

[solmoller]

Just to let you know that Abilica Winrower 2.0 appears to be a very easy task to convert to Open Rowing Monitor.

I'll submit more data as I progress, but so far my main worry is that the reed switches are reading the driving wheel, not the flywheel. I suppose there are two reed switches on the Winrower so that the system differentiates back and forth on the driving wheel.

I might have to fit a new switch and a couple of magnets to read the flywheel, but that should be a very easy task.

The system has four impulses per revolution of the driving wheel in the left side of the picture, the flywheel is in the right side

So far the major problem was that I had to inspect the installation file to find out, that the software is installed in the directory /opt/openrowingmonitor. The documentation assumes that the user knows the install dir.

BR Henrik

[JaapvanEkris]

Thanks for reporting this back!

I've been thinking about the effects of this kind of monitoring. You can either keep the reed-switch as-is, and set the damper setting to something static in a way that the metrics start to make sense. The benefit is that it is easy to implement, but the disadvantage is that starting to row with more force isn't easily detected.

Another option indeed is adding measurement to the flywheel, which really upgrades your rower. One word of caution about that procedure: this isn't trivial. Most (cetrainly not all!) flywheels are balanced, so adding magnets might disturb that balance. The experience also is that reed-switches are quite vulnerable to decent placement of the magnets (the magnets should get pretty close to the reed switch). So using four magnets and placing them perfectly on each quarter of the flywheel (or just two) requires some planning.

If you need any help with finetuning the settings for your rower, please let us know.

[solmoller]

Two topics;

Firstly the Winrower is perfectly capable of calculating load from existing switches. If it can be solved in software, why change hardware? So I'll be working with one switch, and then if need be spend an entire GPIO pin to read the other switch, if, and only if one switch is not sufficient. The main issue is that my switch is triggered on both back and forward movement, and the software will probably look at the wrong half of the action, if it filters anything out. (Goes out and researches GPIO timing, seems better than ten years ago when last worked with it)

Secondly, I've spent the day trying to fill a gap in your ideas section:

• implement or integrate some rowing games
  With Scratch on the Rasbperry Pi it's actually pretty easy to build simple games, and make them use GPIO as input. We'll have something like the fish game on a Concept. I'm pretty far with the project, I'll probably have something playable by tomorrow

If that all works out, then I'll look into reading and changing the load setting on my Winrower, if that works, Winrower 3.0 is open source :-)

[laberning]

Hi Henrik,

first of all welcome to our little open source rowing community 😄

It's really interesting to see how many different approaches there are to measure the rowing characteristics. I think what your machine does is quite similar to how SmartRow measures the device (https://smartrow.fit). This approach requires a way to differentiate between backward and forward movement, hence the two reed sensors.

An advantage of this kind of measurement is of course, that it make it super easy to differentiate between the drive and recovery phases of the stroke, but there is no way to measure advanced parameters of the flywheel like the drag factor.

I currently don't see a super easy way on how to use this with the current rowing-engine of Open Rowing Monitor, but what might work is something like:

• If you hook up both reed sensors to the Raspi you could try to modify GpioTimerService.js so that it will only delivers impulses when the handle is pulled (drive phase)
• The measurements for the drive-phase should be quite similar so I would assume that our engine should handle those well
• For the recovery phase we would probably need a new logic, also calculating the assumed rowing distance would have to work differently

[solmoller]

Thanks for the feedback, I'll look into this as I progress, for now I'm happy with the game that I just got working.

I've clanced one last time at the system before sealing it, one switch appears to be 'stop' indication, so the system can reset at start.

The system counts cycles and see when reversing happens, that's pretty clever:

If it sees the pattern
xyxyyxyx then it knows, that what really happened was xyxy (turn) yxyx
xyxyxxyxyx then it knows, that what really happened was xyxyx (turn) xyxyx
There may be a little error when the change in direction is just on top of a switch, but who cares?

I thought I had to look at the timing of the switches, but I think the above is sufficient, if it's not enough to tweek Open Rowing Monitor.

Meanwhile I have the first playable game, I'll add that in a separate discussion

BR

Henrik

[JaapvanEkris]

There are rowers that don't make the distinction, I guess some water rowers use that approach as well. Here you simply measure on the pulley and the reversal might cause some issues (as the reversal might cause a quite short time between impulses). The noise filter could do a lot here, but it can't create things that aren't there. But it might work.

When the second switch is just a stop signal, it might also work. When you set a static calculation (thus naturalDeceleration to 0 and autoAdjustDragFactor set to FALSE) the rower basically converts impulses to distance and measures the time between impulses to keep track of time. As most metrics are directly derived from impulses, they should be pretty OK, providing you provide decent parameters.

Some internal metrics (especially driveDistance and recoveryDistance) which we plan to expose through exports might be totally useless, but the most essential metrics still should work.

A potential issue might be the triggering of the stroke detection. Stroke detection is triggered (when naturalDeceleration is set to 0) by acceleration, i.e. a shortening of the time between impulses. Although one big interval might do the trick (I actually don't konw), you can set a timer in GpioTimerService.js to simulate a recovery when the recovery is started (i.e. an imulse every x miliscenonds, with a longer interval than normally encountered during a drive). Keeping the flankLength to 1 might be needed here.

[solmoller]

Thanks for the tips
The second switch is permantently closed at stop. It also generates pulses during operation, but on a separate wire, so I'll go with the filters first, then I'll look into hardware if need be.

[laberning]

So far the major problem was that I had to inspect the installation file to find out, that the software is installed in the directory /opt/openrowingmonitor. The documentation assumes that the user knows the install dir.

Ideally one would not need to know the the application directory, since you could edit the configuration via the network share and could interact with the system services to restart it. However there might be cases where you want to directly tweak the application directory (i.e. for debugging). I'll update the documentation to make this a bit more specific.

For the reference, here are some tips on how you could interact with the services:

The install script already prints a message for this at the end of the installation:
"You can now adjust the configuration in /opt/openrowingmonitor/config/config.js either via ssh or via the network share"

You can always find the full path of an executable with the which command:
which openrowingmonitor.sh

Manually restarting the system service (i.e.) after config changes:
sudo systemctl restart openrowingmonitor

Get the status of a service:
sudo systemctl status openrowingmonitor

Show the log output of a service:
sudo journalctl -u openrowingmonitor

If you selected the option to run the GUI, then there is also a second system service called webbrowserkiosk.

[solmoller]

Thanks!