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

[pdf]

Thanks for the reply.

I only know a little about motors and power, but do tinker quite a bit with various things. I am working with students with very little practical experience (as much of a paradox as it might seem, such is the current nature of the majority of even engineering students). The "K" value is obvious and I suspect easily available from a manufacturer. A few questions about other parameters:
1) Is measuring the "motor resistance" as simple as putting a meter across the windings? I am working with a group of students writing a proposal to fund the building of an electric vehicle and we don't currently have any motors to test. I know only the very basics of brushless motors, but I understand there are multiple windings and that the motor is made to rotate by cycling the current through the windings, which is timed by sensors in the motor to determine where the rotor and stator are relative to each other. So what resistance is relevant? They are, presumably, in parallel to each other but only one is active at a time so I am assuming the resistance of a single winding is the relevant resistance.
2) Same basic questions about no-load current. Do you simply run the motor through an ampmeter or a clamp meter and check the current through one set of windings? Would this not vary with the voltage applied if the resistance is fixed?
3) Is a manufacturer likely to communicate this information?

A 10% good number for speed and power required are more than sufficient. Actually, that degree of accuracy would be highly unusual with such an easy-to-use simulator in my line of work (chem. eng. reserach) and would be highly welcomed.

The reason for these questions is that we don't have a large budget and don't want to do a lot of costly experimentation with different motors, so the simulator will be a primary tool for limiting motor choices. If motors are rated by the vendor in terms of power, it is probably a highly subjective measurement since one has no idea how the number was determined and if it is max power, continuous, etc. If we could boil the motor parameters down to a small set of quantifiable values like those required by the simulator, we could at least see at what conditions the power ratings are reached and then make a judgement about if a motor from a particular vendor is likely to run continuously at that power or if not, try to judge for how long the motor might stand up to it. We are building a vehicle for a hilly area and while the distance for which the vehicle is being designed is not long, it is a series of hills and not a flat drive. Because our budget is limited we want to make an appropriate choice. In particular, the students seem excited about the offerings by Golden Motor, esp. the heralded "MP"; GM sells motors rated at 1000W at 48V much cheaper than about any other vendor I have seen, but I don't know what that power rating means. As we expect to need on the order of 1500W peak for times on the order of a minute, if that figure is continuous, that is probably fine. If it is peak power or close to it, it will not work. Now I know there is a good deal of positive and negative sentiment on this board with respect to GM, but if we had some objective numbers that quantify the motor design, we could judge for ourselves what to expect. Some of their larger motor designs have some potentially useful characteristics for us so we don't want to eliminate their products out of hand based only on negative PR. However, we do need to be mindful of "due diligence" and do what work we can up front to be sure our selections are likely to be approproiate choices.

Thanks for any help.

[patrickza]

I've also been kept up nights playing with this toy. I find it to be almost exactly spot on with what I find in the real world. Have you plugged in the 5306 data yet, I've been toying with the idea of getting one, but I'm curious to see what the differences would be compared to my 5305.

[justin_le]

I have several questions, if anyone is following this thread. It looks like the no-load current, motor resistance, and "K" value uniquely specify the different motors.

This is more or less true in the case of DC motors or brushless motors where the L/R time constant is small compared to the commutation period, and so for the Crystalyte motors with just 8 or 12 poles it is good enough. But as the commutation period gets closer to this time constant, as we see with the 23 pole NC motors, and especially with the 80 effective pole (16 x 5:1 gear ratio) of the eZee/BMC motors, then the winding inductance has a very large effect. A model that is based only on motor resistance and 'K' will show much higher power and torque values at speed than you would measure in practice. This gets more and more pronounced the higher the RPM that you are simulating at.

You can try and 'hack' the simple model above by increasing the resistance so that the torque/RPM slope better matches what is measured over the RPM range of interest, but then you end up with the model showing a worse efficiency and higher input power than you would measure in practice, even though the output power is close.

Justin

[justin_le]

then the winding inductance has a very large effect. A model that is based only on motor resistance and 'K' will show much higher power and torque values at speed than you would measure in practice. This gets more and more pronounced the higher the RPM that you are simulating at.

To illustrate this point, the graph below shows how you would predict the performance of an eZee motor at 48V/20A if using only the motor constant 'K', the winding resistance, and the no-load current as your motor model:

Predicted eZee motor at 48V, using model that doesn't take winding inductance into account

eZee graph no inductance.gif (22.45 KiB) Viewed 1144 times

Meanwhile, the actual data matches much more closely with the graph below, which has exactly the same parameters for R and Kv but where the effect of motor inductance and commutation events are taken into consideration:

