New Open Source E-Bike/E-vehicle calculator & simulator

swbluto

10 TW
Joined
May 30, 2008
Messages
9,430
The latest (vastly improved version) is going to be either on the last page or the next to last page. The version listed below was the original version that only works for Windows and Linux.

Hello all. I created this program just for curiosity's sake and also the sake of me needing to choose the right motor and gear ratios for my soon-to-be electric scooter to perform upto the desired specs. It is here I release it to the community and to indulge in however you wish. Since it's a java applet, it requires a java-enabled browser which I've heard to be claimed to be nearly universally compatible with browsers. If you can't view it, you probably need to download the Java Runtime Environment(Google "JRE") or use whatever your browser might suggest.

Here's a test to see if you're java enabled

It can be viewed here.

Update: For those with compatibility issues, I've ported this to a stand-alone application(But the application still requires the "java libraries" to be installed). The program-version is here. Since this is my first application and I didn't take the time to completely learn stand-alone application programming, exiting requires pressing the "file" tab and clicking exit. The little red 'x' in the corner does nothing. Explanations for the variables can be found on the original online page, http://www.geocities.com/swbluto4gems/classes/SpeedPrediction.htm.

Right now it's in the "Beta testing version", so I'm looking for testing! Basically, this provides your top-speed under the given conditions you specify and if you can report this calculator's prediction and your in-real-life speed, that'd be wonderful! Also, I'm looking to make it more user-friendly, clear and accurate, so any suggestions are welcomed! In fact, I encourage them! Also, if you feel there should be other features, please say so. Some features, like those involving graphs, would take some time for me to investigate so those probably won't be coming for a week. However, if you like more specs like battery current demanded, motor current, power, etc., feel free to make the request! And, also, if anyone thinks the layout is awful, I can upload the User-Interface file which you can edit as you please in NetBeans (A java IDE Gui program.) or you can make suggestions. If any of the interface seems too vague or not clear(like the resistance doesn't specify units of ohms even though that's what it works with), be sure to mention it!

Planned and upcoming features(as of October 10th, 2008):

Completed
-Adding functionality to account for excessive motor heating. Basically, the user would put in the motor's winding's temperature.
-Air density that is automatically calculated from user-specified temperature and altitude.
-Pop-up to alert of missing necessary input.


More upcoming features(As of October 22nd):

