Bug: angularDisplacement calculation in RowingEngine.js contains an error

[JaapvanEkris]

There is a bug in the angular displacement calculation of RowingEngine.js in Line 121: in the calculation of recoveryPhaseAngularDisplacement the flankDetector.noImpulsesToBeginFlank() is missing. Every AngularDisplacement that is related to linear distance calculation should include it, as you haven't got a clue about the status of the flank itself..

[laberning]

Hi Jaap,

good catch and thanks for reporting this! Just did some quick tests, fixing this would have quite a bit of effect on the calculated metrics, so we might also have to alter some parameters of the rowing profiles.

Otherwise some people might be surprised how their fitness changed significantly from one day to the other 😄

Will take a closer look at this soon...

[JaapvanEkris]

Yeah,

I always hope to find a bug that makes me faster. Sorry :)

We could wait until the new RowingEngine comes along, which is a month to two months out by my current estimate (you can have a peek at the raw test-code here: https://github.com/JaapvanEkris/openrowingmonitor/tree/Raw_Implementation_As_Is , but be aware, it really is well-tested code, but not cleaned up or optimised). That update will change some settings anyway, and the dynamic dragfactor calculation will behave differently.

[laberning]

Getting faster by hunting bugs, thats the spirit 😄 Unfortunately fixing that bug makes everyone slower though 😄 It is quite easy to tweak the rower profiles of all rower models that we have test data for so the result stays almost the same so I think it is safe to release the fix.

That draft for the new implementation already looks really promising! I'll try to keep changes to the core physics engine to a minimum in the coming months to minimize friction...

[JaapvanEkris]

Please let me know if you need specific metrics which I can include (and test?) from the start. For example: in your game you (obviously) needed unfiltered raw power. In line 69 and 106 of RowingStatistics you can intercept it by saying RawPower = stroke.power, followed by a powerAverager.pushValue(rawPower). Another interesting one could be peak force or average force. If you need more of those metrics, please let me know, as I'm expanding them anyway for the RowingData export.

[laberning]

In general for games we want to go for more direct, unfiltered metrics since those would feel more responsive when controlling games. So far I've experimented with a first simple game that is basically controlled by stroke rate and stroke intensity but there is quite a bit more that can be done there. Peak forces and average forces could come handy for some game mechanics, also some interesting game controls could be pulled out of the power curve. Basically everything that we can extract from the drive phase can become interesting as a game controller...