eZee 48V 20A simulator curve with inductance modeling

eZee graph with inductance.gif (22.12 KiB) Viewed 1140 times

Compare the predicted power output at 40 kph, the winding inductance reduces the output watts by more than a factor of 2. But at really low speeds, where the commutation period is significantly longer than the L/R time constant for the motor windings, then the two graphs converge and ultimately show the same stall torque.
-Justin

[swbluto]

then the winding inductance has a very large effect. A model that is based only on motor resistance and 'K' will show much higher power and torque values at speed than you would measure in practice. This gets more and more pronounced the higher the RPM that you are simulating at.

To illustrate this point, the graph below shows how you would predict the performance of an eZee motor at 48V/20A if using only the motor constant 'K', the winding resistance, and the no-load current as your motor model:

eZee graph no inductance.gif

Meanwhile, the actual data matches much more closely with the graph below, which has exactly the same parameters for R and Kv but where the effect of motor inductance and commutation events are taken into consideration:

eZee graph with inductance.gif

Compare the predicted power output at 40 kph, the winding inductance reduces the output watts by more than a factor of 2. But at really low speeds, where the commutation period is significantly longer than the L/R time constant for the motor windings, then the two graphs converge and ultimately show the same stall torque.
-Justin

Thanks for the illustration. I was recently under the impression that the caveat you brought up affected performance in the region of 5-10%, but it certainly seems to be fairly important.

By the way... can you tell me how the "commutation" period is so long at low speeds?

It seems obvious that the phases are activated for longer periods of time at lower RPM, but it also seems that you're encountering PWM at the lower speeds due to current limiting. Is the "commutation period" of the PWM waveform not particularly important (Once current limited has deceased at higher speeds, the PWM disappears and the phase waveform becomes the only one existent), and it's mostly just the phase current's period?

[justin_le]

Thanks for the illustration. I was recently under the impression that the caveat you brought up affected performance in the region of 5-10%, but it certainly seems to be fairly important.

Yes, well the level of importance really depends on the motor and RPM under question. But when the inductive impedance of the windings at the commutation frequency starts to reach the same order as the ohmic resistance, then the effect can be very significant, and as illustrated with the geared eZee/BMC motors it is more than a factor of 2. If you look at an oscilloscope trace of the waveform, the current never comes close to leveling out at the value predicted by (V-emf)/R. It is still ramping up when the commutation event takes place, then it takes a big hit during the commutation as the current steers away from one phase to the other. The graph here shows a Nine Continent motor spinning at 510 RPM, with both the actual drive voltage when the controller is on (pink) and the back-emf voltage when it is off (green) showing. The blue line is the phase current when the controller is on.

BLDC Motor Waveforms.jpg (38.88 KiB) Viewed 1707 times

Notice how the current through the phase is always ramping upwards? With a sinusoidal motor driven by a 6-step controller as is the case here, we would expect the current waveform to look a bit like a 'w', but here it is a 'w' on a pretty big slant.

By the way... can you tell me how the "commutation" period is so long at low speeds?
It seems obvious that the phases are activated for longer periods of time at lower RPM, but it also seems that you're encountering PWM at the lower speeds due to current limiting. Is the "commutation period" of the PWM waveform not particularly important (Once current limited has deceased at higher speeds, the PWM disappears and the phase waveform becomes the only one existent), and it's mostly just the phase current's period?

I think on my 6th read over that I see what you're getting at! In the context above, by "commutation period" I just meant the time period between one commutation event and the next, not the actual time duration that it takes the current to switch over from the non-driven phase to the newly driven phase. The actual time required for the commutation to take place is dependent on a) the current through the windings, b) the inductance of the windings, c) the back emf voltage, and c) the supply voltage.

I'm completely ignoring PWM in all of this, it's not part of the equation at all. At PWM frequencies the winding inductance is assumed to be for all intents and purposes infinite, and that approximation seems fine.

-Justin

[swbluto]

Ok, I've gone through the steps for licensing and dedicating an SVN space to the open source movement. This software is now GPL licensed and ready for open sourcing to allow improvement or modification to the software by anyone who wishes to contribute. All improvements and derivatives must be open source under the same license as part of the terms for GPL licensing.

The SVN is http://svn2.assembla.com/svn/ebikecalculatoropen .

If you just want to browse or have a look around the space, the url is http://code.assembla.com/ebikecalculato ... sion/nodes .

Here's the directions for developing this.

This project was built using the NetBeans IDE for the GUI Builder and code editing and JDK 5 to maintain compatibility with Mac Systems. It also uses JFreeChart in order to create graphs and all those cool things.

What I would suggest is find JDK 5 as offered by Sun, download it bundled with netbeans and install it. If you want to contribute to the above project, please send your email address to me and I'll add you as a member to the group so that you can add to the project directly, otherwise you can check it out anonymously and create a derivative work. After installing it, checkout the project using the subversion feature of netbeans and, if you wish to contribute directly, add your member login info there. Once you've checked it out, make sure to add JDK 5 so that the project can use it and find and download JFreeChart-1.0.11 from sourceforge and add the libraries to Java's lib folder, and add to the folders to the project inside netbeans. After that's done, you should be able to compile and edit the project freely and you would commit changes to the source code by right clicking the project and clicking commit.

Some things that might be desired to change/add

-Change the built in 2d array for the motors so that it can read that information from an external CSV spreadsheet or some other database. This way, the motors can be added in the future without requiring compiling the program and so anyone could add motors to the motor database.

-Add in a motor current limit so that motor-current limited controllers like Kelly controllers can be accurately simulated.

-Modify it so that it'd be possible to use more than one motor in the same drive-train. That honestly sounds like a lot of work to keep relatively simple.

-Include a drive-train loss box so that one could include drive-train losses into the simulation. A percentage may be the most intuitive.

-Add in inductance so that high inductance motors can be accurately simulated in the high RPM range.

-Get rid of the antiquated efficiency linear-interpolation code for hub motors, since the efficiency calculations now work.

...Some superficial things for maintainability reasons...

-Capitalize the "Final Int" variables to distinguish it as a constant used for the general motor's data array for array item access.

[swbluto]

Just changed the title.

[damcard]

it doesn't seem easy to port to an online format without heavy bandwidth costs.

Bandwidth should be minimal. I could see doing this app two ways to get it online. I could do either one fairly easily and would be glad to so I can loose my "lurker" status.

The first is with servlets and a html form via jsp's. The bandwidth would be comparable to any simple web application. Infact, it would only have a single main form with a few popups. The charts themselves are fairly small. Do people use the zoom functionality in the charts? The issue here is you would need a servlet engine such as Tomcat to run it. But it would work for limited devices like an Iphone.

The second would be to port the whole thing to actionscript3 (flash). For this application I would prefer to do that. The cool thing doing it that way is all the graphs could be dynamically updated as you change values in the form. It would be the most responsive. You could serve it from any web server as static content such as in a post on this forum. All the calculations and graphing would happen on the client. The bandwidth would be small as the user would simply download the swf and not interact with the server anymore. The downside is you need the flash player use it. For normal web browsers, its not an issue. But, it would not work on limited devices such as an Iphone.

Is anyone interested in making this a web application?

[wshi]

Ok, I've gone through the steps for licensing and dedicating an SVN space to the open source movement. This software is now GPL licensed and ready for open sourcing to allow improvement or modification to the software by anyone who wishes to contribute. All improvements and derivatives must be open source under the same license as part of the terms for GPL licensing.

The SVN is http://svn2.assembla.com/svn/ebikecalculatoropen .

If you just want to browse or have a look around the space, the url is http://code.assembla.com/ebikecalculato ... sion/nodes .
.....

Well done! I would like to checkout and have a look. What's the username and password for read only access anyway?

[damcard]

Change the built in 2d array for the motors so that it can read that information from an external CSV spreadsheet or some other database. This way, the motors can be added in the future without requiring compiling the program and so anyone could add motors to the motor database.

How were you going to do this exactly? Would you have a folder with the files it could load? That is, where would the csv files be held? A form could be used to load custom csv's I suppose. If it is a hosted app or if it connected to a service I could see how users could add motors.

I ported Motor.java to Flash(as3). I will finish up the others once I can get read access to the repository and check out the entire project. Thanks -David.

[swbluto]

Quick response.

It appears they classify two types of people:

"watchers" and "members".

Under permissions for each type of the above user, they offer "read", "edit" and "all". Currently, watchers have read access and members have edit accesses. If the "watchers" category doesn't allow checkout, then I don't know how to offer anonymous access without also offering the ability to commit. It appears that checkout is tied up with commit abilities.

So if anyone has any insight into what can be done to allow anonymous checkout without commit abilities, please let me know.

[swbluto]

Ok, I've created a watcher and maybe watchers will be "special" since they have a password.

Username: anonymous_1359
password: anony

This user has read access which might allow checkout, methinks.

Hmmmmm... it appears I changed something relevant because it seems eclipse checked out the project without a user logon, while also not presenting the commit option. It appears "anonymous checkout" has been somehow enabled.

[swbluto]

Change the built in 2d array for the motors so that it can read that information from an external CSV spreadsheet or some other database. This way, the motors can be added in the future without requiring compiling the program and so anyone could add motors to the motor database.

How were you going to do this exactly? Would you have a folder with the files it could load? That is, where would the csv files be held? A form could be used to load custom csv's I suppose. If it is a hosted app or if it connected to a service I could see how users could add motors.

I ported Motor.java to Flash(as3). I will finish up the others once I can get read access to the repository and check out the entire project. Thanks -David.

I have no idea how a csv would be situated.

I was just thinking of a simple comma-separated-value(csv) sheet that contained the motor database. Basically, each line contains a distinct motor, and each comma separated value is a distinct value (Motor Name, kv, resistance, io, whatever else.). If you're creating it online, you could connect it to whatever database schema you want, with maybe something like mySql.

[wshi]

Have you looked at Google code project hosting? It's pretty cool and support SVN.

http://code.google.com/opensource/

[swbluto]

It looks cool. I'm not going to put more effort into putting it somewhere else, though, especially if all the desired functionality appear to be working where it is already.

I noticed development is slow / non-existent which is OK. Maybe it's just fine the way it is. I've stopped personally contributing to it largely because it does most of what I wanted in a simulator - it easily enables me to design an electric vehicle with a good educated guess as to what I might expect of performance and efficiency. However, maybe some people want more but don't have the programming skills to do it. I may be willing to help in that regard in return for services, goods or payment. My rates are fairly cheap since I know any improvements would help out the community at large and I really want to help the revolution, but my time isn't free.

Anyone can contribute to it whenever they want, whatever they want. If it significantly deviates from some of the inherent stated goals of the project, it might be good to make a branch. I'm just offering services to help those who don't know how to contribute programming to the project but want some specific feature or set of features implemented. Like perhaps dual motors. Motor current limiting. Or something else.

For the main branch, I want to....

Minimize screen clutter. If someone is going to implement dual motors, it'd probably be best to have a dialog box to input motor and drivetrain characteristics for a given motor, and then to have a summary on the main input screen then it would to have double the amount of boxes on the main input window. There's probably way too many boxes on the main window as it stands.

[wookey]

OK. I just had a go with this. It works fine on java 6 openjdk on Debian Linux. Or at least everything except the help works. Clicking on the help button launches a browser containing the URL: http://www.help\mainindex.htm/ rather than openning the URL file:///home/wookey/archive/vehicles/Help/mainIndex.htm where it actually is. Something small not quite right there.

It's a nice application, and I'm very pleased to see it gpled and put online. I could package it for Debian/Ubuntu if there was any demand, but as has been pointed out it's probably most useful as a web-app.

Could I ask that if people are going to make this into a flash application that they _please_ test it with/write it for Gnash and swfdec - the free flash applications. Currently flash is a real problem on the net because it requires Adobe's proprietary technology for much of it to work - that is not the sort of web we all want to be using (imagine where we'd be if 10 years ago there was only one web-browser available to us all, from one supplier and no-one else could write web-browsers because how stuff worked was not documented). I'd much prefer for it to remain a java application, now that java has been made a free language. flash is not searchable, flash is not link-to-able.

I found a couple of minor corrections in the help. I just tried to check the code out and fix these but it seems the help docs are not actually checked in. Is this just an oversight? Shall I do that? I've joined the project and it's set me to 'member' does that give me svn checkin rights?

Now, on to the app itself. I am trying to simulate my moped. The motor is the e-fun 1500W twin-mode device with data here:
http://www.efun-ev.com/technology/advan ... raphic.swf
http://www.efun-ev.com/technology/advan ... L_data.swf
http://www.efun-ev.com/technology/advan ... raphic.swf
http://www.efun-ev.com/technology/advan ... _data2.swf
(Snigger at the craziness that takes about 1K of data, scans it and then turns it into a swf application to display pages (and hides access behind a login) - a triumph of gratuitous technology over accessibilty)
Can anyone tell me how I work out K or Motor resistance from that data?

This motor is not in the datbase already so I picked 'Custom'. Setting 1 amp no load current (perhaps this box should be next to the other 2 that need filling in?) 0.04 V/RPM and 0.1ohm resistance, gives me something approximately in the right ballpark, but I can't get anywhere near the 2500W that my watt's up tells me is peak current.

The help could use some generic values for mopeds too (for tyre rolling resistance, frontal area, drag co-efficient, etc). Does anyone have ideas for typical values? Similarly do we know any of the motor specs?

