Genetic mangling of electric motors

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.

Overcoming FEMM limitations

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.

Problem reduction

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.

The wheelmotor goes to school

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.

Rethinking the project

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.

Hybrid Electric Motors?!

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

A new (contributed) hub motor

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.

A map for my code

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!

The braking problem – energy analysis

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.

Back to school

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.