Anatomy of an overlean

[Chriull]

On 7/25/2017 at 4:35 PM, Chriull said:

Just one point is not clear to me till now - he accelerated with ~3 m/s² before the incident. The calculated values for the limit graph would suggest just 1,2-1,4 m/s² (between the orange and black line)- wondering what went wrong with the calculation of the needed power/current... 

 

On 3/13/2019 at 1:18 PM, Chriull said:

For BLDC (electric motors in general?) the generated Voltage U = kv * n. This same constant describes the relation between motor current and torque  kv * km = 2 * pi / 60 (1) and M = km * I_motor. With this i calculated the "needed motor Current" to overcome the airddrag, incline, friction and acceleration.

Maybe i made some wrong calculations - used wrong constants, or by now i assume that there is some factor within the reported motor current - i had the idea to "calibrate" my wheel once by doing some "controlled" driving, logged by wheellog. .... maybe this summer ....

(1) for n in rpm ... if i remember correctly. But its easy to derive - P_motor_output_electrical = U_generated_voltage * I_motor = kv * n  = P_motor_output_mechanical = M * omega

Seems i found the discrepancy - also the KS16C already reported battery current. With this corrected in the formulas one gets to something like this:

Here acceleration taken by Delta v / Delta t correlates much better to the calculated one by the motor current

Works also nice for GW (MSX) which report the motor current.

Here the calculated acceleration from the motor current is (mostly) higher as the one calculated from speed change in difference to the KS16C log. Maybe the rider was much lighter as the KS16C, the KS16C reports too low current/the GW too much, i guessed some constants wrong, still have some wrong assumptions in my to ?simple? model, ....

But the GW seems quite right - as for this graph the acceleration is calculated from the motor torque current fully disregarding all the non electric losses/burdens (magnetic, friction/air drag/...)

edit: calculating the msx as 18 inch wheel will reduce the accel a bit (~11%)... corrected

Edited December 4, 2019 by Chriull

[Chriull]

Some new graphs - just got csv from an KS18XL going to the limit. Fortunately no crash/faceplant, just getting a bit out of control (spinning up, but resistance on the wheel!)

One sees nicely again in the current vs speed diagram the current(torque) over speed limit beeing followed.

What's new is that we now have the "inverter_load" value logged with EUC World. (green lines) 

As comparison a "normal" ride (same wheel)

Here the maximum inverter_load value is ~76%. Here current was about 23A at a speed of ~42.5km/h. To check if inverter_load is really (hopefully) a sane measure for "overall wheel load/capability) i divided these values by 76% to get the 100% values (limits). These would be ~30A and ~56 km/h. Putting this point into the first current vs speed diagram it could really be on the prolonged limit line. Battery voltage was in the second example a bit higher as in the first - but similar enough for such a rough first check...

[Chriull]

And here a current-speed scatterplot for a KS16S ride (blue dots). The red dots are the current/speed values divided by inverter_load to get the corresponding 100% values (limit):

Seems to really quite correspond with the current over speed limit (an area in because of the changing voltage)

Thanks Kingsong!

 

[Chriull]

