The Soapbox PoC takes its first spins

Here it is, at long last. The Soapbox proof of concept takes to the road. Actually, to the parking lot. It’s a lot safer.

I promised video, didn’t I?

First of all, a simple systems check:

Tonight I tightened the transmission chains, they were falling off on tight curves. Also adjusted the long board to center the mass a little bit more, the tail was way too heavy. And switched the sealed lead-acid batteries with some lead-gel batteries to increase power.

And after that, a few rides and cartwheels around the place:

Not bad, for an electric vehicle that is completely unballanced and has power controllers that run away in unpredictible manners…

This thing is very much like riding a go-kart. I bet that I can get the same thrill at a quarter of the speed…

Trike assembled!

But not exactly functional…

The new brakes are assembled and tuned (as well as possible), the batteries are charged (almost), the tyres are full, and the curiosity is unbearable: will it work? there’s only one way to know: throw that switch on.

Ok, you can stop laughing now. Seriously, that’s enough. Seriously. Last warning.

It’s running in circles because one of the accelerators is producing a bad signal. It’s the one with a new Hall sensor we replaced, so it’s expected to need some tweaking.

I didn’t shoot it with a rider yet because the batteries are not supplying enough power to run the motors. That’s a problem under investigation. They should have enough power; I suspect the controllers are at the source of the mischief. At least when I take them out of the loop, the motors seem to behave with enough torque and speed.

The shiny new brakes work well enough, but my first attempts at sliding down a ramp while using only the brakes to establish direction reminded me why cars and any other vehicles with parallel wheels always have interconnected brakes: it’s nearly impossible to steer the thing by braking, we humans just don’t have the reaction speed to do it. 10 out of 10 times I ended up facing the slope; the center of mass is too far back away from the axle. Plus, the whole braking system is very cheap and unresponsive (but still reliable). Hmm… I bet I could steer it if I put in those Magura hydraulic brakes from my mountain bike… naaah, leave it alone.

If you notice the previous pictures, the frame has changed a bit; I had to replace the side boards with longer ones to accommodate the support bar for the horseshoe brakes. Now the trike weighs around 50kg with the batteries on. Talk about a heavyweight!

But before I go on with crazy tests, there’s a fundamental component still missing: the seat. Without something to press my back against, it’s almost suicidal to ride this thing. Although I haven’t managed to get past nauseated so far.

Ok, that’s just to give you a hint of what’s going on. Still a lot of work ahead, so stay tuned.

And now for something entirely different…

I’m sick of cars. Fed up with traffic, stress, and pollution. It makes no sense to drive a four-seater alone everyday.

This summer I’ve come to realize something: cars are the past. The future is in flexible personal mobility. And I’m not one to live in the past.

I had already read a thousand times in a thousand places that the way to go is to invest in public transportation and good inter-modal terminals, but that took a long time to actually sink in. So, stopping short of buying the expensive but fantastic (and pedal-less) Yikebike or the fantastically expensive eRockit, what can I do?

I actually bought my first Hybrid Electric Vehicle: a plain chinese e-bicycle (I’ll blog about it later, in depth). With it, I can go to work every day and deliver my kid to school as well. I was incredibly lucky that my township finally implemented the bicycle paths in time of my life-altering decision, and they are actually useful to me. It is a ride we both enjoy very much, and allows us to experience the pleasures of silence, fresh air, and natural beauty while we cross the green zones of our city. I get about 30km day average out of my lithium batteries and legs while leaving the gas-guzzler in the garage, so that part of my mission is accomplished.

But just because I’ve solved my mobility problem with a ready-made human hybrid, that is not the end of this project. I’m still developing MyOwnHybrid. It’s just not a car any more.

There’s been a lot of interest recently in 3-wheeled vehicles. I was initially prodded into it by another EV project developed here in Portugal (the Veeco roadster), whose owner is contemplating a 3-wheeled version. I like the 2-wheel-in-front layout a lot, because it is fundamentally stable in curves – the weight gets thrown onto the outer wheel, enhancing traction where it is needed.

