As has been said before, we’ve taken an Intelligent Algorithm approach to our motor design framework.

We started by adding a Genetic Algorithm to the MotorFemmulator project code, and left it running on a 7 computer improvised cluster. It has yielded some results, namely the optimization of a motor from 44Nm (5kW) to 200Nm (23kW) at 90% efficiency, but the whole process of optimization is out of our control – we define the initial parameters (population size, mutation rate, reproduction rate) and then hope for the best. The best, in this case, we defined as 20 generations without improvement.

This takes a hell of a long time to produce results, is very wasteful of computer time, and does not guarantee a global optimal solution. So, also in the context of another course subject group work, we decided to add a Fuzzy Logic control over the Genetic Algorithm, so that we didn’t have to define those parameters and they would adjust on-the-fly to the current state of each generation. What looked like a neat idea quickly snowballed into a veritable Ph.D investigation… there are many more papers on the subject of fuzzy-genetic algorithms than the ones I care to read.

But eventually I found a couple of papers that promise to make it better for us. One shows how to control Mutation Rate and Crossover Rate via Fuzzy Logic to achieve a good balance between diversity (breadth of search) and convergence speed, and another one shows how to design the Genetic Algorithm with adaptive Population Size (which helps save computing cycles by eliminating the least interesting individuals, but also explodes the population size when stuck on a local maximum). This last one doesn’t have Fuzzy in it, but I’m sure I can turn one of those parameters into a Fuzzy-controlled feedback.

Man, I need that vacation… but it’s still 2 weeks and 3 group works away… 

If it weren’t for the real benefit that we are seing as an outcome in this project (automated optimization of electric motors), I think I’d have given up by now.

Just like any other software, FEMM has its limitations.

I’ve been talking a lot to David Meeker, the author, who has been extremely kind and thoughtful in guiding me not only in the program’s usage but also in general electromagnetic modeling, while trying to sort out the modeling mess I’ve put myself and my colleague into with this project.

As it stands, we have a problem: FEMM only works with a single frequency at a time. This means that permanent magnets (freq=0Hz) and electromagnets (freq>0Hz) cannot simulate together. That’s a big downer. It means we can’t draw the magnets and the coils and set a current frequency and get the corresponding torque – FEMM will ignore the permanent magnet’s fields and give us the torque from only the AC-induced field.

But perhaps this is a good thing. This “problem” is just an aspect of a greater, deeper problem: time modeling in the finite element method (f.e.m). You see, time is usually only present in f.e.m. in the shape of the sinusoidal E.M. waves: current, field, and all their related partners. There is no way to describe (let alone simulate) mechanical movement between parts of the design. I don’t know if other programs have this solved, but I can guess how difficult it would be to program it into FEMM. Anyway, it would be incorrect to expect good results even if FEMM did do the math with the DC and AC components, because a static PM is not the same as a moving PM.

So we are left without a way to simulate the magnet’s rotation around the stator, which means the machine is always static and we can’t evaluate all the other points of operation that involve speed. If we turn on the frequency, we lose the magnets and so the major source of torque; we turn it off, and we lose the core losses and the counter-electromotive force. And combining the two simulations is not correct, because there are always saturated areas where the flux cannot be summed linearly. So it looks like we can’t simulate in FEMM a brushless DC motor like this one:

Or can we? David was kind enough to show me how.

We basically replace the original design of the permanent magnets in the rotor with an “equivalent alternating field source” that emulates the moving field of the magnets at the desired speed. If things are done properly, this “current sheet” in the rotor will generate the same field as the PMs (with the same amplitude and frequency) when they are rotating. The distance between 2  opposite magnetic poles corresponds to half a wave’s period. The amplitude of the current must be reverse-engineered; David suggests to run a few simulations to find out which current density in the “equivalent rotor sheet” generates the same field strength in a distant point of the machine as the magnets would. Then it’s just a question of dividing the sheet into a lot of small(ish) segments and insert the current density vector into each one. It sounds complicated, but it’s not. Take a look at the very same motor as above, modified according to this technique:

Each one of those new little segments in the rotor has a different material property, which just defines a current density vector with the same amplitude but different orientation. The values are inserted as complex coordinates:

The resulting field is a sinusoidal one which matches the permanent magnet’s field, as you can expect:

This in fact simulates magnet movement. To define the rolling speed of the motor, you set the frequency of the problem. So what’s the catch?

Well, David pointed out one: this only gets you the base sinusoidal frequency. To get the contribution of the harmonics, further simulations are necessary – and you have to know which harmonics to simulate. And our motor model has loads of harmonics because of the squarish shape of the poles, which renders this technique somewhat erroneous.

