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

swbluto said:
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.
Yeah, I got all that. I am re-designing the applet as an application, which will make things like the "x" in the top corner work. Time to pretty it up a little too ;)
 
Good swbluto
Haven't tried your app yet. Only noticed the factor for air density... Not sure what to put in there! But if it is a combo of height above sea level, temp and humidity, these might be easier values for ppl to find/know and input?
Cheers
Lock
 
Lock said:
Good swbluto
Haven't tried your app yet. Only noticed the factor for air density... Not sure what to put in there! But if it is a combo of height above sea level, temp and humidity, these might be easier values for ppl to find/know and input?
Cheers
Lock
That's a good point, i'll figure out how to calculate air density from those values, and change the app around.
 
tostino said:
Lock said:
Good swbluto
Haven't tried your app yet. Only noticed the factor for air density... Not sure what to put in there! But if it is a combo of height above sea level, temp and humidity, these might be easier values for ppl to find/know and input?
Cheers
Lock
That's a good point, i'll figure out how to calculate air density from those values, and change the app around.

http://www.kreuzotter.de/english/espeed.htm - Towards the middle of the page, they have the formula for air pressure based on altitude, temperature, etc.; That can be put in there to solve for air pressure that the function currently uses. I was planning on it but I've lost my enthusiasm for java development since it seems there's applet compatibility issues as, well, I thought people would be comfortable with some kind of convenient "online" form instead of a program you have to download. So I'm now investing my time planning and development of an online CGI/perl/whatever-else interface but I may just use the webFx library that ebikes.ca uses as that helps to minimize bandwidth(although is bandwidth really a problem with <20kb images for each simulation?) for multiple simulations.
 
The number for the last conversion function from KPH to MPS(meters per second) should be 0.277777778 instead of what it is. As far as I can remember, this would only affect wind speed's input into the formula for metric system calculations.
 
swbluto said:
The number for the last conversion function from KPH to MPS(meters per second) should be 0.277777778 instead of what it is. As far as I can remember, this would only affect wind speed's input into the formula for metric system calculations.
Good catch, it's fixed in my code.
 
Hrmm, I feel really dumb for asking this, but i'll go ahead anyways :p.

How can I calculate motor resistance? Using ohms law, my motor (at full no load speed) would have a resistance of 13.679 ohms, but if I plug that into the ebike calc, my bike won't move at all.
 
No problem. I had that exact same question when coming up with the program and it took many hours for me to solve(All in all, the "leg work" of all this research took about 20 pure hours(spread over 4 days), so there's a lot to understand about it when you're not already familiarized with it. I know I wasn't! :lol: )

One way is to get a really precise ohm-meter.

Another way is to measure the output voltage and current from the controller-to-the-motor in the "not controller limited" region and do an estimation based on that(R=V/I). Basically, for most controllers, the "not controller limited" region is speeds near the "no-load speed". Or you might estimate directly if you have a really high amp limit on the controller or you don't have to have a controller between the voltage source and the motor.(I'm not too sure how easily this would be measured in multi-phased motors, like brushless motors.). But the problem with measuring the voltage and current from the battery is the controller and battery introduces resistances and a voltage drop in the diode, and the total effect of that is going to be much higher than your motor's actual resistance. You might be able to account for that, somehow, but I'm too lazy to think of it. I'm sure there are other technical ways to directly measure a motor's internal resistance, but I'm not that knowledgeable. Here's apparently one attempt at the RC forums, but it looks complex. And expensive. But you might extract some useful theory you could adapt to your situation.


Another way is to consult the manufacturer's data sheet. Most motor manufacturers provide this as its one of the well-known constants of performance, but this can be harder to obtain if you can't find the manufacturer and the retailer doesn't supply this information. Reading through the thread linked above, it appears there's already databases on Motor values(like Rm), one belonging to "Motocalc" which I'm guessing is a program. But it's probably mostly RC motors considering the forum(But that's OK to me!).

And there's the way I did it to derive it from ebikes.ca's chart: R_motor = (30/pi)*(V_oc)^2/(t_o*w_f) where t_0 is the torque at 0 rpm(in newton-meters) and w_f is the highest rpm the motor obtains under no other resistances besides the motor's. This can all be obtained by using "custom values" and setting controller and battery resistance to 0 and making the controller amp limit REALLY high so that there isn't a controller-limited region(I.E., you'll see a straight torque line). This equation makes sense because t*w = P and P=v^2/R, thus R=v^2/P=v^2/(t*w). The (30/pi) constant is just a conversion factor for the RPM units. This can be translated into practice, after accounting for resistive losses and the such.

And, just so this information is consolidated in one post for others who might be reading, K is another motor constant being the open-circuit voltage divided by the no-load rpm. Since "Kv" is the no-load rpm divided by the open-circuit voltage, K = 1/(Kv).
 
tostino said:
How can I calculate motor resistance? Using ohms law, my motor (at full no load speed) would have a resistance of 13.679 ohms, but if I plug that into the ebike calc, my bike won't move at all.
Your measure seems high to me, consider a 5303 is ~0.11 ohms winding resistance, USPD can motors ~0.067 ohms. I recall someone on this forum had made an cheap/easy to make adaptor for a multimeter to measure very low ohms.
 
Mathurin said:
tostino said:
How can I calculate motor resistance? Using ohms law, my motor (at full no load speed) would have a resistance of 13.679 ohms, but if I plug that into the ebike calc, my bike won't move at all.
Your measure seems high to me, consider a 5303 is ~0.11 ohms winding resistance, USPD can motors ~0.067 ohms. I recall someone on this forum had made an cheap/easy to make adaptor for a multimeter to measure very low ohms.
Well I wasn't taking a measurement from my motor, I just know that when my batteries are charged fully, they are 29 volts, and at WOT with no load my motor pulls 2.12 amps.
R=E/I (resistance = 29v/2.12a)
 
Well here is the progress i've made so far. I still need to get in error checking, and quite a few other things, but take a look none the less.
 

Attachments

  • program.rar
    10.3 KB · Views: 135
Wow, that looks pretty nice.

I'm curious, what IDE and/or editor are you using?

Also, I think the gear ratio should include an explanation of what it means. And, also the battery. I noticed that the "Open circuit voltage" of ping's batteries are typically 51-52 volts even though the operating voltage is usually 48 volts, so that might be clarified as the formula is based on the "open circuit voltage".

Anyways, I'll come up with the formulas that both of us could use for the java and online application.

rho = (1.293*273.15/(Temperature+273.15))*Math.pow(2.71828183,-1.293*9.8*Altitude/101325); //where temperature is in C, and altitude is in meters. A conversion function might be written from F to C and "ft." to meters for imperial users.

I think kreuzotter meant 273.15 instead of 373, as 273.15 is the Kelvin temperature at sea level and you'd basically get P_sea_level != P_sea_level if you plugged in 0 for altitude and 0 degrees celsius, in Kelvin(273.15), so it's obvious the kelvin temperature for 0 degrees Celsius was meant as the numerator.



There was another one I was thinking of.... hmmmm....

Edit: Oh yes, that's right. A revamped formula for the grade portion of the power_needed function. The problem with the current one is that it's based on small-angle approximation which means it's pretty accurate for small angles(upwards to 20% slope) but it becomes increasingly inaccurate past that. So I'll find...errmm... I mean formulate a better one. ;)

A quick one of the top of my head is... sin(arctan(grade/100)) if grade means "this many units up for every 100 units forward". If grade actually means that 100% means 90 degrees(straight up), then sin(grade/100) would replace grade/100. (I guess I need to investigate the "standard" definitions.)

I'm also curious, how easy is the application able to port to an applet? If you wouldn't mind. Of course, you'll be in the credits. :D
 
swbluto said:
Wow, that looks pretty nice.

I'm curious, what IDE and/or editor are you using?

Also, I think the gear ratio should include an explanation of what it means. And, also the battery. I noticed that the "Open circuit voltage" of ping's batteries are typically 51-52 volts even though the operating voltage is usually 48 volts, so that might be clarified as the formula is based on the "open circuit voltage".

Anyways, I'll come up with the formulas that both of us could use for the java and online application.

rho = (1.293*273.15/(Temperature+273.15))*Math.pow(2.71828183,-1.293*9.8*Altitude/101325); //where temperature is in C, and altitude is in meters. A conversion function might be written from F to C and "ft." to meters for imperial users.

I think kreuzotter meant 273.15 instead of 373, as 273.15 is the Kelvin temperature at sea level and you'd basically get P_sea_level != P_sea_level if you plugged in 0 for altitude and 0 degrees celsius, in Kelvin(273.15), so it's obvious the kelvin temperature for 0 degrees Celsius was meant as the numerator.



There was another one I was thinking of.... hmmmm....

Edit: Oh yes, that's right. A revamped formula for the grade portion of the power_needed function. The problem with the current one is that it's based on small-angle approximation which means it's pretty accurate for small angles(upwards to 20% slope) but it becomes increasingly inaccurate past that. So I'll find...errmm... I mean formulate a better one. ;)

