Simulation Program Pre-Announcement

[safe]

Justin at Ebikes.ca had created a GNU software program that dealt with our electric bikes. It was a good foundation, but as far as practical usage it didn't apply to anything but the hub motors. What I've done is extended the work that Justin did and changed the way the program works. I'll be doing a full presentation of the Simulation later, but for now I'll just say that you can load:

Bikes
Tracks

...and then once these files have been loaded (they have all the data you need) you can either call:

Dyno
Evaluate

...which means you can either do a simple Dyno of the motor itself (a good place to start) or you can evaluate the track results of the simulation. I'll get into it further when I do the formal presentation. (I'm still debugging it)

The Good News

The "good news" is that the RC motors completely blow away other motors in the simulation. This is documentation that proves that the RC motor idea is a clear winner!

 

[safe]

In order to make things fit here better I trimmed the Legend off of the charts (it sits to the right) so the Legend for all the charts is this:



All three bikes travel the same track which looks like this as far as elevation:

 

[safe]

In order to get a more fair result I set things up so that they performed nearly the same (took the same time) so that the results are comparable:

 

[safe]

When it comes to efficiency we get:



When you hit up against the controllers current limit your Duty Cycle gets reduced, so this is a good way to check how close to full power you are. (they all are doing okay)

 

[safe]

There's a difference between current and torque at the wheel on geared bikes, so you can spot the differences here:



...verses the torque:



...it's really only on the green line that you notice it.

 

[safe]

You can see how the Power Output:



...compares to the drain on the battery which actually involves a Peukert's formula (to be discussed later):

 

[safe]

The Grand Conclusion

This is where you really see the big difference. Check out the heat created:

View attachment 1

...and the total heat:



The bottom line is that the RC motor just blows away the competition. This should put the final nail in the coffin of the hub motor and makes me want to adopt the RC motor for what I'm doing. :wink:

THE BLUE LINE IS THE RC MOTOR

 

[dimitrib90]

The Grand Conclusion

This is where you really see the big difference. Check out the heat created:

View attachment 1

...and the total heat:



The bottom line is that the RC motor just blows away the competition. This should put the final nail in the coffin of the hub motor and makes me want to adopt the RC motor for what I'm doing. :wink:

THE BLUE LINE IS THE RC MOTOR

The RC motor just about beat both the motors in almost every test. BTW did you mean the AXI 5345_14 motor?

 

[safe]

The RC motor just about beat both the motors in almost every test. BTW did you mean the AXI 5345_14 motor?

Yes, it's a good little RC motor.

I'm still adding new features and debugging the simulation program, so I'm going to continue testing it until I'm certain that I've gotten 99% of the bugs out. It's looking good.

I know a lot of guys are using more than one motor (like Jozzer) so I've added the ability to select multiple motors for the simulations. It all works seemlessly... it's kind of fun to play with. (addictive)

Here's a crazy idea...

How about a 50 horsepower powerplant that is made up of 24 AXI 5345_14 motors. They weigh about 2 lbs each, so that's a 48 lb "motor" (so it's a little heavy) but it would pump out 50+ horsepower while still running in it's high efficiency area all the time. The price might be high too.

If two (big) motors make things a little better, then why not 24 small ones?


Red Line - Current Unlimited
Blue Line - Armature Limited
Green Line - Battery Limited (standard)

For people doing motorcycles the idea of RC motors might be a good idea as well.... still need to experiment a little more with the idea... (sort of like multiple cylinders you use multiple RC motors)

The Induction Motor is still the best way to go when you get into this kind of horsepower...

 

[etard]

Nice work Safe. Can you verify the results in a real world setup? If those 24 motors were brushed it might be a good argument, but 24 brushless controllers would be insane.

 

[safe]

Nice work Safe. Can you verify the results in a real world setup? If those 24 motors were brushed it might be a good argument, but 24 brushless controllers would be insane.

I'm just throwing out ideas right now... you could build something that looked like a big disk with the motors out on the ends of the disk. Then on the inside of the circle you have a large gear with many, many teeth. On the outside the motors have maybe 12-15 teeth each. So the inner (shared) gear might be 400 teeth and the final geardown ratio would be:

400 / 12 = 1:33 which would bring the rpms down to:

8000 / 33 = 242 rpm which would be manageable.

