What should be user settable on a torquesensor based EBike system?

[stancecoke]

Hi, the Open Source Firmware for the Bafang CAN bus controllers is at a point, where I start thinking, which functions should be user settable.
Of course, you can implement any gimmick, if you are able to write the necessary code and compile the firmware yourself, but my experience with other projects shows, that only very few users are willing to go this way.
So I plan to make the firmware compatible to the Bafang Canable tool.
But many settings in this tool are not fully understood and some don't seem to be senseful or useful for the rider.
My main need would be the possibility to create your own ride modes. So deviations from the main logic "motor power = assist factor * riders power"
A mountain bike mode will be different from a commuter mode or a tour mode.
Any suggestions, what and how things should be settable?

There is a discussion about the Bosch ride modes recently, maybe we can get some inspiration there?

regards
stancecoke

 

[TPEHAK]

Sensitivity (ratio between the measured torque and the motor power)
Decay time (when the motor power start dropping after decreasing torque on the crank)
Decay profile (how motor power transfers from higher to lower state after reducing the torque on the crank depending on time).

Increasing toque on the crank should immediately be reflected on the motor power, but reducing toque on the the crank should not immediately reduce the power of the motor and should be adjustable).

With zero cadence or very slow cadence the motor power should be limited (or the ratio between the toque on the crank and the motor power should be very low). That "slow cadence" zone and the "slow cadence maximum motor power" (or ratio) should be adjustable also.

After passing the "slow cadence" zone the motor power should not immediately go to full match the torque sensor value, but it should have some ramping up zone between the top value of the "slow cadence" zone and the "power matching torque" zone. That zone should be adjustable also.

 

[stancecoke]

Decay time

This would be not useful for shifting gears at all.
I don't like any kind of artificial ramps, the support should always directly correspond to the riders effort without delay.

But of course this my personal opinion and I ask for yours in this thread

For all suggestions, we need the math and the parameters, to calculate the motor torque from the sensor data like torque on the crank, cadence, speed...

And we have to keep in mind, torque is something else than power

my favorite behavior for commuting is this: a linear increasing assist factor with speed. At low speeds in the crowd of the city, you have a good sensitivity, you can ride any slow speed you like, the higher the speed gets, the more power you get from the motor, so you need only little effort to keep a high speed.


This is quite easy to calculate:

motor current setpoint = (a*torque*cadence*speed + b*torque*cadence)/speed

So parameters a and b have to be settable by the user.

 

[TPEHAK]

I addition to decay time, there should be decay zone which will be measured in amount of pulses of the PAS rotary encoder. Whichevewer comes first (time or amount of encoder pulses) should command the power reduction.

For instance you do not want to precisely follow the motor power to the torque on the crank because of the torque on the crank in not consistent during one revolution and even goes near to 0 at some position of the crank. Without decay or some smooth algorithm the bicycle power will feel jerky. The higher the power the jerkyer it is going to be. At 4000W of power without decay you have like 4000W at 90 deg of crank arm and 0W at 180 deg of crank arm, and so on each 90 deg fluctuation between 0W and 4000W.

 

[stancecoke]

not consistent during one revolution

Of course we have to work with a mean value of the riders torque within at least half a crank revolution.
Please try to put your ideas into a mathematical formula.

 

[TPEHAK]

This is how motor power depending on torque should look like. Ideally it should be a graphical interface in the VESC Tool application just like this graph where user can drag the points of the curve and the application will determine the parameters



T is toque on the crank arm

𝜶 is crank arm position angle. The PAS can not determine the angle but the algorithm can use pulses per revolution parameter and peak torque within one revolution or 1/2 revolution or 1/4 revolution to determine the starting point of the decay moment

W is motor power.

The graph shows 𝜶 but not time. When cadence is slow the time should start commanding the decay interval prevailing over the cadence. When cadence is fast the cadence should command the decay interval prevailing over the time.

 

[TPEHAK]

In the firmware to make it simple it is not necessary should be a mathematical formula, but it can be mapping tables with multiple values the algorithm compares the actual parameters against to determine the motor power.

 

[stancecoke]

To meet the requirements of EN15194, the motor must stop within 2m after stopping to pedal. It is tested at 90% of the speedlimit of 25kph. So about 300ms after the last PAS pulse, the motor must stop assisting.

