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

[tostino]

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.

[tostino]

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.

[swbluto]

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! )

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).

[Mathurin]

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.

[tostino]

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)

[tostino]

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.

[tostino]

Next on my list is error checking.

After that, I want to have it calculate range based on battery size, speed, wind resistance, etc.

[swbluto]

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.

[tostino]

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.

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.

[swbluto]

Oh, that's cool. I'm not sure what SVN is, really, so I'll be looking it up.

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.

[tostino]

Oh, that's cool. I'm not sure what SVN is, really, so I'll be looking it up.

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

[swbluto]

Ok, I'm there. Now what? I've noticed there's a subversion form of NetBeans.

[tostino]

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]

Basic error checking is in (extremely basic).

[swbluto]

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.

[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