Jump to content

Anatomy of an overlean


Chriull

Recommended Posts

8 minutes ago, DaveThomasPilot said:

Maybe it didn't beep or tiltback because the control board's voltage measurement was inaccurate?

The voltage from the graph was delivered from the control board and seems fine?! No tiltback is just because the motor could not accelerate enough anymore.

7 minutes ago, meepmeepmayer said:

Would you have some slightly bigger versions of the pictures?:)

Done. Somehow imgur downscales pdf's... ;(

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

  • Upvote 1
Link to comment
Share on other sites

  • 1 month later...

This all seems a sweet mystery, yet if that chart was sent real time to our smart phones along with training on how to read it then I'm sure more crashes could be avoided.

Or perhaps not as we would try to ride closer to the edge...

  • Like 1
Link to comment
Share on other sites

On 9/19/2017 at 10:26 AM, ir_fuel said:

+1

There are way too many similarly colored lines on that first graph. :wacko:

You can read in the data from the graphs using this tool and then replot them with any color of your desire using one of the 2 million tools out there for plotting.

Edited by Mono
  • Like 1
Link to comment
Share on other sites

 

Tried it with nicer colors - the only really important stuff is the green line (motor current over speed) and the grey backgrounds (out of limit)

7918cNC.jpg

And the normal graph over time:

This time i added a first try prediction by the acceleration (speed difference between last sample and actual sample) if the limit will be reached/crossed within 2, 1 or 0,5 secs. This is shown with the "I>I limit" line, where a value of 20 means limit reached/crossed within 2 seconds, 40 within 1 second and 60 within 0,5 seconds (assuming acceleration and load stays the same).

There was no averaging or flattening done by now - just the "raw" values. But seems to make sense by a first look...

The one second alarm came ~2 *) secs before the crash (because he decelerated inbetween), then imedeately the 0,5 secs alarm started ~1,2 *) secs before the crash (because again the acceleration was reduced)

*) Edit: The accident happened at ~18:15:01,7 (when the current and power went down) and not at ~18:15:02,4 when the speed went down... So the pre warn times are this ~2 and ~1,2 secs instead of the previous mentioned ~3 and ~2 secs...

5bLI7NZ.jpg

 

To compare the same chart for an incident free part of the ride

vPeTgbN.jpg

Edited by Chriull
  • Like 2
  • Upvote 1
Link to comment
Share on other sites

My original intention was to implement such an alarm in wheellog - as it seems it took from July 25th till now to make an first try in excel :ph34r:...

So as @palachzzzis quite active developing wheellog, maybe he or some other member here could easily overtake me ;)

How to achieve this alarm:

First step is to obtain the current (==torque) over speed limit.

For this one needs the maximum speed without load. A first approximation is to take the lift cut off speed and add a little bit...

This maximum speed gives one the motor constant kv (battery voltage == motor voltage at this speed, so maximum speed divided by the  battery voltage gives kv)

A little bit more complex is to obtain the slope of this line. My first attempt was to take @EcoDrift's measured max output power (http://airwheel.ru/test-monokoles-na-dinostende/) which would be for the KS16C about 2,2kW and lean the line from (current=0, vmax) to the "current for max output power of 2200W" line in the graph. But as one sees easily from the wheellog measurements this would lead to a limit which is already way outside of the limits!

My (so far) explanation for this:

- @EcoDriftmade the measurements with an "cold" motor. Copper increases its resistance from 20°C to 80°C by ?20% or 40% (don't remember exactly)? and the coil resistance is one of the main factors of the slope of this limit line.

- the second important factor for the slope of the limit line is the internal battery resistance. This is, from what i read so far a quite "complex" value - quite varying by the chemistry "changes" by the historical load situations...

- Maybe the coil resistance is in dynamic situations not a constant ohmic value, but also the inductance is to be considered? (and also the inertia of the system which reacts like an inductance?)

- accuracy of the data send by the wheel to wheellog...

So the best compensation for all this was that i got the wheellog logs of this overlean :ph34r: - by the logs one gets directly the limit line and by this v max at no load and the slope of the limit line (internal resistance battery and motor coils). (2)

So then the last step from the logs would be to split up the internal total resistance to the battery and the motor coil part.

This was done by me just by calculating the "ideal" Battery voltage (U_battery_0) and by changing the value of the internal resistance to get a smooth graph (least deviation...). Is not the nicest method, but i could not think of an other way till now...

Used formulas:

Valus delivered from wheellog:

U_battery, I_motor, v (speed)

Values to be determined for each wheel: kv, R_internal_battery, R_coil

U_back_emf = speed * kv

P_motor = I_motor * U_back_emf + I_motor * I_motor * R_coil (consumed power by motor)

( P_motor_output = I_motor * U_back_emf)

I_battery = P_motor / U_battery

U_battery_0 = U_battery + I_battery * R_internal_battery ( ideal battery voltage )

v_max_no_load = U_battery_0 / kv

Now the actual torque speed limit line is described by:

Current axis endpoint (speed=0, I_max) and speed axis endpoint (v_max_no_load, current = 0) with

I_max = U_battery_0/ (R_coil + R_internal_battery) (1)

I_limit = - I_max / v_max_no_load * v + I_max

Now with the actual acceleration

a = delta v / delta t

one can "look" into the future and get the speed within 2 seconds 

v_2secs = v + 2*a

calculate I_limit with this speed and check if the actual motor current is already above this limit value. If so one can give the 2 seconds warning.

I did not try till now to also calculate the current change rate and by this also extrapolate the future current... But an constant current means constant load (acceleration, incline) and a current change means a change in current and could by this be "overdone" and gives too many "false" alarms?

My next idea is, to just calculate by the acceleration and acutal limit line in how many seconds the limit will be reached and plot this against the "normal" graphs so one can test "on paper" different methods...

(1) Made a "small" fault with my posted diagrams before and used U_battery instead of U_battery_0 here...

(2) unfortunately for this (by now imho the best method) one would need fearless testpilots which make some overlean logs for the different wheel... :ph34r:

Ps.: As one sees in the graphs these formulas are not valid while regenerative braking!

Edited by Chriull
  • Like 1
  • Upvote 1
Link to comment
Share on other sites

17 hours ago, Chriull said:

My next idea is, to just calculate by the acceleration and acutal limit line in how many seconds the limit will be reached and plot this against the "normal" graphs so one can test "on paper" different methods...

Here one gets time to overlean t as

t = (I_motor_current - I_max - k * v) / ( k * a ) for (a >= 0 :ph34r:)

with k = - I_max / v_max_no_load

This time to overlean (black line) looks in the charts like this ( for a>0, limited to max 10 seconds), values in seconds on the right axis (i forgot to change the axis label from Power W to time (s) :ph34r:):

Seems to be a very valid and usefull warning indicator!

Also the acceleration is included (green line, shows 10 times the acceleration in m/s² on the left axis, negative values set to zero) - is a very "instable value", but imho averaging won't help too much since the sampling resolution is already 0,2-0,3 seconds and every averagin will delay the warning further untill it warns once one lays already on the ground....

 

Epi8Ejt.jpg

And for an accident free part of the ride:

j6WJoqr.jpg

 

 

Edited by Chriull
  • Like 2
Link to comment
Share on other sites

@Jason McNeil and all the other resellers with good contacts to the manufacturers - maybe this time to overlean calculation would be something to show to the manufacturers and gently "force" them to implement this into the firmware for tiltback/beeps?!

As shown this is nothing magical or complicated to calculate and they should know all the needed values of their wheels.

Edit: 

They also could use this method to eleminate at last the "tiltback of death" - if one accelerates like crazy the tiltback sets in at max speed within tenth of a second and vault the rider of the wheel.

With the known acceleration the firmware knows that the max speed will be reached in 1-2 seconds and can already start earlier with a soft tiltback..

And with the much higher internal sampling rate of the firmware they know the acceleration much more precise and accurate than with the wheellog samples...

Edited by Chriull
  • Upvote 1
Link to comment
Share on other sites

4 hours ago, Chriull said:

@Jason McNeil

They also could use this method to eleminate at last the "tiltback of death" - if one accelerates like crazy the tiltback sets in at max speed within tenth of a second and vault the rider of the wheel.

I can speak first hand how scary that is. It's like something that is designed to help you crash, is specifically designed to make you crash.

Irony, they call it.

  • Like 1
  • Upvote 1
Link to comment
Share on other sites

On 20.9.2017 at 8:00 PM, Chriull said:

...

I did not try till now to also calculate the current change rate and by this also extrapolate the future current... But an constant current means constant load (acceleration, incline) and a current change means a change in current and could by this be "overdone" and gives too many "false" alarms?

...

Since the prewarning time was imho a bit low, i tried it again with the actual current change rate regarded (1). This leaded to ~0,5 seconds earlier warning. Unfortionately the warning comes still way too late in the "hot" phase of the first strong acceleration and the warning could have just a chance because there was a short break inbetween...

This is imho because the acceleration here did increase "more than" linear. But with just linear extrapolation one looses already one sampling period, which is about 0,2-0,3 seconds with wheellog. For some polynomial extrapolation more historic sampling points would be needed which leads to an even longer delay rendering the warning absolutely useless... ;( (... imho i have to doublecheck this, but for now this seems quite logical too me...)

So such "better" extrapolations could only be implemented in firmware where the full sampling "resolution" is available.

"Time to overlean 1 (s)" is the old calculation based on constant future acceleration with constant future current (green dotted line) and "Time to overlean 2 (s)" is the new calculation based on (constant future) acceleration and (constant future) current change.

Maybe regarding the "ideal" battery voltage U_battery_0 change rate could lead to again a bit of more prewarning time... ? (regarding that with the wheels which send no negative (regenerative) current values my formula for u_battery_0 is not valid - as one sees easily in the charts...)

The overlean:

82OCnPk.jpg

And a normal "hard" acceleration:

For the "main" acceleration phase here (starting around 18:00:53) the "new" prediction seems to work fine - here was an almost constant acceleration (and at the end even a decreasing acceleration).

CIcEKZE.jpg

In this case he stopped the "hard leaning forward" voluntarily at around ~20 km/h. But this acceleration from 10 km/h to 20 km/h only took 1 second - and he reached max speed (30/km/h) at roughly another 1,5 seconds!

Comparing both charts the first acceleration phase (current) looks about similar in both cases (maybe a little bit more in the overlean chart) - the big difference is that here he just went on acceleration comfortably up from 20 to 30 km/h in the overlean case he again accelerated very hard again from 20 to overlean.

At the beginning of the acceleration my calculation show ~1,5 seconds until overlean, by his slightly decreasing acceleration still around 1 second until he continued (after ~1 second) to just accelerate comfortable.

So imho an alarm beep in wheellog could make some sense? Maybe better in combination with the vibration alarm of a pebble/android watch this could be "subconsiously incorporated" by some kind of feedback loop? But imho any kind of alarm coming 0,2-0,3 seconds after one leaned forward hardly leading to an overlean within ~1,5 seconds could be quite hard to regard? 

The much better chance should be the firmware implementation with some direct undelayed "analogue" feedback (sound - getting louder/noisier, tiltback) so one could somehow incorporate this?

Should be a nice addon for new wheel generations?! Maybe something for our manufacturers representatives here @Barry Chen, @Diana@szkingsong.com, @King Ma - INMOTION? ( I hope i forgot none...)

(1)

Then

time till overlean = (I_motor_current - I_max - k * v) / ( k * a + dI ) valid for 0 <= v_t= v + t * a <= v_max_no_load and t>0 (otherwise the limit line would be crossed outside the valid range or "in the past")

with dI = delta I_motor_current / delta t

Rest of the other formulas above stay unchanged.

  • Upvote 1
Link to comment
Share on other sites

  • 1 year later...

Just messed a bit around with my KS16S and recorded some lift cut off logs with wheellog, visualized with 

RKebDDa.png

With the two constants kv and r_internal I (highly imprecise) approximated the limit lines to the recorded graph. Although i tried to push it forward real hard while lifted, "unfortionately" the wheel is too "powerful", the accelerated mass of the wheel too low and the time resolution of the values to coarse to get some nice values like with an real overlean. (.... Be carefull/use your common sense when trying this yourself - the wheels are no toys, especially the newest versions, etc, etc ....).

My previous and till now imo best idea to get nicer data (beside an overlean) would be to accelerate the wheel lifted while letting the tire rub the ground (moist meadow?) to get some more burden - but still don't know if thats a good idea or just a way to injure myself/destroy the wheel/make the wheel zipping around without control? Maybe i know more next spring/a warm and sunny winter day, when i take it out again...

So with this as a first step i fed some older logs into the gnuplot script - most were really boring (far away from the limit) but two recent ones (driving in colder conditions with not fully charged battery) seem to be a bit more interesting:

OQ8vHoW.png

kdGJUKE.png

As there is no information about time or battery voltage in these graphs (just current over speed) the two events crossing the lower limit lines are no overleans ( i would remember otherwise) - the battery voltage was higher and some higher limit lines applied to them (the two shown limit lines are for the maximum and minimum voltage during the ride). Also there is no information of the timely flow (have too look if gnuplot supports lines with arrows...).

But tiltbacks are shown nicely. As my intuitive conservative (boring) approach to handle tiltback is to decelerate, these events are with a 99,9% probability to be "read" from left to right and up to down (accelerating into tilt back and then decelerating).

In the first graph the "longer lasting tiltback" (longer line with more point going straight down) shows nome "nice" acceleration into the tiltback with a decrease of the acceleration before speed stays stable (maybe my internal speed "feeling" or the soft start of the tiltback made me react like this? (1) But both indicate nicely that the tiltback event does not lead to some substantional power/burden/torque increase (like always favourd by @Mono and my convivtion, too). In the second graph the tilt-back event shows some torque increase, which i would explain as my acceleration into tiltback, especially looking at my "fast reaction" to decelerate out of it. For (more) substanital statements this of course needs to be combined with the normal logs (over time) and some more "visibility" (these graphs are too cluttered to really see details...)

Let's see if i get ideas, time and passion to make something usefull out of this... One idea would be to write some small java program to expand the wheellog csv files with a column for the above described time to overlean and show that in the graphs (different line colors/point sizes in the current over speed diagrams?). Could enable nice analysis of the own driving behaviour - maybe with an immediate output of the java prog like "boring" till "suicidal tendency" :ph34r:

Ps.: (1) while rereading this maybe these two events (eventually) the "tiltback" with just two data points are no "tiltback" events, since with both i decelerated afterwards to much lower speeds? Maybe i just held the speed quite constant by accident? Especially since these speeds were below my normal tiltback setting of 35 km/h, but not too long ago the wheellog freshly installad on my new phone decided to reset the tiltback to 30 km/h which would make this to a tilback event again... ;)

Anyway - this is the first "try" in this direction and more serious graphs/analysis maybe to come...

  • Like 2
  • Upvote 1
Link to comment
Share on other sites

I don't quite get how you identify where tiltback has taken place.

I don't understand how the vertical lines come about: constant speed with largely changing torque. This seems impossible unless the inclination of the ground surface (or wind) changes. What is the time difference between two crosses? I guess I am missing something here, but what is it?

 

  • Like 1
Link to comment
Share on other sites

13 hours ago, Mono said:

I don't quite get how you identify where tiltback has taken place.

I don't understand how the vertical lines come about: constant speed with largely changing torque. This seems impossible unless the inclination of the ground surface (or wind) changes. What is the time difference between two crosses?

I guess I am missing something here, but what is it?

 

The difference is about 0,2 seconds - about 5 values a second the wheel reports to wheellog.

These parts (constant speed with largely changing torque) came by accelerating up to some speed (high torque for acceleration) and then reducing torque to just hold that speed. With the further rudiction of torque i decelerated again.

As these "events" were at quite some "constant" speed threshold my "probable guess" would be that these are tiltbacks - but as written in the post it'll need further analysis - could theoretically also just have been my decision to hold the speed for some time...  It reminded me of my normal behaviour, once i get tiltback - i do not "ride it", but reduce speed to drive on normally.

Best to make some real analysis will be dedicated logs from some intentional tiltback rides - once it gets warmer again ;)

 
  • Like 1
Link to comment
Share on other sites

A new iteration of my whellog data interpretation/visualisation:

CdGm1sr.png

3TC6vUs.png

Whats new:

Current over Speed Diagram:

- made a double check and showed the vectors which follow the actual "line segments" for "time till overlean" seconds. Fortunately they arrive at the limit line :ph34r:

- The min/max Limit Lines in the graph are now calculated with the (theoretical, calculated) "open circuit" voltage of the batteries (as they should instead of the battery voltage under load) More on this later on.

- If at any point of the diagramm the "time till overlean" gets less than 2.5 seconds a point in different sizes is drawn (2.5 seconds small to the biggest for 0 seconds)

- The points and lines are now colored depending on how near the are to the limit (safety margin). This is calculated by an imaginary line through the origin. 100% is the length of the whole line from the origin until the intersection with the limit line. If the point in the graph is below 50% (more than 50% safety maring) it's colored light-green, till 60% (more than 40% safety margin) green, till 70% dark green, till 80% orange, till 90% dark orange and the last 10% (less than 10% safety margin) in red.

Speed over time diagram:

- Speed, Voltage and Motor current as normal

- Time till overlean: Is now the dark blue line (between the values -5 and 0 on the left axis). A value of -5 means that there is more than 2.5 seconds until an overlean with the actual acceleration and change in current (torque). -2 means 1 second till overlean, and 0 itself is limit reached.

- The line below (between the values -14 and -5 on the left axis) is again the colored "safety margin" line

- U_battery_0: The open circuit voltage of the battery pack. This is beside kv (the motor constant) the determining value of the limit line. The outmost left value (max current (==torque) at zero speed is U_battery_0/resistances of battery and motor coils (+connections, mosfets, etc...) and on the other extreme is the no load maximum speed kv*U_battery_0). I calculated it by taking the reported battery voltage plus battery current (calculated) times the internal battery resistance. Unfortionately this is just an simplified model of an li ion battery, the reported values from the wheel are imprecise (imo mostly by not beeing sampled at the same moment in time but still showing a distinct timely value instead of the average of the period of the sampling frequency of laughable 5 hertz). So it is seen in the graph that this U_battery_0 deviates from a perfect line...;( Especially at current peaks and mostly while regenerative braking (which fortunately is of no concern for these considerations - there presumably other formulas are needed for the different operation mode...). But alltogether a nice first approximation.

This U_battery_0 would also be the appropriate value to calculate the charge percentage...

Edit: Ps.: Was a "nice" ride, but with just about 50% battery charge. Would have had no idea that it was at times so close to the limit...

Edited by Chriull
  • Like 2
Link to comment
Share on other sites

  • 3 months later...
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:

d40savb.jpg

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

Sorry that I forgot, but what is the model for the wind resistance in these graphs?

Link to comment
Share on other sites

35 minutes ago, Mono said:

Sorry that I forgot, but what is the model for the wind resistance in these graphs?

I use F AirDrag=0,5*cw*roh*A*v², P AirDrag = F Airdrag * v with cw=0,78, rho=1,2 kg/m³, A=1m². 

But as already "mentioned" before 

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

These "Current for incline..." lines are very "relative"!

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

Edited by Chriull
  • Upvote 1
Link to comment
Share on other sites

Thanks @Chriull! I didn't realize, or forgot, that the impact of acceleration on the necessary current is so much larger than the impact of speed. Yet intuitively I seem to know this, as I am very hesitant to accelerate quickly at larger speeds.

  • Like 1
  • Upvote 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...