[swbluto]

Your motor might not be 100 mOhm.

Also, the power output value you see in the calculator is just that - the motor's power output. The peak you see with your wattsup is the input electrical power firstly, and secondly, the peak power probably does not correspond to your "current limit" as there's some current overshoot with almost all current limiters so you're not going to see that in the simulator. You'll need to make your current limiter perfect, first.

As far as the help files, I'm pretty sure they were sitting in a separate folder from development that was just zipped into the rest of the program's zip file, so that makes sense. That computer has since crashed (And data lost), so someone will have to check it in to make it part of the project.

[damcard]

Could I ask that if people are going to make this into a flash application that they _please_ test it with/write it for Gnash and swfdec - the free flash applications. Currently flash is a real problem on the net because it requires Adobe's proprietary technology for much of it to work - that is not the sort of web we all want to be using (imagine where we'd be if 10 years ago there was only one web-browser available to us all, from one supplier and no-one else could write web-browsers because how stuff worked was not documented). I'd much prefer for it to remain a java application, now that java has been made a free language. flash is not searchable, flash is not link-to-able.

I found a couple of minor corrections in the help. I just tried to check the code out and fix these but it seems the help docs are not actually checked in. Is this just an oversight? Shall I do that? I've joined the project and it's set me to 'member' does that give me svn checkin rights?

I had started to port this to Flash. I just started my Masters degree, so my time is limited. I think it would be easier for me to just do a web app using the existing java code except for the UI code of course. It will be another week before I can start up on it again.

[tostino]

SW I was thinking of taking a look at the code, but for some reason, it is just not wanting to see the jFreeChart libraries I imported.

Any ideas of what I did wrong?

[swbluto]

I believe that one needs to include the libraries inside the library manager, as well. So, I think you might have to point netbeans to the appropriate .jar.

[tostino]

Silly me! I downloaded the source for jFreeChart and jCommon, and didn't build it, so there was no Jar for it to point to (even though I "added" the library in the library manager). I built them, and now it's working . Time to take a look at all this.

[swbluto]

Heads up, I don't trust the hub motors, at least not when you're looking for heat generated and efficiency information - everything else should be fine. If the heat figures are distrusted, just copy down the k, motor resistance and the no-load current into the custom option and it'll be accurate. This is because of some antiquated "If block" that uses a linear approximation model for the hub motor's efficiency near the end of the RPM range, which was made before the efficiency formulas became accurate. Simply deleting the "if block" should make the hub motors evaluation correct again.

The graphs are unaffected by this, so they'll be accurate either with a hub motor or a custom motor.

[auraslip]

THIS IS AWESOME THANK YOU SO MUCH!

[swbluto]

No problem.

I was thinking about getting a 9C motor so I was looking at the graphs and it looked like the performance was pretty impressive. But then I went to double check ebikes.ca's newfound suggestion of modeling motor inductance which applies to "high inductance" or "high pole count" motors and apparently 9c is a high pole motor. It turns out that there was indeed a significant difference in performance at high motor RPM, and meant the difference between a prediction of 30 mph up a hill and 18 mph.

Well, this is reshaping my 9C plans. More importantly, inductance should be modelled but I getting the data would probably require one to have ready access to the motors - i.e., a dealer like ebikes.ca. *sigh*

EDIT: I quoted the below for reference because I must bite my tongue. It appears they provide L(inductance) when you use the custom option near the bottom of the graph. Now armed with the L value, what can I do? I know the L/R time constant will tell me how fast the phase current rises as it switches phases, so one just needed to take an integration of current and find the average phase current and thus torque, and the time period will be determined by the electric RPM which increases with motor RPM. Now, the question is... is the phase current 0 immediately when it switches? The time period I believe will be
1 / (motor RPM * pole count), where RPM really is radians/sec.

They haven't exactly been too forthcoming in releasing the inductance data and it's not readily extractable from the graphs since "numerical estimation" techniques are used (LOL- in other words, no formula), so I guess they have the monopoly of "true performance" simulation and unfortunately doesn't include all the detailed vehicle analysis that I've come to love about mine (Like heat generation, acceleration, predicted speed given a defined hill and motor temperature and the such).

In otherwords, true performance prediction for 9C's will be LABORIOUS. I really really really really don't want to fall back on the old tiring methods. Design will be a huge PITA that way. Freak, I really have taken a huge hiatus on this but I really need to include this. Now I need to get the programming environment up and running again, haha (My windows system has crashed and burned so many times since I've last developed this that I've lost all the necessary programs and libraries for development.).