Bosch let you define individual modes by a graphical interface where you can drag points to the wanted position.

 

[amberwolf]

Do you accept feedback from those that will probably never be able to use the system, but would use it if they could in a way that's probably different from most users? If not, no worries, and apologies for the interruption.

My request, on behalf of the perhaps five other users on the planet that want to ride like I want be able to:


I cannot put this into a math formula, but the way I would want a pedal-torque-controllable system (taht can also monitor cadence) is to use the torque sensing from a stop or in high-pedal-load situations (slope-climbing, hard acceleration, etc), to provide the maximum amount of assist during those instances regardless of the chosen assist level.

When the torque load drops below some (user-configurable?) point, it goes back to the chosen assist level amount, and switches to cadence control to vary speed.

This is so that for heavy cargo (and dog, etc) hauling usage, the way the system operates may need to be different because of the heavy loads, when the user wants to do most of the work but needs to accelerate quickly and can't pedal that hard in the required and/or available gear, and needs all the help the system can provide for that period. Afterward the system can drop assist to whatever is required to maintain the speed the rider is commanding via pedal cadence under the present riding conditions.


I'm sure my description is insufficient, but I've gone over it for almost an hour and haven't been able to revise it with more detail. If I can help clarify anything, let me know and I'll try.



Separately, If it is useful feedback:

I don't like any kind of artificial ramps, the support should always directly correspond to the riders effort without delay

I agree completely with this.

So about 300ms after the last PAS pulse, the motor must stop assisting.

Personally I'd like it to stop assisting "instantly" once pedalling ceases, but I know that's not typically possible with most systems.

 

[stancecoke]

switches to cadence control to vary speed.

Is it really your aim to have simple speed levels? That's the way worst way to ride a bicycle I ever experienced

But of course, it would be no problem to achieve your wanted behaviour. This would be simple speed levels with a torque override. The torque signal would be interpreted like the throttle.

 

[amberwolf]

Is it really your aim to have simple speed levels? That's the way worst way to ride a bicycle I ever experienced

But of course, it would be no problem to achieve your wanted behaviour. This would be simple speed levels with a torque override. The torque signal would be interpreted like the throttle.

My apologies, I suppose I wasn't clear enough; I'll try to correct that but it takes me a lot more words. I hope it isn't too long; I minimized the necessary divergences as much as possible:

I myself don't want / need speed levels. No speed limits enforced by levels (an overall speed limit based on whatever reason, such as the local legal speed limit (20mph here in Arizona). ****see bottom of post for more about levels

What I want with any future dive system is what I have now: Cadence-controlled-speed, because torque varies signfiicantly throughout the pedal rotation, especially for people like me that have a hard time pushing at all because of the serious pains in various body parts, among other issues. By Cadence-controlled I mean that if I pedal faster, then the system does whatever it needs to to increase speed by that proportional amount. If I pedal slower, the system lessens assist proportionally to allow speed to drop.

This works very well, once the load has been overcome; especially from startup from a stop where it needs to have pure torque control and not wait for sufficient cadence measurement to occur.


It's possible that I simply have never been able to set up torque sensing to work correctly at "cruising speed" without varying too much because of the varying road conditions and slopes. Since I need a constant speed when riding in traffic, cadence-controlled speed works better than torque-controlled. Otherwise I end up getting bursts of speed when I don't want it just because there was a slight momentary incline in the road surface that is gone by the time the system reacts to my input and now I'm too fast and have to brake to ensure I won't get too close to the vehicle in front of me. Conversely the road dips and my speed decreases because of the sudden drop in pedal torque and then the vehicle behind me gets too close. Etc.

I couldn't use more "smoothing" on the pedal-torque control or then it doesn't give power fast enough when I need it to overcome loads "instantly" such as at startup....I ended up having to just turn off torque control because I couldn't tune it to do what I wanted (almost certainly my brain problem rather than the system's) without unsafely interfering with normal riding, and just went with pure cadence control, which other than the situations in which I can't move the pedals first (or quickly enough to do what's needed), works "perfectly" or as close as I've ever come for the majority of riding.

If pedal-torque control behavior can maintain speed correctly without doing unsafe things, by reacting "instantly" to torque demands under the right conditions (like from a complete stop) but not reacting like that when riding along "at speed" just because of small road surface variations, but would still react to large changes in pedal torque required for large road surface variations or rider-demand (*** more thoughts below), then pure cadence control at speed and pure torque at other situations would be unnecessary.