I would guess you would have to build a custom controller or something... it's just an example of the simulation being able to do "what if" scenarios. While I want to publish the simulation soon, I also want to be sure it's completed and perfected. So give me some more time and then later you will be able to do your own "what if's".

 

[safe]

Automatic Gearing Estimation

The latest feature I've added is the ability to turn the gearing process on to "automatic" and solve for "perfect power" or "perfect efficiency" in gearing over the track being studied. This gives you an idea of what the bike "wants" to do whether your gear ratios are capable of delivering on it or not.

In this run I went Flat, Valley, Hill, Climb (really steep) and came up with these results. I then did a little paintbrush work to plop my gear ratios I've calcuated elsewhere (my spreadsheets) to show how they relate. This was run under the "perfect power" setting.

The Safe Project #001 bike seems geared just right for the low end, but it's missing the ability to get anywhere near it's top end potential. (downhill) I've found this to be very frustrating as every time I try a speed run I just run out of gearing to do it. The Safe Project #003 (not finished) looks to have some pretty good coverage. After running this program I know that I need to buy another rear sprocket because I chose the wrong choice... I went 38 on the rear rather than 25. (stock)



Merry Xmas for today and I'll be posting the full software soon...

 

[AussieJester]

Nice work safe...i guess LoL...I get lost soon as graphs start popping up but i did happen to notice this one-->

How you get your Unite motor doing 8000rpm they max at 3000rpm well my 1000watt does according to Unite specs :-S

 

[Jeremy Harris]

Nice bit of work, Safe.

Any chance of just publishing the algorithms behind these plots so that we can play around with them in Excel, please? The coding you've done is great, but I've found it useful to be able to cut and paste data sets into alternative forms for some of the performance prediction stuff I've been doing - it makes the "what if?" stuff easier to do in some ways.

I'd be interested in seeing the controller impact, too. I've just run into a small problem with a cheap RC motor controller and fixed it by using a much bigger controller. The effect on motor performance was marked, even way below the current limit, so it's clear that there are some big differences between controllers. The snag is I don't think that these differences are always highlighted in the controller specs, so a simulator is going to have to make some assumptions about things like on resistance and switching losses.

All good stuff, though, I take my hat off to you for having the patience to put all this together.

Jeremy

 

[safe]

You can download the Version 1.0 here:

http://www.ebikehub.com/forum/viewtopic.php?f=12&t=603

...I'm going to have to do a bunch of screen grabs to do a good tutorial, so that will take time. I will eventually set up a thread here.

 

[safe]

You can download the Version 1.0 here and get a little bit of an explanation of what to do:

http://www.ebikehub.com/forum/viewtopic.php?f=12&t=603

Or you can just get the file directly here:

View attachment ESP_1.00.zip

...I'm going to have to do a bunch of screen grabs to do a good tutorial, so that will take time. I will eventually set up a thread on endless-sphere. So this is a pre-release.

This is the stuff you need to know about your bike before you can run the simulation effectively.

Gnuplot.bat starts the simulation...

#
# Crystalyte 407
# --------------
#
# Motor
# -----
#
# rm : motor resistance
# k : motor constant (voc/maxrpm)
# a0 : cogging torque
# mu : motors used (1 or more)
#

rm = 0.4310
k = 0.1154
a0 = 1.1125
mu = 1

#
# Battery
# -------
#
# voc : battery voltage (open circuit)
# rb : battery internal resistance
# wh : battery total watt hour
# pk : battery peukert constant
# vs : battery voltage sag (volt per Wh)
#

voc = 48
rb = 0.4
wh = 500
pk = 1.2
vs = 0.008

#
# Controller
# ----------
#
# ic : controller current limit
# rc : controller internal resistance
# lmt : controller limiting
# value = 0, no current limiting
# value = 1, battery current limiting
# value = 2, armature current limiting
#

ic = 20
rc = 0.03
lmt = 1

#
# Aerodynamics
# ------------
#
# rho : air density in kg/m^3
# cda : effective frontal area in m^2
#

rho = 1.18
cda = 0.4

#
# Hill Climbing
# -------------
#
# wt : weight of bike plus rider in kg
#

wt = 100

#
# Rolling Resistance
# ------------------
#
# cr : coefficient of rolling resistance
# dw : diameter of wheel (mm)
#

cr = 0.01
dw = 700

