Wednesday, June 29, 2011

ECSEW V: tinyKart


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.



Friday, June 24, 2011

DirectDrive: A Simple MechE Solution

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


Tuesday, June 21, 2011

DirectDrive: Well, it certainly looks nice...



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:
  1. 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.
  2. 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.
  3. 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.
  4. 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.


Thursday, June 16, 2011

Pan-Project Update 6/16/11

I got a little distracted last weekend...

...by F1 cars.
I took a spontaneous trip to the F1 Canada Grand Prix, the only F1 race held in North America. It turned out to be a very rainy weekend, but even so the F1 cars were impressively fast and loud:


It's literally not possible to capture the sound of an F1 car passing 15 feet in front of you with my camera. The microphone just saturates and it just sounds like an explosion. Then again, that's sort-of what it sounds like in real life too, when your eardrum saturates. Combine the sound with the ominous sprays of water shooting 20 feet above the treeline on the far side of the track and it's like something out of a monster movie: You know it's coming for you next. Max has a more thorough summary of the experience, plus some better video.

But since we ran into car trouble (lol) on the way back from Montreal, I've had to spend a few days catching up with work. I made a bit of progress on some projects before and after the weekend, but not enough to justify an entire post for any individual one. So, I will do the thing I hate doing and make a Pan-Project Update to make excuses for highlight the lack of  progress on each.

First and easiest,


Sensorless Field-Oriented Control

I've made no progress on this. I have a decent idea of how to start, and I maintain my opinion that you can do pretty much anything in software if you spend enough time messing with it. Some day soon I will do it, and nobody will care because it's software and has no tangible meaning, but then I'll just laugh at everyone.

Moving on then,


Flinch

I got the M3 screws I needed to finish mounting Flinch's four gearmotors, so I did that:


Flinch is a straightforward 4WD robot layout, so there were no surprises here. It's essentially the same size and shape as mini4WDbot:


In fact, as a starting point I just transfered mini4WDbot's entire electrical system over to Flinch. That includes four repurposed VS-11 servo drivers, an Arduino Nano Carrier, and a 7.4V LiPo. I wanted to test the open-loop performance of the FingerTech mini-Mecanum wheels before investing significant effort into the inertial sensors for high-speed Mecanum-ing.

Unfortunately the low-speed tests didn't work out so well. I've worked with larger Mecanum wheels before and even those are very sensitive to weight distribution, driving surface, and the condition of the rollers. The rollers on these wheels are rubber with brass axles riding in plastic wheel hubs. Off the ground, they roll just fine. But under axial loading, the steel washer spacing the rubber roller out from the wheel does not make a very good thrust bearing. Maybe with a lot of tweaking they might do something Mecanum-like, but I don't have the patience for that.

Plan B involves putting real rolling-contact bearings on each roller axle. FingerTech sells these (an implicit admission that the regular axles leave something to be desired?), but they're needle bearings, which won't help much with friction between axial-contact surfaces. So I instead opted for SR144ZZ tiny ball bearings. At least with these I can use tiny shaft spacers to keep the washer from making contact with the side of the wheel. Of course, this means carefully drilling out each roller axle and pressing/gluing in a tiny bearing. After that, another open-loop test to evaluate the new level of Mecanumosity.

Next,


DirectDrive

I'm starting work on my larger motor controller, called DirectDrive because it uses a crapload of DirectFETs. I ordered a single board for testing, since usually my v1.0 motor controllers wind up failing spectacularly in some way anyway. But I can still be hopeful, right? Plus, I get to play with a new toy:


Add it to the list of things that are absurdly cheap if you buy them from China, a bagel toaster programmable reflow oven. DirectFETs cannot be soldered with an iron, since the gate and source pads are under the device. I was planning to use a hot air station, but this is way faster and I've never done it before so it was an opportunity to learn. It's pretty simple:

Step 1: Apply paste haphazardly without a stencil.
Step 2: Place MOSFETs in the correct orientation.
Step 3: Toast for 7 minutes or until lightly browned.
Actually there are a few little DirectFET-specific tricks I learned along the way that I would definitely use in the future:
  1. DirectFETs are ever so slightly magnetic. This is great because you can pick them up with a small neodymium magnet (instead of tweezers) and carefully lower them onto the paste. Once they touch the paste, surface adhesion is enough to pull them off the magnet.

  2. You can look at the board edge-on to verify that there is still a gap between the gate and the nearest row of source pads. If not, you probably want to clean off that one and try placing it again. After reflow, this gap is usually still visible. I did see a few after reflow where the gap was no longer visible. But upon measurement, they did not appear to be shorted.

  3. The drain tabs and source pads need a lot of paste. Screw stencils.You can lay down a thick line. It's got to conduct a lot of current anyway, and much of the volume of the paste is flux, so it gets thinner as it evaporates. It's not like a BGA IC where you have to worry about shorting adjacent balls. There is only one critical point (between the gate and source) and by preferentially steering the line of solder paste toward the far side of the source pads, you can avoid bridging that.

  4. You can and should test the MOSFETs after they have been reflowed. I test to make sure there are no shorts from gate to drain or gate to source. (If you shorted drain to source, you did something terribly wrong.) I also check the capacitance from gate to source, which should be near the datasheet spec and consistent across all FETs. And finally I check the on-state resistance.

As far as alignment goes, some of the FETs are visibly rotated by a few degrees. However, they are very flat, something I was concerned about for heat sinking. I'm happy with the procedure and will be even more confident in recommending it after I load test this board.

One minor problem was that the ACNW-3190 gate drivers that I was so excited about last post turned out to be 400mil DIP packages instead of 300mil. I should have RTFDS more carefully. Anyway, that means I will have to go back to the 2.5A HCPL-3120 drivers. Though maybe I can, you know, stack them on top of each other or something.
And finally,


???

The mysterious four-wheeled Edgerton Center Summer Engineering Workshop 2011 project. It's not quite ready for a reveal yet, but here's a teaser: