Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Smart-Assist] Use increased processing power for improved assist-calculations #3

Open
Ornias1993 opened this issue Jun 7, 2021 · 2 comments

Comments

@Ornias1993
Copy link
Member

*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:

  • 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.

@casainho
Copy link
Contributor

casainho commented Jun 7, 2021

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
Copy link
Member Author

@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👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants