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

[swbluto]

Hrmm. I am not liking the front/rear sprocket to calculate gear ratio at the moment. My motor runs through a jackshaft, than down to the bottom bracket, and through the 21 gears. I am thinking about doing something like I did to calculate "K" down below for the front and rear sprocket to get the gear ratio.

Any objections?

Weeeeeelll, this program was hoping to be designed to accommodate the greatest range of users as possible without too much clutter for the greatest range of users, so I was thinking there could be an educational link about calculating the "front and back" sprocket value for different arrangements to conform(I don't personally like that idea, though, as it doesn't make it easy enough for everyone) or, possibly, instead of creating special calculating boxes for every possible unique configuration which would be many, I'm guessing(I've seen a few!), perhaps a combo-box that allows the user to choose their particular configuration and then the appropriate boxes appears dependent on the selection? This would help keep down the clutter while retaining versatility.

In that spirit, what do you think about using radio boxes to allow people to choose to use K or Kv for the current K box? I think it'd help increase the amount of screen-space available which has becoming rare as of late.

[swbluto]

I think I should incorporate armature temperature as part of Miles' suggestion. This link has an excellent explanation, but is it really linear? The explanation "This means if the temperature increases 1°C the resistance will increase 0.393%." would suggest R_f=R_o*(1.00393)^(change_in_temperature).