Seems inverter_load is quite exatly what i thought: (sorry for the many unnecessary lines in this graph

The inverter_fits very very well the "limit percentage" i calculated. (The one line not found in the legend  - its the "multicolor" line green from 0-60, then over orange to red...)

[Chriull]

Was already clear from the last graph - but here a inverter_load over limit_percentage scatter:

So with my "just guessing of the wheels parameters" i'll take this as an 100% hit

Same nice correlation is true for KS18XL and other KS16S logs!

[jancellor]

I'm finding it hard to follow all the threads so far on this. Sorry if I'm rehashing anything. Can I just clarify what is commonly agreed on? Speed is one measure of safety from overlean but it's pretty crappy because it ignores hills, wind, and acceleration. But this is what the majority of alarms in our wheels are based on. Something like torque/power/current margin are much better measures. By definition, these are the extra torque/power/current that the wheel could provide before an overlean happens. These are things we can calculate from the real-time wheel data. I'll just stick with torque margin for now and I acknowledge these are not the only possible measures.

The first point is that I want to be able to analyse my log data to see what kind of safety margin my riding has. How do I get the relevant values for my wheel, the 16X? If I understand correctly, I just need to know the effective internal resistance of the battery (assuming we are modeling it as a pure voltage source and resistance) and the effective resistance of the motor (assuming we are modeling it as pure back EMF voltage and coil resistance). Where do I get these values (like you have done to produce the straight lines on the current/speed graphs in this thread @Chriull and others)?

The second point is that it would be great to have real time alarms based on this safety margin. Have people been working with @Seba to integrate an alarm based on some kind of margin into EUC World? I can only see speed based alarms (maybe battery dependent) and current alarms (though not speed dependent). Is it not agreed in this community that something like torque margin is the appropriate measure to use as an alarm? (If not, I don't mean to start the debate here/now.)

 

[Chriull]

18 minutes ago, jancellor said:

The first point is that I want to be able to analyse my log data to see what kind of safety margin my riding has. How do I get the relevant values for my wheel, the 16X? If I understand correctly, I just need to know the effective internal resistance of the battery (assuming we are modeling it as a pure voltage source and resistance) and the effective resistance of the motor (assuming we are modeling it as pure back EMF voltage and coil resistance).

Plus kv (rpm per Volt) - but thats the easiest value to get. Just a log of some lift cut off speed tests is needed.

18 minutes ago, jancellor said:

Where do I get these values (like you have done to produce the straight lines on the current/speed graphs in this thread @Chriull and others)?

It's playing with the figures until it seems nice enough. Battery resistance is not really constant.

If you can log somehow an overlean of your wheel you see the limit line and can calculate the sum of the resistances from it. Best to do this with "simulated" overleans like letting the wheel spin up against some burden (be carefull to not injure/endanger yourself!)

Also logs from unsuccsefull trials of driving up a curb are helpful.

Then one can play with splitting this sum into coil and battery resistance and look at the calculated graphs until they look reasonable.

Maybe one can get a sane battery resistance value by taking some voltage sags from the log? Never tried this approach.

For KS wheels one can also just take the inverter load (motor output) logged by euc world. Maybe also darknesbot logs this value?

34 minutes ago, jancellor said:

The second point is that it would be great to have real time alarms based on this safety margin.

We KS riders have the 88% alarm - once inverter load/motor output (imho the new name in the ks android app) reaches 88% (12% "safety margin" left) 4 fast consecutive beeps come from the buzzer.

If one accelerates hard this gives one unfortiinately just some tenth of a second to react...:(

But as i noticed at one of my.last rides with my 16S - with already lower battery going up an longer incline i could get this alarm by slowly increasing my speed. So by staying a bit below this alarm i knew i still had a bit more than this 12% safety margin.

Would by nice if this value could be set in the app to some 80% to get higher safety margins.

34 minutes ago, jancellor said:

Have people been working with @Seba to integrate an alarm based on some kind of margin into EUC World?

It's in progress to use this wheel reported number. Is in testing with the beta version - so this should be soon available in the public version.

34 minutes ago, jancellor said:

I can only see speed based alarms (maybe battery dependent) and current alarms (though not speed dependent). Is it not agreed in this community that something like torque margin is the appropriate measure to use as an alarm? (If not, I don't mean to start the debate here/now.)

It is for sure an improvement to use a real safety margin.

But as you noticed it's not so easy to get the right numbers. And they would be needed for each wheel. Usability of app generated alarms is limited, too - the sampling rate of the reported values is quite low (~3 per second). With fast accelerations/high burdens one lies on the floor before the app could trigger an alarm.

For more prudent/considered riders they will give a nice feedback about the available safety margin!

[Planemo]

39 minutes ago, jancellor said:

 Is it not agreed in this community that something like torque margin is the appropriate measure to use as an alarm? (If not, I don't mean to start the debate here/now.)

A 'Torque Margin' alarm would indeed be ideal. Or even better, a 'margin meter', displayed on a dial on a smartwatch. A bit like the 'power reserve' meter that Rolls Royce use.

The Gotway 80% alarm goes some way to address this, being based on speed and voltage and is infinitely variable dependent on battery % (unlike the EUCW battery dependent speed alarms which only has 3 battery % reference points) and the Gotway one is extremely reactive - it can and will trigger a beep if the voltage dips even for a split second (like when at speed and you hit a small dip in the surface). It works well, but as you say a proper measure of torque remaining would be awesome.

On the flip side, many people do get used to what their wheels can and cant do. Unfortunately this can also bring with it a crash but having done a fair few miles now and hit beeps under various scenarios I have a pretty good idea of when my wheel is likely to beep before it does, and thankfully (crossing all fingers and toes, touching wood etc) I haven't crashed yet. I am under no illusion that it's not around the corner though, and never get complacent.

A general understanding of how our wheels work is a massive bonus and it is this one single factor which I feel has caught many riders out, particularly those who buy one and don't think for a minute about accessing valuable forums such as this. I am talking about some ex scooter riders and those going straight from a pushbike who think that an EUC's top speed is attainable under any circumstances, or at least rely on the assumption that it will never overlean or cut out and will simply 'not go faster' when the limit is reached. It is for this reason (if the manufacturers want to target a much wider audience) that they should be implementing apps that display the data you suggest. Until that time we are all expendable guinea pigs who run the gauntlet entirely at our own, sometimes significant risk. Not something I like, but it is what it is if I choose to ride an EUC

 

[Chriull]

1 hour ago, jancellor said:

How do I get the relevant values for my wheel, the 16X?

BTW here 

you have some overlean data from another KS16x

[jancellor]

3 hours ago, Chriull said:

Plus kv (rpm per Volt) - but thats the easiest value to get. Just a log of some lift cut off speed tests is needed.

Right, just understood this. We need two parameters to get the straight line representing the overlean limit on the current/speed graph. If my equations/understanding are right, one is the sum of battery and motor resistance (the individual values don't matter), the other is k_v (the emf/torque constant). (Or two other parameters that give the same information.) I'm new at this so forgive/correct any errors.

Quote

For KS wheels one can also just take the inverter load (motor output) logged by euc world. Maybe also darknesbot logs this value?

Can you clarify what you think inverter_load and limit_percentage is? inverter_load = duty cycle of the PWM controller? limit_percentage is clearly something very similar from your above graph.

Okay so we can get k_v by lifting the wheel off the ground and tilting until until max speed. (Based on another thread saying 65kph is the no-load speed for the 16X and using 21cm radius for the tire, I get a value very close to 1.0 volt seconds = 1.0 newton meters per amp).

If this inverter_load really is the duty cycle, can we just calculate the second parameter (total resistance) from our logs? I have:

i = (d v₀ - k_v ω) / R_t              (the symbols are current, duty cycle, no-load voltage, emf/torque constant, angular velocity, total resistance of battery+motor)

and we know all the other values. (And then we have torque equals the motor constant times the current.)

Quote

It's in progress to use this wheel reported number. Is in testing with the beta version - so this should be soon available in the public version.

Fantastic.

3 hours ago, Planemo said:

The Gotway 80% alarm goes some way to address this, being based on speed and voltage and is infinitely variable dependent on battery % (unlike the EUCW battery dependent speed alarms which only has 3 battery % reference points) and the Gotway one is extremely reactive - it can and will trigger a beep if the voltage dips even for a split second (like when at speed and you hit a small dip in the surface). It works well, but as you say a proper measure of torque remaining would be awesome.

What is this exactly? 80% of what? Or if you can point me to a thread, great.

Quote

On the flip side, many people do get used to what their wheels can and cant do. Unfortunately this can also bring with it a crash ...

Would be nice to find out without a crash This is the fear creeping up on me. Personally I have a lot of hills and I have no idea how fast is safe.

One thing I didn't explicitly say and I'm not sure if others agree but when I say "torque margin", I mean an absolute value like, say, 40 netwon meters, not a percentage of available torque for the given speed. Otherwise the 88% KS alarm is okay (although not adjustable and not very conservative). (And really, of course we mean force margin, not torque margin. And a light rider needs less force, so we probably mean acceleration margin, but comparisons might be easier between wheels if we ignore the rider.)

Edited June 19, 2020 by jancellor
trying to shorten an already long post

[Chriull]

12 minutes ago, jancellor said:

Can you clarify what you think inverter_load and limit_percentage is? inverter_load = duty cycle of the PWM controller? limit_percentage is clearly something very similar from your above graph.

The "limit percentage" used above i "defined" as if one draws a line through an I motor/speed point and the origin 100% is the lenght to the actual limit line and the correspontant % to the point is the "limit percentage"

I assumed that the inverter load/motor output % is the same value and my plots above seem to harden this assumption.

17 minutes ago, jancellor said:

If this inverter_load really is the duty cycle

Imho not. But would be worth to plot this against the calculated duty cycle!

19 minutes ago, jancellor said:

one is the sum of battery and motor resistance (the individual values don't matter)

To some extent the individual values are needed - the limit line "shifts" in regard to U0 (the internal "no load" battery voltage) and the motor current is needed, as this is proportional to the torque. But at the limit line battery current is equal to motor current....

[Planemo]

16 minutes ago, jancellor said:

What is this exactly? 80% of what? Or if you can point me to a thread, great.

Excellent question! I'm not entirely sure, but I suspect it's 80% of the max possible motor rpm at the given battery % sample.

For example, the no load speed on a 100v MSX is about 57mph. 80% of that is about 45mph and this would tie in about right under testing, as this is when the alarm sounds. In reality, the beeps will come at about 42/43mph with a 'full' battery when riding due to battery sag.

Of course, this is far from ideal. Who decides that 80% is the 'safe' limit? Well, Gotway did, but does the rider feel the same? I dunno, I think it's pretty conservative, but I like it that way. If I chose, I can ride beyond the beeps no problem, but it's a no mans land so I don't go there. Some do though...and...well you can guess.

16 minutes ago, jancellor said:

And a light rider needs less force, so we probably mean acceleration margin, but comparisons might be easier between wheels if we ignore the rider.)

Funnily enough I thought about a wheels ability to read rider weight some time back. It's not difficult to implement but of course only of any use if the alarms systems were smart enough to use the weight data...

[jancellor]

7 minutes ago, Chriull said:

The "limit percentage" used above i "defined" as if one draws a line through an I motor/speed point and the origin 100% is the lenght to the actual limit line and the correspontant % to the point is the "limit percentage"

Ahhh, I see. I'll need to think about that. I imagine we could still use it to get an estimate of resistance (or somehow use it more directly in calculation of a absolute torque margin rather than some percentage).

7 minutes ago, Chriull said:

To some extent the individual values are needed - the limit line "shifts" in regard to U0 (the internal "no load" battery voltage) and the motor current is needed, as this is proportional to the torque. But at the limit line battery current is equal to motor current....

The limit line shifts in regard to the no-load battery voltage, yes. But this happens even for a perfect battery with no sag under load. With this simple model (constant battery resistance) I believe both the battery resistance and motor resistance just represent heating losses and affect the circuit in exactly the same way. I could be wrong.

13 minutes ago, Planemo said:

Excellent question! I'm not entirely sure, but I suspect it's 80% of the max possible motor rpm at the given battery % sample.

Okay cheers. Makes sense but I need to think about this too.

 

[jancellor]

@Chriull I think your definition of limit_percentage is equivalent to the duty cycle. Please confirm if the following seems correct.

The straight limit line on the speed-current graphs represents 100% duty cycle, right? Similarly, there is a line for maximum braking that is parallel but crosses both axes on the negative side that represents -100% duty cycle. A third parallel line through the origin represents 0% duty cycle (this is zero average voltage, not to be confused with zero current).

For a particular point P on the speed-current graph, you defined limit_percentage by drawing a line from the origin through P and extending it until it hit the limit line (aka max current line or 100% duty cycle line). The limit_percentage is just how far along that line P is. If you instead drew a vertical line (constant speed) from the 0% duty cycle line through P until it hit the 100% duty cycle line, you would get the same value. But this is just the value of the duty cycle. They're the same.

Here's a hand-drawn  with a circuit diagram and equations to help explain what I mean and make it easy for someone to correct me if I'm making some really basic errors.

Also, from the torque equation I believe that a fixed duty cycle percentage always corresponds to a fixed torque margin for a given wheel regardless of speed. In other words, at x% duty cycle, there is y Nm of additional torque that could be provided by the wheel. (Most riders would prefer to think of this as something like z degrees more lean is available -- which is approximately correct.) So assuming this is right and inverter_load, limit_percentage and duty cycle are all the same thing, it means that the inverter_load is the perfect value to use directly in apps as a safety warning alarm.

Again sorry if I'm rehashing what has already been said by others.

(Edit: I think the simplfied circuit and equation for current is slightly wrong. It doesn't take account of the fact the battery current is lower than the motor current by a factor of d, the duty cycle. I would replace Rt with (d^2 Rb + Rm) based on my current understanding. If this maths is correct, there can be interesting situations where increasing the duty cycle actually decreases the motor current. Very speculative but this could explain pedal dipping in certain scenarios.)

 

Edited July 2, 2020 by jancellor
see text

[mrelwood]

13 hours ago, Planemo said:

Excellent question! I'm not entirely sure, but I suspect it's 80% of the max possible motor rpm at the given battery % sample.

At least it seems close enough to warrant its name. The speed threshold curve is just programmed in for each GW model. GW released the speed thresholds as a hand written chart (the thread is still somewhere in here) before the Nikola was out, but my 84V MSX is the only one I remember: 58km/h @100%, 45km/h@10% battery. 

13 hours ago, Planemo said:

Funnily enough I thought about a wheels ability to read rider weight some time back. It's not difficult to implement but of course only of any use if the alarms systems were smart enough to use the weight data...

Given the trouble the EUC manufacturers have in understanding the needs of a western consumer even when repeatedly explained, unfortunately a feature like this seems to remain in a very distant future. If even there.

[EUC Endurist]

On 7/25/2017 at 12:23 PM, Chriull said:

Just got the wheellog data from another rider of an "high-speed crash" he had with his KS16B some time ago. (1) He heard no beeps and there was no tiltback - they wheel just stopped supporting him...

The speed and current (dark blue line - IMotor KS16C) in the limit diagram:

One sees nicely how he "hit" the motor limit (violett line) at around 27 km/h - 36A and continued on this limit line until about 36 km/h. So tiltback would have started at 30 km/h - but not anymore possible since the motor was at it's limits. It just should have beeped by then - but quite imagible that this was not heard anymore after beeing in the process of falling and seeing the street coming nearer...

The wheellog data (speed,voltage,current,temp - the rest is calculated..):

I had to adjust some motor constants a little bit to get the calculated limit line to his measured one (my first try was some real rough estimation (http://forum.electricunicycle.org/topic/7549-current-demand-versus-battery-voltage/?do=findComment&comment=106424))

For the internal resistance of the battery pack (16s4p LG MJ1) i have now 0,23 Ohm instead of the calculated 0,148 Ohm. I got this by minimizing the "ripples" of the calulated no-load battery voltage (U Batt 0) as low as possible... The still nicely seeable peaks on U Batt 0 are from the regenerative braking - the motor current is always measured as positive value and the used formulas are not right for the "regenerative" case.)

 

R Coil was changed to 0,37Ohm and kv to 1,41 V/km/h.

(1) he "just" got some nasty road rash/bruises and recovered fully.

Ps.: Had some interesting reading about that the coil temperature has quite an influence on the motor charateristic - copper increases it's resistance roughly about 0,4% per degree celcius - so between 20 and 80 °C is a difference of 24% in resistance of the coils! And this resistance is one of the main parameters for the "steepness" of the limit line.

PPS: he refused to repeat this with his KS16S so i get data for our new wheels... 

thank you for putting that much effort into that, you really support me with my accident!! this are great references

[Chriull]

On 6/19/2020 at 6:41 PM, jancellor said:

@Chriull I think your definition of limit_percentage is equivalent to the duty cycle. Please confirm if the following seems correct.

Great approach - i never thought of it this way around! But this is (would be) especially great news for all riders, as the duty cycle is an easily available number in firmware and so manufacturers do not have to mess around with the changing resistances!

Would also explain the name "inverter load" and "motor output" KS has choosen for this. 

It'll need some time thinking about this and looking at the formulas again to 100% confirm the equality, but it seems right. 

Quote

The straight limit line on the speed-current graphs represents 100% duty cycle, right?

Yes.

Quote

Similarly, there is a line for maximum braking that is parallel but crosses both axes on the negative side that represents -100% duty cycle.

This would be "power braking". And i'd assume as the voltages of the battery and motor add up in this case the current should double.

Quote

...

Seems, as stated above very sound, but for all the details of duty cycles and different quadrant operations of the BLDC motor i cannot confirm anything by now. I concentrated mostly on the first quadrant (normal driving) and bit on the second quadrant (regenerative braking).

But this weekemd was just too hefty   to really gather thoughts about this - but i'll go along this way once i have time and a clear mind to follow your great idea!

[Chriull]

14 hours ago, Chriull said:

It'll need some time thinking about this and looking at the formulas again to 100% confirm the equality, but it seems right. 

@jancellor - duty cycle and my limit percent are not the same, but similar enough.

If you look at your sketch above the 0% duty cycle line is the omega axis (current == 0). With 0% duty cycle the inverter is constantly turned off and the motor spinning freely.

So the vertical arrow you draw needs to start from the axis, showing the possible motor currents depending on duty cycle (between current=0 for 0% and the maximum at the limit line for 100%).

So both percentages give slighty different numbers. I already thought of whats more usefull/makes more sense - to give the percentage as i did with the limit percentage or as the duty cycle shows, the "used up torque" for a given speed?

[jancellor]

3 minutes ago, Chriull said:

If you look at your sketch above the 0% duty cycle line is the omega axis (current == 0). With 0% duty cycle the inverter is constantly turned off and the motor spinning freely.

No, I don't think so. 0% duty cycle is 0 average voltage, not 0 average current. Agree? (There are complications with multiple sets of coils at different angles that I don't pretend to have any much understanding of currently but which I believe are not relevant. And I'm fully aware others on this forum understand the electronics of batteries and motors far better than me.)

[Chriull]

1 minute ago, jancellor said:

No, I don't think so. 0% duty cycle is 0 average voltage, not 0 average current. Agree?

No - 0V would mean braking - the inverter shorting the motor.

0% duty cycle means the mosfets are never engaged - the motor coils are never "connected" to the battery and he runs freely without current flowing.

One has to stay with the motor operation for driving in the first quadrant (positive current and speed) - once one crosses an axis operation is very different.

1 minute ago, jancellor said:

(There are complications with multiple sets of coils at different angles that I don't pretend to have any much understanding of currently but which I believe are not relevant. ....)

It's better to stay with the simple equivalent circuit diagram of a dc motor - much easier to follow and no(t too much) difference to a multicoil bldc motor with all the commutation stuff. At least for this considerations.

https://forum.electricunicycle.org/topic/7549-current-demand-versus-battery-voltage/?do=findComment&comment=104078

 

[Chriull]

39 minutes ago, jancellor said:

No, I don't think so. 0% duty cycle is 0 average voltage, not 0 average current. Agree? (There are complications with multiple sets of coils at different angles that I don't pretend to have any much understanding of currently but which I believe are not relevant. And I'm fully aware others on this forum understand the electronics of batteries and motors far better than me.)

But you are right with not starting "to count with 0%" at the axis. As at for example half speed already 50% duty cycle is needed. Duty cycles below 50% are no valid state for driving anymore.

... so it's getting a bit more complicated to find out why duty cycle and the limit percentage are not equal. (At least they are not in my diagrams - maybe i start out checking the program again if there are any faults... )

[jancellor]

6 minutes ago, Chriull said:

No - 0V would mean braking - the inverter shorting the motor.

0% duty cycle means the mosfets are never engaged - the motor coils are never "connected" to the battery and he runs freely without current flowing.

One has to stay with the motor operation for driving in the first quadrant (positive current and speed) - once one crosses an axis operation is very different.

I'll have to go over that thread and all the others I can find discussing this. In lieu of that, here's my basic understanding so you can explicitly tell me if I'm wrong.

I did write a PWM controller for an inverted pendulum back at university a long time ago and maybe it was different. It was probably a brushed motor because I don't remember dealing with commutation. It was simply using an H-bridge circuit to switch between full forwards and full backwards voltage in a certain ratio. Mathematically this is nice and simple. The average voltage corresponds fairly closely to the force (I think I was even ignoring back EMF back then which may have been justified if the speed was low).

So speaking from a position of complete ignorance, I don't see why one would make the BLDC circuit switch between full forwards voltage and open circuit. It seems simpler to switch between forwards and backwards, or at least forwards voltage and short circuit (0V) (assuming this is easily possible - really not thinking about the mosfets/electronics). Also it means that there is no distinction between which quadrant you are in -- whether you are riding fowards or backwards and whether you are accelerating or braking. I briefly read mention of capacitors on the linked page. I guess you'd need to stick one in somewhere to smooth out the draw of current from the battery. But this is true whether we switch between full forwards voltage and full backwards voltage or full forwards voltage and open circuit. Am I just wrong to think there is always a defined voltage over (a particular phase of) the motor?

[jancellor]

On 6/19/2020 at 2:06 PM, Planemo said:

For example, the no load speed on a 100v MSX is about 57mph. 80% of that is about 45mph and this would tie in about right under testing, as this is when the alarm sounds. In reality, the beeps will come at about 42/43mph with a 'full' battery when riding due to battery sag.

 

On 6/20/2020 at 3:46 AM, mrelwood said:

GW released the speed thresholds as a hand written chart

Okay, it's just speed. The mention of sag made me stop to think but I guess simply the loaded battery voltage is the easiest thing to measure so they just use this. No harm in the speed alarm coming earlier due to sag due to a hill or higher acceleration or whatever. (But speed is still a bad concept to base an alarm on in general, I suggest.)

Do GotWay/InMotion provide a value similar to the King Song inverter_load or something that may represent duty cycle (whether or not this is the same thing) in app logs? And does DarknessBot grab these values too?

Just wondering if we might be able to reach a concensus across apps and wheel manufacturers for setting alarms for safety.

[Chriull]

2 hours ago, jancellor said:

I did write a PWM controller for an inverted pendulum back at university a long time ago and maybe it was different. It was probably a brushed motor because I don't remember dealing with commutation. It was simply using an H-bridge circuit to switch between full forwards and full backwards voltage in a certain ratio. Mathematically this is nice and simple. The average voltage corresponds fairly closely to the force (I think I was even ignoring back EMF back then which may have been justified if the speed was low).

If it's controlled by a voltage it's a brushed motor.

Bldc are controlled by the rotating field generated by the three phases in the coils. So rotation is generated by the commutation frequency. But as with the brushed motor the voltage has to be "right" to drive the right current through the motor to get the torque. For this the inverter (3 h bridges) generates the right commutation sequence and simultanously act as step down converter.

As soon as one brakes (regenerative) the mode of operation changes and the h bridges work as step up converter in the other direction.

I had problems getting this different modes in accordance with your previous posts - so i messed some things up :(.

 

Quote

So speaking from a position of complete ignorance, I don't see why one would make the BLDC circuit switch between full forwards voltage and open circuit.

With bldc there is the commutation sequence (giving the rotational feed and determining the rotation frequency) and the pwm (regulating the step down converter determining the torque). So at a duty cycle of 0% the formula is not valid anymore and the mosfets open.

Wirh regenerative braking the mode of operation is different anyhow all the lines you sketched below the omega axis are "not really valid". But valid for the model you described!

Quote

 I briefly read mention of capacitors on the linked page.

In the link i messed up with putting a capacitor on the wrong place They are used in EUCs to deliver peak motor currents which would not be possible from the batteries over the wires.

Quote

I guess you'd need to stick one in somewhere to smooth out the draw of current from the battery.

Smoothing the motor current is done by the inductance of the motor coils.

From what i got till now the batteries have unfortionately pulsed load. Could be that the capacitors act for smoothing, too? And the wire inductances? 

Quote

But this is true whether we switch between full forwards voltage and full backwards voltage or full forwards voltage and open circuit. Am I just wrong to think there is always a defined voltage over (a particular phase of) the motor?

I'd strongly assume there should be always a defined voltage and 0% duty cycle never happens. But bldc afaik have different algorithms again for slow speed movements...

So the easy model works well - if one looks in the right regions paying attention to the right details.

 

[jancellor]

Okay I'll go away and make sure I understand multi-phase BLDC so I'm not just confusing the discussion asking for explanations. Thanks for this though @Chriull. However, I think we agree the relationship between inverter_load and torque margin is still true even if I was wrong to equate it to duty cycle (I should have realised this was irrelevant and stopped asking about it).

That is, inverter_load directly measures how much extra current/torque/acceleration/lean is available regardless of speed/incline/wind/lean-right-now. It should be used as a measure of safety when analyzing logs retrospectively, as an option for the main gauge in apps like EUC World as @Planemo suggests, and as a basis for warning beeps (like the unconfigurable KS 88% alarm).