Shane Colton

Did you know that Flinch still exists?

2012-01-29T22:19:00.000-08:00

If you don't even know what a Flinch is, I don't blame you, since I last posted about it in June 2011, and it's been sitting on a shelf ever since. It's a miniature Mecanum-wheel robot that was supposed to be a smaller companion to Twitch:

Unfortunately, I ran into trouble with the FingerTech 2.125" Mecanum wheels. The rollers are nicely-molded rubber, but the shafts are just 1/8" brass rods riding directly on the plastic hubs. Steel washers separate the rubber from the face of the plastic, but there is still way too much friction for the rollers to do what they're designed to do. (For reference, here's a smooth-driving ~40lb Mecanum wheel chassis. And here's the full ~110lb robot.)

FingerTech does sell a bearing upgrade kit, but I have my doubts. The bearings they sell are needle roller bearings, which can only handle radial force. The roller shafts can still slide sideways, allowing the metal washers to rub against the plastic face of the wheel. That, if anything, is the large-surface-area friction culprit of these wheels. So, I decided to go my own way and get much more expensive SR144ZZ ball bearings:

Pictured: Lunch money for three days.

Additionally, I bought some 1/8" ID bearing shaft shims, McMaster P/N 99040A316. These tiny shims keep the metal washers that come with the Mecanum wheel rollers separated from the inner race of the bearings, spacing them out from the side face of the wheel. This allows the ball bearings to take up the thrust load, rather than the face of the wheel. Here's the roller, stock washer, and extra shaft shim all in place on one shaft:

The next step was boring out each of the 24 roller shaft holes from 1/8" to 1/4" to accept the new bearings. Since the faces on which these holes are drilled are at 45º to the rotational axis of the wheel, and spaced 60º radially from each other, and there are two different (mirror image) wheels, this was not a simple task.

Or maybe it was, and I made it way more complicated.

In any case, I managed to increase the roller bores to 1/4" in a way that isn't idiotic. The next step in this already-too-long-and-expensive process was to take apart all the wheels:

Sigh...

Then, I pressed in the bearings one by one and...realized I only ordered half as many SR144ZZ's as I needed.

...

FFFFFFFUUUUUUUUUu

...

A few days and $70 later, I finally got around to reassembling all four wheels with the new bearings.

And after all that work I had four wheels that look exactly the same as they did before, but cost 122% more than FingerTech pretends they do. At least they will be more functional. Except they weren't, at first. After just a minute of driving around, half the bearings had slipped sideways, allowing the metal washers to contact the sides of the wheels again. This was mostly because the new bore was exactly 1/4", so the press fits were loose. So, I took all four wheels apart again...

...cursing myself for ever thinking this was a good idea.

And I very carefully added CA to each of the 48 bearings (two per shaft) to hold them in place:

I used a sharp object to spread CA around the bearing perimeter so it would wick into the bore, hopefully without getting into the bearing itself. I managed not to ruin any bearings, but the process took half a day. And then I still had to reassemble all the rollers.

I wish I could say that the result of all this Mecanum wheel re-engineering was a wonderful drivetrain that will rival Twitch for its speed and maneuverability. I wish I could say it was all worth the effort and the money. But, after putting it all together and running it, it's still only barely passable as a Mecanum, drive:

Yes, it moves sideways. But it's a jerky, bumpy, inefficient sideways. All Mecanum drives are less efficient sideways than they are forward, but this one is really fighting. It tends to rotate while moving sidways as well, which is a sign of mismatched wheel friction and bad weight distribution. That can mostly be compensated out by gyro feedback. But the gyros won't be able to stop it from bouncing around like a cockroach bot. That's mostly a function of the wheel shape and twitchy nature of small/light robots with oversized motors.

So I'm not sure how much more time or money I'm willing to spend on it. I feel like adding weight, switching to a higher gear reduction, and adding closed-loop rotation control would help a lot. But the thought of buying new gearboxes, a gyro, and possibly stiffer chassis plates makes me cringe. I'm glad it isn't just sitting half-finished on a shelf anymore, though.

tinyKart: More Abuse

2012-01-22T21:41:00.000-08:00

Poor tinyKart. Pretty much ever since we built it and it didn't fall apart, it's been put through a series of tests it was never designed for, including off-roading, hill climbing, and Radu. But this week, it was given its toughest trial yet: New England winter weather rallying. The thing about living on the coast is that it's not just snow - it's cold rain, mist, sleet, salt, slush, dirt, and sometimes snow. To really handle all the crap that occupies the ground here during the winter months, you would need something like a small tank. But to make some attempt at handling the winter season, we splash-proofed the electronics and fitted Razor Dune Buggy tires to the rear wheels:

After that, there was only one thing left to do, and that was to hand it over to our tame racing driver. Some say his urine turns snow blue, and that he doesn't believe in polar bears. All we know is...

...he's called The Stig.

The aftermath was a very snowy and very dirty tinyKart:

But it was worth it. The kart behaves as a RWD ultralight kart with a lot of torque should in low-traction conditions, which is to say that it either goes in a straight line, if you are trying to decelerate, or spins in violent circles, if you are trying to accelerate. This wonderful combination of user-selectable understeer and oversteer makes it a lot of fun to drive, though not particularly practical for real rallying.

Somebody should make a 4WD version...

Precision SMALL Prop Balancer

2012-01-18T23:07:00.000-08:00

The biggest problem I've had with my PCB quadrotor has been mechanical vibration disturbing the rate gyros and causing the angle estimate to drift or be unstable. While the small and flexible frame exaggerates the vibrations, their source is imbalance of the propellers and, to a lesser extent, the motors themselves. So far, I've been balancing the propellers by spinning them on a small allen wrench and watching which way they prefer to settle, but this is obvious not ideal. The problem is, commercial prop balancers are useless for props this size:

Here's a commercial prop balancer from Hobby King, which has "very low friction bearings" on which a shaft with conical plugs rides. There are other types that use magnets to hold the shaft. They work pretty well for large props. This one can probably be useful for 8" or larger, and the magnetic one might be able to do 5" props. Smaller props weigh less and the friction in the bearings or at the shaft/magnet contact cannot be overcome by the slight imbalance of a 4" prop. My main beef with them is pretty simple:

For small props, they work better if you ditch the bearings altogether and use them as horizontal rails. (You could even argue that the same is true for any size prop...) Why not minimize the number of rolling contacts by using the shaft directly? There is much less friction this way. It's like somebody Google'd "prop balancer" and built something that looked like it should work without thinking about a simpler way to make the same thing. There are some commercial balancers that use simple rails, and no surprise, they tend to be for boat props and RC car wheels. If they work for such small things, they must work better for large props.

I know what you're thinking: How do you know the rails are level? The answer is the key to my new precision small prop balancer:

Those are two nice-but-cheap bubble levels from McMaster, P/N 2151A65. They are aluminum-and-plastic levels for $8.51 each. Add to that one precision-ground tool steel shaft, P/N 2900A222, and you have a precision small prop balancer for about $20. I use the prop adapters that come with these small 1.5mm-shaft motors to sandwich a prop on the shaft:

Then after finding a level surface, I place the shaft on the flat aluminum edges of the levels and let gravity do the rest:

Unbalanced.

Balanced!

It's almost that simple. There are a few subtleties:

Make sure the level edges are clean and free of dust/dirt.
Make sure the set screws are tightened evenly and facing perpendicular to the prop blades, so they don't contribute to the spanwise imbalance. (They will contribute to chordwise imbalance...no way around that.)
Depending on the chordwise balance, you might get to a state where the prop seems bistable, so that it will settle on either side but never stay horizontal. If so, rotate 180º.

That's pretty much it. 4pcb's props were already pretty well-balanced, but after a bit of tweaking with the more precise balancer, it became even easier to fly. It takes off and hovers more smoothly and remains in one place for longer with no command inputs. Because of this, I took some time to learn a new trick: hand launching!

tinyKart: "Winter" Special

2012-01-08T22:03:00.000-08:00

I was planning to keep tinyKart inactive for most of the winter to upgrade the power system and move to custom controllers, figuring that it's too cold to do any test driving anyway. But for some reason it's 50ºF in early-January in Cambridge, MA. That, combined with tinyKart co-designer Max Hill being in town, along with a some other distinguished visitors, was enough reason to put the kart back together for a brief "winter" testing season.

The first things to fix up were a few loose screws in the steering assemblies. Normally, loose screws aren't a problem: take them out, add more Loctite, and re-tighten. But these screws were a little hard to access:

They're the six screws that hold the uprights together, and they were not designed to be accessed without taking the entire front chassis plate of the kart off. By dislocating some of the steering linkages, though, two out of three on each side could just barely be reached with a screwdriver. To make matters worse, they were stainless steel cross-head screws, which are easy to strip. So, after careful removal, they were replaced with alloy steel Torx-head screws which will hopefully never come loose:

Max and I also finished yet another motor swap. tinyKart started on Turnigy SK-6374-170 motors, which were excellent except for the lack of can bearings, which allowed them to tear themselves apart at high speeds. I then installed but never test drove the newer SK3-6364-190s. They have can bearings and nicer windings than the old SKs, but I'm still annoyed that they're not actually 63mm motors. They're 59mm and they have a smaller shaft than the old SKs (8mm instead of 10mm). The smaller diameter messes with the timing of the external Hall effect sensor boards I made, which were specifically designed for 63mm. The resistance of the SK3-6364-190 is also 60% higher than the old SK. So, we removed those and installed the third set of motors tinyKart has seen so far:

These are ~~Turnigy~~ EMP C6374-200s from Leaders Hobby. As far as I can tell, they're identical to the Turnigy C6374-200 that is no longer stocked on Hobby King. It is actually 63mm in diameter and it has a 10mm shaft, like the old SK. But it has a can bearing like the new SK3. The only noticeable shortfall is the messy/loose windings, characteristic of the old SK and old Turnigy motors in general. The SK3s are probably perfectly suitable motors, but right now these are a better deal, especially since Leaders Hobby ships them from the US. It's good to have a few options; I dread the day when the imported fruit-sized motors disappear and all that's left are the economically prohibitive purple-flavored ones.

Because the C6374-200 is actually 63mm, the sensor board fits nicely and the motors are relatively easy to time for forward and reasonable reverse, unlike the SK3s. These motors should have about the same amount of torque as the old SKs. Even though those were rated at 170rpm/V, our data showed something closer to 190rpm/V, almost the same as the new EMPs. These should be able to handle higher speeds, though, since they have a can bearing. At 190rpm/V and 40V, the no-load speed is 40mph. But we will have to solve the controller limits and find more testing space before that can happen.

The Kelly controllers have been okay, but quirky. When they don't like something, they cut power temporarily and give a useless "Frequent Reset" error code. It's dependent on load and motor timing, and seems to trip when the maximum current is set to 80A or above (on a 100A-rated controller). I think it's a hardware current limit being tripped by current spikes. I think the high speed firmware version would handle these motors a lot better, since the switching frequency is higher and the current ripple should be lower. But I'm not sure I want to spend $400 exploring that option when I could implement DirectDrive and, some day, have sensorless field-oriented control. For now, though, we have to live with these Kelly controllers.

We also installed new batteries to replace the 0.33kWh of LiPo high explosives that tinyKart has used up until now. This pack looks shadier, but it's LiFePO4, which is significantly less frightening to work with:

The orange straps make it safer.

The packs are custom 12S3P A123 26650 m1-sorta-B's (39.6V, 6.9Ah, about 30mΩ). They've got a little less energy storage than the LiPos (0.27kWh), so less run time per pack. But the packs are easy to swap now and can be fast-charged in under 30 minutes with Cap Kart's 15A charger. The also have a lower internal resistance than the LiPos or an equivalent pack of A123 M1A cells, which means higher peak power (theoretically up to 8kW).

With the new motors and battery installed, we took tinyKart out for some garage testing:

It's nothing as brutal as the last couple of garage runs, just making sure everything still works. The controllers seemed to be okay, although I was able to make the right side cut out a few times at full throttle. The new motors are equal in torque to the old ones, and the new battery seems fine. The handling is as wonderfully drifty as usual, and a close inspection afterwards revealed no loose parts.

So, while I sort out the details for converting it to custom controllers, we at least have something to play with if it stays warm. If not, we also have a back-up plan involving snow tires...

4pcb: √ Control Law + Teaser...

2011-12-27T22:07:00.000-08:00

Yes, I am making another post about quadrotors. A made a few minor tweaks to the control of 4pcb. The most notable is a change to the output command for each motor, after all the P[I]D controller and motor mapping. The commands are now sent through a square root function. The force produced by the props is more related to rotational speed squared than to rotational speed. The speed is roughly proportional to the command. So, to produce a corrective a force, as the PID controller would like to do, the command generated in response to angle or rate error should follow a square root-type curve. Or so the story goes.

The remap sends the command through a square root function while normalizing to 1, to preserve the command range. Something like this:

// square root remap, command range is 0-255:
command_out = 255.0*sqrt(command_in/255.0);

This keeps the maximum command at 255 and the minimum at 0, but shapes the intermediate values to be a square root function. I don't actually do it like this because square root on a microcontroller is a horrible thing. Both the input and the output are 8-bit integers, and I have plenty of memory, so I use a look-up table instead:

// I'm a horrible person, generating my LUT at run-time:
unsigned char SQRT_LUT[256];
for(unsigned int i = 0; i <= 255; i++)
{
SQRT_LUT[i] = (unsigned char)(255.0*sqrt((float)i/255.0));
}

...and later, in the loop...

command_out = SQRT_LUT[command_in];

Because it's an 8-bit integer table, there is some quantization near the extremes, but my upper and lower throttle limits (100 and 230) constrain it to a well-behaved part of the curve:

After implementing the remap, I noticed a significant improvement in the performance. For one, some of the high-frequency oscillation is gone. It doesn't seem to wiggle back and forth quickly when it's just hovering. It's also easier to hold it at a given altitude, probably due to the more linear stick-to-force relationship. I don't think it's just placebo effect, but who knows?

I also made one other ugly hack. One motor has been consistently and annoyingly slow compared to the other three, causing the roll axis to be hard to fly, especially as the battery drops below about 7.4V. I just multiplied this motor's rate gain by 1.3. I have no justification for this value, but it helps. Maybe I will replace that motor and ESC at some point. Here's some new video:

I can keep it in the air indefinitely in a small room, as long as the battery is above 7.4V. Below 7.4V, the roll axis still gets soft and it's hard to not crash into things. So for now I live with flying just a bit more than half the battery capacity. Even Charles can kinda fly it now. So it must be a little more stable.

The two hardest parts about flying it are maintaining altitude and remembering which way it's pointed. While I think you can learn to deal with both of these, I would like it to be easy enough for anyone to pick up and fly. I have, waiting to be installed, a sonar module that can be used for closed-loop altitude control. Then, the stick would control a climb rate or descent rate, but with no input it would hold altitude and you can focus on flying the rotational axes. I also have yet to implement the magnetometer on the new IMU, which can be useful for holding heading so you don't have to deal with yaw.

I really shouldn't be spending this much time on quadrotors, though. I'm pretty sure I had other things I was supposed to be working on. On that note...

......

More Sensorless

2011-12-23T19:05:00.000-08:00

I'm still tweaking the sensorless routine for Pneu Scooter. The software framework for sensorless sinusoidal commutation and field-oriented current control is set, and now I am playing with the different parameters to see if they have the effects I think they should.

First, I hypothesized in the last post that the positive relationship between current and flux estimator offset (with respect to the Hall effect sensors), seen here, was due to underestimated inductance. At high current, the rotor electrical angle predicted by the flux estimator would lead the angle interpolated from the Hall effect sensors, which I trust to be more accurate. Based on this figure, if the inductance parameter is too low, the [-IL] vector will be too short and the estimated flux vector will lead the actual flux vector at high current.

To test this, I changed only the L parameter in the sensorless code definitions, from 200μH to 300μH, leaving all other settings the same. After another 15-minute outdoor test drive, I plotted the flux estimator offset as a function of current once again. Here it is with the old data for comparison:

The effect is exactly what I thought it would be, flattening out the slope so that the offset is constant (near zero) though the entire range of load currents. I may have even gone a bit too far, creating a very slightly negative slope. But now I know that the inductance parameter has as predictable effect. The lead induced by using an inductance parameter that was 33% too low was about 20º electrical at maximum current. The error sensitivity is easy to predict using the vectors in this figure, but I will spare you the analysis in this post.

A closed-loop flux observer, which some day in the future I will certainly try out, would seek to minimize the effect of an over- or under-estimated inductance parameter. The ultimate goal would be plug-and-play sensorless that adapts to any motor on the fly. But for now, I can live with nicely-behaved dependencies like this. Though, without the parallel-processed Hall effect sensor data, I would be lost as to how to characterize any of it.

I also tried out the sensorless controller on a different motor:

The thing clamped to the table is Kitmotter, a demonstration motor with very similar characteristics to Pneu Scooter's wheel motor. They have virtually the same measured inductance. Kitmotter has a higher resistance, which I modified in the sensorless code definitions for this test. It also has a lower torque constant, which is not an explicit parameter in this sensorless algorithm. What it does mean, though, is that the flux magnitude should be lower:

And in fact it is, by a small amount. It's also interesting to see that the general form of the flux estimates is very similar for both motors. In particular, the gap between about 200º and 210º shows up in both cases. This eliminates the possibility that the gap is caused by some asymmetry in one motor's winding. It could be current sensor asymmetry, though.

Kitmotter also accidentally allowed me to test the fast overcurrent shutdown. The dangling mess of alligator clips seen above was not the best idea, and when two of the phase outputs shorted to each other, causing a large spark, the controller shut down properly and gave an overcurrent fault. No dead FET.

The next parameter I want to tweak is the low-pass filter time constant, which affects the low speed performance of the sensorless control. I mentioned that the low-pass filter causes the flux estimator to lead the true angle at low speeds, and showed the offset as a function of speed. Here it is again, but in pseudo-3D:

Is this nauseating?

Below 200rpm, the flux estimator angle is greater than the Hall effect sensor angle (trusted to be the true electrical angle). This causes the data, which should lie on the x = y plane, to slope off to the left at low speeds. Making the low-pass filter time constant longer should flatten out the plane and improve the low-speed torque. A lower "valid data" speed for switching to sensorless control will make start-up ramping, when I get around to that, just a bit easier.

I'm also worried about high-speed operation, which was the problem that magically disappeared when I made several code improvements. But, I'm still working with relatively slow motors, having commutation frequencies of 200Hz or less. I'm interested to see how things change (probably for the worse) when I try to run a non-direct-drive (indirect-drive?) motor like that of tinyKart, which can hit 750Hz or more.

More testing to come...

Sensorless Pneu Scooter: Part 2

2011-12-18T01:07:00.000-08:00

Pneu Scooter is now Sensorless Pneu Scooter! (Which means I can ride it again.)

This is the follow-up to Part 1: Where I make my code much fancier. Most of the work of the past two weeks went into setting up a new timing structure for the control code, which is summarized by this graphic. The controller has a fast loop, which runs at 15.625kHz, and a slow loop, which runs at just under 1kHz. The slow loop handles the computationally-burdensome Field-Oriented Control (FOC) calculations, and hasn't changed since I first implemented it on B.W.D. long ago. The concept of FOC is summarized in these two posts, and is shown in this, the first of many neon graphics I color-inverted for this post:

FOC seeks to keep stator current, I, in phase with back EMF, E, which is equivalent to saying that it keeps stator flux 90º ahead of rotor flux. This produces the most torque per amp. To keep the current and back EMF in phase, the voltage, V, is phase-advanced by the controller to counteract the effect of inductance.

All these quantities are treated as vectors (really, the magnitude and relative phase of a set of balanced three-phase sine waves). The coordinate system is aligned with the rotor's magnetic field (hence, "field-oriented") and the axis on which the rotor flux is at a maximum is called the Direct (D) Axis. The Quadrature (Q) Axis leads the D-Axis by 90º electrical in the direction of rotation.

Because the coordinate system is locked to and spinning with the rotor, the position of the rotor must be known with good resolution for any of this to work. Previously, I used Hall effect sensors and time-based interpolation to derive the position. But, as the name would imply, Sensorless Pneu Scooter needs new tricks that do not rely on Hall effect sensors. To obtain the rotor position, the fast loop estimates flux on all three phases. The flux estimator I chose to start with is a very simple one:

It's an "open-loop" flux observer that derives the rotor flux linkage from measured currents, driven voltages, and a good estimate of the motor's resistance, R, and inductance, L. The vector version of this flux estimator is shown in the image above. Note that the integral of a given vector is another vector which lags by 90º and is scaled by the angular frequency:

Which brings up another good point: Unlike back EMF, flux does not vary with speed, so the flux estimator should produce a constant magnitude at any speed. As the V and E vectors increase in magnitude, the scaling by ω keeps the integral-form from growing.

The figure above is actually somewhat misleading. For one, the flux estimator doesn't run in the rotating D/Q coordinate system, but rather in the stationary frame, on each of the three phases independently. Also, the estimated flux on each phase is a scalar quantity; it's just the magnitude of the rotor flux seen by that particular motor phase at that particular instant. To derive position from this, I take an unusual approach of watching for flux zero-crossings (with hysteresis) and feeding these transitions to the same interpolation routine that my Hall effect sensors would have gone to.

In this way, the flux estimator is always running in parallel with the Hall effect sensors and control can be given to either one at any point in time. Additionally, they can be compared to each other. So, as I've been test-driving with the sensorless position estimate in control, I've been logging data from both. Cue the rest of the neon graph sequence:

All of the the data in this post was recorded during a five-minute outdoor test drive with the sensorless position estimate running the field-oriented control. The top plot above shows effective regulation of Q-Axis current to follow the throttle command, and the D-Axis current being held close to zero. The bottom plot shows the speed estimates produced by both the Hall effect sensors and the flux estimator. (Both calculate speed by measuring the time for one full period of rotor flux.) They are nearly identical at all speeds, including below 100rpm.

Speed is not sufficient for control, though; the flux estimator needs to be able to accurately derive the rotor position. Comparing the rotor position derived by the flux estimator to that of the Hall effect sensors reveals the following:

The ideal case would be a straight line with a slope of one, indicating perfect agreement between the flux estimator and the Hall effect sensors. There is a good deal of noise in the position estimate, but the general 1:1 correlation is there. The flux estimator angle leads the Hall effect sensor angle slightly, shifting the entire line upwards by about 15º. This is not necessarily the fault of the flux estimator; it could be interpreted as the Hall effect sensors being about 15º behind neutral timing.

To get more of a feel for the source of the noise around the 1:1 line, I plotted the relative phase offset between the flux estimator's angle and the Hall effect sensor angle as a function of a few other quantities. First, speed:

There are several interesting bits of information in this plot:

At any speed, the band of uncertainty in the position estimate is still about 30º. Therefore, there must be factors other than speed which cause offset in the position estimate.
The bulk shift of 15º (flux estimator leading Hall effect sensors) is clear in this plot too.
At low speeds, the flux estimator leads the Hall effect sensors even more. This one is easy to explain. Instead of a pure integrator, I implemented a low-pass filter on (V-IR) as part of the flux esimator:

Pure integrator.

Low-pass filter.

The low-pass filter is used to keep the integral from drifting away. It's combined with a gain of τ, the filter time constant, so that at high frequencies it looks like a pure integrator. But at low frequencies, it has less than the -90º of phase a pure integrator would give:

At the corner frequency I chose for the low-pass filter, 0.053s, the low-pass filter causes the flux estimator to lead significantly at low speeds. The blue line in the offset vs. speed plot above is the theoretical lead induced by the low-pass filter. Setting the filter time constant to be longer would push the speed at which lead becomes significant down lower. Since the data seems to clearly show this effect, I would like to run some tests where all I change is the low-pass filter time constant. Obviously a longer time constant would be better for low speed operation. Integral drift might hurt the performance overall, though.

I also plotted the offset between the flux estimator angle and the Hall effect sensor angle as a function of load (Q-Axis current):

Here, another clear trend was revealed: the flux estimator lead increases with current. My hypothesis on this one is that the inductance estimate is low. In the first graphic of this post, the -IL vector would be too short if L were underestimated. This would cause the estimated flux to be somewhere in the upper-right quadrant, leading the true flux, which is on the D-Axis. Again, since the data shows a very clear trend, I would like to run some test where I vary only the inductance parameter to see if I can flatten out this line.

This particular dependency (position error as a function of load) is one that I think can be avoided as I pursue more advanced sensorless algorithms. A "closed-loop" flux observer would be able to more readily handle misidentified motor parameters by using feedback to adapt the motor model or negate some of the effects of the misidentified parameter. Another valid option is to have the motor parameters self-calibrate, either at power-on or dynamically as it runs.

Lastly, my favorite graph of all:

I had the data spit back the actual flux estimate on Phase A along with all the phase currents. Plotting the Phase A flux as a function of the flux estimator's angle reveals a very nice sinusoidal flux that peaks at 180º and has an amplitude of about 15-17mWb. Not coincidentally, this is close to 1/7th of the motor's per-phase back EMF constant of 0.105V/(rad/s) = 0.105Wb. (The motor has seven pole pairs.)

The three phase currents are also plotted and are bounded by nice 40A sine waves, representing maximum positive throttle. Phase A's current (yellow) leads Phase A's flux (white) by about 90º, as it should if the field-oriented control is doing its job.There's a very interesting gap in the flux estimate angle just before 210º, which is also seen as a "staircase" effect in the flux estimator angle vs. Hall effect sensor angle plot. I still haven't tracked this one down or formed a theory about it yet, but this convinces me that it's an issue inherent to the flux estimate, since this plot has nothing to do with the Hall effect sensors.

Altogether, this "simple" sensorless routine has been working very well since I modified the controller timing. I can't say I understand exactly why (or even if) the changes I made to the loop timing caused it to start working, but I'm happy that it's now producing useful data and that I have new tests to try out.

I'm even more happy that my Pneu Scooter riding ban can be lifted since it's now capable of propelling itself in 100% sensorless mode.

Sensorless Pneu Scooter: Part 1

2011-12-17T08:53:00.000-08:00

After just about one month, my voluntary moratorium on Pneu Scooter riding is officially over. Yes, that means it is now Sensorless Pneu Scooter. Even though I was distracted by flying things for a short period of time, I have made steady progress on working out the software kinks to get my first attempt at a sensorless field-oriented control strategy up and running. This is a two-week update, so I think I'll have to split it into two parts. The first part here explains most of the code tweaking I did. The second part, to come shortly, is when the sensorless control finally begins to work the way it should. How the two parts are related to each other, I don't exactly know.

Part 1: Where I make my code much fancier.

In the last update, I had been able to get Pneu Scooter running for a short indoor test drive on sensorless control. While it worked at low speed and low load, it was glitchy at anything above 20A and seemed to completely fail at 800rpm. These may have been related or unrelated problems, and I never got far enough into troubleshooting it to find out. Instead, while test-driving, one of the glitches took out the power stage, killing the FET, at least two gate drivers, and leaving a small crater where my DC current sensor used to be:

In a previous FET failure, the trace leading into the DC bus had blown, so I reinforced it with some copper braid. This moved the weakest link to the current sensor, I guess. It's worth noting that there is a 40A slow fuse in the system but it seems never to actually do anything during failures. Maybe time to go back to the magnetically-tripped circuit breaker switch. In any case, this board is toast. Even after I repair the power stage, it will only work with the DC current sensor bypassed completely. Possible motivation to design 3ph v4.0.

I switched to my back-up 3ph v3.1 controller and took some time to implement a few software improvements, including fast over-current shutdown designed to (possibly) save the FETs if (when) the sensorless control commutation glitches. I also implemented a better ADC sampling strategy to try to clean up the current measurements as much as possible. The goal was to sample phase currents at a time where no power switching is happening, since the switching transients can couple noise onto the current sensor signals.

First, the three PWM timers are synchronized (no easy task) and set to center-aligned mode, producing nested and symmetric voltage ouputs. In addition to reducing ripple on the DC bus capacitors, this has the benefit of creating a guaranteed point in time where all three PWMs are off. This is where I wanted to trigger the ADC to sample phase current. The STM32F103 has all sorts of interesting timer and ADC setup nuances that I discovered. After several days of messing around with timer and ADC configuration registers, I got to this:

Scopemas Tree.

I had to overlap the three voltage outputs to get all the traces to fit on the scope. Here, they are running with duty cycles of 25%, 50%, and 75%, just to illustrate what center-timed PWM looks like. Timer 1 is the master and the other two are synchronized to it. I set up an unused Timer 1 compare output as the trigger for the ADC, and I configured the dual ADC so I can convert two measurements simultaneously. I group and order the measurements as follows:

Phase A Current & Phase C Current
DC Current & DC Voltage
Throttle & Nothing

The phase current measurements are most important, so they go first, triggered just before the center of the "off" portion of all three PWMs. The other measurements are more heavily filtered in hardware and software, so I don't care about protecting them from the switching transients. With my ADC configuration, it takes about 1.7μs to sample the two phase current analog signals. So, I set the ADC trigger to occur about 0.85μs before dead-center and expect it to finish 0.85μs after dead-center. After that, there is about another 2μs of conversion time, when the ADC translates the sampled voltage into a digital value. Then, an interrupt is triggered which stores the result in a variable. Zooming in on the center of the PWM, the timing of the first two sample-and-converts is something like this:

This scope plot also shows the motivation for sampling the phase currents away from the transitions. The tiny bits of ringing at each switching event show up everywhere: on other voltage outputs and on the digital line being used to illustrate processor timing. So, by leaving a window where all three PWMs are off and sampling the phase currents exactly in that window, the noise is hopefully reduced. The width of this "all-off" window has to be just a bit wider than the ADC sample time of 1.7μs, so perhaps 2μs. That limits the maximum duty cycle at 15.625kHz to 2μs/64μs, about 96.8%. Since the gate drivers are bootstrapped anyway and need some off-time to work at all, this seems like a reasonable limit.

After the three sets of ADC conversions, the fast loop is triggered and runs the sensorless field-oriented control routine using the freshly-converted current measurements. I also added some fast over-current shutdown code to kill the gate drive if any of the phase currents or the DC current exceed a maximum limit, positive or negative. Hopefully the combination of cleaner current measurments and shutdown within 64μs of an overcurrent fault will have some chance of saving the FETs if there is a controller glitch.

In case the last 1,000 words weren't very clear, here's a graphic showing the controller timing in its entirety:

(Click to enlarge.)

There are still some minor tweaks I want to make to the code. One way to save a ton of time is to use the Direct Memory Access (DMA) peripheral to automatically store ADC results in memory. Theoretically, this would cut the entire ADC block down to about 10μs. I'm also still running at only 32MHz. I don't need it yet, but the processor is capable of 72MHz in case I want to add more fanciness to my fast loop.

But for now, this setup seems fine. After loading the new version of the controller, Sensorless Pneu Scooter magically started working the way it should. I didn't think I had changed anything fundamental, but the performance is much better than it was before, almost indistinguishable from the previously-sensored Pneu Scooter. I've been riding it around for a few days now with no problems.

In Part 2, I'll get to the sensorless scheme itself and the data I've collected during my few days of test driving...

Slightly More Quadrotor

2011-12-10T08:59:00.001-08:00

I promise I will put it away soon...

After some reasonable success with the new digital IMU, I decided to play around with the digital filters built into the L3G4200D 3-axis gyro to see if I could improve the performance a little more. (The accelerometer is already heavily-filtered by the complementary filter, so no need to focus much attention on that.)

In previous testing, I had determined that the gyro rate signals were incredibly noisy and that the source of the noise was not electrical but rather mechanical frame vibrations. This is a common problem and, according to many people, it can most often be solved by mounting the sensors with foam tape. For some reason, foam tape alone is not enough on this frame, so I have to resort to heavier filtering:

From top to bottom, the graphs represent digital low-pass filters (built into the gyro) with cutoff frequencies of 50Hz, 25Hz, and 12.5Hz. The left plots are the rate signals when the quadrotor is held level and the motors are run at full throttle. The right plots are the angle computed by the complementary filter.

Noise in the rate signal can cause trouble in two ways: (1) directly, by being amplified through the derivative (D) term in the control loop, and (2) indirectly, by causing random drift in the angle calculated by the complementary filter. I actually think the second problem is the bigger one, since the angle drift occurs on a long enough time scale that it doesn't get averaged out by the mechanical system. I noticed while flying that the quadrotor would drift a lot and sometimes quickly dart off in one direction, something that could be caused by the sharp jump in angle seen in the right-middle graph.

With heavier digital low-pass filtering, the rate signal noise is significantly reduced. The angle estimate is also more stable. The trade-off is dynamic performance. With a 12.5Hz low-pass filter, command inputs faster than that cannot be tracked. A 12.5Hz low-pass filter has a rise time of about 20ms. I tried flying with this filter and the improvement in static hovering ability greatly outweighs any decrease in response time. Here's some new video:

It doesn't drift as much and the random darting is significantly reduced, at least to the point where it can be controlled. It still lacks altitude control, so maintaining height is difficult. But the improvement just by tweaking the filters is pretty neat.

I also finally compiled the documentation for this project. It's certainly not a fully-tested and user-friendly kit, but if you want to make your own, here is the documentation folder:

4pcb_DOC.zip (1.38MB)

It's also on the project page. It contains:

Full bill of materials
EAGLE files
Gerber board files
Schematic
Arduino project
Executable control station GUI
Control station GUI source (VB .NET)
Picture showing mounting of IMU

The most important change from the original schematic is that the Sparkfun IMU, which has been discontinued, is not used. Instead, the Pololu minIMU-9 is externally wired into SDA, SCL, +5V and GND. Since the IMU needs to be creatively mounted on a ball of foam tape anyway, I did not include it in the board schematic. The power wiring to the motor control chips is also done externally, connecting to the pads near each chip. In a future version of the board I may clean all this up.

PCB Quadrotor: New Digital IMU

2011-12-05T13:07:00.001-08:00

Over the weekend I took a break from my sensorless FOC work to upgrade 4pcb with a new digital IMU:

It's a Pololu MinIMU-9, featuring an ST L3G4200D 3-axis gyro and LSM303DLM 3-axis accelerometer and magnetometer. This replaces the now-discontinued Sparkfun 6DOF Razor IMU, which had six analog channels (3-axis gyro and 3-axis accelerometer). So, instead of reading each axis into the Arduino Mini's 10-bit ADC, the digital IMU streams 12-bit readings over a 2-wire serial interface (I2C).

The digital IMU has other nice features as well, such as programmable gains, sampling rates, and low-pass filters. No more fidgeting with RC filters on the board. It's compatible with the Arduino Two-Wire Interface (TWI/I2C) library and the sample code on the Pololu page is easy to work with. For once, I must admit that the Arduino I2C stuff does in fact make life easier.

Even with the nice new IMU, 4pcb still seems to suffer from the same vibration problems. I'm not sure why most people are able to get away with just mounting the sensors on some foam but that doesn't seem to be enough for this frame. In order for it to be even flyable, I need to add mass (aluminum) to the back of the IMU board and stick it to a very loose loop of foam tape:

Even the wires connecting the IMU to the main board need to be very flexible high-strand-count wire so as not to transmit vibrations. I should really film it in high speed and be horrified at the amount of high-frequency flexing happening in the frame. It would also be very easy to add stiffeners, though I would have to think about how much I want to compromise on the "entirely made out of a single PCB" goal.

In any case, with the foam loop mounting and carefully-chosen filters, it works:

It's certainly flyable with not much skill and it can stay aloft much longer than in previous testing. The roll axis seems to be more prone to oscillation than the pitch axis, which is something I'll have to look into. I'm not sure it will ever be the type of quadrotor that can sit and hover in one place for an extended period of time with little input from the user. Given its size and minimal sensor set (no GPS, no altimeter), it might always be a little twitchy. But at least it's robust; it's almost never damaged in a crash and even if it is, I have enough spare parts to last forever. And it poses no risk to human life...

First Sensorless FOC Test Drive

2011-12-04T10:58:00.001-08:00

Having done enough computational optimization of the flux observer math and tested the sensorless sine commutation with no load, the next obvious step was to test drive it on Pneu Scooter:

Well, no, the next obvious step would have been to run it under load with the Hall effect sensors but collect data from the flux observer in parallel to ensure that it is working. But I guess I skipped over that step.

As you can see in the video, the open-loop flux observer appears to work very well at low speeds. There is no start-up ramp in the code right now; I just nudge the scooter very slightly forward and it picks up commutation right away. It's able to find the position of the rotor at speeds down to 50rpm, which is less than 5% of the maximum speed. Here's a slice of data from one of these low-speed runs, showing the flux observer speed estimate matching up with the Hall effect sensor speed in the range of 50-400rpm:

Here's the comparison of estimated rotor electrical angles for the same data range:

The 1:1 correlation is not as tight as that of the no-load test. The additional noise is most likely caused by the current sensors, and is a target for improvement. The current sensors on this particular controller have always been noisy. When I was in Singapore last year, I confirmed that the source of noise was the PWM. I later added better filtering and that made the sensors much more usable. But one thing I've wanted to try for a while is more intelligent ADC sampling, where the ADC is triggered in the middle of a PWM pulse, away from the noisy transitions:

In order to do this on 3ph v3.1, I will need to mess with the timers a bit. Each of the three phases of PWM are controlled by different timers (for very good reasons, I assure you). So before I can have them trigger the ADC, I will need to synchronize them and change the PWMs to be center-timed, all things the 1072-page STM32F103 reference manual ensures me are possible.

Current sensor noise isn't the only problem left to solve, though. Somehow, the flux observer works very well at low speed, where sensorless routines are supposed to struggle, but it fails at high speeds, where they should do well thanks to the large back EMF. The speed at which this happens, under no-load operation, is strongly dependent on the low-pass filter time constant I use for integrating V-IR. (I swear this low-pass filter is evil.)

During the process of tweaking the low-pass filter time constant, I was able to bump up the speed of the flux estimator. But this time when it failed at the higher speed, it took out one phase worth of MOSFETs with it. So I'll have to replace the whole IXYS GWM100-01X1 module and/or switch to the spare controller. That gives me an opportunity to implement a few other improvements:

Center-timed PWM with clean ADC triggering, as discussed above. I may even try to use the Direct
Memory Access (DMA) to fully automate the ADC and save processor time.
Faster fast loop. I don't want the fast loop and the ADC sampling to run into each other, so I will put the entire fast loop at PWM frequency, as it was on 3ph v2.1. The timer interrupt will trigger the ADC, then the End-of-Conversion interrupt will trigger the fast loop.
Fast-loop current fault protection. If any phase current measurement exceeds some threshold, it will trigger gate driver shutdown in the fast loop, within 64μs. This might help protect the MOSFETs from destruction in the (likely/certain) event of commutation failure.
More data. I would like to transmit some of the intermediate variables in the flux estimator so I can maybe see more clearly why it fails at high speed.

Hopefully with all these changes, testing will go more smoothly this week.

First instance of sensorless sine commutation!

2011-11-29T09:38:00.001-08:00

I won't quite call it sensorless field-oriented control yet, because it's still running open-loop sinusoidal commutation, but I've finally been able to yank the sensor cable:

Here's the proof in data:

(Cap Kart's fancy data logger has certainly come in handy.)

What you see there is a plot (in time) of the motor RPM as measured directly by the Hall effect sensors (yellow) and indirectly by the open-loop flux estimator (blue). At first, both RPM measurements are running simultaneously and they overlap. At the point where the sensor cable is yanked, the RPM measurement from the sensors freezes and then times out to zero, but the flux estimator RPM continues to read properly. The commutation is being controlled by the flux estimator only and the motor continues to run, even under load.

For this test, the motor is being driven by a 12.5% command, which means the peak-to-peak value of the sine waves is 12.5% of the DC voltage. The no-load speed is therefore about 12.5% of maximum. The loaded speed dips to as low as about 6% during the test. This is a good sign that the flux estimator is capable of working at low speeds where the back EMF is small. I haven't written the start-up ramp yet, but this test tells me that I should be able to exit the start-up mode at less than 10% speed.

The properly-functioning flux estimator did not come easy. As I mentioned last time, I converted all the floating-point math to fixed-point 32-bit integer math to get the estimator to run at 10kHz. This led to several instances of both loss-of-precision and overflow problems. The biggest culprit was a low-pass filter being used as a pseudo-integrator on (V-IR). Here's how it looks in floating-point:

vir_a = 0.9996 * vir_a + 0.0004 * vir_a_temp;

Every 100μs, the variable vir_a is decreased by 0.04% and the same percentage of a new value, vir_a_temp, is added in. Since this happens 10,000 times per second, the overall effect is that of a low-pass filter with a time constant of 0.25s. The simple conversion to fixed-point math would be:

vir_a = vir_a * 9996 / 10000 + vir_a_temp * 4 / 10000;

The constants are moved to the opposite side of the variables so that left-to-right order of operations doesn't yield zero all the time. (9996 / 10000 = 0 in integer math.) But that's not the only issue:

[Start of horrible multi-day debugging sequence:]

If vir_a_temp is less than about 10^6, the minimum tolerable precision (~1%) of the second term is lost. Since the physical unit of vir_a and vir_a_temp is Webers, this means working in μWb or even nWb depending on the expected flux.

But, if vir_a is greater than 10^6, then the first multiplication of the first term, vir_a * 9996, overflows a 32-bit signed integer.

Okay, no problem, let's just change the order of operations in the first term:

vir_a = vir_a / 10000 * 9996 + ...

Problem solved? Actually, no. Think about what happens on the first two iterations with vir_a_temp set to 10^6 and vir_a intially at zero.

(1) vir_a = 0 / 10000 * 9996 + 1000000 * 4 / 10000;

The result is 400.

(2) vir_a = 400 / 10000 * 9996 + 1000000 * 4 / 10000;

The results is...400 again. The first term is zero.You can probably see the problem. vir_a will never increase because the divide by 10000 kills off the small initial values completely. So, you can't divide by 10000 first because it kills the small initial values, and you can't multiply by 9996 first because it overflows the large steady-state values. My solution is so horrible that I'm actually ashamed to post it:

if((vir_a <= 214748) && (vir_a >= -214748))

{ vir_a = vir_a * 9996 / 10000; }

else

{ vir_a = vir_a / 10000 * 9996; }

(Note: 214748 is 2^31 / 10000)

There must be a more elegant way to do this...

[End of horrible multi-day debugging sequence.]

After sorting out that mess, I could finally get to the interesting part, which was actually testing the flux estimator to see if it works. Because I opted to paste the flux estimator directly in parallel with my existing sensor-based control code, the testing was greatly simplified:

At all times, the Hall effect sensors are being read and a rotor electrical angle is interpolated from them. Separately, the flux estimator is running on all three phases. At flux zero-crossings, a "virtual Hall effect sensor" transition is generated. The rotor electrical angle based on flux is interpolated from these virtual Hall effect sensor transitions, using the same method as the real sensors. This is where the two methods intersect, and either electrical angle can be fed into the field-oriented control algorithm (or, in this case, directly into the sine wave generator).

Both electrical angles (from flux and from sensors) are recorded and periodically transmitted to the data logger. Because the commutation frequency is much greater than the transmit frequency, plotting either angle against time would not be very informative. But, plotting them against each other tells the whole story:

The rotor electrical angle derived from Hall effect sensors, which were properly sequenced and timed, is nicely correlated to the rotor angle derived from the flux estimator. The "virtual Hall effect sensors" from the flux estimator do not require sequencing or timing, since they are linked to the correct phase variables already. (No more guessing wire combinations!)

There is a bit of a staircase effect which I have yet to determine a cause for. There are also still a few bugs to track down, including something that is causing the field-oriented control to freak out. And I haven't even begun to write in the start-up and fault detection, but at least progress has finally been made.

Ah, software optimization, my old friend. It's been a while.

2011-11-19T14:41:00.001-08:00

In a somewhat drastic attempt to force myself to get work done, I have decided not to ride Pneu Scooter until I implement sensorless field-oriented control on its controller, a 3ph 3.1 board that's been happily commutating the motor off Hall effect sensors for something like 2-3 million electrical cycles. It's pretty much an ideal test platform since the motor is well-characterized (I built it.) and the controller is known to be reliable. It's also a relatively low-frequency system (175Hz at top speed), so the sensorless algorithm need not be absurdly fast to keep up with the commutation frequency. But, I do plan to use this algorithm on faster motors, so I'm designing for higher frequencies anyway.

The highest frequency the controller could run at is the PWM frequency, in this case 15.6kHz. Above this speed, it's not possible to update the commanded voltage to the motor fast enough, since the PWM duty cycle is not latched into a timer until the next PWM cycle. So, even if you could run a sensorless algorithm faster, there would be almost no point.

Back when I was using the MSP430F2274, I ran a "fast loop" at 14.4kHz (PWM frequency) to handle sensor polling, speed estimation, position interpolation, and updating the three phase motor PWMs from a sine look-up table. The "slow loop" ran at 122Hz and handled current sampling, coordinate transformation into the rotating reference frame, and feedback control of the q-axis and d-axis currents.

This.

On that processor, which doesn't have a hardware multiplier, getting the fast loop to run at 14.4kHz was a major challenge. I spent a large portion of the development time just optimizing the software using a number of tricks to get the processing time down to 53μs (for two motors). The largest single processor burden, accounting for 10μs, was the integer division required to get the speed of the motor, 1/(time per cycle). This was large enough that I couldn't compute both motor speeds in the same fast loop cycle; one always got priority.

High = processor in use. Low = processor free. The lighter portion of the trace is the single integer division.

Even totally optimized with all integer math (no floating-point), the dual FOC was just barely able to fit in the fast loop at 14.4kHz. The leftover processor time went to the slow loop, which could be run arbitrarily slow thanks to the coordinate transformation to the rotating frame. So, having floating-point controller math in the slow loop has never been an issue.

But now, I've moved on to the STM32F103 32-bit ARM processor, which has a hardware multiplier. Though so far I haven't done anything other than waste the extra processing power on silly things, one of my motivations for giving up my beloved MSP430 was to be able to implement sensorless field-oriented control. But first, for comparison, here's what single-motor FOC code looks like ported to the STM32F103:

The fast loop on this processor runs at 10kHz. It's no longer tied to the PWM frequency, so it's easy to change. I chose 10kHz for simple math. Using the same clock speed as the MSP430, single-motor FOC takes just under 7us. The integer operations, including multiplication, happen in one clock cycle instead of the 50-60 it took on the MSP430. Integer division is also fast, though to the best of my knowledge it isn't single-cycle. And these are 32-bit operands, so they inherently have more precision than the MSP430's 16-bit integers.

What about floating-point? I thought maybe the fast integer hardware would be leveraged somehow to make floating-point operations faster as well, even though the STM32F1-series does not have a hardware floating-point unit. So, I threw on my first attempt at a rotor flux observer, all implemented in floating-point math, to test this.

Mathematical Tangent:

The rotor flux observer, used to estimate the position of the rotor magnets in lieu of Hall effect sensors, is a simple one that I mentioned before:

It's an open-loop rotor flux observer, meaning there is no feedback to correct the estimated flux. It relies on a reasonably accurate estimate of R and L (the motor resistance and inductance, respectively) to produce the flux estimate. I did a little more thinking and decided that this is a good place to start, instead of jumping right into closed-loop flux observers. The nice things about the open-loop rotor flux estimator, in my view, are:

It's very obvious what it's doing, in the context of the motor electrical model. In my experience, simple things tend to work more reliably.
It estimates flux, instead of back EMF. The value of flux is speed-independent, so the amplitude of the flux estimate should remain constant. The integrator also filters out noise in the current measurement. No derivative of current is required.
The effect of parameter offset is easy to analyze. More on this in a later post, but it's easy to show with simple geometrical arguments what the effect of an improperly-set R or L is.

I think in time I will move back toward the closed-loop observer, which can compensate for the parameter offset automatically, but for now this is what I'm starting with. So, the fast-loop code must sample the phase current sensors and the DC voltage. Phase voltage is computed as a duty cycle fraction of the DC voltage, based on the sine look-up table. The integration is implemented as a low-pass filter, to kill off DC offset.

All three phase fluxes are estimated, and used to establish the motor position through what I will call "virtual Hall effect sensors" that detect flux zero-crossings. This method, though completely non-traditional and probably stupid, allows me to tape the flux observers to the back of my existing sensor-based FOC code and get up and running quickly.

Okay back to software:

Implementing the above open-loop flux estimator in all floating-point math was a terrible idea:

It looks like the processor utilization is 99%, but it's actually more like 120%. The 10kHz loop took so long that it actually took 120μs to finish each cycle...so I'm not even sure if it really finished or if the interrupt controller just gave up. The flux observer alone took about 80μs to run. I determined that each floating point multiply was taking about 7.44μs, or close to 120 clock cycles at 16MHz. So clearly the floating point math is still being done in software, and it's not really leveraging the hardware multiplier at all to speed things up.

So began a day or two of modifying the code to run faster without actually changing what it does. Software optimization is probably one of the most thankless tasks ever, since you make something work the same way it did before and nobody can see the difference. But I still find it somewhat fun to try to squeeze every bit of time out of a control loop.

First, I now have the ability to stick all my state variables into 32-bit integers and use the extra precision to make up for the lack of floating point capability. For example, instead of Phase A's current being represented in software as 38.7541723[A], it can be 38754[mA]. I don't care about sub-mA precision, and that still leaves me plenty of multiplication overhead. By that I mean I can still multiply the current, which fits in 17-bits of signed int, by up to 15 bits of precision without overflowing the 32-bit signed int.

For example, the floating-point current scaling would have been:

float raw_current, scaled_current;

raw_current = adc_read(CH) - offset;

scaled current = raw_current * 0.0561;

This scaled the raw ADC value to physical units of Amps. But it has more final precision than is really necessary and can be replaced with all integer math:

signed int raw_current, scaled_current;

raw_current = adc_read(CH) - offset;

scaled_current = raw_current * 561 / 10;

Now the scaled current is an integer value in mA. The intermediate precision required is about 22 bits. (12 bits for the raw ADC value plus 10 bits for the scaling operand 561.) The integer division by 10 is fast, and the precision is high enough that the truncated result is still perfectly fine.

After thus converting all the floating-point operations to integer math, the fast-loop consisting of FOC, ADC sampling, and flux observer was down to 50.5μs at 16Mhz:

This would already be good enough to run, but there are several other processing efficiency tricks I had ready to deploy. One obvious target for efficiency improvement is the ADC sampling. The STM32F103, like many other microcontrollers, uses a Successive Approximation Register (SAR) ADC, which is sort-of like a guess-and-check process for converting an analog value to digital representation. Each guess takes time, so many cycles are spent waiting for the conversion to complete. As implemented above, the processor would just sit there waiting for the sample to finish.

With the ADC settings I have been using, each sample takes 4.55μs. The fast loop samples four analog channels, taking a total of 18.2μs. For most of that time, the processor is waiting for the ADC to finish. It doesn't need to be, though, since the ADC can run on its own and trigger an interrupt when it's done converting. Implementing this was straightforward: I have the fast loop code start the ADC and then have it cycle through five samples on its own. After each sample, the ADC interrupt retrieves the data and moves on to the next sample. While waiting for the ADC, the processor returns to the main loop.

This showed only marginal improvement. The total processor utilization is still about 50%, because the idle time saved by not waiting for the ADC is offset by extra processing time to decide what to do with the data. The result is that each sample now takes about 8μs, four of which is spent converting and four of which is spent decided what the data is and where to put it. The data manipulating part can be completely eliminated by using yet another hardware feature of this processor, the Direct Memory Access (DMA) peripheral. The ADC can tell the DMA to automatically transfer data to a specified memory location, with no processor involvement. This would completely automate the sampling, and bring the total processing time for the fast loop down to about 28μs.

But, there's also another way to squeeze even more horsepower out of the STM32F103. The clock speed can be multiplied by an on-board Phase-Locked Loop (PLL) to up to 72MHz. (Right now, the 16MHz oscillator sets the clock speed directly.) I've never even bothered to try turning on the PLL, but now seemed like a good time to see what it would do. For some yet-unknown reason, I was only able to multiply my 16MHz oscillator by as much as 3.5 (or rather, divide it by two and then multiply it by seven...don't ask). That gives me 56MHz. I'm not sure why it won't go higher than that, but I suspect some hidden clock speed limit on a peripheral. But I tracked down all the obvious ones, and none were overclocked. Anyway, here's what the fast loop processor utilization looks like at 56MHz:

The entire FOC and flux estimator now take only 8μs. The ADC samples still take about 4μs, but the amount of that time spent processing data is greatly reduced. (The sampling time itself is limited by the ADC's peripheral clock speed limit of 14MHz, but the data manipulating time is based on the system clock.) The total processor utilization is now about 20%, leaving room for increasing the fast-loop rate or doing more processing for a closed-loop observer.

For now, though, I'm satisfied that the flux observer will run happily at 10kHz and I'm merging it with the FOC code I already have. Hopefully I will get to test it before Thanksgiving.

Hey Shane, why haven't you been working on your motor controllers?

2011-11-04T18:12:00.000-07:00

I haven't done much on any of my motor controller projects in a while. For example, DirectDrive hasn't been touched since the July update where it passed a 2.4kVA bench test. And I have yet to do anything other than theorize about sensorless FOC code. And that was so long ago that I would have to reread the post to remember what I was talking about. But now that the season of building and testing vehicles is winding down, and I have sworn off doing any demos, faires, expos, exhibitions, presentations, or showcases until the spring, I can actually have time to get back to motor controllers. For real this time.

First of all, even though I've been relatively pleased with the Kelly KBS36101 controllers on tinyKart, they are frustrating to work with. With the external Hall effect sensors perfectly positioned, the performance at 80A per motor is spectacular. But, if the sensors go out of timing even by just a little bit, the controllers cut out and you lose power to one or both sides. Also, they won't work at all at full current (100A) and they have issues at full speed. (The baseline KBS is only rated to 40,000erpm, which is about 75% of this motor's top speed.) Recently, with the changeover to SK3 motors, the controller bugs have just gotten buggier. So...

I pulled out its heart...

...and put it in a box.

If I'm gonna deal with buggy controllers, they might as well be my buggy controllers. DirectDrive was pretty much designed for tinyKart. If I were as hardcore as I was back in 2008 when we built Cap Kart, I would have put it on from the start. But I guess building the entire chassis was enough of a challenge and we did get quite a lot of use out of the Kelly controllers. Still, screw it, time for the complete power system overhaul.

DirectDrive has yet to be tested under any real load, so by committing it to a vehicle, I am forced to solve any to-be-revealed bugs. I guess that means I should also buy more DirectFETs and solder paste, since things rarely go well on the first version of a motor controller. I've only built one so far, but I have enough parts for a second. The payoff will be:

More power. DirectDrive is sized for 200A peak at 48V. In this application, assuming it doesn't just outright blow up (it will), it should have no trouble pushing 100A peak at 40V.

Sinusoidal field-oriented control. I'm not sure this is directly advantageous on such high-speed, low-inductance motors. But the side effect of having complete control of motor timing in software is worth it. No more screwing around with sensor positioning.

Wireless data. I can get vehicle performance data off these controllers, and use the data to help debug failures. (As opposed to the Kelly controllers, where *** ** is the universal indicator for every possible failure...)

Wireless throttle? It worked for Cap Kart.

Shedding weight. DirectDrive is a tiny bit lighter than the KBS.

For all that, the only cost is probably dozens of hours of troubleshooting...

You might also notice the new battery pack. I'm tired of worrying about LiPos and am willing to take a ~20% energy capacity cut for the peace-of-mind that comes with A123 LiFePO4 cells. But in order to match the power density of the LiPos, they will have to be m1-B cells. (The green ones, not the paper ones from that DeWalt Drill tree I found.) These have a lower internal resistance, such that a 6lb, 12S3P pack can put out bursts of 6-8kW.

But yeah, messing with tinyKart's Hall effect sensors has reminded me just how much of a pain in the ass it is. It would be really, really nice to never have to play the phase-and-sensor-musical-chairs-wiring-game ever again. I am still very convinced that vehicle-grade sensorless control is a possibility. In fact, we recently found proof:

That is a $28 shady eBay eBike controller, similar to the ones that bailed me out in Singapore. Except, it's sensorless. And the start-up doesn't suck. Unlike RC plane controllers, it ramps the output frequency and voltage gradually at start-up so that you get a smooth acceleration. It also does current (torque) control in both start-up and running modes. It's quite nice on Pneu Scooter and RazEr Revolution. But it's still dumb square wave drive, and it simply refuses to start ultra-low-resistance outrunners. However, it's proof that a smooth ramping start-up is achievable.

So, that will be my first task on the way to full sensorless field-oriented control. Start-up is regarded as the hard part of sensorless control, but for some reason I think it's easy. I will be aiming for a sinusoidal drive current with a ramping amplitude and frequency determined by some estimate of the system inertia. It may need locked-rotor detection or a way to reset and try again if it fails to achieve commutation. But I think it will be pretty easy, actually, compared to the rest of the project:

Once the speed is high enough (10%?), the fun begins. Unlike the $28 version, I will be going for full sinusoidal field-oriented control, with no direct measurement of back EMF. I'm sure this will keep me occupied in software for quite a while. It is my first big software project in a long time...and sadly I'm kind-of excited for it. So much so that I violated one of my long-standing software principles:

I split my build into multiple files. :/

I'll be implementing sensorless field-oriented control first on the 3ph 3.1, Pneu Scooter's controller. It's been totally fine ever since I replaced the FETs that died in Singapore. I'm still not 100% sure what the cause of that failure was, but since I've never seen it before or since, I will assume it was something specific (like bad sensor timing....) or just high ambient temperature and humidity. Once sensorless Pneu Scooter is up and running, I can think about porting it over to DirectDrive.

Let the season of motor controllers begin...

Strobe Attack

2011-10-27T22:37:00.000-07:00

The bad thing about having tinyKart around is that we will just keep driving it until something breaks.

Besides drifting the tires off, the only reliability problem I've seen so far with tinyKart is the motors. Electromagnetically, the Turnigy SK-6374-170's are very good. But mechanically, they suck. We already had to replace the left motor at Maker Faire because the entire rotor was loose and would shift axially until the motor locked up. Last week, the right motor suffered the same fate.

Additionally, the outside rotors are out of balance and the sound like they are going to detonate at full speed (7,500rpm). The vibrations are so bad that the entire kart needs to be clamped to a table to do a no-load test, lest it resonate like the giant aluminum flexure it is. And I'm sure all that vibration would eventually lead to more problems.

tinyKart was originally designed with the larger "melon-class" 80mm motors in mind, but the 63mm "grapefruit-class" with KBS36101 controllers is a better match for its size, weight, and performance. When we built it over the summer, the SK-6374-170 was the only 63mm or 80mm motor in stock, so we didn't have much choice. (Well, okay, we could have dropped $360 on Hacker A60's...) But now there is a new line of inexpensive Hobby King motors called SK3, and there are quite a few 63mm ones:

SK-6374-170 (left) and SK3-6364-190 (right).

They look very nice, and the construction quality is definitely improved. The SK3 has a large radial bearing on the shaft side of the rotor, making it far less prone to shaking itself apart violently at high speeds. It should also help better-constrain the rotor axially. My only real problem with the SK3 63mm motors is that they are not actually 63mm:

The outer diameter is 59mm. The stator is proportionally smaller. And because of the can bearing, the active length is reduced as well. The shaft is also smaller: 8mm instead of 10mm. They don't look much different in the pictures but if you held one in each hand you'd clearly be able to tell that the SK3 is a shrunk-down model, probably to cut materials costs while still passing it off as a 63mm motor.

All of this I would be fine with if it was as good, electromagnetically, as the old SK. But the first indication that it is not is the line-to-line resistance: 37mΩ for the SK3-6364-190 as opposed to 23mΩ for the old SK-6374-170. Normally, it wouldn't be fair to compare a 190rpm/V motor to a 170rpm/V motor. But in my testing, the old SK actually was closer to 190rpm/V anyway, so they have virtually the same back EMF constant. So, for a given amount of current, you get the same torque from each, but the new SK3 generates 60% more heat.

Maybe it's not a big deal. After all, the comparable Hacker A60 is 59mm and 32mΩ. Even at 37mΩ, the power lost to winding resistance at 80A is only 237W per motor, or about 10% of the peak power input. If, with more robust motors, the speed can be increased past the 75% please-don't-blow-up limit its been at so far, the peak power might even go up. And tinyKart has never had motor overheating problems. So, it's worth a try. Swapping motors will mean changing the pulleys to 8mm bore, but that's easy. The bigger problem is the Hall effect sensors...

Because the can diameter is 4mm smaller, the sensors are now 2mm farther from the rotor can. They're already relying on the small amount of field leaking out of the side of the can, so every millimeter counts. It turns out they have no trouble picking up the field from the larger distance and I could still time the motor in the normal way.

But, reverse sucks.

When timed correctly for forward commutation, the reverse is awful. I didn't recall this being the case on the old SK's, but a further test with them confirmed that forward and reverse have always been asymmetric. The extra distance between the sensors and the rotor can, and possibly a thicker rotor can on the SK3, seem to exaggerate the problem. I wasn't 100% sure it was a sensor problem, though. So, I went to borrow a strobotach from the Edgerton Center:

Borrowing a strobotach from the Edgerton Center is kind-of like borrowing an airplane from the Wright Brothers Museum...

This strobotach is an old-school box of vacuum tubes with a giant dial that can adjust the strobe rate. One way to use it is to point the strobe at something spinning at a constant rate and dial the knob until it appears to stop moving. Then, you can read the rpm off the dial. But, I was interested in using the external trigger, which flashes the strobe in response to an electronic signal. I tied this in to one of the Hall effect sensors. The signal bias is 54V for some reason that I'm sure has to do with the vacuum tubes, so I had to make a quick transistor trigger circuit so it would run off the 5V Hall effect signal.

To make a position indicator on the rotor, I passed a fixed current into all six permutations of phase wires and put a tick mark on a piece of yellow tape at whatever fixed position the most was held at by the current. I used three different color tick marks, for A, B, and C phase. There are seven ticks of each color around the motor, since there are seven pole pairs.

The strobe makes it very easy to see where the Hall effect sensor is firing, in forward and in reverse, as well as the physical effect of moving the sensor mount:

The strobe aliases with the video camera's frame rate a bit, but you can definitely see the tick marks. Here are still pictures of the forward and reverse case as well:

Forward.

Reverse.

I had already timed the motor to run properly in the forward direction. So, in forward, the Hall effect sensor (and the strobe) fire almost exactly on a fixed-current motor position (green). A long time ago I convinced myself that this should be the case. But, if it's firing on green in forward, it should be firing 180º electrical out of phase in reverse, or, somewhere about halfway between red and black. Instead, it's firing on the wrong side of black, about 70º away from where it should. The reversing problem is definitely a timing issue, then.

I tried a similar experiment with the old SK, for which the gap between the sensors and the rotor is much smaller, and the reverse mark was still offset from where it should be. But, it was better. Probably enough so that the SK would actually run in reverse, if not happily. I also tried making a flux-concentrating extension for the sensors:

i.e. I glued cap screw heads to the sensors.

This also brought the reverse mark closer to the correct position, but it still was offset by about 60º. I think the problem is due to the Hall effect sensor hysteresis (about 8mT for these sensors). If the field outside the can is weak enough that the total swing is only, say, +/-20mT, then the hysteresis will have a huge effect on the forward/reverse timing.

I could try getting the sensors themselves closer to the rotor, which I think will be better than gluing cap screw heads to them existing ones. I could also try more sensitive Hall effect IC's with a small hysteresis band. Of course, I would not want to have to make bunch of acrylic ones to test all this. Luckily...

Melon Checker: Now with more fruits.

2011-10-24T23:31:00.000-07:00

I've updated my Hobby King large motor inventory checker:

http://web.mit.edu/scolton/www/aremelons.html

Previously it had only the three "melon"-class motors, so-called because at 80mm OD, they are roughly the size of melons. (So called by whom? What kind of melons? Not watermelons...) These motors haven't been in stock at Hobby King in quite a long time, though they are starting to pop up in other places.

But there are other large motor candidates that are interesting to keep track of, including the brand new shiny SK3 line, which is the new "grapefruit"-class of 63mm motors. Somewhat dissapointingly, the SK3-63xx motors are actually 59mm in outer diameter. (The old 63xx grapefruit-class motors were truly 63mm.)

That said, tinyKart's older-model SK-6374-170 motors are falling apart due to poor construction and lack of a large radial can bearing. (And unrelenting abuse...) I will try replacing them with SK3-6464-190's I bought for a potential tinyKart swap a while ago. They have a can bearing and should be able to run to higher speeds without shaking themselves apart. They also weigh 1/3lb less, each. But, they have a higher resistance (37mΩ as opposed to 23mΩ), so they will generate more heat and/or less torque. Testing to come soon...

In the large motor category, there is also a durian class and a guava class that are relatively new and nicely-built. If you're interested in inexpensive RC plane motors that can be re-purposed into electric vehicle traction applications, this consolidated inventory list might help you choose.

Okay, tinyKart frightens me now.

2011-10-18T21:54:00.000-07:00

So it turns out tinyKart was hiding something...

...and by something I mean about half its full power. I know I've had nothing but good things to say so far about tinyKart, but somehow I think I underestimated it. tinyKart. Kicks. Serious. Ass. We need to make more of these things right away and race them against each other.

tinyKart was the Edgerton Center Summer Engineering Workshop's 2011 project. It's an ultralight electric go-kart, something I've dreamed about ever since Cap Kart. The total weight is 55lbs, it fits in the trunk of a car, and it has a trigger throttle. We took it to Maker Faire NY a few weeks ago, and it was a lot of fun.

But it seems this entire time it's been operating with at least one powered-back controller. The left side Kelly KBS36101 would give a "frequent reset" error and, at high sustained load, cut out entirely, leaving the kart with half power. The right side would also give errors occasionally, but rarely cut out. Then, I tried the parking garage climb and both sides cut out at full throttle. I was getting ready to ditch everything and put in my own controllers.

I guessed that the problem was bad sensor timing. I've seen it before on KBS controllers. The timing is off enough that the drive voltage and back EMF don't match up, leading to current spikes that trigger the controller's protective features. It's exaggerated by the low inductance of the brushless airplane motors. So, I went to carefully re-position the external Hall-effect sensors...

...or actually the entire sensor mount just disintegrated because I failed to remember that Loctite and plastic parts do not play nicely together. For now, I had no choice but to make a new one and forgo the Loctite, but for the future I am switching over to PCB-mounted sensors:

In addition to fixing the sensors in the correct positions and providing for up to 60º (electrical) of adjustment, the board also has a pair of jumpers which can be used to swap two sensor leads, for easy reversing. Much better than having to dig through the software, anyway. These are the first PCBs I've attempted with internal routing, in addition to the curved outside shape. It was a good opportunity to try out MyRO PCB, since Advanced Circuits does not allow internal routing on their $33 Each or Bare Bones deal. (Advanced Circuits' $33 Each deal does handle complex outside dimensions, though, as evidenced by the so-named 4pcb quadrotor.) I've dealt with MyRO before, and it seems okay. So I ordered six of these boards in a tab-routed panel...

...at least, I think I did.

The process I use for "timing" the motors is pretty simple. I set the throttle limit on the Kelly controllers to 30%, so that I can tune the sensors at a reasonable wheels-up speed without much frame vibration. Then, at max (30%) throttle, I move the sensor mount by hand within its 60º (electrical) of adjustable range until the current going into the controller is at a minimum. If the minimum is at an extreme of the adjustable range, I swap motor leads and/or reverse the direction of commutation and try again.

Minimum current means the back EMF and drive voltage are as close to in-phase as possible. (At no load / assuming zero inductance, blah blah blah.) With the new acrylic sensor mounts, I did this quickly with my clamp meter, then reset the max throttle to 75% (because the controllers and motors may or may not explode above 40,000 electrical rpm.).

And...well, a new tinyKart was born, apparently. One that is much more evil than the original one. It will happily give full power on both motors now, right up to the motor current limit (80A per side) or the battery input current limit (60A per side), or the maximum throttle (75%), whichever is lower. It accelerates as fast as Cap Kart and might even hit the same top speed if not for the throttle limit. No more play toy...it recorded a peak input power of 4.1kW on the hill climb. And the motors only eat about 200W each to heating at that power, so it's probably putting out very nearly 5hp now.

With the new, scarier tinyKart, I also took the opportunity to re-balance the two front disk brakes and change the steering ratio to give more travel on the steering wheel, and hence more mechanical advantage over the wheels. As if we had actually planned ahead, this only involved moving some pin joints to pre-drilled adjustment holes:

Drive link gets shorter by moving the ball joints closer to the steering column...

...and follower link gets longer by moving the pin joint away from the kingpin.

The length of the tie rods also changes, but that is adjustable by nuts on a threaded rod. I don't think it could have been any easier.

After that, we took it back to the parking garage (along with some other things) and the video above is the result. With 5hp available, narrow drive wheels, and low-traction parking garage concrete, it would happily lose grip coming out of turns, even while hitting the uphill slopes. That was a little surprising. But what I find amazing is that it actually happily re-finds grip as well. It does what I would expect a go-kart to do when I steer against a drift and adjust the power. This thing that we built with 80/20 and McMaster parts behaves the way I think it should, presumably from some experience driving real go-karts... I like it.

Singapore Post

2011-10-08T23:24:00.000-07:00

I was in Singapore again last week for the Singapore University of Technology and Design's first ever Open House.

When I went to Singapore last year, SUTD had just the two upper floors of a Chinese language school, mostly for administrative offices. Now, it has fully moved in to the interim campus, part of the ITE Dover Campus. We built up a small workshop ("the shed" or Gecko Works) at the interim interim campus, which has now been transplanted to a room at the interim campus:

It was cool to see the shop space I helped put together actually being used by future SUTD students and faculty to work on projects. I was expecting the interim campus to have a full shop, since it was formerly part of a technical institute, but it seems Gecko Works is still the primary fabrication space for SUTD. That makes our trip last year seem like a pretty good investment of time, actually.

As you can see in the above picture, Charles and I significantly increased the number of moving vehicles on campus, as usual. But in fact, some of the future SUTD students have been forming an Electric Vehicle Team of their own, using an electric bike we got from MKP Bikes last year as their first vehicle. It's been converted to a chopper bike, and now runs on a frightening amount of lithium polymer battery. You can see it towing half of the SUTD student population here:

Also featured in the video above are a fire ant-motivated top speed test of Pneu Scooter and Charles taking RazEr Revolution's name literally.

Pneu Scooter's officially-measured fire ant-induced top speed: 21mph.

Pneu Scooter actually took its very first test drive in Singapore last year. I finished building the frame and began testing on my 3ph v3.x line of controllers during my last trip. Unfortunately, the v3.0 controller had serious electrical noise issues, so I redesigned it when I got back and wound up with the v3.1, which has been ultra-reliable for almost a year now...

...and then two of them broke on this trip. I don't really know what happened since both times it was being ridden by someone other than myself. (Not that I would know what exactly caused the failure if I was riding it, but I could at least eliminate some possible causes.) My theories are:

The ambient temperature in Singapore is just that much higher than it is in Boston, and the FETs failed due to thermal overload after basically racing it around all day.
Since replacing the rear wheel a few weeks ago, the motor timing had shifted enough to cause commutation failure, leading to a destructive current spike.

I would weight theory #2 a bit more heavily since both controllers (the original and the spare) had the same phase fail. In any case, having burned through even my spare controller and having neglected to pack an extra IXYS module, I went back to MKP Bikes for Plan B: an off-the-shelf e-bike controller similar to the one I used in Singapore last time when my controller also failed. With that, I was able to get through the Open House. When I got back to Cambridge, I promptly changed the FETs on my controller:

Precision MOSFET removal tool.

All the gate drive was in working order, which is unusual after a FET failure. I re-timed the motor and have been riding it around with no issues, so I still have no idea what the problem was. I am going to pretend that nothing ever happened. But I did buy all the GWM100 IXYS modules remaining on the internet.

Scootering around at the Open House was not the only thing I did in Singapore for a week. Earlier, we visited a place called evHUB, which is a Singapore-based electric vehicle conversion and R&D house. They have a somewhat hidden EV showroom/dealership with the name FSG Mobility Concepts, where I continued my trend of finding Tesla Roadsters scattered around outside the US.

In addition to the Tesla, FSG also carries the YikeBike. Rather than dedicate a paragraph of this post to describing the YikeBike, I'll just put in a video of us attempting to ride it:

I think the evHUB crew had an easier time learning how to handle Pneu Scooter than I had learning how to ride the YikeBike. Also the YikeBike is more expensive than Pneu Scooter by about the same ratio as the Tesla Roadster is to the YikeBike. So I'll stick with the kick scooters for now.

I also brought over 4pcb, my mini PCB quadrotor. It still doesn't fly spectacularly, but I wanted to bring it because I was meeting up with Ali S. to see his somewhat larger quadrotor in action...

Recursive quadrotors...

The exhibition hall actually turned out to be a perfectly reasonable place to fly a mini quadrotor and a perfectly suicidal place to test the one with 10" blades. For that reason, the mini one got a bit more air time. Here it is taking a few short hops:

It still needs work. After returning, I replaced the one weak motor and it at least hovers level now. But at some point in the near future I will replace the IMU with a different board. Not because I think it will necessarily handle the vibrations better, but because I am just sick of dealing with this one. And because Sparkfun doesn't make this one anymore.

I also got to visit most of my favorite Singaporean hobby shops and industrial centers. (I am such a bad tourist...) So overall, another successful trip to Singapore. I don't know how frequently I'll be going back, but I'm sort-of used to the climate and I seem to have a system for dealing with jet-lag. (I just sleep for the entire 25-hour set of flights.) Soon, there will be actual students and classes at SUTD, so maybe I'll go for an entire semester next year.

Because clearly this is my type of university.

For now, though, I have resolved to stop doing anything resembling a demo/expo/faire/whathaveyou for at least a few months. For one, I'm tired of answering misinformed technical questions from the slightly-more-tech-savvy-than-general public. I might just sound cranky but there's only so many times you can explain that MEMS rate sensors are not the same as flywheel gyroscopes without going crazy. Secondly, I am tired of having my vehicles turned into amusement park rides and then having to repair them after every event. And most importantly, I don't actually get any work done on new projects when I'm constantly exhibiting old ones. It's fun, but I need a break, so no more demos until at least IAP.

Now, what was I working on?...

Maker Faire NY 2011

2011-09-20T17:00:00.000-07:00

Last weekend I went down to the World Maker Faire in New York, along with some of the other builder-types from MIT and the Summer Engineering Workshop crew. Needless to say, we were responsible for most of the rideable objects on our side of the Faire:

I've been to the Cambridge Mini Maker Faire twice, but this was my first experience with one of the three World Maker Faire events. While the Mini Maker Faire probably attracts a crowd of a few thousand, the World Maker Faire numbers must be in the several tens of thousands. First off, I was amazed that a handful of people actually knew me from my blog, so here's a shout-out to the people who came by my table to say hi. I'm not as famous as certain people, but it's cool to meet my blog readers in person.

Also present was Max H., who brought TOBL to show off, and most of the tinyKart crew. A large sampling of the MITERS builders came down from Cambridge as well to show off a pair of sound-reactive EL shutter shades, giant Tesla coil driver, 3D printer, battlebot, tankboard, hub motor kick scooter, eddy current clock, and rideable freakin' hexapod.

For my part, I decided that I would attempt to bring five projects. First, my three Maker Faire veterans, Pneu Scooter, Twitch, and SegStick. Additionally, I brought 4pcb, which turned out to be an attention-getter even though I did not even attempt to fly it. I would say that quadrotors are the new Segways - the current obsession of every random tech-savvy person. But in fact, Segways are still the new Segways. For some reason, no matter what else I bring, I can't escape the Segway people. Then again, I've said a few times that the quadrotor is just two Segways and a FIRST robot, so maybe it's all inherited from one parent class of silly self-stabilizing objects.

So before I get angry, Yes, it does have an angular rate sensor, commonly known as a "gyro" for historical reasons. No, there is no mechanical flywheel keeping it balanced. No, it does not use a Kalman filter. And yes, it runs just fine on an Arduino, and it doesn't even use that much of its processing power because the code is very, very simple...much simpler than you want to think.

And that's all I want to say about quadrotors and self-balancing platforms. But here are the Maker Faire recaps for the more interesting projects:

tinyKart:

That's tinyKart in the trunk of a Ford Fusion. I loaded it into the trunk myself in about 10 minutes. It involved taking out 12 cap screws and sliding the two halves apart, then flipping the front half over so that the steering wheel rested in the seat. The back half weighs less than 40lbs and the front half weighs less than 20lbs. There was even enough extra room in the trunk for Tyler's monster Tesla coil driver.

In terms of making an ultralight, ultra portable go-kart, I consider this trip a huge success. We like to make things that don't exist, and an ultralight electric go-kart is something new. There is the Razor Ground Force, which is the same weight (55lbs) as tinyKart but there really is no comparison. Which brings me to my next point:

tinyKart is absolutely freaking awesome as a go-kart.

Just look what reverse did to this dude's hair...

We drove it all weekend and it is actually amazing to me that we built such a thing from scratch. It's a totally different experience from Cap Kart and most other go-karts I've driven, and it's more fun than any of them. "Sprightly" might be a good word. I really don't know. It darts around in ways that defy its narrow tires and flex-y frame. The acceleration is good too, despite the lack of more formidable brushless motors. The trigger throttle just makes it even more of a unique experience. And the brakes are so good that I worry about bending the steering wheel from the deceleration force. I really would not change a single thing about the mechanical design...it's pure win.

"If it's going to break, it's going to break now." -Max

It even does things it shouldn't, like off-roading. We took it on slippery grass and dirt, and it was even more fun than on asphalt. The flex-y frame doesn't mind at all and the 17mm aluminum wheel axles, which are probably the weakest link in the structural loop, survived both the shock load from bumps and side load from drifting.

Pretty much the only things that isn't 100% perfect are the controllers. Maybe I just have a high standard for motor control...well okay, I definitely do...but the Kelly controllers just aren't quite up to the task of driving full load into these motors. They cut out occasionally, leaving you with half power for a second or two. I'm learning the acceleration threshold that works, but the motors can handle more power so I feel the urge now to give tinyKart a set of controllers that can, too.

Pneu Scooter:

A few days before Maker Faire, Pneu Scooter got a flat rear tire. I knew it would happen eventually because the front tire got a flat about a month ago. Unfortunately, the 6" pneumatic casters are not conducive to easy tire/tube changes. I thought they would be, which was one of the motivators for using pneumatic tires in the first place, but as it turns out, barring special tooling, it's easier to change the entire wheel. So changing the rear wheel means taking apart the hub motor. But, really, Pneu Scooter has been ultra-reliable, so this is more like scheduled maintenance than a design flaw.

Could use a cleaning while I'm at it...

So I opened the motor for the first time since it was built. The process is pretty simple. The only tricky part is getting the three phase wires out, since they are soldered to connectors. To fit back through the bearing, they needed to be de-soldered and shoved back into the axle slot. Here are some pictures from the teardown, with everything dirty but intact:

Windings.

Outer spacer.

Dirty rotor.

Awesome adapter ring.

After taking off the adapter ring, I could get a good look at the rim and tire to see where the damage occurred. I suspected that the tire and tube had been punctured by screws that hold the ring onto the plastic rim. (The front tire suffered a similar failure.) Sure enough, I found a bunch of slashes like this:

I guess the screws were wearing through the tire and eventually the tube over time. The solution is so simple that I have no idea why I didn't do it in the first place.

Duhhhh...

So I put the motor back together with the shorter screws and Pneu Scooter was back up an running in less than three hours...

...which is great, because it actually came in really handy during Maker Faire. Not only was it the only one of my vehicles that I actually felt reasonably safe letting the annoying little kids ride, but it turned out to be the best way to get from the Citi Field parking lot to the Maker Faire itself. There were shuttle buses, but they were crowded and only took you about 60% of the distance anyway. So, I just took the scooter instead.

Twitch

Twitch also had some lingering wheel problems before Maker Faire. Specifically, the press fit holding the custom aluminum hubs to the plastic Vex omniwheels had failed on one wheel, making it hard to drive. It's happened before and I've resorted to epoxy for a quick fix, but I wanted to make a more permanent solution before the Faire. So, I manned up and got on the lathe...

...and then the mill...

... to turn out some new hubs that will actually bolt onto the wheel instead of relying on a press fit into flimsy plastic. The six-bolt pattern lines up with the spokes such that 1/4-20 screws rest against the inside surfaces to positively transmit torque to the wheel. I only put on one new hub for now, but I have the full set for when the remaining press fits fail.

As I was doing this, though, some other problems revealed themselves. One of the linkages had a stripped-out hole, and one of the servos that drive the linkages was also damaged. I suspect both were symptoms of the wheels running into hard stops while the servo continues to drive the linkage. So far, I've only been calibrating the servos by hard-coding in soft-stop values, but they change every time I take the robot apart and put it back together.

Twitchguts, if you don't remember.

I decided that after replacing the servo and fixing the linkage, the best way to prevent this problem from happening again would be to just write the damn trim software the way it should be written.

Now the servos each have a software-settable minimum and maximum value. Through some coding trickery I was able to "or" the calibrate state with the normal drive states (forward, sideways, omnidirectional) so that you can trim the servo end positions while in any one of the states. This is useful since the servo maxima occur in the forward state and the minima occur in the sideways state. And just for extra software hacker cred, I save all the trims to a text file that automatically loads when the program starts up.

Twitch was, as usual, a constant source of entertainment that filled in the gaps well while the vehicles were charging. Part of the fun of Twitch is that nobody (or very few people) have ever seen a robot move the way it does. I am finally able to drive it in the way that it deserves, making smooth state changes and combining rotation and translation in ways that just look cool. It took a lot of practice, but I feel like Twitch is finally living up to its potential. And on that note I'll just leave this here...

The great XBee 57.6kbps mystery finally solved.

2011-09-13T12:51:00.000-07:00

Ever since I started using the STM32F103 microcontroller, I've been hindered by the inability to wirelessly program the way I could with my old MSP430F2274 setup. Which sucks because that's the entire point of the wootstick (Wireless bOOTloading). The wootstick is the MCU board I've used on all my motor controllers:

The latest one, v2.0, has the STM32F103, an FTDI USB-to-UART converter, and an XBee Series 1 digital radio built on to a 3"x1" board with 2mm breakout headers. Ideally, it should:

Send and receive data over USB or over the XBee as a virtual COM port to a PC. Switching from USB to XBee wireless is seemless - no software modifications required on either side.
Be bootloader programmable through either the USB port or (with some configuration) the XBee radio. The latter option is the most useful to me, since it means the controller can be embedded in an enclosed system and still be programmed.

The USB interface works fine, but up to now, I've been able to get only half of the wireless functionality working. I can either wirelessly bootload or send and receive data over XBee, but not both. Changing from one state to the other requires reconfiguring the XBee, which is impossible if the controller is embedded in, idk, say, a scooter.

I decided I would solve this problem before moving forward on sensorless field-oriented control, or rather, that I would use it as an excuse for not making any progress for so long... I figured it would only take a day of messing around to figure out why exactly this was happening, I just hadn't actually sat down and done it up to now.

Then, as I was spending the last two weeks playing with the PCB quadrotor, I ran into almost exactly the same problem. I tried to set up the Arduino Mini on the quadrotor to be wirelessly programmable, so that I would not have to tether it to my computer every time I want to change the controller. But I found that if I set the radio to the baud rate required for the bootloader (57.6kbps, same as the STM32F103), I would get intermittent communication under radio control. Furthermore, the problem went away under USB control with the same baud rate, which suggested a problem specific to the XBee radios. And I've seen other online sources that suggest XBee trouble at 57.6kbps. So I decided to dig a little deeper.

Step one was to round up all my XBees, minus the two high-power transceivers that I have yet to get back from certain unscrupulous borrowers.

Step two was to find a real scope.

As much as I love the Tek 2445 analog scopes in MITERS and the Edgerton Center, I absolutely needed a digital scope to see what was going on at the bit level of the PC-to-XBee-to-microcontroller serial communication. So I went down to the mechatronics lab, which I now have access to since I am apparently the TA for a new course. (Have you heard?!) And there are 12 brand-new four-channel Agilent digital storage oscilloscopes with all kinds of fancy features. They can even save waveforms as .png images to a flash drive. (Something I did not find out in time for this post, as you'll soon see.)

Anyway, based on internet rumors, I suspected a problem with baud rate timing mismatch between the computer, XBee, and microcontroller. All are nominally set to 57.6kbps, but due to the limited clock frequency dividers on the XBee and the microcontroller, there is some error. First, the PC:

I zoomed way in on the first (start) bit of the transmission, something only possible with a nice set of working trigger and holdoff settings on the new scopes. The bit width is 17.34μs/b, the inverse of which is 57.67kbps. Within the error tolerance of the measurement, that's exactly correct. Next, the XBee:

A single bit on the XBee Tx pin was 17.00μs wide. This is 58.824kbps, which is what the internet suggests a XBee set to 57.6kbps actually is. The reason for this is because the XBee has a 16MHz crystal and an integer divider the produces the buad rate. If the integer divider is of the form 16MHz/(16*N), and N=17, then the exact baud rate is 58.824kbps. The next integer up, N=18, would yield 55.556kbps, which has a higher error than N=17. So the XBee uses N=17 assumes the PC can deal with the 2.1% error in baud rate, which it can.

Now here is where it gets interesting. The Arduino, when configured with Serial.begin(57600), showed up with a bit rate of 17.50μs. (Sorry, forget to take a picture of the scope...) This is 57.140kbps. It's consistent with an integer divider of the form 16MHz/(8*N) with N=35, and digging into the Arduino serial library source code suggests that this is in fact what happens. With an error of less than 1%, it's preferred over N=34, which would make it exactly equal to the XBee rate.

But, the error on the XBee is in the opposite direction as the error on the Arduino. So the total error of an XBee talking to an Arduino at 57.600kbps nominal is close to 3%. This is flirting with the maximum error tolerance of the USART, according to the ATmega328 reference manual, page 193. (Seriously, RTFM, you will not find this information on www.arduino.cc.) When you factor in the +/-1% error tolerance of the ceramic resonator used to generate the Arduino's 16MHz clock, the chance for framing errors increases even more.

Why exactly it works in the bootloader but not during normal data transmission, I don't know. Maybe it has trouble picking up bytes that are adjacent to each other, or maybe the bootloader just has better software error checking to verify the program data is correct. In any case, I took the safe route and forced the Arduino baud rate to match the XBee baud rate exactly:

Serial.begin(57600);

UCSR0A |= (1 << U2X0);

UBRR0L = 33;

Which, now that I look at it, should be the same as:

Serial.begin(57600);

UCSR0A &= ~(1 << U2X0);

UBRR0L = 16;

It's 16MHz / [16 * (16 + 1)] instead of 16MHz / [8 * (33 + 1)]. (RTFM on page 179.) The latter is preferable because slow mode has a wider error band. Either way, it forces the Arduino to have a bit rate of 58.824kHz, matching the XBee. This made the RC control much happier, and the bootloader still works. (It should be independent of the user code.)

But that was all for the Arduino. To test the clock speed deviation theory on the STM32F103, I took out DirectDrive and brushed the dust off of it:

Wasn't I going to do something with this?

I checked the USART documentation for the STM32F103 against my code only to find that the USART clock divider has significantly more resolution. Instead of an integer clock speed divider of the form 16MHz/(16*N) it is essentially 16MHz/N, and I have N=278. (For some reason, it's not quite that simple, RTFM page 768.) But the result is that it should be (and is) running at 57.55kbps. The error between this and the XBee baud rate should be within tolerance of the USART.

Additionally, sending and receiving data works just fine on the STM32F103 at 57.6kbps with 8-N-1 configuration. Only when set to 8-E-1 (even parity bit, required by the bootloader) would the wireless data transmission stop working. But the bootloader worked fine on 8-E-1, with the XBees properly configured for even parity. So now I had at least narrowed it down to a problem involving the parity bit configuration.

Interestingly, I had unknowingly managed to avoid the problem over USB, set at 57.6kbps 8-N-1, because the FTDI chip would automatically reconfigure to 8-E-1 when using the bootloader, then switch back to 8-N-1 when running user code. Only because the XBee radios are have a fixed parity setting did the problem seem to be a wireless-only issue.

I think the theme of this post is Read The Fucking Manual because after only about 10 minutes of doing just that, I found the answer:

It's right there on page 791.

Essentially, by setting the PCE bit, I thought I was appending a single, even parity bit to the end of the data frame, making it 8-E-1. Instead, it was replacing the last data bit with the parity bit, making it 7-E-1, and screwing up the entire data protocol. Only by changing the word length to 9-bit by setting the M bit could I get 8-E-1. I should point out that no other microcontroller that I've used does it this way. Setting the parity enable bit appends a parity bit to the data frame on the ATmega328 and the MSP430F2274.

Well, with that sorted out, everything works properly now. The flash bootloader works over XBee and I can send and receive data at 57.6kbps, 8-E-1. Clearly the next thing to do is ~~go back to working on sensorless control~~ make MIDI scooter play Railgun.

I should put the PCB quadrotor away...

2011-09-05T12:48:00.000-07:00

...but it's just so addicting. I implemented a few simple improvements:

On the suggestion of Max H., I added 1" nylon standoffs to each of the four corners as landing gear:

You might also notice that the motor looks a little different. Although the landing gear does the job of keeping the quadrotor level during takeoff, it also transmits much more of the impact of landing into the motor. (Previously, it was being absorbed by the LiPo battery...) Now, except in the rare soft landing, the impact would dislodge the motor can almost every time. I tried a few different types of adhesive, but they were too brittle and the surface area was too small for them to withstand the shock. In a moment rage-induced inspiration, I found a piece of heat shrink that fit over the motor and cut it so it would just overhang the can when it shrank, which is what you see above. This turned out to be the best idea of the week: after heat shrinking, there have been no further motor can failures.

With the ~~risk~~ certainty of crash landing directly on the LiPo eliminated, I also upgraded to the more potent chemistry of the Turnigy nano-tech line, specifically the 2S, 460mAh, 25-40C pack:

Can it explode just from looking at it?

It's roughly the same size, weight, voltage, and price as the lower-power LiPo I've been testing with, but it has a much lower internal resistance, which means less voltage sag under load. The difference is noticeable, with lower throttle for takeoff and also similar flight time despite the slightly lower capacity, since the motor controllers stay above their low-voltage cutoff longer.

I made one more change which has nothing to do with the quadrotor itself: I decided to take Ryan A.'s advice and fly with a PS2-style gamepad instead of a joystick:

I haven't tried flying with a Weller power supply yet...

It's generally better for controlling robots, so I'm not sure why I expected the joystick to be more appropriate for a quadrotor. The only other quadrotor I've flown used a standard RC flight transmitter, which is closer to a gamepad than a joystick. Thumbs are more precise and faster than entire arms, or even if you're doing it right, wrists. The gamepad has a spring-loaded throttle, which I thought would be problematic. But, with no altitude control anyway, I am always going to be adjusting the throttle even to hover, so it doesn't matter if I have to keep pressure on it.

Up to now, it sort-of flew, but it would tend to drift around a lot. The series of small changes helped, but I still wasn't really satisfied with stationary hovering. I had speculated that the control loop itself was working and stable, but that the zero angles in pitch and roll were wandering, causing it to sporadically dart off in some direction. With enough space, I could still catch it and bring it back to center, but the immediate goal was to be able to fly it in a small room. For that, a more consistent zero would be necessary.

To troubleshoot any further, I had to spend some time getting the data acquisition up and running. This should be easy since I've been doing it the same way forever, but for some reason it took me half a day to get the XBee radios to cooperate. And I had to settle for 19200bps transmission because 57600bps seems to be very tricky with XBees, particularly when wireless bootloading is involved. I've had the same problem with the STM32 chip, and I swear I will sit down and actually solve this soon. Anyway, once I had the data running, I did a test run at full throttle with the quadrotor held down on the bench.

My theory that the power supply was sagging, causing the ADC readings to be offset under load, was quickly disproved and replaced by a new theory:

Specifically, that the sensor signals are total garbage. What you're looking at is a plot of the angular rate signal coming from the +/-300deg/s pitch gyro...while the quadrotor is stationary. So, the noise amplitude is half the full range of the sensor. The complementary filter, which relies heavily on the gyro for computing the angle, is understandably confused, reporting an angle that wanders from -5deg to 11deg, again while the quadrotor is stationary.

And here is where I possibly violate the golden rule of troubleshooting. ("If you can hear it, it's a mechanical problem. If you can smell it, it's an electrical problem. Everything else is a software problem.") I have implemented both hardware and software filters to take out high frequency noise from the inertial sensor signals. But somehow, a massive amount of noise was still making it through. Probing with an oscilloscope revealed it to be broad-spectrum noise, including some low enough to make it through all my filters, with a little bit of an 800Hz sine wave on top of everything. The cause seems obvious now, but I'm so used to electrical noise in high-current motor controllers that I at first neglected to even think about mechanical noise. The test to separate the two was simple:

Running at full throttle with the inertial sensors off-board, the data tell the story:

The rate sensor noise is completely gone, and the angle stays much closer to zero, where it should be. This very clearly points to mechanical vibration as the source of the noise, and more so it suggests that only a mechanical solution will work; the noise is so destructive to the gyro that no amount of hardware or software filtering will take it out. So, having the inertial sensor sitting on headers is no longer an option, and it's time to break out the foam tape:

Attempt #1 used foam-tape only and replaced the headers with a long loop of flexible wire, so as not to transmit vibration through the connections.

Well now that didn't really work at all.

After this failure, I decided to switch over to the C part of the mechanical RC filter by adding some mass to the sensor board:

Sorry, Ryan.

I also made the tape thicker and looser.

The extra mass of the small aluminum plate helps the sensor board establish its own frame of reference that rejects high frequency vibrations that do make it through the tape. And the data:

Hrmmm.

Well, it doesn't look much better, visually. But the noise amplitude is a tiny bit lower and, more importantly, the angle doesn't wander around as much. (The times it does are when I was picking it up and moving it. You can tell because the rate is very clean there.) At least it gives me a little bit of hope that the vibrations can be damped enough to make the signals usable. I decided to give this configuration a chance in flight, using the best controller gains I'd established thus far:

Somewhat surprisingly, the small amount of noise reduction makes a huge difference in flight. (Well, combined with the other changes I made above.) You'll notice that I've changed venues and can actually fly it in this smaller classroom now. It still wanders around a little, but I at least feel much more in control of the wandering. I even manage to land smoothly a couple of times. And the data?

Well, that's basically still noise. Maybe there is more useful information contained in the average rate, but it's still visually lost in the noise. I think more drastic isolation measures, maybe combined with more aggressive filtering, will be required for it to give a clean rate signal. Ideally, it should reject everything above about 100Hz. Since the sensor board mass is still very low, I suspect I will need an even more compliant mount. What the heck is more compliant than loose foam tape?

But anyway, I am happy that its hovering can be contained to a 10'x10' area now...

Something Like Flight

2011-08-31T14:18:00.000-07:00

After a day of tweaking control loop settings, I've been able to fly 4pcb for at least several seconds at a time before crash landing or hitting a wall. I tried out two different control loop styles, PD control and nested angle/rate control. It's hard to tell from the video which one looks more promising. I want to say the PD control led to longer, more stable flights, but that was also earlier in the day and I was a bit hyper from coffee, so that may have had an effect.

Proportional-Derivative (PD) control would be my first instinct for stabilizing a quadrotor, since it deals directly with the two physical quantities at hand, angle (P), and angular rate (D). Each term gets multiplied by a constant, or gain, and then the sum is sent out as a command to the relevant motors. For pitch angle, the front and rear motors are used. For roll angle, the left and right motors are used. The control structure is straightforward:

The proportional term acts like a virtual spring, pulling the quadrotor back to zero angle (or whatever reference angle the joystick commands). The proportional gain (Kp) is like the spring constant, setting how stiff the virtual spring is. The derivative term acts like damper, resisting motion in either direction. The derivative gain (Kd) sets the damping constant, how viscous the virtual damper is.

With proportional gain only, the quadrotor (which has rotational inertia) will oscillate like a mass on the end of a spring. With derivative gain only, the quadrotor won't know what angle to go to. But with both, it returns to the proper angle and settles there with minimal oscillation. Choosing the exact right gains is often a matter of tweaking. A lot of tweaking.

If there is a net external torque on the quadrotor, for example due to an off-center C.G., it may also be necessary to include an integral control term that ramps up the motor command over time. With this, one motor would spin faster even when the quadrotor is level, canceling out the net external torque. Then the structure would be that of a full PID controller. I've left the integral term out for now.

There's another subtlety: because the motors and props have inertia, they can't instantly spin up to the commanded speed. The sensors, microcontroller, and ESCs also have built-in delay. So, if the gains are too high, the simple model breaks down and the quadrotor will just oscillate. This type of oscillation tends to be faster and twitchier than the proportional-only mass-spring oscillations. So yes, even more tweaking.

After tuning the PD controller for a while, I got a tip from David B. about www.openpilot.org. Now, I'm usually more of a do-it-myself-and-ignore-everyone-else's-version person, but the quadrotor loop tuning guide on openpilot is truly excellent. The video especially is really, really well done. Props (lolpun) to the creator, who can also be seen here demonstrating my ultimate goal for 4pcb, a frisbee launch.

The openpilot control loop uses a different structure, which I would call a nested or inner/outer control loop. The inner loop controls (angular) rate, and the outer loop controls angle. Both the inner and the outer loop contain a proportional (P) and an integral (I) gain, but for simplicity I will leave out the integral term.

What happens in this case is that the angle error gets multiplied by a proportional gain, Kpo, to create a desired rate. The desired rate goes into a second proportional gain, Kpi, to create the motor command. There integral terms would come in at each step, one in the outer loop and one in the inner loop. Though the documentation suggests using only one of the two possible integral terms. (In the video, both are explained.)

So, I tested this loop structure as well. In both cases, I left out the integral terms and I tweaked the gains until I was satisfied that I was getting the most stable flight I could. The values I get for PD control were Kp:1.2 and Kd:0.4. The units are a bit funky. Starting from degrees or degrees per second, these gains give you a motor command from 0 to 255. So, a 10º error would give a motor command increase of 12/255. A -20º/s error would give a motor command of -8/255.

For the nested loop, I settled on Kpo:4.0 and Kpi:0.5. Kpi has the same units a Kd from the PD controller. Kpo, though, is now in (deg/s)/deg. Confused? Well then now might be a good time for the plot twist.

They're actually the same thing.

When you ignore the integral terms, anyway, the two different control structures are actually equivalent. Kpi is Kd and the product of Kpi*Kpo is Kp. I didn't know this while I was testing, so the fact that I settled on slightly different gains (0.5 instead of 0.4 for Kpi/Kd and 4.0*0.5=2.0 instead of 1.2 for Kpi*Kpo/Kp) is probably due to the coffee. Interestingly, the gains I settled on are not far from the suggested gains on openpilot, when you convert to their unit scheme.

When you add in the integral terms, though, I think two control structures do have important differences. I couldn't exactly tell you what they are, but it's an interesting thing to think about. Since the main problem I'm seeing now is drift, integral control might be an important part of making it fly better. So that will be one of the things I'll be testing next. Along with that:

Landing gear. As suggested by Max H., I'll be trying out some nylon standoffs on the four corners. If nothing else, it will help keep the quadrotor level during takeoff. It also might minimize the motor damage on slight-to-moderate crash landings.
x-configuration. I've been using +-configuration, where forward is in line with one of the four appendages of the quadrotor. But when I think of a quadrotor, my mind sees x-configuration, where forward is halfway between two appendages. I don't know why. Also the openpilot video demonstrates x-configuration. The only possible technical advantage I can think of is that all four motors are involved in both pitch and roll, so perhaps any individual motor anomalies will be averaged out more. Or that might just be total BS.
Flying with a gamepad instead of a joystick, as suggested by Ryan A. Reaction time and precision may be improved with something more closely resembling a normal RC transmitter.
Supply voltage offset correction. I'm not sure if this is actually a problem or not, but the analog-to-digital converter references all signals to the supply voltage. If there is some deviation in the supply voltage under load, the zeros may drift. The gyros have a reference voltage that can be measured to correct for this offset, so I may at least test that voltage to see if its ADC value is varying under load. If it is, I can scale the other signals to compensate.

I would eventually like to be able to fly it in a small room. Whether I get there by tweaking the control or by practice, I don't really care...

Hurricane Special: Navbar Updates + 4pcb's First Hops

2011-08-28T15:41:00.000-07:00

I'm camping inside today due to the remnants of Hurricane Irene, which came up to the Northeast this weekend.

Isn't this what Boston looks like normally?

Anyway, it's a great time to make some major long-overdue navbar updates.

Most importantly (seriously) I added a bit of dynamic content that tells me if the large brushless motors (codename: melons) have come back in stock at Hobby King. It should be right around here -------------------------->

Turns out Hobby King has a web API that you can use to do everything from check inventory to pull up tracking numbers for specific orders. I've been habitually checking the site every day to see if any new motors have been released, because they are out of stock on almost every motor larger than 55xx. I think they're working on a new line of motors that will replace things in the 63xx size range, like the ones on tinyKart, but I also have hope that the 80xx (melons) will return. So, rather than scrolling through the site every time, I can take a quick glance at my navbar to see if any are in stock! I made a static page with the melon checker as well.

I've also added new links to other awesome project sites right about here --->

I hadn't updated my links in such a long time that I feel bad for leaving out so many awesome blogs, such as that of Transistor Man and fellow battery abuser Dane Kouttron, combat robot and electric vehicle builder extraordinaire Jamison Go, and potentially (lolpun) the most frightening underclassman ever Tyler C. of TC-Engineering (or does TC stand for Tesla Coil?).

Lastly, the project pages have been shuffled and updated:

Since there are now two electric go-karts, Cap Kart and tinyKart now share a new high level page. I don't know if I'll ever build another electric go-kart, but just in case, I now have a project category for them. (Or maybe, now that I have a project category, I have to build more...)
I added DirectDrive to the Motor Controllers page.
I actually populated the Self-Balancing Things page which has been a dead link for several months now. I've determined that the internet is an infinite Segway sink, so I can keep making silly balancing robots/vehicles and people will actually want to see them. Not sure why. But anyway, now there is a page for them.

That's it for the administrative updates, on to more interesting things:

PCB Quadrotor!

I'll admit, I rushed through this build without posting any updates, so this will be a little on the long side. I got the board from Advanced Circuits (www.4pcb.com) early last week. It's $33 for a two-layer board with silkscreen and soldermask, routed to any shape you want (including quadrotor shape). The first thing to go on was the Toshiba TB6588FG sensorless driver chip:

It's not the easiest chip to solder, but it can be done by hand. I managed not to put it in backwards. I decided to solder up just one ESC and its supporting passives so that I could test it with the tiny 5g motors to see if it would even work. I had to also put on the Arduino Mini before I could do so, but that didn't take very long.

Very quickly I ran into one of the problems that I was expecting: the TB6588FG datasheet mentions a commutation frequency limit of f_osc/(3*2^11) in the context of a protection feature that shuts down the drive if you exceed this limit. But, it doesn't mention what happens if you turn off the protection feature. I figured the possibilities were either that (1) it would work, (2) it would limit the frequency, or (3) it would explode. The actual answer was (2):

Speed limiting at about 800Hz (3 pulses per cycle).

The tiny 5g motors are actually very, very fast. Not only do they spin at about 14,000rpm, but they have 16 poles, so the electrical frequency in Hz is 14,000/60*8 = 1,867! Under load, I thought I might need at least 1,600Hz. So, I tried overclocking the chip by changing its oscillator resistor from 20k to 10k. This bumped f_osc from 5MHz to 10MHz.

And the speed limit goes up to 1,600Hz (3 pulses per cycle).

This seemed to work just fine. It will also double the PWM frequency, but I chose the lower of two options, so it's no worse in terms of switching losses than the higher case with 5MHz. I'm not sure how much more you can push f_osc, but it would be an interesting experiment to try. Other than that, the ESCs work well. The start-up routine is dubious, and seems to be designed for much slower motors. But they seem to be able to find sync on these motors even starting in the run state. Once spinning, they are able to change speed quickly and smoothly.

Confident that the Toshiba chip would do the job, I filled in the remaining three and then mounted the motors:

Copy-paste, copy-paste, copy paste.

Motors mount with 2-56 machine screws.

The motor leads are just long enough to reach the pads.

And when all the parts are together:

The total weight, including a 7.4V, 500mAh LiPo battery, is 125g. This is just a bit over what I predicted, but then again I was using a slightly different battery for that estimate. Each 4x2.5 prop should be able to generate at least 50g of thrust, so it can still fly. The yellow electrical tape is for balancing the props, which, for $0.40, were not very good to start with. It also helps for visibility and avoiding finger contact.

I put together some quadrotor control software (yes, in Arduino..) based heavily on the previous quadrotor project I was involved with. It uses a complementary filter on each axis to calculate pitch and roll angles from accelerometer and gyroscope signals. The angle and rate then go into a Proportional-Derivative (PD) controller that attempts to keep the quadrotor level and stable. Yaw is handled by a simple proportional controller that applies a differential signal to the counter-rotating props. The input for the control is done through my stock RC solution: a USB joystick and XBee radio modules.

Once I had something close to flyable, I did a few test hops:

You can see the control loop still needs a good amount of tuning. But the test hops also revealed a few other problems that I'll want to fix as well. For one, it could really use some landing gear. And I'm not just saying that because it currently crash lands on its LiPo every time, I don't really care about that. But taking off is actually the most difficult part, because it's not very stable in ground effect. Having four solid points of contact would help a lot at keeping it level during take-off, I think. Right now, the only real solution is to gun it and get it off the ground as quickly as possible, hoping it stays level enough to fly.

The other major problem I encountered was that, even though the props survive crashes very well, the motors are not as durable:

After several hits, the cans started to detach from the faceplates of a couple motors. They are held on only by a press fit with a short interface. Once the can comes off, the motor locks up. To attempt to fix this problem, I've been adding superglue to them as they come off. It would also help if I would stop crashing it.

Mostly, though, I think the flight can be improved with control loop tweaking. I'll be playing around with the P and D constants, to start with. The control loop is currently running at 100Hz, which should be fast enough to stabilize the system, but it's possible that there is some unaccounted-for lag in the motor control or sensors. The tradeoff seems to always be between oscillation and drift. Higher gains cause more overshoot and oscillation, but do a better job of holding it level. Lower gains are more stable, but it flies away in one direction or another. Finding exactly the right combination is frustrating, since it also depends on your ability to trim and fly it. So, hopefully with more tweaking and practice, I'll get it to the point where I can legitimately call it "flying".

tinyKart: Round 5

2011-08-21T20:03:00.000-07:00

tl;dr tinyKart works:

It ran outdoors for the first time at Swapfest, our de-facto vehicle debut venue. This time, tinyKart and Charles Guan's Straight RazEr were revealed to the ~~world~~ crazy swapfolk. It took a while to get there, as evidenced by the greater-than two week gap between tinyKart posts. But here's where I fill in that gap. When we left off the kart was mechanically complete, minus the steering wheel.

Problem solved.

The angular butterfly design courtesy of Max H. fits very nicely with the overall aesthetic of the kart, plus it's all 1/8" aluminum plate welded to thin-wall aluminum tubes, so it weighs less than a pound. For various reasons I can't quite say how this nice thing came into existence. But did you know that Amy Q. is awesome? Just sayin'.

The steering wheel is very important on tinyKart. It holds all of the driver inputs; there are no pedals. The two front disk brakes are controlled by cables which go to a really awesome double pull lever I found on Amazon. We had some issues stemming from unequal length brake cables (different amounts of friction). But a trip to the bike shop for two new 48" cables solved that problem. The throttle is a trigger from an RC car controller, and it really does work like an RC car. (Pull to go, push to brake, push twice to reverse.)

One interesting consequence of having no pedals is that you can put your feet wherever you want...

...

One other minor mechanical detail came up during the week: the drive pulleys which attach to the motor shafts had been bored out to 10mm, but that left very few threads for the set screws. As a preventative measure, I took the four prop adapters that came with the motors and pressed them into the even-more-bored-out pulleys. The Frankenpulleys are held together only by a 0.003" press fit and large quantities of retaining compound, but I still think they're better than the stock ones.

Before attaching the pulleys to the motor shafts, I filed small flats on each side for the set screws to grab. The other side of the pulley attaches to a 10mm aluminum idler shaft that runs in a bearing in the outer plate of the drive module. This way, the pulley is supported on both sides and motor shaft incurs less bending moment, all of which helps my MechE side sleep at night.

And with that, all that remained was a crapload of electronics work. The first step in that process was to mount the batteries and the motor controllers. Up until we thought about it hard enough to realize that nobody should sit in between two 3lb LiPo batteries, the plan was to put them along the sides of the kart. But it turned out that the two batteries and the controllers fit nicely in some space behind the seat. To isolated them from mechanical shock, they are attached to a separate 1/8" aluminum plate floating on left-over BWD wheel urethane:

But weren't BWD's wheels stupidly hard?

If you feel the seat warmer kick in...GTFO!

This is the second time I've used giant "long pack" LiPos on a vehicle. The first was Pneu Scooter's maiden voyage in Singapore. To be honest, they scare me...and I am not easily scared by batteries. I am used to the potential for 1,000A short-circuit currents and the precautions that go with that. I know how to monitor cell voltages and protect the pack from damage. But all I can think about with these is how far away I need to be if the battery starts spewing flame in all directions.

Tangential thought: I think I will spend some time in the near future making a 12S3P A123 pack for tinyKart. To keep the same weight while switching from LiPo to LiFe, some capacity must be sacrificed (273Wh instead of 333Wh). But I could make a couple of packs and swap them. And as much as we fret over the safety and liability of having loose cells and homemade battery packs lying around, I still feel safer that way than with these giant LiPo bombs that I can buy freely on the internet.

Finally, a good load test for eBay Hack Charger #7,523. Set at 41.0V cutoff and 5.0A, it would take almost two hours to fully charge the batteries. They arrive about half-charged, so this was a good one-hour full power (200W) test of the Vicor brick power supply I built. Seems to hold up just fine. And no fiery LiPo death yet.

Thank you, Cell Loggers, for giving me at least some peace of mind.

With the batteries and controller mounted, the wiring could begin:

The wiring for this kart wasn't nearly as bad as Cap Kart. For one, the primary wiring could be done with double 10AWG instead of single 2AWG. So, the hammer crimper was not required for this one. Each battery gets its own 60A fuse. Then, the two positive wires come together inside a master switch, which has a precharge circuit bypassing it. Chris C-T. decided to put all of this inside the master switch, because that's just what he does.

A switch within a switch...

The master switch needs to be easily reachable by the driver, so it is attached to the right 80/20 frame rail:

The rest of the primary wiring was easy. Well, I shouldn't say that, because it turns out that the 5.5mm bullet connectors on the batteries are not that same size at the 5.5mm bullet connectors I bought... So, a couple hours of tense giant LiPo connector surgery were necessary. But other than that it was easy. The signal wiring, on the other hand, took a very long time.

Cue wiring montage...

Each Kelly controller needed a total of 12 signal connections: 5 for the Hall effect sensors and 7 for the throttle, brake, reverse, and diagnostic signals. The Hall effect sensors ride on a laser-cut acrylic mount (a la Pneu Scooter) that holds them just off the motor can, at the proper electrical angle. The cans on these motors are thin enough that the magnetic field is easily picked up from outside; no need to bury the sensors in the motor windings. The acrylic mount is tangentially adjustable so that the motor timing can be fine-tuned after finding the proper combination of wires. The process by which this happens is a matter for another entire post, but generally it's sufficient to set them for minimum current at a given throttle position.

Throttle, brake, and reverse are controlled by a ~~sophisticated central vehicle processor~~ Arduino that intercepts the throttle signal from the RC trigger and decides what to do with it. The Arduino reads in the trigger analog input and generates four PWMs which are low-pass filtered, buffered, and set out to the throttle and brake sensor inputs on both Kelly controllers. Ted G. and Catherine C-T. set up this fancy throttle interceptor to capture the brake/reverse function of the trigger, but also because we want to implement steering angle-based differential torque on the two motors. Future feature, once the steering potentiometer is installed.

As it turns out, regenerative braking will also have to wait for some minor modifications. The Kelly controllers can use an analog brake signal, but apparently they still need their digital brake switch pulled low at the correct time for the braking feature to work at all. So, there will actually be 8 signal wires for each controller, one of which may not be zip-tied to the nice wiring harness that was already made.

After a week of wiring, we finally got a chance to test drive it this weekend. Here are the two videos:

8/20/11- Maiden voyage in N52.
8/21/11 - Outdoor testing at MIT Swapfest.

So, one year to the day after Cap Kart v2.0's first successful test drive, and three years after Cap Kart v1.0 first touched pavement, we made it back out to our favorite strip of trackside delivery road. This time, though, we didn't need four people and a pick-up truck to get there. One person can easily tow tinyKart with two wheels on the ground, and two people can carry it for a long distance. It also fits in elevators and through doors.

d'awwwwww

The test drive validates some of the mechanics of tinyKart: The 17mm aluminum wheel axles seem okay, the brakes and steering work as they should, and the frame holds itself together. In the video, you can see that the chassis does flex, a lot. You can feel it in the seat. But it's not the kind of flex that will break things - more like an airplane wing flapping a bit because it's just an aluminum truss. Interestingly, it keeps all four tires on the ground.

There are definitely still some weak points, some of which we knew about and some of which were revealed in this test drive:

The left side motor can is loose and has a tendency to shift axially, once to the point of binding so hard that the entire rotor shifted, changing the motor timing. The only question is: repair or replace?
Both controllers exhibit a well-know problem of cutting out under heavy load (80A?). This seems to be common with RC outrunners running on Kelly's. I've seen it at least twice before. Since I pretty much spend all my time debugging motor controllers anyway, I can probably find a quick fix. If not, there is a higher PWM frequency option for Kelly controllers that could be worth a try. (The inductance on these motors is so low that the current ripple at 16kHz is still large.) If nothing else works, tinyKart may some day be merged with DirectDrive...
The weight.

The current weight is just under 55lbs. To get down to the target of 53lbs (less than one of Cap Kart's old lead acid batteries), we will have to do a bit of trimming. The current weight already represents the first major cut - the side seat mounts that Max put so much effort into had to go. We were worried about whether the rear seat mounts by themselves could handle high cornering forces, so we did a quick 1G turning test:

Removing the side seat mounts only saved 0.85lbs, though. To cut an addition 2lbs, we will have to take small bits off of several places. Some easy targets are the belt tensioners, the front of the frame, and a few of the lateral 80/20 braces which could be swapped for lighter box extrusion. After that maybe we'll drill some holes in the LiPos to reduce weight...

In the meantime, a bit more test driving may be in the near future. Also, exciting news: We will be bringing tinyKart to NY Maker Faire in mid-September. Look for it there!

4pcb: A Printed Circuit Board Quadrotor.

2011-08-12T19:30:00.000-07:00

I know I have too many project tags open right now, but this is one that I just couldn't resist:

Lately I've seen a number of things that almost fly, and they reminded me of a project idea that I put in the queue a long time ago: a printed circuit board-based quadrotor. Fiberglass, like the FR4 used in PCBs, is actually a pretty nice structural material - lightweight and stiff. So why not integrate the electronics and the structure into a single printable frame? I named it "4pcb" after the URL for Advanced Circuits, where you can go to print your very own. (Though now that I think about it, Myrocopter would have been a cool name, too.)

I've actually helped with a quadrotor before:

It was built by high school students as part of the Edgerton Center summer engineering class in 2010. You can see the details in this Instructable, the first and for some time only Instructable on how to build a quadrotor. (Credit goes to June K. for the write-up.) This one has a pulltruded carbon fiber frame and is built mostly from Hobby King parts. It uses 7" props, two right-handed and two left-handed, and is controlled by feedback from gyros and accelerometers.

The nature of the control system is what appealed to me about building a quadrotor, and I pretty much drew it up from scratch the way I knew it would work. The internet does have a lot of good and bad information on the topic, all of which I skipped over. But if you're new to this game you might want to read some of the following:

The basic idea, and why you need counter-rotating props.
My surprisingly well-traveled white paper on the angle estimating filter.
Sensors and filtering sections from my other Instructable.
Code and tuning sections from the quadrotor Instructable.

Props to Welkin U. for translating my ranting into workable code for the Edgerton quadrotor - it did in fact fly stably, if only for about 10 seconds at a time. I think with a bit more work on the yaw control, and a lot more pilot training, it would have been almost easy to fly.

Anyway, now I want to build a small one.

I settled on a 4" prop (4x2.5) and pretty much the tiniest motor that Hobby King sells, the HXM1400-2000. Despite its size, this is a 12-slot, 16-pole brushless outrunner.

Yes, 16 poles!

And it is an incredibly nice little motor. The build quality seems a lot higher than other tiny motors I've seen, including the ones from our last quadrotor. For example the can does not feel like it's going to separate from the motor and fly away under load. The prop adapter that it comes with actually fits the prop, and the whole assembly (motor and prop) weighs only about 10 grams. With the 4x2.5 prop and a 7.4V supply, reviews suggest the thrust will be about 50 grams.

And I've somehow made it several paragraphs into a post without talking about motor control yet. Well, I can fix that. I was browsing for a piece of enabling technology: an integrated sensorless control IC. There are plenty of cheap, small brushless ESCs on Hobby King and elsewhere, but what's the point of a PCB quadrotor if I still have to zip tie ESCs to it? Also, there's a fundamental bandwidth limit with RC ESCs due to the ~20ms gap between servo PWM pulses. We definitely battled with this limit on the Edgerton quadrotor, and a smaller quadrotor will need an even faster control loop.

So, I was very happy to find this:

It's part of Toshiba's line of small, integrated motor control chips. The TB6588FG is the brushless version. They contain both the power and the signal electronics, so it really is almost like having an ESC on a chip. You do have to add a few passives.

Okay, a lot of passives.

But still you get a sensorless ESC in about a 1"x1" PCB footprint with no wasted weight for packaging or heat sinking. It has some features you wouldn't get on a cheap RC ESC too: analog speed input (very high bandwidth), adjustable frequency PWM, adjustable timing, over-current protection, and some others. But there are also a few drawbacks: It's designed for higher voltages (7-42V), so running it off a 7.4V battery is borderline. It also may have issues with the extremely high electrical frequency of these motors. The datasheet mentions an optional commutation frequency limit, but doesn't say what happens when you turn the limit off. Only one way to find out.

Since I'm working in EAGLE, I have to live within the constraints of the 100mmx80mm board size limit. That's one of the reasons I put this project on hold originally - I figured I might have to go back to FreePCB or some other layout program to do it. But recently I remembered that the board size limit only applies to placing components. The free version of EAGLE will definitely let you create a board outline (dimension layer) and even traces that go outside the limits. So, I just had to place all the components in the 100mmx80mm dashed rectangle in the title picture, which has the origin at its lower-left corner.

After laying out a single ESC block, I just had to copy-paste three times and - oh right, this is EAGLE, FML.

As it turns out, even the already convoluted process of copy-pasting a group of components and wires in EAGLE is not enough to get you through this one. If you do so in the schematic, an unorganized batch of new components inserts itself into the bottom-left corner of your board. If you try to do so in the board, it just yells at you. A combination of Googling and random screwing around got me to a workable solution:

Close the board file. This breaks the link that automatically inserts new components into the board when you copy-paste schematic groups.
Copy-paste the group in the schematic. If you don't know how to copy-paste groups in EAGLE, you might want to figure that out first.
Open the board. It will now yell at you because the board and schematic are not consistent.
Copy-paste the group on the board. Make sure the board group contains exactly the same elements as the schematic group. (Same components and nets.)
If you have not re-named any nets, or used any power supply nets, then you are probably done. If you have, go on to Step 6.
Power supply nets and user-named nets copy properly on the schematic, but not on the board. On the board, GND becomes GND1, VCC becomes VCC1. USERNET becomes USERNET1, OTHERNET1 becomes OTHERNET2. It either appends the number 1 to the name, or if there already is a number, it increments. Depending on your intentions, you may have to change the net name on either the schematic or the board. Usually for power supply nets, you'd be renaming the board nets to GND, VCC, etc. But for user nets, you may actually want the automatic number incrementing. In that case, you can update the schematic net names appropriately. The ERC shows the inconsistent nets. Once you have cleared all these, you're done. Unless...
The numbered nets (N$1, N$2, etc.) should increment properly on the board and the schematic when you copy-paste. But, I found that if you have extra nets on the board that are not present on the schematic, it offsets the net numbering on the board. For example, the 20 motor mounting holes I had were numbered N$25 through N$44. They were not represented by anything in the schematic. So, to avoid the problem, I had to rename all the nets associated with these isolated vias so that there were exactly the same quantity of numbered nets on the schematic as on the board. Only then could I successfully execute Steps 1-6. So maybe this is actually Step 0.

And after all that:

Three hours to copy-paste three instances. WHY!?

Now that I know how to do it, it would probably only take me five minutes or so to copy-paste a block of this complexity in the future. And I'm not sure I can blame EAGLE, since it does do a reasonable job of re-syncing net and component numbers, or at least telling you when it makes a mistake. But dammit, there must be a better way!

After that adventure, routing the few remaining signals was easy. I opted for an Arduino Mini this time, just due to the space constraint. The sensors are on a Sparkfun Razor 6DOF IMU, which I would link to but Sparkfun seems to have discontinued it within the last day or two. I've got a few buffered, but it does bother me that they're ditching the only analog-output 6DOF board, and that I will have to rework the documentation for this and other projects that relied on this part. >_<

For wireless control, an XBee radio module is hidden on the bottom layer. These have become my standard for custom RC, one of the building blocks I can rely on to just work. The XBee link has several advantages over normal RC Tx/Rx systems. First, it is not constrained by the 20ms servo PWM period, so the control bandwidth can be higher. It can have bidirectional data transfer, which is useful for debugging and real-time data visualization (virtual quadrotor!). And since the other end of the XBee goes to my laptop, I can control it with any USB HID controller.

The full layout is in the title image above, and in high-res here. Lead time on the boards will be about 10 days, so the next update will be in a couple weeks. Back to tinyKart...

tinyKart: Round 4

2011-08-04T12:28:00.000-07:00

I've been preoccupied with Robocon, the International Design Contest which this year is hosted at MIT. But somewhere in the past week we found some time to complete the rolling chassis on tinyKart. The tires came in, so this was the moment of truth for the custom aluminum frame. And as you can see in the video above, it actually rolls (past the unfortunately copper-deficient LOLrioKart). The chassis itself weighs only about 40lbs, so we were quite happy to see it handle the full weight of a driver and not simple bend in half.

The tires are 8"x2" pneumatics with tubes from ElectricScooterParts. They're certainly not for racing, but they are remarkably light, which is the point in this case. They are high-pressure (70-80psi) so they roll very well, though the ride may be a little rough outside. We will probably run them closer to 60psi since we have four points of contact with the ground and they're normally used on scooters with two.

Other than that, the only addition here is a Vise-Grip steering wheel. That will soon be replaced with a custom job. One interesting thing about tinyKart will be the hand-based throttle and brake (no pedals). More on that to come when we install them, but I think it will be incredibly fun to drive.

A few more pictures of the substantially completed chassis:

Slackermann steering geometry at work.

More 80/20 for the steering column support.

Thin as a razor blade...

Convenient storage position.

Next up: Electrons. Thousands of them. Actually thousands of billions of billions of them...per second.

tinyKart: Round 3

2011-07-30T18:57:00.000-07:00

The quest for an ultralight go-kart continues...

In the last update, we had assembled the two critical front wheel modules, which allowed us to complete the aluminum plate and 80/20 sandwich that is the front of the chassis. With that, the basic structure of the kart was complete and we could get a look at the full size and shape of tinyKart:

So tempted to throw this on the railroad tracks...

The rear drive modules attach to the rear 80/20 frame using standard t-nuts, though we did have to drill an access hole on the inside of the side rails for the single 1/4-20 screw which holds the rear wheel shafts in place. Each drive module has a single Turnigy SK6374-170 motor driving an HTD 5M-15 belt with a gear ratio of 4.5:1. This will give a top speed of....I have no idea. It depends on the motor's performance under sensored control. More on that to come.

The standoffs and outboard plates for the drive modules have been fabricated, so all that remains are the belt tensioners. We may also modify the motor pulley to have a set screw hub on both sides to leave open the possibility of attaching a second motor to the outboard plate, with the two shafts coupled by the pulley itself. This would not be for the ultralight version, but rather for a high-performance follow-up. With just one motor per side, the peak force at the ground should still be close to 100lbf.

Thus far, the build had been fairly 2D: plates, extrusions, and right angles. The steering linkages and seat mount are where the interesting angles start to come in. Here's one of the tie rods:

Normally, a tie rod would just have one ball joint on each end, the 3D equivalent to a pin joint in a planar mechanism. But here I wanted the steering linkage to go in the 1" gap between the front chassis plates. So, I came up with this Non-Collocated Ball Joint which is really just two pin joints, one in the horizontal plane and one in a vertical plane. Together, they remove the same degrees of freedom as a single pin joint, but they allow part of the tie rod to be completely planar and thus fit in the tight space between chassis plates:

Vertical pin joint.

The horizontal pin joint fits, just barely.

The other end of the tie rod is a straightforward ball joint going to the driving link on the steering column:

The rod itself is 1/4-28 threaded steel rod with a 3/8" aluminum sleeve over it. Bling nuts on either side of the sleeve put the sleeve in compression and the rod in tension. This bit of preload makes the combined rod much stiffer and ensures it won't buckle on the "pushing" side of the steering linkage. Here's the whole linkage:

There are several ways to adjust the linkage: The easiest seems to be to change the length of threaded rod passing through the vertical pin joint block. This can be used to adjust the toe angle and alignment of the front wheels. These dimensions also depend on the angle of the steering column, which is adjustable (for now) by pivoting a block that acts as the bottom bearing for the column itself:

That potentiometer might come in handy...

Still to be fabricated is the second support for the steering column. Once that is in place, an overall fine-tuning and stiffness assessment will be necessary. Some of the pin joints could use a bit of tweaking to take out as much play as possible, but overall it seems like it will do the job. If there is one thing I am still worried about, though, it's the performance of the front wheel systems under load. It all went together too easily...

The seat mount was the last bit of critical structure to add. The bottom of the seat is just bolted to the 80/20 rail that comes across the front of the rear chassis assembly. The back, though, needs to be supported in 3D by a set of braces:

One brace, constructed in a manner similar to the steering linkage, connects the side of the seat to the side rail of the rear chassis. Another brace, a strip of 1/4" aluminum, links the side of the seat to the rear rail. This provides stiffness in all directions and actually makes the frame itself stiffer as well, since it now has structure outside the plane of the main chassis rails. Okay, so it's not a space frame, but for a group that makes everything out of 80/20 and plate stock, I think we did pretty well in 3D.

The moment of truth: a weigh-in with a makeshift steering wheel (vise grip), the controllers, and the batteries dangling from various frame rails:

Shaaady...

Noticeably absent are the tires and tubes, which should weigh about 3lbs total, the tensioners, the second steering column support, and the wiring. Not noticeably absent but probably the weight killer is minor hardware like controller mounts, switches, etc. I think we will need to take about 2-3lbs off of our current configuration to meet a 50lb target. Otherwise, 53lbs is the weight of one of Cap Kart's old lead-acid batteries, which was also a potential target. I would not be disappointed either way.

Onward...

tinyKart: Round 2

2011-07-21T20:51:00.000-07:00

Round 2 is all about putting together the steering things:

These things.

But first, armed with many more t-nuts, we finished putting together the lightweight 80/20 frame:

It's more like 0.75-scale kart.

Next up, pressing 1/2" ID bearings into the steering reinforcement wings, a.k.a. the "cool parts":

Easy so far. The moving assembly includes a front wheel, brake disk, brake caliper, and a control arm (not shown in the above picture because it's between the chassis plates). To hold all of this together, there's a little bit of 1/4" plate jigsaw puzzling:

The control arm doubles as a support for the lower thrust bearing. It, and the upper thrust bearing support, slip (press) into what would normally be called the upright, if it wasn't so short not-upright. I'll just call it the shaft mount. Then, three 4-40 screws pass through the shaft mount, the upper thrust bearing support, the shaft mount again, and finally thread into the control arm.

Like so.

I guess I forgot one important step (in real life, too, the first time): First, the 1/4-20 cap screw that threads into the front wheel shaft must be in place, with its head in the relief cut in the top and bottom thrust bearing supports. So far, so good. To properly align and stiffen the thrust bearing supports, three countersunk 1/4-20 screws with plastic spacers pass from top to bottom:

The image above also shows the brake caliper mount. The brake calipers will need some shimming, but they're at least located to within a few millimeters axially. No major machining or design mistakes there. Finally, we attached the front wheel shaft. This requires removing one of the screw/spacer combos and shoving a hex key in between the thrust bearing supports. It's kind-of a pain, and we don't want it to come loose ever, so we Loctited the shit out of it.

After the two front wheel assemblies were together, we had to ream the kingpin holes since (a) they were undersized to begin with and (b) there's nothing really aligning the top and bottom thrust bearing supports. Luckily, we bought a 0.499" reamer two years ago for reaming BWD's stators, and it hasn't disappeared.

MillKart

The kingpins were quickly fabricated from 1/2" 7075:

The result is a tight fit to the 0.499" hole, but not so tight that you can't force it back and forth with a rubber mallet. And it's a slip fit in the two "cool part" bearings. Those are the radial bearings that support the bending load on the kingpin, but there are also two needle-roller thrust bearings:

And then the top plates complete the sandwich:

The end result is a nice, stiff steering pivot with radial and thrust bearings on top and bottom.The frame passes the "stand on it" test, though it is a little more flexible than I thought it would be. We'll see how it changes with the added structure from the seat mounts. Total weight of the chassis so far is 21.5lbs. Still have the entire powertrain to add. The good news is that the controllers are a bit lighter than expected, so 50lbs still seems within reach.

Next up: steering linkage, motor mounts, and controller testing.

DirectDrive v1.0: 2.4kVA Test

2011-07-18T01:28:00.000-07:00

After my ducted fan load tester turned out to be basically unworkable, I decided to go back to lower-RPM motors. This way I'm not simultaneously testing the controller's basic functionality and the ability of my FOC algorithm to handle greater than 1,000Hz electrical frequency (it can't).

The first candidate: a re-wound and sensored Turnigy 8085-170 motor:

Well this pretty much didn't work at all. There's some issue with the sensors that makes it sound horrible, and also it's too small to be able to sink a lot of power internally.

I decided to stop when the hot glue holding the sensors in started melting.

Anyway, that was just a little distraction before the real show:

Eeeeeteeek.

The Mars PMAC (brushless Etek) is probably my favorite load-test motor. It's so big that you can't really hurt it, at least not in the time scales of a bench test. I put the DirectDrive controller on its edge to give the heat sink a tiny bit of natural convection, but no active cooling for this test. I wanted to see the temperature rise. Nice, steady temperature rise, and no spontaneous FET destruction.

Now here is where it gets interesting. Short of coupling it to a second Etek, there's not much I can do to apply mechanical load to the motor. (At least with the ducted fan, I had a way of doing so.) So, instead, I brought the motor up to speed under ideal timing conditions, i.e. manipulating the phase of the drive voltage until the current draw is at a minimum. Then, at nearly full voltage amplitude, I threw the timing way off so that the motor begins to draw 100A (phase peak).

And I let it sit that way for one minute. The phase voltage is a sine wave with an amplitude of 16V. The phase current is a sine wave with an amplitude of 100A. But...they're not in phase. So the real power is still low, but the apparent power is 2.4kVA (1.5*100A*16V). The good thing about this load is that it can all be run off a bench power supply, no need to break out the giant batteries yet.

But is it actually a representative test of the controller? It doesn't really test anything outside of the bus capacitor, where the DC current is determined by real power only. But what I'm still not sure about is how it looks to the inverter itself. Here's what it comes down to:

The RMS current is the same regardless of the phase angle. The only thing that changes is the phase of the sine wave that the duty cycle traces out. But, the MOSFETs are still either blocking 36V or carrying their share of the current at any given instant. It makes sense, then, that both the conduction losses and the switching losses should be the same regardless of the relative phase of the current with respect to the duty cycle. Anyone care to confirm or refute this?

If that is the case, than I'm happy with the test results. A minute of running at 100A with passive cooling yielded a temperature rise of 15ºC. I would guess that the heat sink mass is about 0.25kg. If it was mostly just absorbing power (with no active cooling and very little temperature gradient, this is true), then a quick estimate of the power dissipated in the inverter is 24W, which is exactly where it should be for 100A.

More testing to come.

DirectDrive v1.0: First Three-Phase Tests

2011-07-15T02:15:00.000-07:00

After provisionally solving the first big problem with DirectDrive v1.0, the current sensor coupling, it was time to port my three-phase brushless field-oriented control software over and do some testing on an actual motor. I decided not to bother with Pneu Scooter's hub motor, since at most it could handle 750-1,000W for a short period of time and I'm looking to hit 5-10kW peak. Though really it would be a better intermediate step than what I wound up using...

Nothing about this seems like a good idea now.

"Isn't using an electric ducted fan to load test a motor controller a great idea? It can sink tons of power and it cools itself!" Well, that was the original thought anyway. This is the giant 120mm EDF from Hobby King, which can produce upwards of 4kg of thrust (the same as KM Scooter's eight blower fans...combined). They're meant to be used in model jets, but you could probably do other things silly things with them if you wanted. I bought one specifically for load testing, since they're only $43. Mine uses a this 4030-1100 motor.

With this load tester, I thought I would try something new for sensing rotor position. I printed out an optical encoder disk with eight black and white segments, which I double-side taped to the back of the motor:

And I used a three-phase set of infrared optical reflectance sensors to pick up the signal:

These mimic the function of the Hall effect sensors I would normally use in this application. They differ in a few important and annoying ways, though. For one, they are analog sensors, producing a variable voltage in response to the relative reflectance of the surface in front of them. To get them to act as digital inputs, I have to set them up with a 10k pull-up resistor and put them at about 4mm from the encoder disk. Then, they produce a 4Vpp square-ish wave. But with a 10k resistor, the normal RC filter I would use on the Hall effect sensors won't work, so I had to swap it for one with lower capacitance. The net result is a sensor signal that is less precise and more vulnerable to noise than Hall effect sensors would be.

Back to that in a minute. First, I made the awesome copper heat sink a more permanent feature by drilling and tapping 4-40 mounting holes for it:

Notice that I still have the wires coming straight off the board in the direction that minimizes coupling of the two Hall effect-based phase current sensors. I set up the load test rig on what has become the Table of Load Test Rigs:

Notice the face-to-face dynamometer in the background.

The software on my laptop might look familiar. It's the same GUI and data logging setup I used for Cap Kart and Pneu Scooter - very handy tool. One thing that's nice about DirectDrive is that, for whatever reason, it doesn't cause my USB port to freak out when it's under load. So far I have not had to use the XBee radio to collect data.

I somehow managed to get the right sensor and phase combinations on the first try, and was happy to see that the motor spun up nicely. The current sensors, temperature sensor, and other bits and pieces seemed to be working properly. But the motor was drawing way too much current, even no-load (with the fan rotor removed). By that I mean it was drawing almost as much current with the fan as without. Now, this is a load test, so in some sense that's good, but I would prefer the majority of the power to get dumped into the air, not the motor.

After a day of debating (grad student-ing), I decided that the most likely cause was the shady optical sensor rig. On a hunch, I took the data I had collected from the test run and did a histogram of the sensor states. There are six: 001, 011, 010, 110, 100, and 101. If everything is working properly, they should all occur with the same frequency.

If instead your sensor histogram is giving you the middle finger, well then you know you have issues. You can even figure out what the issue is with a little bit of logic:

The top set is what the sensor signals should look like if things are working properly. The bottom set has Phase A shifted left a bit. The result adds time to states 3 and 4 and removes time from states 2 and 5. And guess what:

That was exactly the problem.

I was able to tweak the position of the Phase A, and it definitely helped, but I think the motor still draws a lot more no-load current than it could if the sensor timing were more consistent. The edges of the square waves are also pretty soft, and I'm relying on the input pin Schmitt triggers to make it work. It only gets uglier at higher speeds.

Speaking of high speeds, there is another reason why this is a stupid load test. Thus far, the fastest motor I've run with my FOC code is the 40,000rpm 2-pole inrunner from my RC car. But at those speeds, the rotor position estimate starts to become imprecise and unreliable. Now this is a 20,000rpm 8-pole outrunner. The electrical frequency is over 1,000Hz. Trying to fit a sine wave at 10kHz onto 1,000Hz is almost useless. High speed FOC is an interesting problem, but not one that I want to solve simultaneously while load-testing a brand new controller design.

So, sadly, I may have to abandon my new load tester. It can get to high currents, since the motor has such a low resistance. De-tuning the timing by even a few degrees in either direction causes the current to quickly shoot up, even at low speeds. So I ran it at 50A, and nothing seemed to mind, but it's 50A at something like 6V output instead of the 50A at 40V output, which would be a much more interesting test. Unless I can get the fan rotor up above 10,000rpm, which isn't going to happen easily, there's just no way to get any power through it.

Time for a new plan.

tinyKart: Round 1

2011-07-11T21:25:00.000-07:00

By popular demand, more picture of crazy vehicles, and less math:

Extrude...thin feature...mid-plane...

That's the size of tinyKart. So I don't know, maybe it's not really in the tiny class, more like miniKart. But whatever, we'll still call it tinyKart since it's going to be 1/5th the weight of Cap Kart.

Step one in the tinyKart fabrication adventure is the acquisition of a large amount of waterjet-cut aluminum plate. The front half of tinyKart is a sandwich consisting of two 1/8" plates with 1" 80/20 t-slot extrusion in the middle. In addition to this, the rear frame, motor mounts, steering system, and brake caliper mounts are made of a combination of 1/8" and 1/4" aluminum plate. None of the waterjets that I have access to can handle 30" lengths of plate, so the entirety of the plate stock was sent out to the Big Blue Saw. A week or so later,

Kit Kart!

It's always fun to see your 3D model almost instantly become a real thing.

Maybe we'll get in the 80/20 flipbook again.

The only problem is we ran out of t-nuts. But the frame is together enough to get a feel for the size. It's a good deal smaller than Cap Kart, but it doesn't look tiny. In other words, a reasonable person would probably call it a go-kart, not a tinyKart. But whatever.

The motors also arrived, so of course I took them apart:

I was a little disappointed, but not really surprised, by the overall construction quality. The magnets, which are the source of most of the negative reviews for this particular motor (Turnigy SK6374-170), actually seemed to be pretty well glued. But the windings are very loose and in fact on a couple of the motors, one or two strands of wire were sticking out into the air gap. So while the motors were open, I took the opportunity to epoxy all the windings in place. I also tested the resistance, and they were all right around 23mΩ, line-to-line, which is a lot lower than the specs say. And there were no shorts, so that's good.

The next order of business was to machine the shafts, which Max, et. al., made short work of:

These shafts are made of 6061 aluminum and the entire weight of the kart and driver are transmitted through them. They start as 3/4" stock and are turned down to 17mm to fit the special replacement bearings for the 8" scooter wheels we're using. The rims get sandwiched on and the shafts are bolted to the chassis with a single 1/4-20 cap screw.

The load carrying capacity of this configuration has been verified in simulation and also by the more scientific method of jumping up and down on it:

The rims needed only minor modifications: For the rear wheels, the brake mounting threads were machined off to make the overall width of the kart as small as possible. For the front wheels, the drive pulleys were machined off to save a bit of weight:

And the last little bit of machining for Round 1, boring out the steering reinforcement plates. These are the 1/4" plates that hold the bearings for the steering kingpins. They are probably the coolest-looking parts of the front frame. I decided to bore them out all at once, which Charles and I decided was a 2 on the scale of bad ideas from 1 to Eating at Bullet Train:

Turned out fine.

Here's the frame at the end of Round 1:

It's certainly come a long way since the tape version on the floor. But there's a lot more work to be done on just the mechanicals, including all of the steering system. To get a quick estimate of how we're doing on weight, I hung the frame and a box of many of the parts that are to go on it from my favorite shady hook scale:

17.63kg, or just under 39lbs, including the batteries and motors, and the weight of the milk crate.. What's missing is only the seat, four tires, the two motor controllers, the steering column and wheel, the brake cables and lever, and any other miscellany that we decide we need. So, 50lbs looks tough but still possible.

Sensorless FOC: More Analysis

2011-07-05T04:10:00.000-07:00

I've been away from hardware for a (much needed) week off. But whenever I'm away from hardware, I inevitably start to think about software. So for the last couple of days I've been going back over all the references I've collected for sensorless field-oriented control, partly to refresh my memory, partly to categorize and compare them, and partly to choose one to actually implement.

I feel like this is where I should make fun of myself for being a grad student and spending all my time thinking about the solution instead of actually solving the problem. But I think in this one particular case, the analysis time will pay back many times over if I correctly choose an approach that will actually work as opposed to one that only works on paper, with properly-chosen gains, and ideal current sensors, and a perfect system model, and on a Wednesday with low relative humidity.

First, a baseline against which to compare any potential solution: In the post where I first looked into sensorless field-oriented control, I put up the following bit of motor math:

This shows how you can estimate the back EMF or the flux linkage using only the voltage applied to the terminals of the motor and the measured current. You can do this on any phase of the motor to find the back EMF of that phase. The flux linkage will give a somewhat cleaner estimate in real life because it doesn't need the derivative of a noisy current signal. You can also convert all the quantities into vectors and find the magnitude and phase of the resultant flux linkage. The phase of the flux linkage is the rotor electrical angle, and can be used for field-oriented control.

The drawback of this approach is that it's entirely open-loop, which means it is heavily dependent on model accuracy. If the values for resistance or inductance are off, the estimate will have a magnitude and phase error, and the phase error will hurt the performance of the FOC. It's still a valid approach, though, and almost certain to be stable. So any alternative closed-loop approach must outperform this baseline.

The general idea of a closed-loop observer.

Last post, I had become a fan of Microchip AN1078's closed-loop observer, so I'll start with my latest impressions of that one. It's a sliding-mode observer, which in this case means that the thing occupying the Observer Compensator black box is just a comparator. If the estimated current is higher than the measured current, it feeds back +K, else, it feeds back -K. So, it's not a linear observer. The switching structure appealed to me because

It's computationally easy, saving precious time in the fast loop that would otherwise be spent multiplying out linear observer feedbacks.
It is highly noise-immune with respect to the current sensor signal. As long as the noise is unbiased (zero mean) and of high enough frequency, it will get drowned out by the switching feedback. This is a huge benefit since my controllers so far have had pretty crappy current sensors.

The part that confused me about AN1078 is what the Fake Motor box does with the stream of +K/-K feedback. It applies a series of low-pass filters which magically produce the back EMF estimate, but doesn't show mathematically why this is the case. More disturbingly, it requires a "phase compensation" which is simply pulled from a look-up table. The explanation for this? "It is recommended that phase compensation be fine tuned for any particular motor." It might still be better than the open-loop estimate, but a true observer should not need phase compensation as a function of motor speed.

I decided that I won't be taken seriously as a grad student unless I run MATLAB Simulations for a significant portion of my life:

Microchip AN1078 in Simulink

That is Microchip's AN1078 observer implemented in Simulink, including the phase compensation (bottom left). It's estimating the back EMF on a single phase, but the same exact observer could be used to estimate the two back EMF vector components (often called α and β components). The values used for the motor model come from Pneu Scooter's wheel motor, since it'll likely be the first test of any sensorless FOC I implement.

At first glance, AN1078 does pretty well:

Yellow: Actual back EMF. Purple: Estimated back EMF.

This is at at about 2,000rpm and 40A peak amplitude, with all model parameters accurately tuned. The phase compensation is taken to be the combined phase of the two low-pass filters at this electrical frequency. (Or, sticking with the Microchip plan, pulled from a look-up table.) The phase of the back EMF estimate is insensitive to current sensor noise, applied voltage phase, and a wide parameter variation of resistance. But, crucially, it doesn't seem to like error in the inductance parameter of the model. With the inductance set to 1.5x the true value...

Yellow: Actual back EMF. Purple: Estimated back EMF.

...the back EMF estimate lags significantly. The inductance is the harder parameter to measure, so an error of 50% or even more must be tolerable. Increasing the feedback gain can diminish the phase error. But now my threshold for tweaking has been crossed. The phase compensation table, the sensitivity to inductance variation, and the overall lack of explanation for how two low-pass filters produce a back EMF estimate have led me to question AN1078, even though up to this point it has been my favorite. Having tweaked it more than I care to, I went searching some more.

Some old and new references that only very few people would find interesting enough to read (I read them all):

Of course there is James Mevey's thesis entitled Sensorless Field Oriented Control of Brushless Permanent Magnet Synchronous Motors. Chapter 6 contains all the information one would need to do this, in the most general way, with a full-order linear observer. I understand the theory, and if I went back to my controls notes I could find information on how to place the observer poles in such a way to force the back EMF error to zero. It's just...a lot of linear algebra to compute in the fast loop. But this is my back-up plan if all other options fail...Mevey to the rescue.
Another approach, which Mevey references (Mevey references more papers than I have ever read...) is in a paper called "High performance PMSM drives without rotational position sensors using reduced order observer." It's an IEEE paper, which means I can't quite link to it. But the general idea is to skip the hassle of making an observer for currents, which are known anyway from the sensors. With only two states to track (α and β components of back EMF) the computation is quicker. I just don't know enough about reduced-order observers to be able to have an opinion on this one. Didn't I learn this stuff at some point?
I also found Freescale App Note DRM099, which has a much more thorough explanation of a sliding mode observer than the Microchip AN1078. Rather than magical low-pass filters, the Freescale approach sends the switching feedback into a full-state observer. It's a bang-bang version of the full order observer that Mevey presents. It also explains why the back EMF error converges to zero even in the presence of modeling errors, though it does not talk about how to set the feedback gains. It also has discrete time versions of everything, which is nice for quick translation to software. And no "phase compensation" table. This looks very promising.

But now, I feel like I am back where I started, just looking at examples of sensorless algorithms and trying to decide which one I like best. I guess I could really be a good grad student and run more simulations of each one, with a standard set of test cases. But I have a feeling any of them can be made to work with enough tweaking, so how should I decide?

Fuck it, I was bored in the airport so I just made my own:

Click to enlarge.

I stole the sliding-mode idea from Microchip and Freescale, but in this implementation I have abandoned just about every other aspect from the observers detailed above. Specifically, I don't want to do any coordinate transformations in the fast loop...at all. The way I avoided coordinate transforms when I was crunched for computing power in my first FOC implementation was to use a sine wave generator, which steps through a table of sine values with some given speed. So I'm doing the same thing here, generating the back EMF estimates for phases A, B, and C as a set of three sine waves offset by 120º in the table.

The inputs to the back EMF sine wave generator are the magnitude and the speed, which are each compensated by the sliding-mode feedback with some gains, G1, and G2. The magnitude feedback isn't as critical, but it corrects for variation of the torque constant in the motor model. The speed feedback adjusts how fast a certain magical index steps through the sine table array. This behaves like a phase lock loop, shifting the back EMF until it is in phase with the true back EMF. Don't ask me to explain it in any more detail than that. Here's it starting with a 180º phase offset and locking in:

Yellow: Actual back EMF. Purple: Estimated back EMF.

The nice thing about the PLL effect is that it doesn't matter if the feedback is positive or negative. As with the AN1078 method, this observer is immune to sensor noise, applied voltage phase, and variations from the model resistance value. But, it also doesn't mind very much having the model inductance off by a factor of 2:

Yellow: Actual back EMF. Purple: Estimated back EMF.

It might still need some tweaking to get just the right gains, but at least there is no "phase compensation" table. It also abandons linearity and state space in favor of ease of implementation. The comparisons for the sliding mode observer occur on each phase individually, and in fact only one phase is needed to run the observer. With all three phase currents, an averaging effect should make it work even better. Another interesting possibility is that the table through which the back EMF generator steps need not be a table of sine values. It could very well be an table of measured back EMF values, which should improve the position estimate in the case of trapezoidal EMF motors.

Once again I've created something that I can't really analyze. Time to try implementing it in hardware.

ECSEW V: tinyKart

2011-06-29T22:21:00.000-07:00

Believe it or not (I don't), this is the fifth year of the Edgerton Center Summer Engineering Workshop, an ad-hoc team of like-minded engineering students interested in things you can ride. Of all my past projects, I think the ones that I've enjoyed the most have been the Workshop ones. Since 2007, we've made:

The DIY Segway, ~~probably~~ definitely our most popular vehicle, which helped spawn a new era of smaller, lighter, cheaper, simpler DIY self-balancing...things.
The Cap Kart, our largest, most ambitious vehicle, which underwent a revision in 2010. Its name comes from the 16V/110F capacitor that gives it a speed boost from a bit of regenerated energy.
BWD Scooter, which led me in the direction of brushless motor design and control that occupies so much of my time these days.

But for 2011, we are returning to four wheels to create an ultralight go-kart. (Okay, maybe not this ultralight.) One of the drawbacks of Cap Kart, even the newer, lighter version, is that it takes three people and a truck to move around. With tinyKart, the target weight is something like "less than one of Cap Kart's old batteries."

Cap Kart's original 53lb deep-cycle marine batteries.

So obviously we're gonna need lighter batteries. Cap Kart v2.0 uses 42lbs of LiFePO4 batteries from Thundersky, now Winston Battery Limited. For that weight, you get 1.58kWh of energy storage and a peak power of 7.5kW. The only way to do better than that, in terms of power and energy density, is with lithium polymer.

tinyKart will use between two and four 10S, 4500mAh LiPos, making it only marginally less of a fire hazard than a gas go-kart. At a maximum, this gives 0.67kWh of energy storage. But since they specialize in absurdly high power density, there is the possibility of using just two batteries, a weight of just over 6lbs, to power the whole kart for a few minutes at a time.

Next comes the question of propulsion. The ultralight kart as I've always imagined it was powered by two short Magmotors, but they're just not cost-effective anymore. For less than the cost of one Magmotor, we got a set of four Turnigy SK6374-170 brushless outrunners. They're not the biggest brushless motors, but two will certainly propel a go-kart and four would make it a competitor for Cap Kart, in terms of acceleration. (One of the emerging themes of this project seems to be modularity; we can change the number of motors and batteries quickly to go between the lightest configuration and the most powerful.)

The drivetrain is really simple: RWD with independent belt drives on each wheel. This is enabled by the cheap and light aluminum rims from electricscooterparts, which have a 72-tooth belt pulley integrated into the rim casting. The rim and tire together weigh less than 2lbs. The motors are light enough to face-mount to a 1/4" aluminum plate and ball bearings on an eccentric standoff provide adjustable belt tension. As-pictured, the gear ratio is 4.5:1, yielding a top speed of about 30mph with the 8" wheel.

These wheels are designed for electric scooter use, where they would fit on 10mm shafts supported on both sides by the rear fork of a scooter. One of the easily-overlooked little details that I think makes this all possible is 6903 bearings. These are the same O.D. (30mm) as the 6200 bearings normally used in these rims, but they have a 17mm I.D. instead of 10mm. Thus tinyKart's four wheels are supported by cantilevered 17mm aluminum shafts.

Ask Max why the plate is at a weird angle like that...

One of the things I've always had in mind for an independent RWD electric kart is torque vectoring, a neat trick where you force more current into the motor driving the outside wheel to help shove the vehicle into the turn. This of course requires measurement of the steering wheel angle, but that's not hard. It might make up for the natural understeer of a kart that has 70+% of its weight on the rear wheels.

Between all of us, we have a ton of experience building electrically-propelled drivetrains, so I'm not very worried about the propulsion side of things. What makes this project interesting is that, unlike Cap Kart, we're building the entire chassis from scratch. And as you can probably tell from the CAD, it is not a typical go-kart build. We briefly debated the idea of making a welded tube frame, but then decided that 80/20 is the ~~only structural material we know how to utilize~~ ultimate expression of lightweight structural modularity.

The kart chassis is split into two halves: the front, which has a lot of platework for aligning steering linkages, and the back, which contains drivetrain components and the seat. The overall width is about 34" and the length is 48", though it can easily be made an few inches longer or shorter to accommodate different drivers. The front and back overlap by an adjustable amount to provide rigidity.

The front wheels are also electricscooterparts rims, but with brake disks instead of drive pulleys. We'll machine off the drive pulleys on those wheels and face the brake mount inwards. This will cause a bit of an issue on the left side, since the brake disk hubs are threaded and the braking force will tend to unscrew that side's hub. But I suspect this problem is easy to solve with enough Loctite.

I went with a relatively low-tech method for working out the geometry of the brake caliper mounts:

The other tricky bit of geometry to solve in the front of the kart was the steering linkage.

From above, it's a pretty straightforward Ackermann steering geometry, with a drive link off the steering column very similar to Cap Kart. But I tried my hardest to contain the entire thing in the 1" vertical space between the plates, which meant that I couldn't use ball joints on the steering pivots. Instead, the two degrees of freedom are split into a horizontal and a vertical pin joint:

The horizontal pin joint is just a shoulder screw with some brass washers. The vertical pin joint, which is far enough inside the kart not to interfere with the plates, attaches to threaded rod that goes to the drive plate on the steering column. Since I know nothing about proper steering geometry, everything is adjustable. The only thing we've sacrificed from Cap Kart's steering is the caster angle, which is by necessity zero in this design. To make up for it (or do nothing at all, idk), the center of the front wheels is just slightly behind the kingpin pivots.

Since the 1/8" aluminum plates don't really provide much rigidity, the gap between the 80/20 rails framing the front of the kart are spanned above and below by 1/4" steering reinforcement plates, which also hold the radial kingpin bearings. The thrust bearings are between the 1/8" plates. It might be overkill, but flimsy steering is one failure that we don't want to deal with.

There are plenty of other little details that went into the design so far, but I'm sure we'll be highlighting them as they get built. For now, we're waiting on parts and I'm on my first real vacation in a long time. The build begins next week and it will drive by mid-August.

DirectDrive: A Simple MechE Solution

2011-06-24T20:03:00.000-07:00

The trivial solution to decoupling my Hall effect phase current sensors:

With the three phase outputs coming off the bottom of the board (top in this picture) rather than the side, they don't all pass over the Phase A current sensor, messing with its reading. With this new arrangement, the coupling between phases is much less. Here's the before and after:

Before.

After.

This quick fix brings the coupling down to tolerable levels for moving on to other testing. I'm amazed at how close the actual gains are (~15LSB/A) to what the first coupling matrix came up with. I guess linear algebra does work. With these gains, the maximum phase current that can be sensed is about 100A, so if I make it past that mark I will have to reconfigure the traces for a less sensitive current measurement. At that point, I will need bigger wires anyway.

I'm still leaning towards a return to the ACS714 integrated-conductor Hall effect current sensors, but before I give up on the through-the-board sensors, I will also try shielding the wires and/or sensors in such a way that they can only pick up the field from the traces passing under them. Then, I may be able to re-route the wires the way I want, which is off the side of the board.

The next milestone was a light load test on a single phase with a current-limited bench supply. Using the SepEx motor field as a giant thermal sink, I ran one phase for 10 minutes at about 350W (48V/7.5A in, 24V/15A out) with passive heat sinking only. No problems passing this test. The temperature reading was clean and the rate of temperature rise on the sink was a mere 0.5ºC/min. Ballpark thermal estimates (the only type I can do) suggest this is reasonable for such a light load.

At this point I'm past the bench supply stage and the next thing to do is run off a battery. If destruction is to occur, this is the point at which it will happen. Shoot-through on a power supply is survivable, but with a large battery pack ready to shove in hundreds of amps, almost any failure is a catastrophic one for the controller. I will also need a suitable load, since the SepEx was already pretty unhappy after sinking 350W for 10 minutes. The next target to hit will be about 2.5kW, in full three-phase operation. Perhaps I need something that cools itself..........

DirectDrive: Well, it certainly looks nice...

2011-06-21T19:58:00.000-07:00

I finished soldering up the first prototype of DirectDrive, my new higher-power three-phase controller. Without a doubt I can say it's certainly the nicest looking controller I've made, to date. But if history is any indicator, it is most likely doomed to failure like almost all of my other v1.0 controllers. The only real question is: Will it be some fundamental design flaw, a layout problem, noise issues, or a fiery death?. Or all of the above? Well,

In the last post I mentioned that the ACNW-3190 gate drivers I wanted to use were in fact not the package I thought they were, and so I went back to the HCPL-3120, my standard high-current gate drive solution since Cap Kart. They have "only" 2.5A of gate drive, though, which is a bit weak for driving four of the DirectFETs. Using 20Ω gate resistors, the switching waveforms looked like this:

The trace that starts high is the Vds. The trace that starts low is Vgs.

I learned a lot about MOSFET switching characteristics, including that the length of the Miller plateau depends on the voltage across the MOSFET. So to test the true switching time, I applied 36V across the FET and measured both the gate voltage and the drain-to-source voltage. The switching time, where the FET is dissipating the most power, begins when the gate voltage reaches the threshold voltage (about 3V) and ends after the Miller charge is satisfied. I measured this to be about 290ns. That's right in line with what I would predict, but my initial calculations suggested that these switching losses would make 50V/200A operation very difficult to achieve. So, I am trying out 10Ω gate resistors:

Wow, that's ugly.

While it's definitely shorter, down to about 110ns, the switching waveforms have much more ringing now. The gate drive traces are fairly long and wander around to get out from under the DirectFETs and bus capacitors. I was definitely worried about the inductance, and here's a clear example of why it helps to put the gate drivers as close as possible to the FETs. The good news is that this was measured up by the TVS diodes that "protect" the gate:

Measuring right at the gate instead reveals a moderately cleaner signal:

As ugly as it is, I've seen worse, and I'm tempted for now to just leave the 10Ω gate resistors in for the rest of the testing phase. On to the next problem!

After I tested a collection of low-side FETs, I attempted to get one full half-bridge up and running. In doing so, I was temporarily stopped by another issue that I swear I've had to solve on several occasions in past motor controller projects. The problem is that the HCPL-3120 gate drivers have a very unforgiving undervoltage lock-out that will shut down the output if the gate drive supply voltage drops below 11V. This isn't a problem for the low-side, which is fed directly by the 15V switching supply. But the high side is bootstrapped and as it turns out, I needed a bigger bootstrap cap to keep the high side on. So, I switched to 4.7μF and the problem went away. With the half-bridges working properly, I finished soldering the rest of the board.

I discovered the first real board flaw when none of my gate drives would turn on, despite all three channels of PWM being active. I've used a hex inverter (74xx04) before to generate the complementary PWM signals, but I guess I forgot that the 74LS series doesn't work on 3.3V. So I'll have to get some 74HCs. In the mean time, I'm not above little-blue-wire hacks:

Little yellow wire...whatever.

I also soldered a current sensor in upside down, but nevermind that. After a few minor fixes, everything seems to be up and running. The tiny temperature sensor and phase current sensors both provide stable zero outputs and the three phases do what they should in response to PWM signals. Moving on to light load testing...

It's a light load, I swear.

Cap Kart's SepEx motor has a 1.3Ω field winding that makes a terrific power resistor. It's big enough to not get hot for a while and it has an assload of inductance, so the current going into it will be smooth at any reasonably PWM frequency. However, for some reason, it has killed a number of controllers in its lifetime, including a Victor HV. So I was a little nervous about hooking it up, but it seemed like the best light-load option.

Mainly, I was looking to test the through-the-board Hall effect current sensors. (If the FETs have issues with this ~20A load, then I'd be pretty much screwed.) The good news is that both current sensors produce a repeatable, stable, and clean output and can resolve current to better than 1A. The range is about +/-80A as configured by copper braid jumpers on the bottom of the board. The bad news is that the current measurements are disappointingly coupled...

Through the magic ways of Gilbert Strang, I was able to produce this coupling coefficient matrix which shows just how bad it is. The lowercase i is the sensor reading and the uppercase I is the actual phase or DC current. The coefficients show how much of each component of actual current winds up coupling into the sensed current on phase A and C. It's not all bad news: the 14.1 and -13.4 make perfect sense (lol) given the gains I expected and the fact that one current sensor is "upside down". The cross-coupling on the C phase is not terrible; it picks up a bit of A and a bit of DC. But the coupling from phase C onto the A sensor (the -10.5 value) is really bad. It means that the A sensor is picking up almost as much C phase current as A phase current. Physically, this all makes some sense: All the wires pass over the A sensor, while the C sensor sits sort-of off to the side. But it's very not good for current control...

So, the options I am now considering:

Presumably if I can find a coupling matrix, I can find a decoupling matrix to recover the true currents from the sensor readings. This is a horrible idea that I will probably try out of morbid curiosity.
Re-routing the wires to come straight off the board instead of passing sideways over the phase A sensor. This is a quick fix that might minimize the coupling, but it's not space efficient and I probably wouldn't be satisfied even if it got rid of a lot of the coupling.
Returning to the ACS714 current sensor and using the back of the board to create an epic bypass shunt to change it from a +/-30A sensor to a +/-200A sensor. It's still a Hall effect sensor, but with an internal conductor and measurement, so the coupling should be much less of a problem. This is the solution I am leaning towards.
Switching to a shunt resistor measurement. I don't really want to think about the isolation issues, but it would be the most accurate. The other problem with small shunts for 200A is they will have very low voltage drops and be hard to amplify.

So I'll have to do a v1.1 to implement a more permanent fix for the current sensing. But in the mean time, Option 2 will probably allow me to continue testing with this board, and I won't feel as bad if I destroy it under heavy load testing. More to come.