Program development update: units added to the right of the boxes to easily indicate the units being requested. I can't update it now since my laptop can't connect to the internet in my current location(Won't be able to upload it until around 5-6 hours from now).

[Mathurin]

Kreuzotter gives funky results when you go near absolute zero:

kreuzotter fuckup.PNG (30.19 KiB) Viewed 1756 times

[swbluto]

Okay, here's a preview! it's a stand-alone application and you also need the Java Runtime Environment installed for your system to make it work. It's not completely organized and some tooltips need to be updated, but the barebone functionality seems to work great so far. I just haven't fixed the "too high of a tail-wind" problem which can cause inaccurate answers and it's likely to give wrong answers if you go too much faster than the "no load speed" since I doubt it accurately captures the motor's back-current too-far into the regen region and the corresponding power. You'll know you're in the no-load region if the efficiency says "0" percent. Anyways, the variables explanations can be found on the first page I linked to in the original post.

Edit: It appears you can't upload .jar files; I'll post as a file link later.

OK, here it is. And, yes, this is also vulnerable to the temperature ~= absolute zero attempts. I *might* add in more advanced error-checking later, but I trust those worthy of using this program in its current state should be able to operate it fine(Given the caveats above).

[swbluto]

Ok, I found out why it doesn't work on macs. It's because macs are stuck back in JDK 1.5(it's latest one currently available for the mac, officially.) which doesn't include the swing library. To download the program with the needed libraries, I've packaged it away in this zip file and it just needs to be extracted so that the folder structure is preserved.

Edit: I've deleted it since it apparently doesn't work.

[voicecoils]

Ok, I found out why it doesn't work on macs. It's because macs are stuck back in JDK 1.5(it's latest one currently available for the mac, officially.) which doesn't include the swing library. To download the program with the needed libraries, I've packaged it away in this zip file and it just needs to be extracted so that the folder structure is preserved.

Still no luck, error message is:

Code: Select all

===== Wednesday, 22 October 2008 9:11:45 PM Australia/Sydney =====
Exception in thread "main" java.lang.NoClassDefFoundError: javax/swing/GroupLayout$Group

Running OS X 10.4.11, supposedly Java 1.5 should be all ready to go, I'm not sure how to check this however...

[swbluto]

Hmmmm. Well, the only other possible action that I think I could take to correct this problem is to convert the whole program to java 1.5 technology. While that wouldn't have problems with the program's "core", that would require a lot of effort to revert as the whole program was built around Java 6 technology with Apple being the only major system that doesn't seem to support it. Until I get my hands on a mac so I can do 1-on-1 testing(Which probably won't happen), I'll have to delay my efforts to get it working on mac-based systems for now. Sorry macsters!

Edit: I think I found the solution. I'll have to implement it later and see what happens(I probably won't have access to a mac until tomorrow, if then.). In the middle of the exhaustive conversion, I'll try to ensure there's scroll bars built into the pane and... I might abandon swing technology altogether(for applet interoperability, although I may be wrong about swing library's incompatibility with applets.) which will get rid of that "Native look and feel", but that's not entirely a goal of mine anyways: The current version doesn't seem to have Window's "look" . Anyways, I'm not expecting anything substantial to change for at least a week.

[swbluto]

Before I proceed with mac-conversion, could I have a mac user test out the following file? I want to make sure it's right before investing a ton of time. The folder structure must be preserved for it to work correctly, that is if it were to work correctly.

[voicecoils]

Before I proceed with mac-conversion, could I have a mac user test out the following file? I want to make sure it's right before investing a ton of time. The folder structure must be preserved for it to work correctly, that is if it were to work correctly.

This is what I am seeing:

[swbluto]

That's good. Does one of the buttons serve as an "exit" button? They all seem the same color.

[voicecoils]

That's good. Does one of the buttons serve as an "exit" button? They all seem the same color.

(from left to right) exit, minimse, maximise. They highlight when you mouse over them. They all work w/ your window as well

[swbluto]

That's awesome!

Anyway, here's the skeletal structure of the program with scroll bars and menu items. If someone on a mac could test it out and could PC testers test out the scroll-bar, that'd be great! Once I get an OK on this, I'll add the code that'll make the menu items work and the labels more realistic(And everything else). That could take anywhere from a day to a week.

[voicecoils]

That's awesome!

Anyway, here's the skeletal structure of the program with scroll bars and menu items. If someone on a mac could test it out and could PC testers test out the scroll-bar, that'd be great! Once I get an OK on this, I'll add the code that'll make the menu items work and the labels more realistic(And everything else). That could take anywhere from a day to a week.

mac_sample_test.jpg (61.33 KiB) Viewed 1645 times

Lookin' good
Drop down menu works, seems fine. So do top and bottom scroll bars.

[swbluto]

Awesome! I just got done with the duplication and the only thing that now needs to be duplicated is the tool-tips. I might start adding those sometime in the near future.

Anyways, currently planned features include design/parameter optimization and graphing capabilities. I suspect I might get design/parameter optimization done within 4-7 days and the graphing part done in 2 weeks to a month(I need to learn how to use the graphing engine! ). Design/parameter optimization basically is... "I want to optimize this "green box" feature varying *this* parameter". For example, you might want to know how to get the top speed with the right gear-ratio and you can tell it to automatically find it. Or you might want the top-efficiency varying the gear ratio. Or really anything. More complicated versions of design optimization might be the varying of multiple parameters or wanting to optimize multiple "green box" predictions or adding constraints(Like, say, efficiency must be above a certain percentage). By the way, I still need to include the no-load-current so the efficiency can be accurately calculated.

And, for all those who use netbeans, the "align" option makes alignment SO much easier if you know how to use it. I just learned how to and it's amazing.

[swbluto]

Newest update:

A Kv option was added on and so is the no-load current! Now efficiency and heat generation can be calculated accurately!

This thing is being made so that now any single PM-motor powered vehicle can be accurately calculated! The only thing that now needs to be calculated is the hub motors. Does anyone happen to know where the no-load currents can be found on those?

Anyways, the calculations for efficiency were based on www.aveox.com/dc.aspx, an electric motor manufacturer.

Also, I'm planning on reverting back to the original gear ratio box and offer a versatile gear-ratio calculator based on the set-up chosen.

[michaelplogue]

I just tried the latest version you posted(EbikeCalc2.jar) - it won't work on my XP system now [error:Java Virtual Machine Launcher "Could not find the main class"].

I just checked, and the earlier version still works on this computer.

[Mathurin]

Still sorta works at my end:

stuff.PNG

(36.68 KiB) Downloaded 2484 times

[swbluto]

That's a quirk of the program. If you're past 80% of the no-load RPM using one of the preloaded hub motors, it draws a line from the efficiency at 80% to an assumed 0 percent efficiency at the no-load RPM and then guesses based on that. To correct that quirk, I'd have to know the no-load currents of the various hub motors(You see that the program currently assumes a no-load current of 0 amps for the hub motors which is, well, clearly wrong.).

Also, 26.3 cm is pretty small for a wheel diameter...

Anyways, I'll look into that "main class" problem. It might be a problem with how I set the program up(It probably is). Edit: I did some testing and it appears it comes up with that error if you don't preserve the folder structure inside the zip-folder(i.e., the "lib" folder is in the same folder as the EbikeCalc2.jar file, and the "lib" folder has the "swing layout" file. The zip file must be extracted/unzipped.). I think I may just create an installer for future releases just so this set-up problem doesn't occur.

[swbluto]

I've found a fatal flaw with the program. If the throttle is less than 100%, it won't do predictions accurately. The further away it is from 100%, the more inaccurate it is. Just a heads up.

I'm in the process of correcting the problem and expect to have a release in 2 days(November 5th). Stay tuned folks! I think some will like it.

[swbluto]

Here's what I have so far. The link to the .zip is below and the self-extracting .exe(which avoids possible set-up problems) can be found here. I've found out macs can't use .exe files(or can they?), so the zip file below is provided for those that have systems that won't work with .exe(or whatever platform winrar didn't target).

The graphing feature is in its early stages. Each variable has its own axis so if you want to know its value, look at the corresponding axis. The different force curves nor current curves are aligned, so don't assume that where they intersect on the graph is the true intersection so make sure to look at the axis. I'll try to get those aligned, but from my power curve attempt, it doesn't seem like I've mastered it yet. Also, the efficiency curve and power curve must be shown since... well... I'm still learning how to make everything optional. Also, the efficiency and heat generation curves aren't accurate near the no-load speed for the hub-motors but they are(or should be) accurate for everything else that has a no-load current. If you happen to know the K, Rm and Io for any of the hub motors, feel free to customize and make sure to tell me what it is so others can benefit!

Also, the optimization feature requires every parameter to be filled in, even for the parameter being varied('cuz I'm too lazy to make it work without it. Just enter any number in the boxes at the top and it should work.). The optimization works by dividing the range of values you request it to test into many different sample points, samples them, and then finds the maximum(or minimum) result of whatever you're wanting to optimize(say speed or efficiency.) and reports back in the message box. The "steps" box basically asks how many different samples you want to test: The more steps, the more resolution/greater-accuracy it'll have but it'll also take longer. My computer starts bogging down past 1000 steps, but it seems some of the newer computers can easily/quickly handle 10,000 steps. It doesn't do any error-checking, so don't be surprised if you may get back negative numbers when requesting the minimum. All I have to say is adjust the min and max so they're "realistic.". You're not likely going to use the throttle at 2% since that's not enough current to overcome the cogging torque, so put the minimum higher than the force it takes to overcome whatever forces you're working against(wind, hills, cogging torque, etc.).

Anyways, report back any features you want! Suggestions for improvements! Bugs! Etc.! I'm making this for the community, so feel free to help improve it.

And, also, a manual/help guide will be eventually developed that describes each variable in detail(including how to determine it). On a side note, "RPM" stands for the motor's RPM in the graph. I should add that...

[michaelplogue]

Very groovy!

How difficult would it be to include a horsepower value?

.

[swbluto]

It shouldn't be difficult.

I've figured how to align the different variables and each variable now has its very own special color and axis, so comparing is made easy! I'm also thinking about undertaking some rigorous algebraic analysis to figure out accurate estimates for the hub motor's specs from ebikes.ca's charts so the efficiency and heat generation can be calculated accurately. So that may get corrected in the next release!(Possibly by tomorrow.)

[Mathurin]

Also, 26.3 cm is pretty small for a wheel diameter...

That's the default value. I still cringe at diameter used for this purpose, would prefer rollout in mm like on bike computers.

Also if you're going to include acceleration, a speed/time at 30m would be a nice touch for urban cyclists.


Edit:
Found a pretty nice calculator online, it's for scooters but is otherwise pretty nice. Very complete instructions, needs a tubful of polish tho.
http://trottelec.ifrance.com/performa.html

[swbluto]

Here's the newest release. The zip file is below and the self-extracting archive that avoids common installation problems can be found here. The zip file is for any system whereas the self-extracting archive is for Windows. The zip file should be unzipped in its entirety so the folder structure is preserved as the program depends on the correct folder structure.

I've added the rudimentary acceleration; Some axes are aligned; Help files have been created with the corresponding menu items; about menu item added; The ability to save input and open input files; and other fixes such as the hub motors. The hub motors aren't perfect but they seem more accurate than before and they still seem to accurately predict my speed.

I'm planning another type of graphing so that you can see your acceleration, speed and distance over time. So if you wanted to see your speed at 30 m, you'd just find where the distance curve is at 30 meters, and you can see your time, velocity and acceleration at 30 meters. This would seem to be a "computationally involved" problem so there's a lot of thinking needed to reduce the total amount of computation(i.e., make it graph quickly), so this might take some time to figure out.

That calculator looks nice but I don't understand French so it seems I can't use it.

A problem with adding the roll-out is that I don't know how to include more than two options along with making the interface "look nice". It'd be possible to use a drop-down menu to select the preferred way of measuring it, but that would seem to uglify and make it look unbalanced.

[swbluto]

OMG! I fixed the hub motors. Now the graphs are >98-99% true to ebike.ca's graphs for at least the 40x series(And the predictions should be equally accurate). It appears the formula for calculating winding resistance from the winding temperature was entered in wrongly, but now it's fixed.

Anyways, I'm going to add the graphing code and then release all these fixes and updates in the next release. Might be some time next week.