And me, I’ve always liked the fact that our models are reality-accurate. Replacing real parts with “movement-equivalent” constructs gives me the chills. What if we get it wrong? Double-checking it would take a lot of effort, and we’d still need the magnets version to find out which harmonics we should look at.

Incidentally, this can be done by doing a “generator” simulation: snapshot (at zero frequency) the flux linkage of the phases in each position of the rotor, and draw up a chart with it’s time derivative (the EMF voltage):

Pretty far from sine waves, right?

So, third option: back to basics. Ignore the fact that FEMM can calculate AC problems in the frequency domain, and use it only for DC static “snapshots” of several rotor positions (with the real magnets), effectively calculating in the time domain outside FEMM. Put enough of these snapshots together, and you can get electromotive forces and powers and even calculate core losses by analytical methods (as suggested by David).

Hmm… decisions, decisions… We’re taking the last approach, because time is not on our side. We will build up the script system to look for the highest Torque/Current factor, and save the core losses for a later attempt.

So, we’re still hammering the motor model in school. You can always take a peek here.

We’ve decided early on to drop the Opti-Y optimization suite in favor of good old fashioned homegrown Octave scripts. On one hand, Opti-Y didn’t look friendly to Linux at all, and on the other hand we wanted to leverage our own knowledge of Intelligent Algorithms. So Octave+FEMM it is.

We’re getting a Genetic Algorithm (”GA”) toolbox ready for action with our FEMM scripts, and at the same time improving those model scripts. The modeling is becoming more complicated each week, as we go along and add variable parameters to the machine model; in our classes people come up with pertinent observations, like for example “what happens to torque if the rotor magnets are embedded instead of salient?”, or “what happens to performance and efficiency if the stator teeth are not ferromagnetic?”; usually the correct answer is “it depends!”. So we add these options into the design as parameters, instead of choosing anything beforehand. But that shouldn’t be a problem, since the GA really doesn’t mind – in fact, the more parameters we have, the more pertinent it is to use GA instead of a simpler exploration approach.

The intention of the project is not to cover traditionally known ground and emulate the “typical” decisions; it is in fact to throw as large as possible a universe of options into the evolutionary cauldron and see which “genetic” traits emerge victorious. I expect we are only going to confirm the already known industrial tricks (if we do it right), but the approach lends itself to the appearance of surprises (which is something I would enjoy very much).

Anyway, not all are roses. There is the tiny problem of CPU workload. The GA itself is really light, but for each iteration and each “individual” in the “population” of options there must be at least one execution of machine simulation in FEMM. This means we are possibly looking at many thousands, possibly millions, of simulations necessary to make the GA converge to a good enough solution. And since the original version of the model takes around 6 minutes to solve on my most powerful computer… you do the math. I’d be an old man when we got the results.

So, the computational problem must be reduced. Two approaches are being taken to achieve this:

1 – Reduce the node count. I used to have somewhat “generic” sizes for the finite mesh in each part of the machine; I had 3 sizes (fine, medium, coarse) and used them more or less arbitrarily. Now that node count has become important, I’ve taken to define each zone’s mesh size as a fraction of the zone’s own dimensions. If I’m very interested on what is going on in a zone, I may pick a mesh size of “dimension/5″; if the zone is of little importance, I may pick as low as “dimension/2″ (although it is theoretically advised to stay over “dimension/3″). Anyway, the node count got reduced last night by around 20% as a consequence of this effort. The subdivision of the air gap into 2 areas (inter-pole gap and stator-rotor gap) also helped a lot, allowing to specify different mesh sizes in these two.

2 – Reduce the overall size of the problem. It is a well-known fact that electric machines are projected with a lot of symmetry. It is correct to do a finite element simulation of a single “tooth” of certain types of machine and then extrapolate for the whole machine. This cuts down tremendously in CPU time, and allows us greater precision (with finer meshing if we like) with the same resources. Unfortunately, our machine has a lot less symmetry than others… The typical 12 pole LRK windings force us to simulate a minimum of half the machine (6 stator poles). Well… half is better than full. And when we increase the pole count to twice as much, we can reduce the simulation to one quarter of the machine (the same 6 stator poles). So, it’s not perfect, but it’ll do nicely. I’ve gotten the stator to “reduce” cleanly upon request, but the rotor is a much more delicate problem because it can be drawn in any position, and so the magnets may end up cut in any proportion. I need to change a lot of code in the framework to achieve this. Oh, and then there’s the debugging…

So, in a nutshell, that’s what’s going on. Time is running out, so we must focus on the important.

I finally got the chance to officially push my wheelmotor project into my master’s.

By an incredible strike of luck, I teamed up with a class mate that is also extremely interested in sustainable energy and electric propulsion; not only that but he also has experience in Octave development and is keen in applying that to my motor project.

So now it’s our project. Don’t worry, everything will be kept open-source as usual.

André and I will be working together at least for the semester, and our plan is to use Intelligent Algorithms to generate highly optimized versions of my basic models. We are keeping FEMM as the magnetic solution calculator, and we’re planning on exploring the “Opti-Y” optimization suite – which we are told can talk to FEMM directly (but he is still evaluating that). For the motor model description itself, I am porting the framework and a single rotor radial model (with Halbach option) from Lua to Octave language. There is much more flexibility and potential in the Octave suite than in the Lua interpreter, for a realistic machine project.

We originally wanted to develop our own Octave toolbox with Genetic Algorithms (and anything else we felt like) for this project, but the teacher advised us to keep it small and simple, and to reuse the professional tools. It was a hard decision, but we finally went with Opti-Y. I hope it doesn’t fail us in the meantime… but if it does, the model and framework are already written in Octave, just in case!

However, the theoretical modelling is not the only thing we are working on… already great ideas about fast prototype fabrication are springing up, and with cool resources like 3D printers and fast curing polymers at hand, things are gearing up for a possibly surprising fast appearance of a real prototype. Of course, it might all be a pipe dream… time will tell.

After 1 year and 2 months, I have very little to show for results.

There is this software framework that produces sketchy models of wheel-motors which have no guarantee of real-world performance. And a web site full of interesting bits of information, a few intelligent discussions, and a handful of very nice and techie web friends. But the car still burns around 9 Litres per 100km, and there are no electric traction motors aboard. And I ride it every day to a job that consumes my time and strength.

I talked to investors, but they were too small and frightened for me and my project. I’d talk to bigger investors, but I’m too small and frightened for them .

The first semester of my M.Sc. in E.E is over. I learned a lot about electric machines, but still not enough to actually build a high-efficiency and high-performance one with minimum confidence. For that, at least another semester must go by. Meanwhile, I’m all over the place in my Uni, and talks about a large and interesting project (which may allow me to work full-time on these areas – but not in my personal project) have begun.

So, anyway I cut it, it doesn’t look like I will be able to convert my gas-guzzling car into a HEV or EV anytime soon. I need another approach.

• Resolution one:  Get an electric car now. This way I start saving the planet (and my wallet) today, instead of tomorrow. Put my actions where my mouth is. It also has the advantage of leaving the big fossil-burning hunk of metal parked somewhere where I can actually disassemble it and start some hardcore tinkering. I’d gladly settle for an electric motorbike, but my wife would divorce me if I got one (if you know the traffic and the road conditions here in Lisbon, you understand her fear of being left a widow with a small child if I rode one to work every day). And an electric bicycle is even more prone to manslaughter than a motorbike. So a car it must be. And the occasional uphill bicycle ride to work, when my strength allows it.
• Resolution two: Subcontract the HEV project as much as possible. When time permits, get some suppliers in line for the main systems, leaving me as the system engineer or integrator. Saves time, and should increase the probability of actually getting things done. John already offered to make me a pair of custom in-wheel motors (or at least the core of them) and the reason he hasn’t already is because I’m lacking the time to honor the commitment.
• Resolution three: maintain the framework as a separate project. I like the way the “motorfemmulator” scripts are going, and if I do get the big break I’m going after through the Uni, I may just get the time to bring this framework to a whole new level of feature richness and usability. But it cannot stand in the critical path of my HEV project anymore. I’ll be glad if someone else takes advantage of it (as Pierre has done).

Maybe I’m being too ambitious in wanting to redesign my career, save the environment, and contribute to open source technology all at the same time, but that’s just the way I am…

EDIT: Oh yeah, I almost forgot – AND HAVING FUN AT THE SAME TIME!!!! 

No pain, no gain.

Well, what do you know, there actually exist hybrid motors!

Basically, when an electric motor has a stator with both electromagnets and permanent magnets, that’s a hybrid motor. It’s called hybrid because it is a cross-breed between a Permanent Magnet Motor and a Variable Reluctance Motor (which has a purely ferromagnetic rotor with salient teeth and without magnets or coils).

This type of motor is very important to me because it is said to have much better efficiency than a regular PM motor – and efficiency is becoming an obsession of mine… battery weight and size will be largely dictated by the efficiency of the system, and the motor plays a large influential part in this. And because of regenerative braking, the total losses are multiplied by 2: we lose energy when accelerating, then we lose some more when braking. So, a motor/generator with 90% efficiency actually has an effective efficiency of 90% × 90% = 81% when we consider the energy’s complete round-trip. Furthermore, it is also said to have better torque/weight ratio and, most importantly for a wheel-motor, a wider range of flat torque response (up to higher speeds).

