Wednesday, April 27, 2011

eBay Hack Charger #...idk I lost count.

It's been a while since I thought about battery charging...

...which is probably a good thing.
This might be a good time to mention that you should not take anything I say about lithium battery chargers seriously...and if you do, you are doing so at your own risk. I highly recommend buying a name-brand off-the-shelf charger and using it according to the manufacturer's instructions.

Frankly, though, my habit of going on eBay, buying the most absurd power supply I can find, and making a battery charger out of it is mostly just unfounded EVT urban legend. But I do take pride in the Cell Abuser, pictured above, which is essentially a 4V/250A power supply I bought for $100. And yes, it is attached directly to an A123 26650 cell with copper blocks and a quick-clamp. It's as close to the 8.02 ideal voltage source as you can get. The result was about as unexciting as you can imagine: the cell charged from 0 to 80% SOC in 102 seconds and to 94% SOC in 3 minutes. At the end it was...warm.

That CV-only charger was just to prove a point, though. For actual day-to-day charging of the LiFePO4 packs I use a sophisticated BMS and integrated charging system re-purposed LED power supply. The MeanWell PLC-100 and the HLG-240 lines actually make very capable 100W and 240W (respectively) CC/CV battery chargers, as I've expounded on in the past. I've been using the HLG-240-36A as BWD and Pneu Scooter's dedicated fast-charger for a long time now.

But it doesn't do cell balancing and you have to buy one specific to your pack voltage and it doesn't make cool beeping noises when it's done and and and...

Okay shut up I finally bought one of these.
Yes, I agree, it's sometimes more useful to have a charger that can handle any pack voltage and can also balance the cells at the end of a charge. For Pneu Scooter, I use separate battery balancers every...well pretty much never; it just stays balanced because A123 cells are so good. But a balance charger would come in handy when first assembling and balancing a pack. So I finally caved and bought a 1010B charger while they were in stock.

But dammit, my MeanWell was $135 and this thing was $128 and doesn't even include a way to plug it into the wall. Too bad there aren't high-current 12V power supplies available for $7...

Oh wait, there totally are.
Thanks to Sasha for the tip. This stupid thing is an obsolete Xbox 360 power supply brick. And it literally is the size of a brick, if not a little bigger. Only Microsoft needs an entire support page dedicated to a wall adapter. Apparently, it's obsolete because it's the old 203W model (12V/16.5A), but since I'm looking for high current anyway it's perfect. They're available on eBay for basically the cost of shipping.

I bought a whole box of them for $60 with free shipping.
They seem pretty easy to work with. Inside the DC output cable there are about 8 more wires than there need to be. All the yellow wires seems to be 12V and all the black wires seem to be GND. Though, there is one set of thinner-gauge yellow and black that seems kinda shady. The red and blue wires can be shorted together to turn the output on. (I guess usually the Xbox takes care of this.) A few alligator clips later and...


It's still a little bulky. If I were truly going for ultra-compactness and I had an infinite amount of money to spend, I'd get a shiny 300W TDK Lambda supply or something similar. But for basically free, this is not bad. It's better than lugging around a giant closed-frame power supply. Now, does it work?



Seems to handle a 5A charge (into a 1.8Ah LiPo) just fine. I let it run until the alligator clips started to smell funny. 

And finally, to show how it compares to the 240W MeanWell:


The 1010B/Xbox Frankenstein charger has the clear advantage of being able to handle any pack size and it can do balance charging. But the MeanWell LED sign supply still wins on size, price, robustness, and power. Verdict: I'll stick with the MeanWell for dedicated vehicle charging, but the 1010B rig will be useful for small robot packs, which vary more in size and charge current rating.

Sunday, April 10, 2011

Sensorless

I hate making excuses almost as much as I hate Toscanini's, but my project progress and posting frequency has gone way down this semester as a result of having actual work to do just to keep up with 2.007, my class on power electrons, and, oh yeah, PhD qualifier exams, Round 2. (Shout-out to all you MechE controls profs: How about a Segway problem? Eh? You know you want to.)

Doooooooo it.
Anyway, whenever it is that I am able to get back to doing real things, I've set a new target on sensorless field-oriented control. The interpolated Hall effect sensor FOC I use now works great, even at low speed, the sensor costs $3 to implement, it's mostly reliable, and it's easy to fix. So of course it's my job now to make it twitchy and unreliable, especially at low speeds, and to eat the $3 cost savings by improving the current sensors.

And there are so many ways to do sensorless control of brushless motors...

Turnigy Sentilon 100A HV
One way is just to buy a sensorless controller. Besides being a cop out, sensorless controllers like the one  above are designed for voltage-controlled RC airplane duty. They use block commutation - driving two phases and measuring EMF on the third to determine rotor position. So, no field-oriented control, no sine waves, no current limting, and only crude start-up routines. Despite all that, a large enough RC plane ESC can sometimes be made to work well for small vehicles.

And sometimes  not.
What I'm more interested in is true field-oriented control without position sensors. This means sinusoidal commutation with a high-resolution rotor position estimate, and independent control of the torque-producing current (Iq) and field-augmenting current (Id). With this type of control, all three motor phases are being driven at all times, so there is no opportunity to directly measure back EMF. Thus, a different way of deriving rotor position is required. Here's where the field diverges (lolpun) into several approaches:
  • Rotor position estimators that measure asymmetric rotor inductance using test pulses or high frequency injection. These have the advantage of working even at zero speed.
  • Open-loop back EMF or flux observers, which require a good motor model.
  • Closed-loop back EMF or flux observers, which are more forgiving.

There are at least two ways to detect the rotor position of a permanent magnet motor even at a standstill. If the rotor has saliency, its inductance is a function of electrical angle. Internal permanent magnet (IPM) motors are one good example of this, since the flux path through rotor steel changes as a function of angle. But surface permanent magnet (SPM) motors, like the ones I mostly encounter, have more-or-less constant inductance. The magnets themselves have close to the permeability of air, and the steel back-iron is rotationally symmetric.

A good sensorless algorithm could probably pick up the little magnet-retaining nubs, though...
There's another way to statically determine the position of the rotor, which relies only on the fact that motors like this operate stator teeth very near to saturation. The flux density in the most "orange" teeth in the FEMM simulation above is about 1.8T. So, driving current into that tooth's winding would not be able to increase the flux as much in the positive direction as it would in the negative direction. (Also, the rise time would be faster in the positive direction.) A clever algorithm could pick out the rotor position based on this principle.

I don't really want to write a clever algorithm, though. Measuring inductance requires good high-bandwidth current sensing, which I don't currently have, to pick out the rise time in response to a voltage step. Also, this algorithm only applies to start-up unless you use high-frequency injection to measure inductance dynamically while the phases are being driven. I'm sure there are some magic ways to do this that are cleaner than I am imagining (Rainer Nase, I'm looking at you...), but right now it's not something I want to mess this.

Moving on, then, to open-loop observers.

An observer is a control structure that attempts to recreate states which are hidden from direct sensing. Generally, an observer requires some model of the plant, so a good place to start would be a model of a three-phase brushless motor.

Engineers do it with models.
It would be nice to know the back EMF, but it's buried inside the black-box PMSM somewhere. Instead, we need to use maths:


The first maths is just stating KVL for the motor model. V and I can be measured directly, and presumably we know R and L for a given motor, so solving for back EMF, E, shouldn't be a problem. If we know the back EMF, then we know the position of the rotor. 

The second maths is an alternative open-loop observer on rotor flux linkage, which is just the integral of back EMF. This has some practical advantage over the first maths. Taking the derivative of the already-noisy current measurement will result in bad things, so even though they are physically equivalent, the smoothing integral formulation of the flux observer is more appealing in a noisy environment. Since rotor flux lines up with the permanent magnets, this also gives rotor position.

The closed-loop observers go one step further.

The motor model is only valid if resistance and inductance are known. If the model parameters are off, the estimated states will also be off. A closed-loop observer attempts to correct for modeling error with feedback. Generally speaking, the closed-loop observer goes something like this:
  1. Input the drive voltage, V, based on the PWM state.
  2. Estimate the current, i*, based on the motor model and back EMF estimate.
  3. Compare to the measured current, i.
  4. Feedback (i - i*) into the observer to modify the back EMF estimate.
"Fake motor" exists only in software.
This is less dependent on having perfectly accurate resistance and inductance parameters. The linear version of this, called a Luenberger observer, is detailed in Mevey, Chapter 7. Since I learned pretty much everything I know about brushless motor theory from Mevey's thesis, I would give a lot of weight to his particular explanation. 

There is also a slightly different feedback structure that I really like, called a sliding-mode observer. Instead of using the value of (i - i*), it uses only the sign of the error in what is aptly described as a Class D Error Amplifier, switching rapidly between a positive and a negative feedback path. The appeal of this method, covered well in Microchip AN1078, is that the switching structure clearly "eats" the current measurement noise. Right? ...... Right?

Anyway the sliding mode observer structure from AN1078 is the one I am most interested in trying, since it might even work on my existing hardware, crappy current sensors and all. The only question remaining is exactly which current and back EMF are being observed. 

Down the rabbit hole of coordinate systems we go...

Motor theory people seem to really like changing coordinate frames. Both the Luenberger observer and the sliding mode observer are most often presented as seeking the stator-frame components of current and back EMF. That is, two orthogonal components (α,β) on a coordinate plane that is tied to the stator, as opposed to (d,q) which is tied to the rotor. In a balanced three-phase system, this is a minimum set of information required to capture the state of the motor. And it makes sense to use this frame for the observed quantities because...

...because...I don't know why. They all seem to get the (α,β) flux or back EMF vector, then go back to rotor angle using an arctan function. Putting an arctan in my fast loop sounds like a horrible idea, and, excess processing power aside, I would like to avoid it if at all possible. So:

Why not observe the back EMF or the rotor flux on each phase? It's easy to do, since there are no coordinate transformations involved. The fast loop can certainly handle the numeric integration and sliding-mode compensator on all three phases. (It would have to do two components plus a coordinate transform and an arctan anyway.) But then how do you get to the rotor angle? Here is where I start digging a brand new rabbit hole...

I can get the rotor angle the same way I do now. All I need are fake Hall effect sensors for my fake motor.

Since I am observing back EMF or flux on each phase, I can easily (with if statements) detect zero crossings and flag a fake Hall effect sensor transition. This can then feed my existing controller, including the sine wave interpolation, with no modification at all. The rotor angle is calculated by the existing interpolation routine with no need for arctan. It's unconventional, which I like, but I really think it will work and it's simpler than what's out there.

So far, I'm ignoring the problem of start-up, the noisy current sensors, and many other practical issues like the fact that I can't yet program my controller wirelessly and it's buried in my scooter... I'll need to solve some of these in the near future before I can really test this out. But it's on the horizon, and now that it's in writing, I have to do it...

Saturday, April 2, 2011

EVER '11


I'm back!

EVER (the international conference on Ecological Vehicles and Renewable Energies, except with the R and E reversed because it is French) is my favorite conference EVER. Last time, the Cap Kart crew and I went in 2009, confused a lot of professors, and ate crepes. This time, Charles and I went in 2011, confused a lot of professors, and ate crepes. Oh, and test-drove an electric box thing that (probably) ran on an Arduino:


...all the Nissan Leaves were spoken for, okay?

Actually, I kinda liked it because you could clearly feel all the inner workings of the electric drive. It reminded me of the Cap Kart...you had to press an LED-lit button with an arrow on it to choose forward or reverse, and it had the turning radius of a small truck. Not sure how well that bodes for commercialization, but it was fun in sport mode, anyway.

Actually, we were there to present a paper on Miniature Electric Hub Motors, which if you're new to this game, is the key technology in Pneu Scooter, BWD, and about one third of the crazy things Charles builds. Generally speaking, the miniature hub motors are more of a fun hobby for us, but we really couldn't pass up this opportunity to disrupt the atmosphere of an academic conference with them.

Yo, where can we park these?

Oh right, I forgot to mention that we brought hardware. As it turns out, both Pneu Scooter and RazEr rEVolution fit well into checked air baggage. (I took Pneu Scooter to and from Singapore as I was completing it.) The only tricky part is the lithium batteries, but according to the TSA, one large (up to 300Wh) battery installed in a device is allowed in checked baggage. Pneu Scooter's battery clocks in at 145Wh, so I should be fine, right? ... Right?

Overall, the presentation was well-received. The chair for our session was Professor Zhu, who is sort-of like a permanent magnet motor deity. In fact, at EVER '09, he delivered the keynote presentation on fractional-slot PM motors, which is exactly the type that we tend to use for the mini hub motors. Of course, then, one of our main goals was to get Prof. Zhu to test drive the scooters.

Mission accomplished.

The academic conference was fairly standard - a lot of math. The highlight, for me, was a dirt-simple explanation of sensorless control using a flux observer that is exactly what I've been looking for. Sensorless control may be silly for EVs, but I'm still willing to give it a try just to see if I can implement it on my hardware. My hunch is that I will have to improve my current sensors a bit. (3ph 4.0?)

The best thing about bringing vehicles, though, is that we got to crash some of the concurrent events, such as the two-wheel vehicle Ride and Drive...


...and the two-wheel vehicle Acceleration Test...


...which I'm not sure we were supposed to be allowed to do. Considering that the other entries all used pedal assist (and one had more than the nominal two wheels), and absolutely none of them fit in a suitcase, the mini hub motor scooters put up a good fight. I think most people were surprised; I don't know if that's because the scooters actually kept up with the e-bikes, or if it was because they had no idea where we came from or if we were even entered in the race.

Overall, another fun trip to the weird bubblestate of Monaco. I leave you with my proposal for how all suitcases should be constructed:

Fuck little plastic wheels.

Twitch Cam

Apparently, my confused little robot Twitch, Jr. is a star on Japanese television...it's been on three different shows. (Part of the MITERS Japanese TV blitz of 2011.) But Twitch recently found its true calling in life,which is not to be in front of a camera, but rather underneath one:


Not only does it look freaking epic, but it also performs exceptionally well. The extra weight of the large camera keeps all four wheels on the ground and damps a bit of Twitch's...er, twitchy...acceleration. And since it's a (piecewise) holonomic robot, it can track in and out, side to side, or pan. Or it can switch to full holonomic mode and do all three. Here's Twitch frolicking in its newfound favorite mission:

MIT Tech TV

I'll post the on-board video when I get it (not my camera, obviously). So, the next step is to build a pan-tilt rig on top and then Surveillance Twitch will be complete...coming to an HVAC duct near you.