#
# Gearing
# -------
#
# gr : gear ratio
# value = 1, hub motor
# value > 0, fixed gear ratio
# value = 0, taken from user defined track
# value = -1, solve for maximum power
# value = -2, solve for maximum efficiency
#

gr = 1

 

[safe]

Any chance of just publishing the algorithms behind these plots so that we can play around with them in Excel, please? The coding you've done is great, but I've found it useful to be able to cut and paste data sets into alternative forms for some of the performance prediction stuff I've been doing - it makes the "what if?" stuff easier to do in some ways.

The simulation produces files in the "data" directory that are in a format that will load into a spreadsheet using the "Text & Tabs" format.

So "yes" you can skip all the charts and just look at the raw data...

The format for the "data" files look like:

Rpm
DutyCycle
Current
Voltage
WattHours
GearRatio
Velocity
Torque
PowerIn
PowerOut
Heat
HeatTotal
Elevation
Seconds
Pedal

The "functions" are all in their own directory so you could look at them too. This is a typical function:

#
# PowerAerodynamic(w)
# -------------------
#
# Global Parameters
# -----------------
#
# rho : air density in kg/m^3
# vw : headwind speed in m/s
# cda : effecive frontal area in m^2
#
# Function Parameters
# -------------------
#
# w : rotational speed (rpm)
#
# Returns
# -------
#
# watts
#

PowerAerodynamic(w) = rho/2 * (Velocity(w)+vw)**3 * cda

 

[Jeremy Harris]

Thanks Safe, nice job!

Jeremy

 

[safe]

I'm still adding features, so when I release the simulation again it will be a Version 1.01. I've added a new Dyno plot that assembles the Power Input, Power Output, Heat (same shape as torque), and Efficiency together.

In a script you would call it like:

call DynoSelected Crystalyte407


I'm also adding some new controller options:

#
# Controller
# ----------
#
# ic : controller current limit
# wc : controller watt limit
# rc : controller internal resistance
# lmt : controller limiting
# value = 0, no current limiting
# value = 1, battery current limiting
# value = 2, armature current limiting
# value = 3, watt limiting
# value = 4, armature and watt combined
#

ic = 30
wc = 1000
rc = 0.01
lmt = 4

Which will allow simulations of a "Wattage Restricted" bike. This might be useful if "Wattage Restriction" becomes a part of racing eventually. It's slightly different than a fixed battery current limit since as the battery voltage declines your allowable current goes up to compensate. You can also combine armature limiting with the wattage restriction. As other controller concepts come along I can add them too. (maybe some of the programmable controller ideas)

 

[safe]

Another Pre-Release

View attachment ESP_1.01.zip
This version has the newer stuff in it.

I've added:

Crystalyte5304
Crystalyte5305

..to the list of motors you can simulate. (12 so far)

 

[safe]

Dyno Results Need To Be Exportable

It dawned on me this morning that not having the ability to export dyno information as a spreadsheet readable file (currently not available) is a major shortcoming. So I'm going to convert over to that.

You could do nothing but:

call Dyno MyBikeName

...and look at the dyno results in a spreadsheet. I thank Jeremy Harris for encouraging me along this line of thinking. (I suspect that many people might just want a way to generate data for their motors to be used on other software programs)

 

[swbluto]

Nice work. I hope it improves and evolves into a user-friendly interface.

Just a quick note. "Total heat" is not watts but watt-hours or Joules, whichever you prefer to calculate in and express. The "total heat" is really just thermal energy that's expressed in units of energy and not power.

 

[safe]

Just a quick note. "Total heat" is not watts but watt-hours or Joules, whichever you prefer to calculate in and express. The "total heat" is really just thermal energy that's expressed in units of energy and not power.

A good point. At present I'm just extracting the portion of the motor watts and diverting it to the heat total, but a conversion to some more standard metric is a good idea. Joules is probably good idea and it's conversion is:

1 Watt = 1 Joule per second.

So the heat value will actually be a multiplication of the time (seconds) and the watts since my tracks are measured in meters and not seconds. It can take more or less than a second to cover one meter and that will adjust the heat total. Faster speeds mean that the heat value is applied for a shorter time, so the faster machine will not look as bad this way. (which reflects reality better)

Maybe I'll stick with "Heat" being the instantaneous motor related value in Watts and just convert the "Heat Total" to Joules. Then you see things both ways, the momentary and the calculated.

Good advice... I'll take it...