*** Further thoughts: This might be too complex to implement, or I might just be making it harder than it has to be, but: During riding "at speed" (whatever speed that is), then when the detected road speed drops *and* the rider cadence hasn't dropped before that (to demand less speed) but is dropping *as the road speed drops*, the pedal torque would also be increasing at that same time, and *then* the torque-control should begin adding in a contribution to the cadence control until the pedal torque drops to the previous level, indicating the rider now is getting the cadence-controlled-speed they are demanding, and the torque-controlled assist can lower proportionally as the pedal torque drops.



Presently I use a throttle for those situations where it is not possible for me to overcome the forces needed to move the pedals but *must* begin moving (or increase speed) to get out of someone's way (usually because they are an impatient (well, you know) that can't wait literally less than ten seconds for anything).

But using any of the throttle designs I've bought or built so far (including various types pulling a cable-operated-throttle box) hurts my hands (imagine having your thumb pulled away from your hand and bent backwards toward your wrist continuously and more forcefully with every passing second--that kind of pain), so can't be used for more than a few seconds on a good day.

Throttles are also not legal in some places, so it would be nice to have a throttle-less system like this for those like me that must do what I do in those places.



**** I actually personally don't need or use any levels, I need the full amount of assist available at any instant for when it is needed...but if a system can or does have levels as part of it's nature, I don't know what the best type of limit there would be for them.

I once thought speed limit levels would be useful for certain low-speed situations, and tried that with a 5mph and 10mph version, (as well as a full 20mph one) in the system I have now, but after having tested them a few times, found it was better and safer to not have them because of the various dangerous users of the same areas (parking lots, primarily) where being limited in speed meant I couldn't get out of their way quickly enough.

I can imagine a situation where a power / current limit level might be useful to maximize battery usefulness and minimize stress on it when environmental conditions (cold, etc) and battery condition (age, low SoC, etc) combine to make it unable to operate the system normally, so that the rider doesn't have to change system settings in the menus to decrease what the battery has to handle just to get to the next charge point wherever that might be.

There could be other situations I have not run across myself that might make some form of levels useful. (power or speed restrictions for children or beginners, etc).

 

[qwerkus]

Is it really your aim to have simple speed levels? That's the way worst way to ride a bicycle I ever experienced

But of course, it would be no problem to achieve your wanted behaviour. This would be simple speed levels with a torque override. The torque signal would be interpreted like the throttle.

I actually agree with a simple pas fallback: torque sensors are not adapted to wide load ranges, like heavy cargo, trailers or steep mountain tours in my experience. In those scenarii, pas + poti assist level tend to be more useful.

In lisp I tested a script using a simple PAS that proved quit useful on my cargo bike: instead of setting the assist level, you set a target speed, and as soon as the PAS starts the motor, the controller automatically find the right phase current required to reach and maintain that speed. This way, there is barely any need to hit a button, once the system has started.

For the rest, it depends on which sensors you want to support. Sensitivities vary between e-rider bafang or shengyi models (the ones I ve seen). No sure how you d implement some sort of calibration tool that is user friendly. For an instance, I spent a whole afternoon tweaking the values in the config file of your ebics firmware to find a suitable tq sensor behaviour for an e-rider on a clwb bike. If the plan is to go for one model only, I m a big fan of simplicity: 3 modes - off / city / cargo-mountain should be enough for most poeple. Keep in mind that the bafang sensor requires drilling a hole in the middle of the bb though.

 

[stancecoke]

Thank you for your thoughts, @amberwolf and @qwerkus !

It's possible that I simply have never been able to set up torque sensing to work correctly

Have you ever ridden a commercial pre build bike with a Panasonic, Yamaha, Bosch or similar system?
To be honest, that you get slower at an incline and faster at an descent is the normal behavior any vehicle has. That's just physics.
With a normal bike you would pedal harder uphill to keep your speed and pedal less hard downhill.
With a power sensing system (torque * cadence = power) you will achieve exactly the same behaviour, just with "magic hand in your back" from the motor.
Using a cadence based assist system would decrease the power, if the cadence is falling due to an incline, that's exactly the opposite, of that what you want.... Of course you can change the gear to get a faster cadence again, then the power would increase again. A crazy guy from Austria has patented such a system, he called it "Affe-Automatik". It was produced by Kunteng. But he is retired meanwhile. His website is down also, but you still can find some information on the Pedelecforum.