The main differential aspect I was able to grasp from the papers and patents about this type of motor was that, because the main part of the air gap’s magnetic flux is actually generated by the permanent magnets, the inductance (or “electrical inertia”) of the stator coils is very low, which in turn allows the electronic drive to cut or establish the phase current a lot faster than in the other systems. This promotes better torque control and higher efficiency. In addition, the generated back-emf is lower than the usual, which allows for higher speeds with the same voltage sources.

Another positive aspect of this motor compared to my current PM model is that it uses a lot less magnets, and so it promises to be cheaper.

And the thermal management is also easier, because all the temperature-sensitive components (magnets & coils) are placed in the stator, where it is much easier to implement liquid cooling (if necessary).

So, here go some examples of this marvelous technology.

• Yuefeng Liao & Tom Lipo’s “Doubly Salient Permanent Magnet” motor (introduction and optimization strategy).
• Ming & Zhou’s “Split Winding DSPM” motor (analysis).
• Sawyer linear motor (concept and cool application).
• Flynn’s “Parallel Path Magnetic Technology” motor (concept and motor).

Thanks to David Meeker (of FEMM fame) for showing me the Lipo and Sawyer motors, and to JPC for showing me the Flynn motor.

I’m definitely considering starting a new motor design based on this approach…

After a 3 week intensive sprint and with a little help from me, Pierre has finalized his own motor model and it is now available in the repository. He also contributed a couple of small tweaks to my common Lua “libraries”. The GPL wins again.

I helped out as much as I could (with just a few hints in magnetic design) in between my school exams and assignments, and after just a week he had my Lua/FEMM framework running with his new model. After two weeks he had a consistent motor and was running optimization scripts. Not bad at all, considering his haste and the sometimes flaky communication between two non-native English speakers! After 3 weeks he had the basic mechanic and cooling design too. So if anyone asks, you can tell them it is possible to completely design an electric wheel in under one month (I’m not so sure about the output quality, though). Anyway, hats off for a man who knows what he wants and works hard to get it.

I haven’t checked-in his optimization scripts yet, they are very redundant (extensive “copy-paste-modify” done in a hurry), but I intend to merge that feature into some “M-files” that I want to create for the project (FEMM has a nice integration level with Matlab & Octave). I did however spend some time cleaning up his model code and also refactoring some of mine to better allow multiple models in the framework. It’s all looking pretty usable now.

The new model  is also 3-phase fed, but otherwise it is quite different from what I had been experimenting with. He followed “industrial practice” and designed a single outer rotor version with a more standard slot/pole topology. He chose a base model of 9 slots & 8 poles (all multiplied by a factor of 8, yielding 72 coils & 64 magnets), and all the stator teeth are wound. Additionally, the rotor is very thin and the permanent magnets are embedded into the rotor shell (instead of just glued to its surface).

Fig.1 – Pierre’s FEMM motor model with flux distribution and two active phases.

Fig.2 – A close-up of the air gap and rotor, showing the “hammerheads” he developed.

The magnets he chose are custom-designed from supermagnete.de for his dimensions. He picked a high-temperature grade (N40UH) capable of withstanding 180 degrees Celsius, which makes perfect sense in a high-power motor. Unfortunately, higher-temperature Neodymium magnets are a bit weaker in the magnetic field aspect. He chose a path of engineering I am not especially interested in: high-power / high-torque. As a consequence, his motor is to be forcefully cooled (and he did a fine job with that arrangement). Personally, I’d like to build a motor that is so efficient that it needs not be cooled.

Pierre was kind enough to share his initial mechanical design with me, although under a “verbal” non-disclosure agreement because he is seeking patents on this design. So, with his permission, I’m only showing here a large scale overview, which in fact contains nothing more than just common industry knowledge and common sense. His specific insight and choices on thermal management and mechanical assembly are purposely hidden (so don’t ask me for more details).

Fig.3 – Pierre’s basic mechanical assembly: the stator structure and the rotor “cap”.

This mechanical assembly does not show any magnetic parts; the stator is empty and ready to receive the ferromagnetic sheet and teeth and copper coils. The same is true about the rotor, it has no magnets or iron sheet in it, it’s just the outer shell.

Unfortunately, I didn’t have much time to follow his work up close, and he was really in a hurry to finish the magnetic and mechanical modeling and deliver the plans for a prototype. That’s right, this baby is going to be manufactured any day now.

According to Pierre’s simulations, his model shows a higher cogging torque (around 10Nm) than my LRK-based topologies (close to zero). But it gets a full 1000Nm for just 50A per phase, which is actually better than my double rotor model – almost twice the “bang for buck”! I have to investigate the reasons for this.

Speaking of phases, here is the snapshot of his motor (Pmult=8) with one phase active (in pink), so we can see the winding sequence:

