The purpose of this project is to provide professional-grade rowing (and other similar ergometer) analytics to indoor rowing machines, similar to the Open Rowing Monitor Project (ORM), but with a much more affordable ESP32 microcontroller.
This project aims to provide the same accuracy of rowing analytics to indoor ergometers (e.g. rowing, kayak, canoe, SUP etc machines) machines as ORM. However, with a much more affordable, compact, widely available and potentially battery operated ESP32 microcontroller.
The math and algorithm used in ESP Rowing Monitor are based on the approach developed by @JaapvanEkris that improves the stroke detection algorithm of the original ORM.
The choice of the ESP32 over the Raspberry Pi (Rpi) due to its smaller size, its operability completely from battery, its very low cost, and easy accessibility.
There is a lot of information available on the physics and math behind the code in the repos related to ORM. Before using this project I recommend reading the documentation of ORM (specifically the docs provided currently under the v1beta_updates branch) as this would greatly help with setting up and tuning in the settings of ESP Rowing Monitor.
Highlights:
- Very accurate stroke detection and a wide range of rowing metrics including force curve.
- BLE connectivity supporting multiple devices simultaneously.
- WebGUI for intuitive setup and data visualization.
- OTA firmware updates for seamless usage and detailed logging for replay.
An intuitive WebGUI can be accessed here that simplifies monitoring, configuration, and firmware updates, accessible directly through a browser. It’s an installable Progressive Web App (PWA) that works offline after installation. It connects to ESP Rowing Monitor via bluetooth taking advantage the WebBluetooth stack. For further details please read the documentation.
Currently, ESP Rowing Monitor is capable of calculating the following metrics, similar to ORM:
- driveDuration and recoveryDuration
- average cycle power
- distance
- stroke rate
- handle forces for the drive phase
- peak force for the drive phase
- drag factor of the flywheel (i.e. resistance level)
- speed and pace
ESP Rowing Monitor may not directly provide certain metrics such as caloric burn, heart rate, VO2max, etc. due to limitations of the device. These metrics require additional sensors or calculations that may not be supported by ESP Rowing Monitor's hardware or software capabilities. Users should refer to the Limitations section for more detailed information on which metrics may not be available directly from ESP Rowing Monitor.
ESP Rowing Monitor provides a BLE interface to get the data and metrics it measures.
It supports dual BLE connections, allowing simultaneous use of two clients, e.g. a smartwatch and the WebGUI or other compatible apps (like Kinomap, EXR, etc.).
ESP Rowing Monitor supports three standard BLE profiles that allows it to be connected to smart watches and 3rd party apps and smart watches (fully compliant with BLE standards):
- Cycling Speed and Cadence Sensor profile
- Power Meter Sensor profile
- Fitness Machine Rowing profile (currently experimental)
For further details how to set these up devices connected under Cycling Speed and Cadence profile or Power Meter profile please read the features section.
In addition to the implemented standard profiles it exposes certain custom profiles for additional metrics (fully supported by the official WebGUI). These are:
- Extended Metrics (metrics not included in the base profiles)
- Handle Forces recorded during the last drive
- Impulse time logging (logging of delta times for settings calibration)
Please see more details on their specifications and protocols under Custom BLE Services.
As of version 6 after the initial installation, an over-the-air Bluetooth update protocol is available.". The protocol is implemented in the WebGUI so installation can be done from there.
More details on the specification can be found here
It is possible to log deltaTimes (i.e. time between impulses) to an SD card (if connected and enabled). DeltaTimes are collected in a vector and written to SD card on every stroke (after the drive ends) or 4 seconds (which ever happens earlier). This incremental way of making deltaTimes available is to optimize performance.
Please see dedicated installation page
Please see dedicated settings page
The monitor works by detecting the speed of the rotating flywheel via measuring the time between impulses through a reed or hall sensor on the rowing machine (more on the physics here).
Please note that, for this monitor to function correctly, you need to measure the rotation speed of the flywheel rather than the handle speed. There are several discussions on this topic under the ORM repos. It is possible that one can make it work but I have not tested such setup. I recommend reading those discussions to better understand the consequences of not measuring the flywheel speed.
All the metrics calculated are based on measuring the time between two consecutive impulses. Time is registered via an interrupt that is triggered by the reed/hall sensor connected to the ESP32 MCU. Basically, the ISR gets the current timestamp in microseconds and calculates the delta since the previous interrupt (as well as counts the number of times the ISR is triggered). This information is then fed into the stroke detection algorithm.
One advantage of the ESP32 ISR is that it is real-time (compared to ORM's polling strategy), which in theory would make this solution more accurate. However, testing showed that any deviation of the data produced by ORM and ESP Rowing Monitor is within the margin of error. So there is no real evidence that this added accuracy can be translated into an apparent improvement of the data quality. Actually, due to some noise filtering that ORM has, ORM may be a better choice for certain setups (mostly machines that produce quite some noise).
This project by default uses the same Theil Sen Quadratic Regression model to determine torque as ORM, which is used as the main stroke detection algorithm. This is supplemented with a secondary fallback algorithm that uses a different approach compared to the way ORM tackles this. This secondary algorithm fits a linear regression curve to the calculated slopes of the recovery regression lines for every "flank" (i.e., it looks for the slope of slopes on every impulse). The slope of slopes calculated from the data points within a "flank" (once there is no power provided to the flywheel by the rower) becomes flat within a margin as the deceleration of the flywheel becomes fairly constant.
The default secondary algorithm looks for the moment when the slope of slopes flatlines (again, within a margin set by the user).
Nevertheless, for certain machines (based on experience where only 1 or 2 impulses per rotation is present), the user can select the traditional stroke detection algorithm. There are three options in this respect:
- the more advanced torque based with the slope of slope as secondary algorithm (recommended for machines capable of producing several impulses per rotation),
- the slope based (that is basically the traditional acceleration and deceleration base method), or
- use both at the same time
Please note that due to the difference between the Rpi and the ESP32 (including but not limited to the CPU power, flash size, etc.), certain limitations and constraints apply to this project. Please see the limitations section for further details.
- Implement a more flexible settings system that doesn't require recompiling and takes advantage of persistent storage.
Lars Berning - Original ORM implementation
Jaap van Ekris - Lots of help and explanation on the background and inner workings of the upgraded stroke detection algorithm