Approaches to modeling and simulation of e-bike performance

[akelm]

Most of us have seen plots produced by the Crystalyte motor simulator at http://ebikes.ca/simulator/.
These plots show graphs of motor torque, output power and efficiency as functions of speed, for a fixed throttle setting. While such plots are very useful for understanding motor performance, the behaviour of an e-bike depends on other factors, such as air drag, rolling resistance and power needed for climbing slopes. A common way to try to bring these factors into consideration is to plot a curve of power requirements as a function of speed. This gives rise to a plot like the following:

The motor torque, power and efficiency curves in the above plot are calculated based on the model used by the ebikes.ca simulator, and have been validated against it (http://docs.google.com/View?docID=ddsfhm9d_30cn55cz7v#Part3 ).
The calculation of the power requirement curves
(http://docs.google.com/View?docID=ddsfhm9d_30cn55cz7v#Part4)
depends on the choice of a number parameters, so the power requirements should only be regarded as a representative example. (The actual choice of parameters for this plot is listed beside the next plot, which uses the same values. Wheel size is 26”).

The point where the power requirement curve matches the motor output power curve indicates how fast the e-bike will go under these circumstances: 40.5 km/hr. This graph doesn’t tell us how the bike performs on different slopes, against different winds, or with different throttle settings. As it is natural to try to drive an e-bike in such a way as to maintain a target speed through various terrain and wind conditions, a fixed speed plot would be useful. The following graph shows such a plot, for cruising (with the help of a CycleAnalyst, say) at the legal limit of 32 km/hr.

This graph shows, for example, that to maintain 32 km/hr without wind or hill requires 7.6A of battery current. The strongest wind we can maintain this speed against is about 15.5 km/hr, which corresponds to 100% throttle and a battery current draw of about 23A. If a 500W output power limit is to be observed (as required in Canada), only 10 km/hr wind can be countered at this speed, and that requires 15A of battery current. This fixed speed plot provides quite a bit of information regarding performance of this e-bike. A separate plot (not shown),with 150W of pedal power added, shows that without wind, only 3.4A of battery current is required to maintain 32 km/hr.

What if we are interested in hill climbing? The following graph shows the same bike configuration, without wind but on various hill grades and with 150W of pedal power added.

The steepest hill this e-bike can maintain 32 km/hr on (with 150W pedaling power) is a 6% grade, but that requires 23A of battery current. Keeping the 500W output motor power limit, only a 4% grade can be handled at 32 km/hr, and that requires 15A of battery current.

While the above plots are quite useful for the range of conditions under which the target speed of 32 km/hr can be maintained, they don’t tell how much the e-bike would slow down for greater headwind speeds or steeper grades. The following ‘contour plots’ provide such information, as they show the combinations of ground speed and wind speed (or ground speed and hill grade) that can be handled for specific battery current levels. The thick red curve on the plots show the 500W output power limit, and the magenta curve shows the 100% throttle line, which is a limiting factor at higher velocities.


Further analysis and discussion of such plots and the theory behind them, along with many other examples, is found in a document I have placed on Google documents:
http://docs.google.com/View?docID=ddsfhm9d_30cn55cz7v
In particular, it has a download link so that you can download the Gnuplot scripts used to produce such plots, in order to experiment with them yourself. I hope that some of you will, and that these new plots will provide added insight into e-bike performance and behaviour.

 

[fechter]

Cool 8)

Graphs with labeled axes too.

 

[Miles]

Fantastic contribution, Alan

As someone who doesn't use hub motors, I'd prefer something a bit more generic, though..

I've just started using this free software for motor analysis.

 

[akelm]

As someone who doesn't use hub motors, I'd prefer something a bit more generic, though..

I've just started using this free software for motor analysis.

The calculations underlying the plots are specific to the circuit used in the Crystalyte controller, although other hub motor setups are likely to be similar. It should be possible to adapt the Gnuplot scripts for geared motor setups, although I haven't tried this myself. The beauty of mathematical modeling is that once the equations have been solved (and Maxima is a good tool for this), the resulting functions are fully parametrized and can be plotted any which way. I'm hoping that interested individuals in the e-bike community will try my scripts out, and tweak them for their own situation. A motivated individual could even package them with a web interface, similar to what is done with the ebikes.ca simulator.

I haven't bought my first e-bike kit yet, but I noticed that a lot of people make changes after buying their first setup, largely because it doesn't behave as they wanted. I worked out these simulations in order to increase the likelihood that I will be able to get the purchase right the first time, and because I love mathematical models.

 

[safe]

Great Job!

I've put together my own spreadsheets to do all this stuff, but as a former Java programmer I really should have done it all in code from the start. My projects all are multispeed and so it was necessary to incorporate gearing from the beginning and so since nothing did that for me I had to do it all on my own. This is very good stuff... I might get into this coding more in the winter when I have plenty of free time to do it.

GNU looks like your basic type scripting language... simple enough to figure out...

It would be great to build a simulator that incorporated the gears in with the motor and the wind resistance... slope... choice of ACL verses BCL.... controller losses... etc...

 

[akelm]

.... This is very good stuff... I might get into this coding more in the winter when I have plenty of free time to do it.

GNU looks like your basic type scripting language... simple enough to figure out...

It would be great to build a simulator that incorporated the gears in with the motor and the wind resistance... slope... choice of ACL verses BCL.... controller losses... etc...

Gnuplot is not so much a scripting language as a mature and flexible graphing package with strong support for functions, parameters, computation and some flow control. Nevertheless, it provides enough that it could be the back-end for a web-based simulator, and it is relatively easy to poke around with, for those who like to experiment.

Justin, in an email of July 22, indicated some future plans for the ebikes.ca simulator:

Anyways, probably before the end of this year we'll have a chance to upgrade to simulator Version 2 which will model the power losses of the bike as well. It's been on the agenda for a while but the store is quite busy.

While the new version will include power losses, which is a big plus, and it already supports a battery current limit (BCL), he makes no mention of gearing, or an armature current limit (ACL). The big advantage of an "open source" simulator is that the community would be free to extend and enhance it, as well as debate the mathematics. (I discovered, for example, that there are two approaches to air drag that differ by the factor Vground / (Vground + Vwind)).

 

[safe]

I've already downloaded everything I need and have done some simulations and changed the code to play around. This winter I'll give it a good attempt. A can already see that changing the gearing is a pretty trivial thing to do and things like ACL shouldn't be hard either.

Maybe this will become some sort of standard that we can all use to communicate with. It's a much more direct method than using spreadsheets which are really bad at documenting.

The coding could be cleaned up a little too.

Suggestion

I would suggest that you create a sort of "classroom" for this software. Start by going back again and cleaning and reorganizing and renaming where appropriate so that you get the code to a very high level of refinement. (it's close, but there's always room for improvement) Then divide the code up and teach each section as a separate "Lesson". Take your time... maybe put together a lesson per week and we could all "digest" the lessons a little at a time and even make commentary and possibly improve the lecture material. Then after the whole process is complete you would wrap up the final result and make that into something that becomes the ebike worlds foundation.

Take your time and really think about how to teach as opposed to just present your work.

Keep in mind I'm suggesting you teach a lesson about HOW to use the code itself and not the theory that the code implements. You've already done that and most of us already know the theory side of things. The idea would be to make this code easy to use and modify and extend for our own purposes. Some of it would be teaching us the fundamentals of GNU and how the code uses these fundamentals.

It's an honor to be the one to do this... 8)

The sort of simulations I want to do involve things like how the timing of gear shifts effect performance under different conditions. I know from my riding that proper shift points are very critical to getting peak performance and it's not easy to do right.

 

[Miles]

Justin, in an email of July 22, indicated some future plans for the ebikes.ca simulator:

Anyways, probably before the end of this year we'll have a chance to upgrade to simulator Version 2 which will model the power losses of the bike as well. It's been on the agenda for a while but the store is quite busy.

While the new version will include power losses, which is a big plus, and it already supports a battery current limit (BCL), he makes no mention of gearing, or an armature current limit (ACL). The big advantage of an "open source" simulator is that the community would be free to extend and enhance it, as well as debate the mathematics. (I discovered, for example, that there are two approaches to air drag that differ by the factor Vground / (Vground + Vwind)).

It would be great if Justin would open up the input side, so that we could key in Io, Rm, kV values, for our own motors - even if the calculation wouldn't be as accurate...

 

[safe]

It would be great if Justin would open up the input side, so that we could key in Io, Rm, kV values, for our own motors - even if the calculation wouldn't be as accurate...

For one speeds you can do most everything by just tweeking a few motor parameters. For geared bikes it's going to require some serious coding changes and things like ACL simulations will need even more. However, I would think a simple input template that included the regular motor parameters might be good if it was online. Then you could compare different motors for your needs.

The problem with making the "simple" request is that they might satisfy it and then that's all we get.

If a more comprehensive educational and source code approach is taken then we start to see a standard develop. I'd like to be able to converse using a common coding language. (and not just play with a template)

"Open Source" is the way to go...

 

[akelm]

I've already downloaded everything I need and have done some simulations and changed the code to play around. This winter I'll give it a good attempt. A can already see that changing the gearing is a pretty trivial thing to do and things like ACL shouldn't be hard either.

Maybe this will become some sort of standard that we can all use to communicate with. It's a much more direct method than using spreadsheets which are really bad at documenting.

The coding could be cleaned up a little too.

Suggestion

I would suggest that you create a sort of "classroom" for this software. [...]

I'm pleased to hear that you have downloaded the scripts and got them to produce plots for your situation.

I appreciate your suggestion that I reorganize the code and provide an online 'classroom' to familiarize others with its operations, to encourage and enable others to make use of it.

It seems to me that the number of folks who are likely to dig in to the level you are imagining is relatively small. There have only been two downloads of the code so far. Such people will be able to navigate usage pretty easily, as its really not too complex.

There are a large number of e-bike users who could benefit from the types of plots this software produces, but most won't bother unless its packaged into an easy to use web-based interface. My hope is that more people will see the value in fixed-velocity plots that show e-bike performance for various wind and hill situations, as well as the 'contour' plots with ground/speed and wind speed (or hill grade) axes. I think they get to the crux of the performance people are looking for. If interest grows, the plotting scripts will develop further, thanks to open source.

My time to carry this forward is likely to be limited, but I'd be happy to facilitate the work of someone else who is up to the task.

 

[safe]

My time to carry this forward is likely to be limited, but I'd be happy to facilitate the work of someone else who is up to the task.

With your permission I might (this winter) make up an online classroom for this. I will want to learn it myself and as I do I could teach others at the same time. Given the often political nature of this forum I would prefer you did it since I often get a lot of flak from this place.

People would likely download the code more if there was a lesson going on. Sometimes you have to sort of get people addicted to the whole process first before they start to get into it. People are lazy at first... but once they get excited about something they lose their laziness and become combative and engaged. An online classroom gives that "edge" of interactive entertainment.

Anyway... this is something that would be great to do in January or February when the ebikes are sitting in the garage and people have nothing to do. I did a classroom using the spreadsheets last year, so maybe this year I could repeat with the GNU code.

 

[akelm]

With your permission I might (this winter) make up an online classroom for this. I will want to learn it myself and as I do I could teach others at the same time. Given the often political nature of this forum I would prefer you did it since I often get a lot of flak from this place.

People would likely download the code more if there was a lesson going on. [...] this is something that would be great to do in January or February when the ebikes are sitting in the garage and people have nothing to do. I did a classroom using the spreadsheets last year, so maybe this year I could repeat with the GNU code.

You would certainly be welcome to use the plotting code as a basis for another course (it's GPL'd, after all). I remembered the "Motor University" course from last year, but hadn't realized it was you who did it. There were some hecklers, 'tis true, but some useful ideas and techniques were still put forward. If I have free time when you do it, I'd be happy to help out. It will be instructive to see how the code can be generalized to other motor and controller setups, as well as geared arrangements.

I'd like to see the emergence of a readily accessible interface where any interested person could tweak some parameters and get a set of informative plots revealing the performance of their modeled e-bike under a variety of real-world driving conditions. So many people seem to buy their first e-bike kit, only to realize later that it won't perform as they had imagined.

 

[dirty_d]

i wrote a little gnuplot script to plot any motors performance, i used this to select my bikes gearing and stuff. heres the code, feel free to use it.

Vmax = 20.0 #operating voltage
R = 0.071 #winding resistance
K = .073 #speed/torque constant(voltage / no-load speed(rad/sec))
Inl = 3.0 #no-load current draw
Imax = 290 #motor current limit, set to soemthing higher than the motor can draw at stall to see how it performs unrestricted

Wnl = Vmax / K
Rm = R / (K * K)
Is = Vmax / R < Imax ? Vmax / R : Imax

x1 = Wnl
y2 = 5000 #Is * Vmax

#tit = sprintf("Motor performance(%dV)", Vmax)
tit = sprintf("Motor performance(%dV) %dA limit", Vmax, Imax)
set title tit
set xlabel "radians/sec"
set ylabel "Torque(Nm), efficiency(%), current(A)"
set y2label "Power, mechanical/heat(W)"
set yrange [0:Imax > 100 ? Imax : 100 + 10] #to give a little more room
set xrange [0:x1]
set y2range [0:y2 * 1.1] #to give a little more room
set ytics nomirror
set y2tics 0, 1000
set ytics 0, 10

Ia(x) = ((Vmax - K * x) / R < Imax ? (Vmax - K * x) / R : Imax) #perfect motor current
I(x) = Ia(x) + (Inl - Ia(x)  / Imax * Inl ) #account for no-load current
V(x) = I(x) * R + K * x 
T(x) = I(x) * K
P(x) = T(x) * x
N(x) = (1.0 - (Inl / I(x))) * (1.0 - (I(x) / (V(x) / R)))
Q(x) = V(x) * I(x) - P(x)

plot T(x) axis x1y1 title "Torque", \
P(x) axis x1y2 title "Power", \
I(x) axis x1y1 title "Current", \
N(x) * 100 axis x1y1 title "Efficiency", \
V(x) axis x1y1 title "Voltage", \
Q(x) axis x1y2 title "Heat"

 

[safe]

If I have free time when you do it, I'd be happy to help out. It will be instructive to see how the code can be generalized to other motor and controller setups, as well as geared arrangements.

This has been presented from the start as an "Open Source" framework and I think it would be great if we could get several people in on it. (hopefully people that have some coding background) We might begin with a summation of all the parameter names that we will all use since in these scripting languages you have a single name space and everything is visible everywhere. Being an Object Oriented Programmer guy (Java) I really prefer being able to have interfaces when doing group projects because then all you have to do is agree on the interface and then people can write their code as they like. Coding can get to be a VERY personal thing because we all have our styles and preferences.

It would be nice to partition the work into specific single purpose subunits so that one person maybe makes a "Geared Bike" chunk of code that seemlessly integrates with the regular one speed code. I like the way the original code has separated the motor params out and we might (as has been said) want to create a template that could manually enter the motor parameters. I was playing around with a few RC motor simulations this morning and discovered some "dream" scenarios, so I have a feeling this tool could help to really focus on how to get the most out of what's out there.

So... let's just wait until winter... in January or February there's just nothing to do but stay indoors...

Another thought...

It might be nice to produce parameters for just about everything we can get our hands on so that within the "Open Source" toolkit you can load the motor parameters and take a look at it. Each of those motor parameter sets need to be reviewed (by all of us) so that we reduce the chances of errors slipping in.

Fortunately with the RC motors they tend to be pretty good about publishing the motor parameters, so for those it should be pretty easy. (there are probably 50 different RC motors to choose from) Unite Motors publishes some data, but it's sloppy and needs to be processed further to get useful parameters. Some motors have next to do data, so there might be some guessing required.

 

[swbluto]

Thanks Alan for making this original contribution! I used your original suggested directions for the "Master Formula" using Mathematica and created several useful formulas and implemented them in the form of a java applet that currently has its own thread at http://www.endless-sphere.com/forums/viewtopic.php?f=2&t=6892 . It's a work in progress, so it's not "Fully featured", yet.

A critique about your work, however. The P_wind = C*A*(v_ground+v_wind)^3 formula provided possibly results in two possible solutions for P_motor = P_needed whereever v_wind > 0. This isn't sensible as the force curves for the motor and the cumulative counteracting force curve(drag, rolling resistance, gravitational acceleration, etc.) only have one intersection(if any). So after thinking about the relation of P to F, I remembered P=F*v, so the actual formula is P_wind = C*A*v*(v_ground+v_wind)^2, and kreuzotter.de supported my suspicion. So those two possible stable equilibria don't exist; sorry.

 

[swbluto]

I haven't bought my first e-bike kit yet, but I noticed that a lot of people make changes after buying their first setup, largely because it doesn't behave as they wanted. I worked out these simulations in order to increase the likelihood that I will be able to get the purchase right the first time, and because I love mathematical models.

That's exactly why I created the applet! A simple change in one value allows you to see how it changes the top-speed and finding the "optimal" combination is relatively easy, so I'll get an idea of what's optimal for my upcoming electric scooter conversion.

Perhaps a 3-dimensional surface plot can be used to vary 2 parameters to see how it effects the top-speed as some factors aren't exactly straightforward(For hill-climbing, for example, "less wheel-size" isn't *always* better. There's a definite optimal size when it comes to top-speed; there's even an "ideal wheel size"/"ideal pedaling power" whose wheel-size might even be different than a straight-forward wheel size for no pedaling input power.).