Open Ornias1993 opened 3 years ago
casainho
commented
3 years ago The wireless board (same as Arduino ML) should be able to run some small machine learning algorithms and connected to a IMU inclination sensor, maybe that could be the missing piece.
Ornias1993
commented
3 years ago @casainho Thats a quite interesting idea and would also seperate more advanced logic from the actual motor controller (and thus decrease the amount of potential issues👍
*Part 1: Introduction
The current assist level is calculated as a factor of the users input (by default: Watts).
However, drafting some example cases, this way of calculating assist is extremely inefficient and requires user intervention, which might lead to the user running a higher assist level than actually needed (which lowers efficiency even further).
Some descriptions/facts/assumptions:
There are two parts is writhing a good smart-assist algorithm that, using the stronger processor in the new controller, should be (relatively) easy to implement:
Part 1: Dynamic Torque Assist
Dynamic torque assist, scales the torque assist amount (the factor) expodentially. Starting (at low manual torque) with a rather low amount of assist (lets say 0.75x), increasing to an "average assistance" on the "max comfortable manual torque" and when thats exeeded it expodentially increases quickly to a much higher level of assistence (2x for example).
This addition should also remove the need for things like a "startup boost" or an "emtb mode".
Part 2: Automatic "power zones"
Dynamic Torque Assist, does not take power or candance into account on purpose. Everyone has their own optimal cadence and Dynamic Torque Assist, tries to increase assist more with higher torque to enable people to keep using the same cadence as much as possible.
However, there are a few more extreme cases where more assistance is needed, even though the amount of manual torque applied by the user is relatively low.
For example: Riding up the mountain, the user might pick a gear with a relatively low manual torque but a relatively high cadence. This is most often done when the speed drops and the user wants to avoid "stalling" and falling of his bike going up a hill.
This scenario has a quite unique character and can easily be mitigated however:
A simple way to fix this is the following:
Part 3: How it is going to come together
When these 2 calculations are combined, the user should be able to run close to "eco" assistence level on flat roads without much wind. When there is some wind he will use a little more torque and hence also gets a little higher "percentage" of assistence.
When said user then tries to ride up a steep hill and switches to a ligher gear, his torque and speed drops, his cadence increases but the motor will compensate detecting he is likely going up a steep hill and needs more assistence.
Then the user goes through a mountainbike trail with some rough technical sections, these sections do not create a high candence, but does increase significant torque spikes. The motor detect these spikes and tries to compensate accordingly by increasing the amount of assistence.
When the user is done he drives back home, with wind against his back side. The motor starts limiting the amount of assistence back to what we would currently be describing as "eco".
Above use cases would currently require the user to change assistance level multiple times, where a "smarter" way of doing assistance would try to "anticipate" how much assistance the user actually needs.
Why focus/submit for motorcontroller v2? I do not think the V1 controller has enough memory and processing power to continueslly and quickly evaluate all data to calculate a new optimal assistence level.