A quick one of the top of my head is... sin(arctan(grade/100)) if grade means "this many units up for every 100 units forward". If grade actually means that 100% means 90 degrees(straight up), then sin(grade/100) would replace grade/100. (I guess I need to investigate the "standard" definitions.)

I'm also curious, how easy is the application able to port to an applet? If you wouldn't mind. Of course, you'll be in the credits. :D
I used to use only Eclipse, but the GUI editor for NetBeans is just too powerful to ignore for GUI based programs.

Okay, I will give a more detailed description for the gear ratio.

Umm, I think I am going to set this up an SVN, so we can both (and anyone else who wants to) can work on it, and submit our changes in real time.

Oh, open circuit voltage is different than nominal how? Could you explain that to me?

And porting an application to an applet is very easy, don't even worry about it, as soon as we get it closer to a final release state, I will be sure to do that.
 
Oh, that's cool. I'm not sure what SVN is, really, so I'll be looking it up. :D

And "nominal voltage" is potentially different than "open-circuit voltage" because most vendors like to advertise batteries as a multiple of 12V - I.e., 48V. However, the "open circuit" voltage of a half-depleted "48V" ping LiFePO4 battery is typically 51-52 volts, 3 to 4 volts above the nominal voltage; the ~48V the controller sees is usually due to the voltage drop in the battery due to its internal resistance, and the equations include this internal resistance in its calculations. This may not be as true for other chemistries, though, like Lead acid or NiMH. I think the open-circuit voltage of my 12V lead acid batteries was about 12.5-12.7 volts, which is still .5-.7volts above the nominal voltage per 12 nominal volts. This detail seems to make a difference between ~.7-4 miles per hour in the final calculation.
 
swbluto said:
Oh, that's cool. I'm not sure what SVN is, really, so I'll be looking it up. :D

And "nominal voltage" is potentially different than "open-circuit voltage" because most vendors like to advertise batteries as a multiple of 12V - I.e., 48V. However, the "open circuit" voltage of a half-depleted "48V" ping LiFePO4 battery is typically 51-52 volts, 3 to 4 volts above the nominal voltage; the ~48V the controller sees is usually due to the voltage drop in the battery due to its internal resistance, and the equations include this internal resistance in its calculations. This may not be as true for other chemistries, though, like Lead acid or NiMH. I think the open-circuit voltage of my 12V lead acid batteries was about 12.5-12.7 volts, which is still .5-.7volts above the nominal voltage per 12 nominal volts. This detail seems to make a difference between ~.7-4 miles per hour in the final calculation.
Ahh thanks for the explanation. I realized that the actual voltage of many lithium packs are not equivalent to their nickle and led brothers, however I thought nominal voltage was the average voltage that the pack will see (not what they are saying the pack voltage is).
Like my Milwaukee V28 batteries have 7 cells in series, each cells nominal voltage is 3.79v. That is 26.53v nominal, even if they claim 28v.

Anyways, SVN is a way for a group to work together on a project and be able to keep their code up to date with what everyone else is doing without any issue. I sent an invite to your yahoo email, once you sign up I can show you how to use it.

The link to our trac is: http://trac2.assembla.com/EBikeCalc
and the link to the SVN is: http://svn2.assembla.com/svn/EBikeCalc
 
You need to install the netbeans svn plugin thingy which can be found from this link: http://d01.megashares.com/?d01=fa3c4ac

After it's installed, you go into netbeans, and click on "versioning", and then go down to SVN and click "Check out"
Once in that, you will need to enter the SVN address, and your user name and password you created on that site.

After that, it should download the project onto your hard drive and you will be able to keep up to date.
 
tostino said:
Basic error checking is in (extremely basic).

Gotcha. Just something that generally indicates that a value might either be missing or invalid is good enough(and easy enough). :)

By the way, I'll replace the air pressure box with temperature and alititude boxes and add on some additional output, like power, efficiency, battery current and whatever else might delight my fancy. Also, I'll add unit-based labels to the right of the boxes so users know what units are being requested, eventually.
 
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?
 
swbluto said:
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.
 
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? :lol: ).

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). :shock:
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.
 
swbluto said:
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? :lol: ).

:mrgreen:

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.
 
Back
Top