You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
User max comfortable manual torque, drops linearly with exaustion
User max comfortable manual torque, varies with speed in a parabolic curve
Using max manual torque, is expodentially (not linearly!) more exausting than using max comforatable torque
Currently the amount of assist, is a linear scale
Which means users inherently want to enable higher assist levels at higher external torque loads.
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:
Relatively low torque by the user
Normal to High cadence
Relatively Low speed
A simple way to fix this is the following:
If torque is < x
If cadence > y
If speed is between 4 and 10 kmh
Then increase assistance level from "Dynamic Torque Assist" by a factor to (so from 0.75 to 1.5 for example)
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.
The text was updated successfully, but these errors were encountered:
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.
@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.
The text was updated successfully, but these errors were encountered: