Retrofit Touch display in 3D-printed case for NOHRD WaterRower (incl. my config) #26
Replies: 8 comments 20 replies
-
|
Amazing work :) I found this in thingiverse. Thanks for uploading. Did you use the whole sensor from your link, or just the sensor part with 3 connectors? If you understand. I have quite the same rowing machine, and my ORM is actually quite close to reality with reed and one magnet, But I might just be lucky tho. I am still working with the setup and calibration to match the reality as close as possible, but settings feels like a mess sometimes. Thanks mate:) |
Beta Was this translation helpful? Give feedback.
-
|
Hi, it depends on which sensor you want to use. I bought this one. It has completely ready-made electronics that just need to be connected to +3.3V and GND. You can connect the pins directly to the Raspi. The sensor signal is connected to GPIO 17 just like shown in the documentation of this project. Furthermore: |
Beta Was this translation helpful? Give feedback.
-
|
Hi Tobi, I have this Waterrower Club model with S4 monitor but it's almost a decade old. From pictures it looks very similar to what you have so I am trying to replicate your setup somewhat My S4 monitor died more than a year ago so i rely solely on ORM (thanks also to authors and contributors for building this !) Currently i am experimenting with just the original sensor assembly. I fed it with 5v GPIO, a GND and then the trigger via the original connector that was connected to the S4 monitor. I then copied your config and changed numOfImpulsesPerRevolution: 4 -> 40 as i counted 40 gaps in the sensor disk Also changed these I must say I totally do not understand the math behind, just thinking the frequency is higher by 10x I have not really tested it in a full session but simply rowing seems to give acceptable reading As you have a lot of experience in this model i like to get your input
Many thanks Regards, |
Beta Was this translation helpful? Give feedback.
-
|
If I have understood correctly, you are interpreting that the original sensor gives 40 signals per revolution? For the mathematics, i.e. the algorithm of this project, the expert @JaapvanEkris has to say something to help you. I am not a software coding guy. |
Beta Was this translation helpful? Give feedback.
-
You're welcome! Love to see people upgrade older machines and extend their usefull life (and get their owners back in shape).
minimumTimeBetweenImpulses doesn't do that much (aside warning you that some times are out of range), and contribute to some sanity checks. maximumTimeBetweenImpulses does a little bit more, as it also determines when ORM starts and ends the session. You might take a look at https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Techtobi83 @JaapvanEkris for your quick reply I read a bit more into the rower settings and guess i need to first generate raw data & chart to have some inkling what to do next. But just want to also find out if the # of signals per revolution in my case make any sense before attempting any other parameters ? In my mind the original sensor assembly works like this so I counted the numOfImpulsesPerRevolution by the number of white spaces on the disk I also just realize that this setup differ from all in the supported rower list, from my understanding if magnetic sensing is used then this param value is way below 40. So in this context should i consider going magnets + hall sensor route, lower down the numOfImpulsesPerRevolution in config or physical or just stay on course ? |
Beta Was this translation helpful? Give feedback.
-
|
I generated some raw data with config, and what i could see on the screen feels OK gpioPollingInterval:` 1, createRawDataFiles: true, rowerSettings: { Output from the service Is the amount of raw data points a result of numOfImpulsesPerRevolution ? 2024-03-27_09-55-36_raw.csv |
Beta Was this translation helpful? Give feedback.
-
Overall, the number of signals has some influences, but they might not matter. Let me explain. Optical sensors actually tend to deliver cleaner data, as there is no signal bounce. So reusing that might be a good approach, especially as the sensor and disk are already integrated into the machine and seem to work well. In terms of volume of data, ORM should be able to handle it. WaterRowers tend to have a much lower RPM on the impellor than Air based rowers. For comparison, a C2 RowErg typically hits around 1000 RPM. So from a data detection and processing perspective, there shouldn't be an issue. There are some side effects to consider. Underneath all the physics, there is a small mathematical model that translates individual pulses into impellor/flywheel angular velocity and acceleration. This is the true core of ORM. The problem is that it uses mathematics that becomes tougher on the CPU as the number of datapoints it needs to consider increases. We control this number of datapoints with the FlankLength parameter. Up till now, we reached 18 datapoints without much issue on an untuned RPi 4. We normally advise to use twice the length of the number of impulses per rotation as FlankLength. We do this, as structural errors in a flywheel rotation (for example all C2 RowErg's have a non-perfect magnet placement) will be killed by our algorithm automatically. But, if the disk is nearly perfect, there is nothing in stopping you to reduce the FlankLength to the point where the CPU can manage easily. That high FlankLength is uncharted territory, but I think manageable.
I remember some people using this kind of setup. It can easily work.
I'd try the original sensor first, simply because it is well constructed into the design. Unless you are an absolute wizard like Toby, making nice a case and end up with a beautiful finish becomes harder when you start modifying stuff. If that route fails, you can always fall back to adding magnets. |
Beta Was this translation helpful? Give feedback.
-
Pace seems a bit low to me, but it could be that you weren't putting in a lot of power in your stroke. But that is a point of later concern :)
No, it is the other way around. The amount of raw data points is what it is. numOfImpulsesPerRevolution helps ORM understand what the angular velocity is: essentially, ORM uses numOfImpulsesPerRevolution to calculate the angular distance travelled between two consecutive impulses. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot @JaapvanEkris for all the detailed explanations and guidance. I will tinker with it a bit more specifically the param you pointed out |
Beta Was this translation helpful? Give feedback.
-
|
I'm interested in your results @ong228, as I have exactly the same setup as you - a Waterrower with no monitor. So if we can tap into the existing optical sensor it would be a more elegant solution. However if that doesn't work out then Tobi's magnet design looks like a great alternative. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @pangit99 , i have the following config working in terms of correctly detecting strokes and distance seems fine to me. The SQM reading though looks jumping around a bit and I was going to tinker a bit more with DragFactor param when our little home reno is over. I had DragFactor:4300 for a full rowing session but was not quite happy, value 5000 is not tested in full session I try to keep rowerSettings with minimal changes as possible from default, found that tight minimumStrokeQuality value solved the stroke detection accuracy somehow. Since i am running Pi Zero 2 , it does not seem happy with high flankLength Maybe we can start a new topic to share our findings ;) 'use strict' export default { gpioPin: 21, createRawDataFiles: false, rowerSettings: { } |
Beta Was this translation helpful? Give feedback.
-
|
I was going to try using a Pi Zero (original) since that's what I have spare. With the original optical wheel having 40 slots it may overload the CPU, so one way around that may be to 3d print a new wheel with say only 4 slots. I'm not keen on just throwing more CPU horsepower at the problem if it can be resolved in other ways. Worth a bit of experimenting. |
Beta Was this translation helpful? Give feedback.
-
|
Probably can try clipping some of the teeth and run with reduced impulses and flanklength (this directly affect CPU usage) |
Beta Was this translation helpful? Give feedback.
-
|
You can change the gpio service code with a counter to ignore every X impulses and only pass that to the algorithm. The CPU intensive part is not the interrupt but rather the algorithm. Once this is done you set the number if impulses per revolution to the reduced number. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Abasz, I have zero experience with this scripting, can you advise please if it is something to this effect in the gpiotimerservice.js or i am totally off the mark ? Say if i want to reduce to 10 impulses and flankLength:5 for eventually for e.g. ; i suppose also minimumTimeBetweenImpulses: also need adjusting ? At the moment my home is too messy to unwrap the rower and test but for me it is a great exciting idea to skip some impulses ` let x = 4 sensor.on('alert', (level, rawCurrentTick) => { |
Beta Was this translation helpful? Give feedback.
-
|
Please have a look at here. We have discussed such approach in the past. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ong228 can you explain your hardware set up? I cannot get it to detect my strokes at all. I found this circuit diagram for the OPB365T55 phototransistor my Water Rower uses, with values of 270 Ohm and 10 KOhm for R1 and R2 respectively. I am assuming the clear plastic side of the phototransistor is the LED i.e. the red cable (right?), so I've connected red to 5V via the 270Ohm resistor, and the blue (Vout) connected to GPIO17 on my RPi. the 1K resistor bridges +5V and Vout. Green is connected to Gnd. Am I on the right track? |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick sense check.Rpi does not do 5v. It only does 3.3v. so it is possible that the phototransistor does not have sufficient voltage to work. |
Beta Was this translation helpful? Give feedback.
-
|
I am using Pi Zero 2W myself and connected directly (w/ dupont) to the connector previously connected to S4 monitor Red - 5V from my Pi (pin2) One thing i notice though is that stroke detection does not work too if there is any typo in the config, took me a while to notice |
Beta Was this translation helpful? Give feedback.
-
|
What I mean is that you are saying that you are pulling Vout to 5v. The Rpi input pins are 3.3v the guaranteed low is below 1.3v (I think) and guaranteed high is 2.3 (I think) and max tolerance is around 3.8 generally. If you connect 5v directly it kills the pin. Now probably lucky for you is that by default there is a 10k internal pullup enabled. If you use the 1k resistor there you will have a voltage divider (1 to 10 considering the resistance values) that probably reduces the voltage. Now this is what you should do:
|
Beta Was this translation helpful? Give feedback.
-
|
How did you solve this in the end? What's the current advice on using the existing waterrower sensor in terms of hardware (esp wiring - direct connection to the rpi possible?) and software/script settings? Can't wait to install it on my rower! |
Beta Was this translation helpful? Give feedback.
-
Hi @hearttheart, For me both the physical connections (direct) and configs are still the same from APR 2024, was going to attempt the minor script change to discard some of the pulses but did not follow through. As i am the only user of the rower and i only really keep track of distance rowed per session of 30mins - not really track other parameters. But total strokes and stroke detection is correct for me as far as i can tell |
Beta Was this translation helpful? Give feedback.
-
|
@Techtobi83 really great setup! Could you describe how you installed the magnets? Is this a printed part or did you just glue them to a stock part? How did you make sure the distance between each magnet is correct? Also, it seems like the stock method of measuring is quite off, as referenced in the Smart row FAQ:
Also discussed here: https://www.reddit.com/r/Rowing/comments/dtm8v7/a_small_test_on_waterrows_stats_difference/ Seems to be connected to the positioning of the stock sensor. @JaapvanEkris would this be solved with measuring via the magnets installed by @Techtobi83? |
Beta Was this translation helpful? Give feedback.
-
Installing the magnets like TechTobi did, improves results. But it could be that the S4 is set too optimistically, which might be due to internal parameters as well. With the small amount of measurements the S4 does, it is hard to distinguish between measurement noise and faulty parameters. Please note: a S4 can't handle just doubling the magnets, as it will assume the impellor will be moving twice as fast. I actually disagree with the statement that the SmartRow is more accurate due to its approach. This really is marketing speak. Certainly not everything is related to power. I'm trying to not get too technical here, but I'll explain (the deeper math/physics is described here) why their approach is different, but certainly not perfect and might even be worse. Rowing metrics actually are derivatives/integrals from each other. Key metrics here are rotational distance, rotational velocity and rotational acceleration. When you have these, next to time, you have all other metrics that can be displayed. The step to Linear distance, Linear Velocity and Force are relatively simple then, providing you know how to measure drag. ORM, S4 and the RP3 start with rotational distance (measured by magnets) and then use derivation to get to rotational speed and derive further to get to rotational acceleration. Measurement errors in practice only manifest in slight errors in angular distance that will correct themselves within one full flywheel rotation. With traditional methods, like the S4 seems to use, these small measurement errors in position will be enlarged in the second derivative, resulting in noisy force curve. ORM moved to a much more advanced mathematical foundation (requiring quite some CPU power), so we don't have that issue as this type of noise is filtered out by the algorithm. So in this approach, distance travelled is rock solid as it is measured on the flywheel directly, average velocity is an extremely good approximation, but the force curve can be unstable as it can contain escalating measurement noise if you use too simple math. ORM's approach requires a lot of CPU power, but is accurate on all three levels. We are not certain what a PM5 actually measures. They technically could measure flywheel speed directly. However, their noise is still considerable, as In EXR you can see that as the displayed force curve is a bit wobbly. So that is a magical box, which also is the golden standard in rowing. SmartRow can take several paths, but I assume they took the smartest one. It essentially uses a load cell, measuring force. This makes nice accurate force curves. By adding a rotation measurement on the pulley one can can determine distance travelled by the handle (not of the impellor!). Measurement noise can have several forms here: time, force and distance can all deviate slightly, where distance and force can't be rectified across a rotation or stroke. Additional issues like belt slip over the pulley can seriously mess up measurements even further here. Taking the integral of force by distance they can calculate power. This calculation enlarges measurement noise. From there you can get to velocity, maintaining that noise. Multiplying with time and you'll get disance. This step increases the effects of noise. So the force curve is good, linear velocity noisy and linear distance even more unstable. An additional issue with SmartRow's approach, due to not actually measuring the effect on the impellor, is that it is extremely difficult to actually determine when the next stroke really catches: resistance force can originate from the return mechanism or from the impellor. So a weak catch (i.e. moving the handle without a good impellor catch) can add a lot of additional noise. As this determines the start of the drive and thus the integration, this is quite a crucial element to get right for them. In ORM we use two indicators (handle force and flywheel deceleration) for this for a reason: it is really tough to get right even if you see what the flywheel does. Our sister project ESPRowingMonitor also uses two similar but different indicators for that same reason. In ORM and ERM these errors results in some pure stroke metrics (distance per stroke, strokerate) being slightly off, nothing more. Key metrics will be unaffected in the long run. On SmartRow the power calculation gets more noisy and thus all dependent key metrics (!) are off. As an aside: the force of the recoil bungee can be neglected. It is a nonsense argument completely. Even an old guy like me pushes over 400N easily each stroke. When measured with a luggage scale, bungees hardly hit 20N. And the bungee actually returns that energy on the recovery by pulling you in. I agree that different muscles would benefit from that, but not really a big concern in the whole scheme of things. The biggest elephant in the room here is that a lot of energy (over 50W!) isn't measured at all, while being totally different on the water: you moving up and down. On an Erg, you push your own bodyweight up and down the slide each stroke, in a skiff, it is only 14 kilos being pushed underneath you. In the upcoming 0.9.7 of ORM we want to add this to some metrics (especially our power curve), to show the total amount of power produced. |
Beta Was this translation helpful? Give feedback.
-
|
Wow, thank you for this very insightful reply! Really adds a lot of perspective! |
Beta Was this translation helpful? Give feedback.
-
|
Just to add a little to what Jaap said in terms of measurement technique. I am working with a kayak ergometer producer (old Danube) to bring ESPRM to their ergometer. But the point is that they have tried several method for measuring power and related metrics. They tried two types of force gauge one that was placed on one of the rolling wheels holder (below is a picture of that) basically a load cell that measured the ropes force when pulling. The other was that they placed two devices on the carbon shaft of the paddle that measured the force directly there. The issue was stroke deduction since technically in paddling a kayak which is slightly different from rowing there is force from the ropes always on these strange gauges. So need to detect the form of the force wave to determine when you are in the drive and when you are in the recovery. In the case of the first option they actually ended up installing a hal sensor and magnets on the flywheel so they detect the acceleration and deceleration of the flywheel. As far as I understand that was used solely to determine if you are in a drive or a recovery (probably they also cross referenced the force data but I don't know ) In the second option, all they can use is force data to determine the phase. This is fine but the problem is that when you calculate distance or speed or overall power you need to filter out accurately what is a force in the data thst is actually moving the boat forward what is just either from the rope or the paddler holding the paddle itself. So what they can do is to disregard any force that happens within the recovery phase. They have done testing with real olympic athletes the result was the first option where they also measure the rotation of the flywheel to determine the actual phase of the stroke. This yield a much more accurate and interpretable results. They were so confident in the data that the Hungarian national kayak team uses this for performance measurement in laboratories (along with their ergo). I am hoping to see comparable results with our OEM/ESPRM ) rotational measurement against this force base measurement. The point I'm trying to make is that you cannot accurately measure things purely from force. I think they probably also measure rotation on the impeller rshaft. To be fair I don't even fully understand how they are placing in the smartrowt their strain gauges. Generally those measure best when things are bending alongside the guage:
This is old Danube. When one applies force to the rope there is an upward bending force on the metal "tongue" and they measure that. I'm the case of smartow I think this force measurement e is somewhat sideways. |
Beta Was this translation helpful? Give feedback.
-
Seen some guys paddle on a machine on YouTube, strokerates are insane, as is the power generated by them. So cool.
The behaviour of belts and chains is wild, especially above 30SPM in rowing, let alone a kayak with its bigger movements. At these higher rates the one end of the chain is totally doing something different than the other part, even when technically proficient rowers are doing it. Inertia in the chain does wild things. That is one of the reasons C2 has introduced a chain guide decades ago, to make sure the chain can't disconnect from its sprocket (what happened in the first model). SmartRow measures on the upper (open) pulley, which is probe to belt slip on higher rates.
Direction of movement in 3D becomes a thing quickly. I worked on magnetic axel counters for trains, which essentially measure magnetic forces in 3 axis (similar to more advanced load cells), dispite trains always moving in one. Learned a lot about 3 dimensional geometry and error correction. Extremely complex and tough math to get things right.
Yeah, it is a tough one otherwise. Measuring on the cable instead of the flywheel requires a lot of insight. On an easy stroke you'd expect the return cord tension to remain, while on fast strokes or wild strokes, the tension might be completely gone as the handle is quicker than the chain or even jumps over it. Mechanically forcing the cable/belt/chain over the sensor under all conditions is far from trivial. The C2 skiErg mechanically uses the same principle as the RowErg, despite having two independent cable systems. I guess partly because to reuse existing RowErg parts, but also as the mechanics actualy stabalize the measurement. Measuring the effect on the flywheel is much easier that load cells on the pulleys.
Wow! That is so cool.
Agreed. As a general rule of thumb, the effect if noise increases the more you process your data. So the longer the chain to the key metrics of time and distance, the tougher is to get it right. And measuring the interesting forces while ignoring the irrelevant ones is complex indeed.
I suspect on the inner or outer roller. Combined with a rotational sensor you get quite some info. But when not pulled perfectly straight, you get weird effects so mechanically they need something to correct that. The S4 ignores water level (and thus inertia) completely, making it unreliable. This is a thing that is easily fixed by WaterRower (or by retrofitting ORM or ESPRM). Others have managed to get it working reliably. RowPerfect's RP3 aqua is a promissing water-based machine from a company that supplied Olympic teams for decades. So from a basic approach, the impellor/flywheel based approach is much easier to get reliable. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
hereby i presenting my way, how I built this great project (with great help from Jaap - BIG thanks again!) on my WaterRower Classic from NOHRD:
This is an Raspberry Pi 4 PCB with an 4,3" Touchdisplay in an 3D-printed case. All detailed files and instructions can be read & downloaded here: Download here: https://www.thingiverse.com/thing:6421760
Version 2 of this case is online since 20th january 2024 with lots of improvements AND: all STEP-files can be downloaded too (so everyone with some 3D skills is able to modify this project for his own rower frame)
*** Note: I am happy to help if I can get some photos with measurements to design a bracket for your Rower ***
The deviation of the distance rowed after 10km between the original S4-Monitor and ORM was less than 1%.
I would like to thank all developers here once again for this great project. Your documentation is very valuable. Special thanks again to Jaap, who helped me a lot with the configuration via Discord.
I am now finally able to row online with you. Quick info why I didn't use factory options: the existing Bluetooth module "ComModule" , a bluetooth extension for the original S4-Monitor does not work for me technically. After communicating with the manufacturer support, the USB port of my original display is broken (replacement board: 150 EUR!). In addition, there are not many good reports about this thing (constant disconnections). The last option was the SmartRow, unfortunately extremely expensive. So now ORM is running :-)
My config.js:
'use strict'
/*
Open Rowing Monitor, https://github.com/laberning/openrowingmonitor
You can modify this file to configure Open Rowing Monitor to your needs.
This file should be placed in the 'config' folder of Open Rowing Monitor.
All available configuration parameters are visible in config/config.default.js
To modify a parameter, copy it to this file and modify the value.
Changes to this file are persisted when you update to new versions.
*/
// eslint-disable-next-line no-unused-vars
import rowerProfiles from './rowerProfiles.js'
export default {
// Available log levels: trace, debug, info, warn, error, silent
loglevel: {
// The default log level
default: 'info',
// The log level of of the rowing engine (stroke detection and physics model)
RowingEngine: 'info'
},
magicConstant: 2.0,
sprocketRadius: 9.0,
flankLength: 8,
minimumTimeBetweenImpulses: 0.005,
maximumTimeBetweenImpulses: 0.15,
minimumDriveTime: 0.40,
minimumRecoveryTime: 0.50
},
}
A few tips for beginners on how I finally realised the project (and also for me to read up on at some point):
I have not had good experiences using a reed switch (v1beta still ran with it, v1beta_updates did not --> switch bounce). I switched to an hall sensor (49e, https://www.amazon.de/dp/B07DPVTKBB?ref=ppx_yo2ov_dt_b_product_details&th=1 ).
The following 2 images shows the hugh difference:
Final notes:
The config.js is a "living" project, means: I'm still trying things out a bit.
Everything works as described above. But without using the "magicConstant" I was not able to set the rowed distance correctly.
Unfortunately, I can't increase the dragfactor very much. From 20000 fast strokes per minute (>24 spm) are no longer detected and from 22000 the stroke detection stops completely. Same problem with flyWheelInertia, which I can not reduce , otherwise stroke detection stops (at least the GUI).
Anyway, i am happy with the actual results, cause my goal was to get bluetooth support for my rower, to be able using EXR and rowing with other people worldwide. This goal was reached, i synchronised data with the original S4-Monitor so that my usual performance data also matches in ORM (EXR).
Greetings from germany
Tobi aka TechTobi
Beta Was this translation helpful? Give feedback.
All reactions