Fig.4 – One phase active at 8 different spots.

And here is a close-up so we can count the teeth.

Fig.5 -Three teeth per phase pole.

This is a very curious arrangement to me…In fact, if we reduce Pmult to 1, we can see that the phases are not arranged in pairs unless Pmult is even…

Fig.6 – Base, Pmult=1.

I have to find some time to run a few experiments on it…

Pierre has told me it is difficult to understand my Lua scripts without a better explanation of what each variable means. He expressed a wish for a drawing that maps the variables to the geometry. I agree this is necessary, it just hadn’t been until now because nobody else dared to go into my code!

Graphically (click to enlarge):

I will explain the variables present in each file.

• START_HERE_model_loader.lua: this is the only file you load directly into FEMM. It will load all the others needed do build a model and execute the desired simulations. It is also where the main variables are defined, so you should edit it before using it. This file defines the following important variables (which define the main dimensions of the motor):
  • Ri = minimum inner radius of the motor (absolute limit); In my case, it is just above the radius of the brake drum. Of course, my scripts assume the motor is doughnut-shaped. If you put a zero in here, things will probably break here and there.
  • Ro = maximum outer radius of the motor (absolute limit); In any case, this should be the safe value of the space available inside the wheel rims.
  • Zmax = the maximum depth along the axis of the wheel; typically also a safe maximum value of distance between the interior of the wheel rim and the suspension arm.
  • Hag = Height of air gap between rotor and stator.
  • Occ = Occupation of stator with teeth. I have to find a better name for this one… it means the ratio between the perimeter occupied by stator teeth and the total perimeter of the stator. In other words, (1 – Occ) gives the free space for wire slots.
  • Dpm, Wpm, Hpm = the 3 dimensions of the currently used magnet. My models only use one kind of magnet at a time, and these 3 variables define it’s geometry. D is for Depth (along axis of motor, or perpendicular to the “paper” axis), W is for Width (along the tangent to the motor perimeter), and H is for Height (along the motor radius). These variables are merely initialized in this file, but then changed by a call to “mfl_pick_magnet_material()” which loads the characteristics of a specific magnet from a library (my_femm_lib.lua).

• model_*_*.lua: these are my motor models. Internally, they combine a stator_*.lua and a rotor_*.lua files to build a complete motor. The model starts out by defining a few variables of its own. These are usually the ones that we play with to define the model.
  • Tst = Thickness of the (non-magnetic) structural plate. The rotors and stator both are composed of two materials: a ferromagnetic core material, and a structural material. The inner rotor has the structural plate on the inside face; the outer rotor has it on the outside; the stator has it right accross the middle of the coils.
  • Nmp_b = Basic number of magnetic poles in rotor (may correspond to 1 or more magnets each). This variable, along with the next one, allow us to express the minimum number of rotor poles and stator teeth and the relationship between them.
  • Nst_b = Basic number of stator teeth.
  • Pmult = Pole multiplier factor. This allows us to scale up the number of poles and teeth in proportion. It is better for efficiency and torque to have as many poles as possible, so you can for example use a factor of 3 to get a 42-pole / 36-teeth motor from a basic model of 14-poles / 12-teeth.
  • Hg = Height (thickness) of glue under magnets. This is a bit of a hack. While it is justifiable as a real project variable, it was born out of my need to compensate for small accumulated errors in magnet placement – which make the corners/faces of the magnets sometimes cross the rotor circles in an almost indetectable infinitesimal amount… Some models use this, some don’t.
  • Hst = Total height of a stator tooth.
• At some point I started playing around with “hammerheads”: little extensions of the stator teeth at the air gap to help directing the flux. But I’m not sure it helps at all… anyway, some models may use this.
  • Hsf = Height of the stator tooth inner/outer hammerhead.
  • Whh = Stator pole Hammerhead width, expressed in coefficient relative to pole width.

• The model file knows how to combine the stator and rotor and create their respective dimensions (and enforce dimension sanity towards the limits defined by the user), and this is all done inside the function “model_refresh_geometric_data()“. This is the most critical function I have in there; if it fails, the model fails to be built. The variables calculated here are dependent upon the other globals already defined by the user, and are supposed to be safely recalculated everytime the user changes those globals.
  • Nmp, Nst = Effective number of magnetic poles and stator teeth (remember the Pmult?);
  • Rs = Stator radius. This is the distance from the centre at which the stator will be placed. It marks the place of the structural plate of the stator, which is where the coil cores are fixed at their middle.
  • Npmpp = Number of permanent magnets per pole. Since we are trying to use several magnet options, it is possible that one magnetic pole is made of more than one magnet.
  • Npm= Total number of used magnets. For financial estimate only. Don’t confuse this variable with Nmp!
  • Wmp = Width (in tangent direction) of a magnetic pole (constructed with one or more magnets).
