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

[swbluto]

I now have subversion on NetBeans but how do I upload the source code and add a "comment"(Like say "I changed this and that and blah blah")?

Also, how did you get the labels so perfectly aligned? I created new labels for temperature and altitude but they seemed to refuse to align with the other environmental labels. And, I was also wondering, is it possible to put a "new line" in a tool-tip, so the tool-tip could become something like a paragraph or multiple paragraphs?

[tostino]

I now have subversion on NetBeans but how do I upload the source code and add a "comment"(Like say "I changed this and that and blah blah")?

Also, how did you get the labels so perfectly aligned? I created new labels for temperature and altitude but they seemed to refuse to align with the other environmental labels. And, I was also wondering, is it possible to put a "new line" in a tool-tip, so the tool-tip could become something like a paragraph or multiple paragraphs?

To upload your changes you need to right click the project, go down to subversion, and click commit. Make sure you are only changing what you intended to. When you hit that it will ask for your comments.

Aligning the labels was a pita, a huge one. Just keep at it, if you can't get it for what ever reason, i'll add it for ya and commit it.

You can use html syntax in tooltips. Take a look at how I did the battery resistance tooltip.

P.S. make sure you update your project regularly with subversion so you can see what others (me lol) are doing to the project.

[tostino]

Awesome, just took a look at your changes, very nice.

[swbluto]

Thanks. Made some new ones, added some more output boxes(Like battery current, efficiency, heat), and I'm in the middle of verifying some of the underlying mathematical models(The efficiency function is a little screwy, so I'm going to have to figure that one out later. Edit: I just observed it, and it seemed to closely correspond to ebikes.ca's output until you get to the no-load speed. Mine heads towards 100% as you approach the no-load speed and then it crashes to negative infinity at the no-load speed(no motor power output, in other words), whereas ebikes.ca's simulator seems to approach optimal efficiency shortly before the no-load speed and then takes a sharp curve downward. I've heard that the closer you are to the no-load speed, the better the efficiency, so maybe my calculation is more accurate? ).

After trying out some test input, it seemed that sufficient high values of "tail wind" started to result in some bizarre answers which cried out for reviewing the underlying mathematical model. Since the power curve is cubic, I decided take a step back to the underlying force curves, which are parabolic(and easier to analyze) and found that the force curve of...

F=C_d*A*(v+v_wind)^2

Had one positive solution for no wind. Check.(That works fine, then)

Had either one positive solution or no solution for high enough headwind. Check.(It slows you down but doesn't stop you OR it's so fast, it stops you and you're probably going backwards.)

For tail wind, it had... going in order of increasing wind velocity, 1 pos. solution(check), 2 pos. solutions(weird as one of which was less than v_wind), 1 positive solution(which was less than v_wind), and then 0 positive solutions for sufficiently high speeds of v_wind. It's clear this whole mathematical model breaks down with high enough tail-wind speeds as there can clearly only be one solution. After thinking about it, it seems the left side of the force parabola needs to be inverted as you're not "needing force" from air-resistance at that point, but rather, it's providing force. So, in essence, the force curve of "air resistance" is a piece-wise function with two pieces:

F = -C_d*A*(v+v_wind)^2 for v<v_wind
F = C_d*A*(v+v_wind)^2 for v>v_wind

(And this assumes this represents the "force needed" axes for the wind, whereas the motor follows the "force provided" axis which is an inverted "force needed" axis. For "true physics", you'd reverse the above equations and just add the forces up to derive the net force. Where the net force = 0, that's your final speed.)

Now, to find the accurate solution for high enough headwind speeds... I need to know the force curve when the motor is past the no-load speed(The region of regen, I think).
Anyways, I think I'll convert the formulas to "true physics" representation so that there's a much greater range of accurate answers. I still don't want to think about going backwards, though, as I have a feeling that'd be something I'd have to write a thesis on AND it seems to be of limited practical value.

[Miles]

Mine heads towards 100% as you approach the no-load speed and then it crashes to negative infinity at the no-load speed(no motor power output, in other words), whereas ebikes.ca's simulator seems to approach optimal efficiency shortly before the no-load speed and then takes a sharp curve downward. I've heard that the closer you are to the no-load speed, the better the efficiency, so maybe my calculation is more accurate? ).

Seems like it's not factoring in the no load torque? The curve should start to turn down at around 10% of no load speed, for BLDC motors.

[swbluto]

Mine heads towards 100% as you approach the no-load speed and then it crashes to negative infinity at the no-load speed(no motor power output, in other words), whereas ebikes.ca's simulator seems to approach optimal efficiency shortly before the no-load speed and then takes a sharp curve downward. I've heard that the closer you are to the no-load speed, the better the efficiency, so maybe my calculation is more accurate? ).

Seems like it's not factoring in the no load torque? The curve should start to turn down at around 10% of no load speed, for BLDC motors.

I was going to take a closer look at that. It doesn't directly do the Torque = I*k - (windage_torque and other counteracting torque which ebikes.ca does a second order approximation on) calculation, but it's a direct mathematical recreation of the CA's simulator torque curve when the only resistance present is in the motor and there is effectively no battery-current limit. So assuming *that* torque curve factored in the windage torque(and what not) already, it seems like further calculations based on that should remain equally replicated. But it doesn't(Just fairly accurately so for most parameters over the normal operating range)...

Custom values don't even account for the windage torque and motor cogging, though, which can be important(The effect is usually negligible, until you start calculating efficiency near the no-load speed.). The problem mainly is that it requires "special tools" to directly measure, which most potential users don't have, and manufacturers/retailers don't be seem to be keen about giving this data. Maybe this can be inferred from the "no load current" that's sometimes given by retailers/manufacturers? Are there any known "motor cogging and windage torque" relationships or rules-of-thumb that'd make it simple to estimate?

Eh. It just seems like this data can't be too easily found by a normal user(Including me, rofl).

[swbluto]

Hey, Tostino, how do you add scrollbars to the existing panel(Just for those who have their resolution too small)? I tried adding the existing panel to a scroll-bar panel but that messed up the underlying code somehow(and entirely messed up the layout): I didn't upload it, so I just re-downloaded the previous revision and now I'm back at square 1.

[michaelplogue]

Not to bust in on the programing conversation here, but I have a question.
Would it be possible to include chain drive motors plus a front & rear sprocket field so those of us working with non-hub motors could use this great tool? I would think that you would be able to use the same system for both types of motors. You would just put a 1 in both the front and rear sprocket field if you were calculating for a hub motor. You could then also include pre-set data for the most common motors like Etek-r and RT, Perp PMG-130, Lemco's three motors, Some of the D&D and even some of the RC motors that folks are using now.

Just a though.....

.

[swbluto]

Not to bust in on the programing conversation here, but I have a question.
Would it be possible to include chain drive motors plus a front & rear sprocket field so those of us working with non-hub motors could use this great tool? I would think that you would be able to use the same system for both types of motors. You would just put a 1 in both the front and rear sprocket field if you were calculating for a hub motor. You could then also include pre-set data for the most common motors like Etek-r and RT, Perp PMG-130, Lemco's three motors, Some of the D&D and even some of the RC motors that folks are using now.

Just a though.....

.

Hehe. It already does via the "gear ratio"(I think that's only in the unreleased version, though, which I don't think I've uploaded.), but if it's not apparent enough, I didn't do a good-enough job - So, changing it so that you enter in the front and rear sprocket value(or whatever else) sounds like a perfectly able and really easy thing to do and it'd make it a lot clearer which makes it far easier to use. So, no problem, I'll add that(I was thinking about the "easiest"/best way of asking for the gear ratio and that sounds like one of the easiest.).

Do you know if there's a database of popular motors and their values, though? I could go hunting down these values to add the motors to the list(or create a new list), but I don't really know what the "popular motors" are and I'm sure there are hundreds of different types of suitable motors out there.

[michaelplogue]

Here's a few of the larger motors that to get started with. I honestly couldn't say which of the RC motors are common.

Perm PMG-132
resistance: 0.025 Ohms
50.2 rpm per volt

Perm PMG-080
resistance: 10 milli-ohms
285 rpm per volt


Etek-R
resistance: .033 ohms
72 rpm per volt

Etek-RT
resistance: UNK (might be .033 ohms, but can't find any reference yet)
51.4 rpm per volt


MARS BRUSHLESS (PMAC Motor)
resistance: 10 milli-ohms
70 rpm per volt


Magmotor S28-400
resistance: .042 Ohm
204 rpm per volt

[tostino]

I think I have a solution to the motor stats issue. Lets not hard code them into the program, but instead have it read an external file for motor name, winding resistance, and k. That way users can keep the program up to date with commonly used motors even if this program does end up un-supported in the future.

Umm I will look into adding a scroll bar to the program, and will post up some instructions when I find out how to do it properly.

Also on a side note, I think there is an issue with the efficency calculation when adding in pedal power. It seems pretty accurate without it in the equation, but with it, everything seems to go out of wack.

[swbluto]

Ok, I'll see what I can add.

Anyways, I'm now adding wh/(distance) consumption and range boxes that'll be contingent on battery capacity(provided by user). This will be the TOTAL WH/mi., which includes the energy used by the battery due to internal resistance.

[swbluto]

I think I have a solution to the motor stats issue. Lets not hard code them into the program, but instead have it read an external file for motor name, winding resistance, and k. That way users can keep the program up to date with commonly used motors even if this program does end up un-supported in the future.

That sounds fine(Sounds a bit neater as well). I think adding another column to the array(or whatever data structure) to indicate "hub motor" would be helpful for cluing in the program that it's hub motor or something else. How would the file be read in applet form, though? I thought applets couldn't... like... obtain an ordinary server's resources unless it was hosted on a server environment that allowed it(I think I may just eventually host it on a specialized host, with TomCat(or whatever), anyways just so adding the GnuPlot graphing back-end will be an easy port.).

Anyways, I'll check out the efficiency formula in greater depth. I thought it seemed pretty accurate with the latest revision, but I'll check that specific concern later after coding in the range, wh/mi consumption, and sprocket's code.

[swbluto]

Also on a side note, I think there is an issue with the efficency calculation when adding in pedal power. It seems pretty accurate without it in the equation, but with it, everything seems to go out of wack.

I just checked out some sample input and it seems to "operate as planned". Can you provide more exact symptoms? Possibly a screen-shot and/or a few pertinent numbers that are thought to be out of whack.

(The problem is is that it doesn't take into account windage torque or cogging torque and so its efficiency doesn't drop dramatically near the no-load speed like ebikes.ca's, so the current algorithm just assumes the RPM at 85% of the no-load RPM is where the peak efficiency is located which may be off by 7% or so from the true peak efficiency. Between 85% of the no-load RPM and the no-load RPM, it does a linear extrapolation towards 0 efficiency at the no-load RPM. To get the windage and cogging torque would require motor-specific knowledge, that doesn't appear easy to get without specific measuring tools, or some semi-accurate "guesstimate" which I don't have enough knowledge to guess on.)

[tostino]

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?

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