-incorporating automatic design optimization
-Adding scroll bars
-Investigating and eventually adding graphing capability(Might not work on all systems as the graphing engine isn't necessarily multi-platform)
-Trying to make compatible with Mac-based systems in some way, shape or form due to Java 5 antiquities.
-Convert to calculate based on Forces as opposed to Power.
-Adding a combo box to allow users to choose their particular gear combinations, with appropriate boxes provided for each.
-Eventually... eventuallllllly document everything and provide links and other useful information to help decide a few values that might be differ depending on your application(Like, say, the frontal area of a motorcycle is usually higher than a bicyclist which this was based on, but a recumbent is less. Having a quick picture guide might help.).
-include no-load current to increase accuracy in general, and efficiency and heat generation in particular.

And I hope to fix a few design flaws that don't impose on normal usage, but could be errant for some combinations. Hopefully, I can make it so that it's more accurate for brushed motors for those that use brushed motors; The current code base is built around the brushless motors assumption which might provide inaccurate estimates of efficiency and dissipated heat for brushed motors.

By the way, some of the "suggested values" may not be entirely accurate as I was pulling them off the top of my head from various places I remember seeing them on the internet. So more research about their accuracy might be desired.

By the way, my real life top-speed is usually 24.9 mph: this thing predicted 25. :shock:

(About the basic theory of operation. It calculates the power provided depending on the motor, voltage, resistance, etc.(a complicated formula) and the power needed at a given velocity. It then logically tests consecutive velocity values and it hones in on the point where the "Power provided" and "Power needed" curves meet. It then reports the velocity at that intersection. And, most of the formulas were derived from Alan Kelm's research and Kreuzotter.de, but I had to modify some of Kelm's since some were... well... inaccurate. I.E., power = F*v, and the force of wind resistance is proportional to (v_ground+v_wind)^2, so the power formula for wind resistance is proportional to [r v_ground*(v_ground+v_wind)^2 and not (v_ground+v_wind)^3. This is important because the latter formula would possibly cause two intersections with the power formula whereas the force curves would possibly have one intersection, which is not sensible. But, I still need to find his thread so I can praise him for his research!)

By the way, the model breaks down where the power needed exceeds power provided near 0 mph so values of ".1" mph should indicate "You're going backwards" or "You're not going anywhere".
 
pwbset said:
"Loading Java Applet failed..."

:?:

Hmmmm... That seems odd. It appears to work on mine.

My guess is that this version uses technology too new for your current Java plug-in, but that doesn't make sense since it uses Swing technology which must be at least 2 years old.

Do you think you might have any of the problems listed at http://en.wikipedia.org/wiki/Java_applet#Compatibility_issues ? I was hoping they wouldn't be widespread enough to prevent a sizable amount of users from using this applet as someone thought Java is pretty much universal. But that "AMD64" problem has me worried as that's kind of widely used.
 
This is failing in all browsers I check with. I'm on a Mac with all the latest everything (web developer by trade), but it doesn't work in IE7 either.

jfail1.jpg

jfail.jpg
 
Well, gee, garsh. If only I had a Mac to do compatibility testing with. You wouldn't think it'd be related to the fact you're using a Macintosh since Java is "supposed to be" platform independent, but java virtual machines must be built for whatever computer they're running off of so I can imagine there might be some entry for compatibility issues.

I kind of wonder who else might be having problems. Are there any PC users having any problems?
 
I can get into it in IE 7 and Mozilla Firefox 3 - and I can select the presets or custom values, but nothing happens when I press the 'Calculate' button. I've got java Standard edition Version 6, update 5.
 
pwbset said:
swbluto said:
Are there any PC users having any problems?

But.. it failed in IE 7 on Windows XP for me also.. see above. :wink:


Haha. "See above", as in the explorer's title bar! I'm confused though as I'm seeing "Windows XP" and an Apple logo in the same window.

I just tried this on another PC laptop and it appears to work fine there. I'll also try my AMD computer if I can get it connected to the net(Or wait... I could just put it on a USB flashdrive.).

And yeah, I was thinking about adding that "This <specific entry> is empty" popup, but I need to learn how to cause pop-ups. :shock: (And, to the feature list it goes!) By the way, michaelprologue, how's the accuracy? I was starting to have doubts about the "pedaling power" box since apparently my peak-pedaling-output power is at what Louis Armstrong(sp?) continuously puts out on the tour-de-france. :shock:(400-500 watts) But I've been bicycling for some time, I guess. :lol:
 
swbluto said:
Haha. "See above", as in the explorer's title bar! I'm confused though as I'm seeing "Windows XP" and an Apple logo in the same window.

Windows run natively on Macs with virtualization. I'm honestly not sure why I'm unable to view your applet as I use/view applets all day every day without issue. Going to drop out of the thread now anyway sorry to waste the bandwidth. The screenshot looks cool. Good luck with your project.
 
It seems to be pretty accurate. I just did a guesstimation on my wheel diameter with tire and it was a bit slow than my real-world test. But then I realized I was using the 'rated' voltage on my battery pack and upped it to what it really runs at and it came out pretty darn close. As for the pedal power box, I didn't use it - since I'm using a stand-up scooter with a 5303 on it..... no pedals.... :)

Soon I'll be able to test it on an Ezee that I'll be mounting on a Schwinn Spoiler chopper bike, but I've got the 20" model motor on a 24 inch rim, so I'm guessing it wont be perfect. Using the 26" model Ezee motor it says that I'll get around 24mph, so I'm thinking it will be a bit faster in reality. I should have it built sometime next week so I'll be able to compare it with what the Cycle Analyst says.
 
Not working in Google Chrome... downloaded latest java, too. :(

Edit: no workee in WinXP IE6... :(
 
TylerDurden said:
Not working in Google Chrome... downloaded latest java, too. :(

That really sucks. Usually programming has a lot of last-minute "gotchas" but ensuring compatibility between multiple machine configurations is hard when I don't have multiple different machines to test it on. Unfortunately, this problem seems more widespread than I hoped. I'll look into creating a stand-alone application and that might be completed in a day or two(depending on several unknowns. Biggest one is that I haven't done one yet. :wink:).

Edit: I just read that Google Chrome hasn't yet got a JVM for its browser with Sun's current release. It appears I had to download a one "newer" than the one Sun currently has to offer to make it work which I found via a missing plugin notice on the applet. After that, it worked.
 
Ok, I now have it in a stand-alone application form. I didn't completely learn GUI stand-alone app programming in the creation process, so exiting requires pressing the file tab and then "exit" as the little red 'x' in the corner does nothing. Explanations for the variables can be found on the original online page, http://www.geocities.com/swbluto4gems/classes/SpeedPrediction.htm.

For now, I'm putting development on hold. I want to develop this in an environment where it can be universally accepted in practice(As opposed to theory like java applets), so I think I'm going to transfer program execution to the server side and just ouput text and graphics using CGI of some sort. Ideally, I would create graphs so that the numbers can be immediately understood(and any possible errors), but it doesn't seem like there's an easy way to do it in java and CGI development with java to interface with apps that could do it seems to require a specialized/expensive server environment, so I think I'm just going to implement this program in another language and add features onto that. It'll take time as I have to learn new languages so don't expect anything new for a couple of weeks. In the mean time, be sure to voice what features/data you want to see! I'm hoping this will eventually develop into something widely useful.
 
Welp, works at my end.

works2.PNG


Off the top of my head:

Would be nice to have mouseovers explaining each variable.

Tire diameter in inches is weird and not very SI compatible. I would very strongly prefer roll out in mm.

The average Canadian man weighs just under 82kg, in the US of A he is ~90Kg and ebikes
stay somewhere between 20-40kg, so the default value of 250Kg total weight is a bit much.

Something that would be absolutely excellent is explanations how to measure each variable,
maybe links to them, or a fairly comprehensive table with approx values for various configs
and stuff. EG stuff like this:
http://bike.terrymorse.com/rolres.html
http://physics.technion.ac.il/~rutman/car/Roll-down%20test.pdf
http://www.recumbents.com/mars/pages/proj/tetz/other/Crr.html
So you wouldn't have to go guessing or digging the internet tubes for nearly every variable. I
know I would love it.

Also an acceleration line would be very nice, not sure how that could work out but it's
something that I feel is missing from other calculators. So for example you could see the stall
speed @ slope for various motor configs.

Having an ebikes.ca style graph output would be very nice, but with 4 tons more info that you
can select to have computed or not. So if you only want to compare say efficiency vs
acceleration or some such then you can have only those two lines plotted, etc. Maybe
something to compare two lines of the user's choice and draw another line from it.
 
All of that's possible. It's just that it's going to require a loooot of work and, subsequently, a lot of "man-hours" to develop. But one step at a time, it can all be eventually developed. The only worry I have is having "too much" information for those that just want a simple, fast calculation or those that can be easily overwhelmed. Maybe simplicity can be maintained using expandable options for advanced users.

I'm curious what you mean by "roll out in mm": Do you mean like circumference or diameter? I'm not really sure what's an SI way for measuring bicycle wheels. Also, an acceleration line: Do you mean like a velocity over time chart? Or an acceleration over time chart?(Your acceleration decreases with time while your velocity increases.) Or an... acceleration over the RPM range chart?
 
Not quite diameter, the distance the wheel travels over one rotation with your weight on the bike, the number you put in a bike computer so it can measure your speed. Although bike computers seem to want it in mm's or cm's, to be SI correct it would have to be formatted like X.XXXm because expressing such distance in thousands of mm's is bad form. But that's splitting hairs.


Not sure how acceleration would be best represented, I was thinking a plot showing instantaneous change in velocity at various RPM/speed.

So if you're climbing a hill with a singlespeed motor running full bore, it may end up looking something like this:
accel.PNG
If you're going slower then the first 0, your vehicle will stall. Any faster and it can accelerate to the second zero. But if you're going faster then the second zero, it will slow down to it. Also, the line is flat despite both 0's being at different Pout.
 
Hmmmm... Are you sure the acceleration curve would behave like that? The point of going a steady velocity is dependent on the balance and neutralization of forces on a given object, and the counteracting force curve is a parabolic curve that increases by a constant factor as a function of slope and mass and the torque curve is a downward sloping line and thus the "thrust" is also a downward sloping line(they're linearly related. Thrust is just some constant multiplied with the torque, or divided by, however you wish to express it). The net force is the thrust minus the "counteracting forces" which is positive up until they intersect which they only intersect once in the positive RPM range. That means that you'll accelerate until getting to that point and going any faster will slow you down to that point and starting off lower will increase to that point. By increasing the slope of the hill, you raise up the countering forces curve by a constant factor which causes the final speed to drop(you can see how the intersection would happen at a less RPM), but you still have that "below this speed, you'll accelerate to that point" and vice versa nature. Where the hill is sufficiently steep is where they stall as counteracting forces curve would rise entirely above the thrust curve, which means you'll start to slow down to a stall at any speed. Now, if you start to pedal or pedal harder... then you also increase the "total thrust" curve which may result in a velocity that goes up the hill.

So I'm not understanding where this curve comes from. According to the physics, going "balls out"(meaning a constant high force) doesn't affect whether or not you'll stall below a certain speed and accelerate when above it. Now... if you're pedaling and adjusting your gears as you slow down, you're increasing the torque you provide which increases the thrust...
 

Attachments

  • untitled.GIF
    untitled.GIF
    7.7 KB · Views: 9,167
Well I'm not sure at all how an acceleration curve would behave, this is one reason why such a line would be nice to have IMO.

On just the right slope, below a certain speed a motor is not putting out enough power (bad eff, etc) so that if I let go the pedals it'll slow to a stop, but going just a few km/h faster it can catch it's breath and go up to a certain speed. Same kinda reason why on steep hills I would have had to pedal furiously to keep the motor close to max Pout, because going too slow I would have burnt myself out by pedalling harder and at too low rpm (SS), and if the bike stalls on a steep hill it's not possible to get it going again without say a driveway or any other few meters of level surface, otherwise would have to walk the rest of the way (but the bike pulls the pedestrian uphill, so it's really not bad).

At least that's what my seat of the pants-o-meter says, and I think the graph I drew represents it fairly well.
 
swbluto if you would like, I can probably clean up and help you refine your application a bit. I am in school for computer programming, and have quite a bit of java experience.

It's up to you. If you would like some help with it, just shoot me a PM.
 
tostino said:
swbluto if you would like, I can probably clean up and help you refine your application a bit. I am in school for computer programming, and have quite a bit of java experience.

It's up to you. If you would like some help with it, just shoot me a PM.

Yeah, no problem. Since halting my contribution to the java development, I was thinking about making this open-source so that others could contribute. But there are concerns about licensing(I have no experience with it but I wouldn't want others to profit off other's work that was intended to be open to the community.) and the work involved in getting everything packaged nicely so that it isn't *too* confusing. Anyways, I'll ready the documents I have(No editing, so just raw thought on ... text documents!) and post them here soon enough.

Edit: Ok, here it is. Since this was my first java applet and application, there are some "garbage files" that were created in the process for ... let's call it testing purposes. Also, the .pdf doesn't contain all revisions I made to the final formulas; the formulas as implemented in the source code should be seen as the "newest versions". The .pdf just contains the original derivations for the formulas that were solved by mathematica's CAS program. The ".nb" file is Mathematica's native notebook file. Also, this applet and application were made in NetBeans, so it makes GUI editing eeeeaaasssy.

Ok, let's hope my programming instructor's insistence of making function and variables names as clear as possible pays off! :lol:


(There are also some formulas that are in the original simplified form that I don't have scanned in my physical notebook. Hopefully any formulas that are needed are self-evident enough as to their function.)
 

Attachments

  • MotorCurrentQuest.zip
    382.8 KB · Views: 122
Mathurin said:
Well I'm not sure at all how an acceleration curve would behave, this is one reason why such a line would be nice to have IMO.

On just the right slope, below a certain speed a motor is not putting out enough power (bad eff, etc) so that if I let go the pedals it'll slow to a stop, but going just a few km/h faster it can catch it's breath and go up to a certain speed. Same kinda reason why on steep hills I would have had to pedal furiously to keep the motor close to max Pout, because going too slow I would have burnt myself out by pedalling harder and at too low rpm (SS), and if the bike stalls on a steep hill it's not possible to get it going again without say a driveway or any other few meters of level surface, otherwise would have to walk the rest of the way (but the bike pulls the pedestrian uphill, so it's really not bad).

At least that's what my seat of the pants-o-meter says, and I think the graph I drew represents it fairly well.

If that behavior is shown for the same motor on the same stretch of hill, then I suspect the low efficiency at lower speeds in increasing the temperature of the motor which increases the motor's resistance, which decreases the current, which decreases the torque and thus the thrust, so then the thrust curve will push itself completely below the "opposing forces curve" and then stalling; Above a certain speed, the temperature doesn't increase as much which means the thrust curve stays above the opposing forces curve in the positive RPM region. In that case, motor temperature as a function of current over time(and environment temperature) would need to be integrated which is a much harder problem, from the mathematical point of view but it is possible if someone had the time and persistence to do it. I think that'd be a nice feature as well, but... that's an insane amount of work as I imagine some of formulas would be implicit and thus numerical estimation techniques would be needed to be used extensively. There's also other variables that need to be tracked like motor's mass and... well, the shape of the motor would also play a vital role and it doesn't seem like that can be too easily generalized in an accurate manner.
 
swbluto said:
tostino said:
swbluto if you would like, I can probably clean up and help you refine your application a bit. I am in school for computer programming, and have quite a bit of java experience.

It's up to you. If you would like some help with it, just shoot me a PM.

Yeah, no problem. Since halting my contribution to the java development, I was thinking about making this open-source so that others could contribute. But there are concerns about licensing(I have no experience with it but I wouldn't want others to profit off other's work that was intended to be open to the community.) and the work involved in getting everything packaged nicely so that it isn't *too* confusing. Anyways, I'll ready the documents I have(No editing, so just raw thought on ... text documents!) and post them here soon enough.

Edit: Ok, here it is. Since this was my first java applet and application, there are some "garbage files" that were created in the process for ... let's call it testing purposes. Also, the .pdf doesn't contain all revisions I made to the final formulas; the formulas as implemented in the source code should be seen as the "newest versions". The .pdf just contains the original derivations for the formulas that were solved by mathematica's CAS program. The ".nb" file is Mathematica's native notebook file. Also, this applet and application were made in NetBeans, so it makes GUI editing eeeeaaasssy.

Ok, let's hope my programming instructor's insistence of making function and variables names as clear as possible pays off! :lol:


(There are also some formulas that are in the original simplified form that I don't have scanned in my physical notebook. Hopefully any formulas that are needed are self-evident enough as to their function.)
I'll take a look at it now! I'll make a post when I get a little further along.
 
Oh my, okay I am going to be cleaning up and re-naming most of the vars to start out, they all mostly have the default names given by netbeans (so confusing!!!).
 
tostino said:
Oh my, okay I am going to be cleaning up and re-naming most of the vars to start out, they all mostly have the default names given by netbeans (so confusing!!!).


Are you talking about the "jTextFieldx" type of convention? Hehe. Yeah, those could be made clearer but it seemed easy enough just finding out what text field belonged to which variable by switching between the "design" and "source", and then use the magic of copy and pasting and editing the appropriate number. By the way, there's one monstrously long function in the applet's source code that netbeans warns not to edit. It just seems to be the main layout code and event handling.

Anyways, SpeedPrediction.java is the main applet whereas motor.java contains the simulation's main source code. "AppMain" and "MyFrame" belongs to the stand-alone application, and everything else is pretty much garbage.
 
Back
Top