• And here comes the really confusing part. As you may have noticed, I’m using magnets with simple block (parallelipiped) shapes, which yield a rectangular cross-section, and attaching them to a curved surface on the rotors. Obviously, this is not a perfect match. On the outside rotor, the magnets only touch the rotor at the corners; on the inside rotor, the magnets only touch the rotor at the middle of their face. To deal with this fact, I created a “bulge” quantity. I normally do the calculations as if the magnets would fit perfectly to the curved surface, and then move them out or in a little (the “bulge” dimension) to get them to touch the rotor face in the right spot. Unfortunately, this math is not perfect yet, and sometimes the model will not simulate (depending on magnet and motor dimensions).
  • Bipm= Inner rotor magnet bulge. The radius at which each magnet centre is placed has to be extended a little bit to account for inner rotor curvature. This is the amount of radius delta that is used to do that.
    
  • Ripm = Radius at which the magnet centres are placed, for the inner rotor.
  • Rir = Radius at which the inner rotor magnetic core ends (and the magnets start).
  • Ropm = Radius at which the magnet centres are placed, for the outer rotor.
  • Bopm = Outer rotor magnet bulge. Same logic as before, but this time the delta is used to retract the magnets towards the inside, so that the corners touch the rotor face.
  • Ror = Radius at which the outer rotor magnetic core ends (and the magnets start).

There. It isn’t everything, but it is enough for anyone to get started. Now hack it up!

I’ve been just talking about regenerative braking for too long. It’s time to define the requirements.

When trying to dimension ultracapacitors or batteries for regen braking, we have to take into account the energy and power of the braking in it’s worst case: from top speed down to zero, and in the shortest time possible. Let’s start with the energy (I will post again later about the power).

So, I already set the top speed at 120 km/h, and that makes it easy to calculate the total energy generated by a full-stop braking: it is equal to the total accumulated kinetic energy of the car (well, not really, the aerodynamic drag helps the braking a little – but I’ll go for the worst case for now).

So the total energy of my car at 120 km/h is:

• E = 1/2 . m . V^2 [J]
  
• E @120 = 0,5 x 1230 kg x 33^2 m/s
• E @120 = 669.735,00 J = 670 kJ = 670 kWs
• E @120 = 669.735,00 Ws / 3600 s = 186,04 Wh
  

186 Wh is easily managed into a small battery pack, whether for acceleration or braking.

Now, for the first phase of my project, I’m only considering rear-wheel motors; this means that the full braking energy will be divided by the two axles, and unevenly so, as usual. A “typical” stock car distribution of braking forces between front and rear axles is 65% / 35%, so:

• E br@120 (rear) = 0,35 x 186,04 = 65,11 Wh

However, we know that the electromechanical system is not perfect; in fact, there are people that say regenerative braking is almost useless because of all the losses. Assuming a generator + converter loss of 15%, we get:

• E br@120(rear)(effective) = 0,85 x 65,11 = 55,35 Wh

Hmm… we spent 186 Wh to accelerate the car up to 120km/h and all we get back from braking is 55 Wh. So, the regenerating efficiency is:

• Eff br@120 = 55,35 Wh / 186,04 Wh = 0,2975 = 30%

But we still have to factor in the losses of the battery itself, and consider that the energy spent on speed maintenance (air drag and rolling resistance at constant speed) is never recovered. So, I’m looking at a 30% maximum potential autonomy increase, but I know it will be less. It all depends on the driving circuit and habits.

Ok, 55 Wh is pretty ridiculous for an EV battery. But if we are talking about a “panic stop”, it is delivered at a very high rate. How high? I don’t know, so I’m taking a guess and estimating that my car could stop from 120 km/h in 10 seconds. Just for the sake of argument. This means the average braking power would be:

• P br@120(rear)(avg) = 55 Wh x 3600 s / 10 s = 19.926,00 W = 20 kW

Although 20 kW is a perfectly acceptable power level for an EV battery discharge, it may be excessive as a charging rate. And a “panic stop” involves a much higher power at the beginning of braking than at the end, so the real maximum braking power may be several times larger than 20 kW. This means I will probably need a few ultracapacitors to take the power hit.

So, how many ultracaps are we talking about? Here I have to extrapolate even further. Luckily, my new friend Guy gave me a hand here and picked out a 70 F / 2,1 V capacitor from Digikey as an example.

I have no idea what voltage the capacitor bank finishes its charge after the braking. But that is irrelevant; let’s assume we put all the caps in parallel, forcing the voltage down to a maximum of 2.1 V – then the corresponding capacitance would have to be:

• E = 55,35 Wh x 3600 s = 143.910,00 J
• E = 1/2 . C . sqr(U) <=>  C = 2 . E / sqr(U)
• C total@2,1V = 2 x 143.910,00 J  / sqr(2,1 V) = 65,2 kF

And the necessary number of capacitors would be:

• N @2,1V = 65.265,31 F / 70 F = 933 capacitors
  

Ordering 1000 caps, the price would be 6,912 USD per unit, or:

• Total Cap Cost @2,1V = 1000 x 6,912 USD = 6.912,00 USD

Yes, 7000 USD is expensive, but still realistically achievable.

Now, something tells me I shouldn’t be getting away with putting all those caps in parallel…

The way I see it, I’ll always need some controller in between the motor and the capacitor bank to regulate the motor braking current and the battery charging current; why can’t it work at such a low voltage as 2,1V? The only disadvantage I see is having a bidirectional “buck/boost” converter there, which would be expensive to build and complicated to manage, and probably inefficient. Another disadvantage would be the very large currents that circulate between capacitor bank and motor, and even between capacitors – also not good for efficiency.

So let’s try another approach. Let’s put enough caps in series to make them withstand 100 V and call that a module.

• N caps / module @100V = 100 V / 2,1 V = 48 capacitors / module
  
• C / module @100V = 70 F / 48 = 1,458 F / module
  
• C total@100V = 2 x 143.910,00 J  / sqr(100 V) = 28,782 F
• N modules @100V = 28,782 / 1,458 = 20 modules
• N @100V = 20 * 48 = 960 caps
• Total Cap Cost @100V = 1000 x 6,912 USD = 6.912,00 USD

So, here we are at the same place again. 6.912 USD or 4.713 EUR at today’s rate.

When it comes to Energy, it doesn’t really matter how you wire the capacitors, they store the same. The small difference between the two options is due to rounding imprecision. Parallel or series is only a question of how much Voltage and Current you need for your circuit.

The fundamental question is: is 15% ~ 25% increase in autonomy worth $7.000 (€5.000) to you?

I bet most DIY builders will answer NO.

So, another new friend (John) suggested a composite solution: tie an Ultracap bank to a Lithium Phosphate bank and then to a Lead Acid bank… like this:

1. High energy / Low Power store: The Lead-Acid bank will provide a large and cheap(er) energy store, but will not be able to accept very high (dis)charging power;
2. High Power / Low Energy store: The Ultracap bank will provide an expensive but very high power energy store, but it’s limited capacity will not handle the larger energy bursts;
3. Medium Energy / Medium Power store: The Lithium-Phosphate bank will provide a compromise between the two, allowing the energy from the Ultracaps to flow to the Lead-Acid bank only after crossing the Lithium-Phosphate.

It’s much like a large electronic circuit: you have your big power supply feeding a group of circuits, then each bus has it’s own big capacitor, then each consumer device has it’s own small capacitor. Distributed energy system. Divide and conquer. This way we reduce the system cost by reducing the amount of High Power components, without lowering the requirements.

As with any composite system, the problem here is the correct dimensioning. Where is the sweet spot? How large must each of the banks be, in order to make the overall solution financially acceptable?

That will be the subject of another study….

——- Addendum ——-

At the request of John, here goes the math for the full 4-wheel-drive system with industrial-grade efficiency (95%).

• E k@120 = 669.735,00 J
• E br@120(4×4,effective) = 0,95 x 669.735,00 = 636,3 kJ

The example capacitor implementation would cost:

• C total@2,1V = 2 x 636.248,25 J  / 2,1^2 V = 288,5 kF
  
• N @2,1V = 288.547,96 F / 70 F = 4.123 capacitors!!!
  
• Total Cap Cost @2,1V = 4.122 x 6,912 USD = 28.492,5 USD
• …which constitutes a mere fantasy at any level.

Now, replace the caps with the LiFePo4 batteries that John suggested (3,2V/40Ah/87,99USD):

• E k@120 = 669.735,00 Ws / 3600 s = 186,04 Wh
• E br@120(4×4,effective) = 0,95 x 186,04 = 176,74 Wh
• Q total@3,2V = 176,738 Wh / 3,2V = 55,23 Ah
• N @3,2V =  55,23 Ah / 40 Ah = 2 batteries (with 27,5% spare charge!)
• Total battery cost @ 3,2V = 2 * 87,99USD = 175,98 USD
• …which is 2 orders of magnitude below the cost of the caps.

But these calculations do not account for the charging current limit of the batteries. If we take the average power for a 10 second braking and the continuous charging current limit of these batteries (3C=120A), we get:

• P br@120(4×4,effective,avg) = 176,738 Wh x 3600 s / 10 s = 63.625,68 W = 64 kW
• U br@120(4×4,effective,avg) = 63.625,68 W / 120 A = 530,21 V
• N @530,21V = 530,21 V / 3,2 V = 166 batteries!!!
• Or
• I br@120(4×4,effective,avg) = 63.625,68 W / 3,2 V = 19,9 kA
• N @3,2V = 19.883,025 A / 120 A = 166 batteries all the same.
• Total LiFePo4 cost = 166 * 87,99 USD = 14.606,34 USD
• …which just means that the chosen batteries are too big: they support too little power and too much energy, and the usual (H)EV manufacturer approach of many small cells is the only way to support higher power.

It remains to do a recalculation with a smaller LiFePo4 cell size (like A123’s cells that can charge at 4,5C)… but I bet a composite solution with ultra caps and batteries must be devised…

Meanwhile, I’ve come across a new type of Lithium chemistry battery that is (almost) commercially available and promises even better performance than LiFePO4: Lithium-Titanate (LiTO). Toshiba’s “SCiB” 24V/4.2Ah pack apparently delivers the same performance as a capacitor; they state charging currents in the order of 12C, which is far better than the available LiFePO4’s 3~5C.

So, redoing the power math with these SCiBs (24V/4,2Ah/50A):

• P br@120(4×4,effective,avg) = 64kW
• U br@120(4×4,effective,avg) = 63.625,68W / 50A = 1,3 kV
• N @1272,51V = 1.272,51V / 24V= 53 batteries
• Since the price has not been published yet, I’m going to extrapolate the total cost. I’ll imagine these new batteries will cost 25% more than an equivalent 25,9V/4Ah Lithium-Polymer pack: 1,25 x 200 USD = 250 USD.
• Total LiTO batt cost = 53 * 250 USD = 13.250 USD
• And they would pack a nice energy capacity of 53 x 4,2Ah x 24V = 5,3kWh, which would be sufficient for 5.342,4Wh / 176,74 Wh = 30 full-stops/accelerations 0~120 km/h!

Well… 13.250 USD in batteries is better than 28.500 USD in caps, right? Especially if the batteries have a life expectancy of 3000 cycles…

The conclusion to this article is that it is trivial to store the Energy required for an acceleration from zero to top speed or resulting from a full-stop braking; however, even when contemplating very modest values of average braking power, it is quite challenging to harness the full regenerative braking Power.

I will post again exclusively on this subject. Please keep your power questions and suggestions in the box until then.

I realized it is almost impossible for a family man with a full-time job to pull this project together in useful time, especially when trying to develop a crucial and complex component such as the hub motor.

So I’m changing my life in order to accommodate the project.

I’ve enrolled in a Master of Science degree in Electrotechnical Engineering with the goal of getting some dedicated time for the project, as well as the added benefits of having access to electro and mechanical workshops and rubbing elbows with the people who actually know something about electric motors.

To start off my education, I’ve bought a very nice book on the subject of permanent magnet motors. I had been scared off by it’s price (165 USD or 163 EUR – I guess the conversion rates don’t apply when it comes to foreign books in Europe), but after John Bass told me it was good, I went ahead and ordered it.

I’ve only had time to read half a chapter, but I’ve already found the answer to a long-standing question my web readings left me with: what the hell is the difference between a “Brushless DC” motor (BLDC) and a “Permanent Magnet Synchronous” AC motor (PMSM)? The answer, just like I suspected from my readings, is: almost none. The motor design itself does not have to have any fundamental differences. The differences reside almost entirely in the electronics that control the motor. But if you were fighting for extremely high efficiency, you might introduce some magnetic optimization tricks to take advantage of the higher harmonics content of the BLDC technique. So, ultimately, you can control the very same motor with BLDC (”six-step” or “trapezoidal” waves) or PMSM (”sine” waves) electronics – you’ll just get different efficiencies, maximum torque, and torque ripple. It’s a good reading, this book. Well balanced between the theoretical maths and the textual and graphic conceptual introduction.

Having said this, my next goal is to go back to work on my motor simulation scripts and make them a lot more realistic by introducing the missing constraints (such as back-EMF and AC/harmonics). Only after that I will have enough realistic info to decide on an actual prototype design. Oh, if only I had tons of money, the damn things would be built already… what the heck, I’ll just have more geek fun then.

Speaking of scripts, if you would like to experiment with them and change them to suit your needs, feel free to do so – that’s why they are open source. My main focus is the radial flux design and the framework itself, which means my axial flux design is pretty much abandoned and in need of a maintainer. There is so much interest in axial flux these days, it would be nice if some one else picked it up and developed it. It would feel very good to develop a real extensible and flexible framework for motor simulation, and these two directions feel just right to start with. So if you’re up to the challenge, step up. I won’t bite.