instead of setting the assist level, you set a target speed, and as soon as the PAS starts the motor

yes, but this a really dumb behaviour, that has nothing to do with bicycle riding. Maybe it is right for delivery riders that are riding not for the riding experience, but for their daily income. Most of this popular 20 inch China fatbikes, that are popular for delivering services, will use this simple way of speed levels anyway.

But coming back to the implementation in the OSF. We can use any mask in the Bafang Canable Tool for defining anything we want, especially the Assist tabs have many possibilities, of course.


But how to describe the assist behavior in a table?

 

[amberwolf]

I guess it's not possible to get across the desired behavior with words, so I won't bother trying any further.

 

[stancecoke]

I guess it's not possible to get across the desired behavior with words

Perhaps we could ask a KI to create an algorithm or a look up table from a written descripton? This might work
Describe the available sensor data, speed, torque, cadence, motor current, battery current, battery voltage and describe how the motor power should change, when the one or more of the input data changes.

 

[stancecoke]

After thinking a little, I will implement it this way:
For each assist level, you can define a specific ride mode:

• Mode 0: Simple PAS mode like in the "old" BBSxx world. Battery current is controlled, phase current is limited to a global max value
• Mode 1: Simple PAS mode but motor torque (=phase current) is controlled, battery current is limited to global a max value.
• Mode 2: Torquesensor mode, assistance is depending on the riders effort. The assist ratio is settable in details for each speed range, like the "Custom Riding Modes" in the Bosch Nyon. The settings for speed and current from the PAS definitions are ignored, only the global limits for speed, phase current and battery current are active.

In all modes, a "torque override" can be activated, so the setpoint calculated in the ride modes will be overwritten by the pure torquesensor value , if it's higher. Similar to a throttle signal. You can define the threshold for this override function individually for each level.
So you can have different ride modes one the same setup.
I would use the Bafang Canable "Assist (Full)" tab in this way:



Of course further suggestion are welcome

regards
stancecoke

 

[phobos]

@stancecoke there probably will be as many opinions as the users. I would just copy something that works well already, for example the bosh, bafang, dji or tsdz2 osf system where you have:
- cadence mode,
- torque mode,
- power mode (torque * cadence)

with adjustable curves. That should suit most users.

 

[fenomeno]

Hi
It will apply to rear hub motor?
BR

 

[stancecoke]

It will apply to rear hub motor?

Both, hub motors and middrives.

 

[aegidius]

All of this depends on how you are measuring the torque that's fed into the power equation. I first started with my VESC using the running average torque of half a crank revolution, but the torque result was too low and varied too much, so the motor would sometimes drop out. I changed it to use the peak torque of the last half a crank rev. which worked much better and was more progressive.

It's all in power mode (motor power = PAS level * torque * cadence) with a half-second run-on time with no cadence pulses before it cuts out altogether.

 

[stancecoke]

I changed it to use the peak torque of the last half a crank rev. which ... was more progressive.
.... with a half-second run-on time with no cadence pulses before it cuts out altogether.

So you update the setpoint only twice per crank revolution? If you just need a short impulse, it needs half a revolution to get less power again?! Is your algorithm somewhere public?
You are on a hub motor system, I guess?

 

[aegidius]

Updates come every cadence pulse from the Bafang torque sensor (32 pulses per crank rev). The last 16 readings were averaged, but not it uses the max torque of the last 16 readings. That way at least one peak pedal downforce is in the buffer.

It's a M510 mid-motor driven off a Spintend VESC. I'll be putting everything up on github shortly, once I'm a bit happier with the performance.

 

[stancecoke]

It's a M510 mid-motor

I guess you are setting the motor current, not the motor power?

motor torque = motor constant * motor current

motor power = motor constant * motor current * motor rpm

motor rpm = constant * cadence for a middrive!

 

[aegidius]

Yes, sorry I omitted that step: setting current to power / inputVoltage.

 

[stancecoke]

inputVoltage

The mechanical power is constant*motor current*motor rpm. It has nothing to do with the input voltage....
The electrical power is battery current * battery voltage.