Then my friend John told me he would very much like to see his wheel motors in trikes, because he also believes profoundly in the vehicle type as a solution for urban commuters. We shared a few basic ideas, I pulled my engineering friends’ wits into it as well (NJay helped a lot), and a fantastically new and bold  innovative design was born.

This design is so bold, in fact, that it seems basically infeasible – unstable to the point of being unsafe. So, to make sure the thing can actually be built and used in everyday life, I’m doing a phased approach and building some “proof-of-concept” models before the final prototype. Whenever a concept is approved, the next one gets designed and built. Think big, start small.

The basis of my trike design is the “differential steering”. Instead of doing a mechanical steering system like everybody else does, I’m fixing the 2 front wheels in a straight position, and steering the trike by giving them different speeds. Turn left by speeding up the right wheel, and vice-versa. The rear wheel is left to turn freely (a “crazy wheel”), and that’s what makes this vehicle so special (and potentially dangerous). It’s got an enormous manoeuvrability and should be very fun to ride. If you can keep it on the road, of course.

At school, the 3rd semester has started, and there is a course on “Electric Traction and Vehicles” that aims at the physics of wheel-to-ground interaction and electric traction stability and control. My teachers are quite delighted with my small project and materials and know-how are already being thrown in. I wish I had more time to work on this… it’s going too damn slow.

Enough talking, let’s have some pictures. Here is my very first life-size proof-of-concept build, affectionately called the “soapbox”.

If you’re wondering where the wheels and motors came from, I’m using materials I scavenged from a couple of e-scooters that Hotrod found in the garbage (literally!). With a little machining and creativity, the “soapbox” concept was born.

It is built to prove one thing only: that a steering-less DiffTrike can actually handle real-world rides in safety (and still be fun). I’ll be developing the electronic control on this lump of boards. Right now each wheel is controlled directly by a hand accelerator, which is really fun for a test pilot but not very practical or safe for everyday life.

I’m still waiting for the machined cog wheels for the right side wheel transmission. Once I get that, it’s soapbox derby madness time!

This is the left side wheel transmission I had to duplicate on the right side wheel:

And here is a close-up on the accelerator/brake levers I came up with for this contraption:

The brake levers are facing backwards because otherwise their weight stops the accelerator levers from returning to their upright position.

This is crazy enough to have potential. Videos are coming, I promise.

Another semester finished. Balance time and my first paper.

We finally wrapped up our group works. Yes, we dragged our feet like sloths on this one (school ended almost two months ago). Or rather, we definitely bit off more than our part-time researcher lives allow us to chew.

Anyway, if you’d like to read the more or less full account of our work in the past 4 months, here’s the “scientific article” that our teachers had us write. It’s not a real paper, it isn’t going to be published anywhere; it’s just their way of getting us to wet our toes in the vast ocean of academic research.

Personally, I liked the experience of writing the paper; but it is a hell of a lot more work than I expected (consistency is a pain in the butt). The most difficult part for me is to fit everything into just 6 pages… for a project without much to say, it sure was hard to cram everything in there!!!

As to the status of the project:

• I kind of gave up on converting a vehicle for myself – I lack the time, space, and money; I’ll probably wait a couple of years and get some factory-made electric vehicle (a Portuguese-made Nissan perhaps?); I had a guy verbally contracted to make the conversion under my supervision, but the benefits were just too small for such an investment; I’d rather do the conversion _after_ I have my own “super” motor available.
• I’ll keep working on my wheel-motor development; things are gearing up for a nice prototyping project in ISEL; I’d really like to mess around with cheap composite materials and see what kind of efficiencies I can come up with; there will always be demand for wheel motors, especially if they can be quickly customized… I think this is my best bet in eventually spending my entire time working on EV technology and propagating it freely to spike European competition in this industry (hey, big dreams power progress ).

As to the code in the repository, I intend to make a comemorative file release for people to play with, but first I have to clean up a little bit… these last few weeks have been, how should I say… intense.

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