Maker Faire NY 2012

I spent the last weekend at a DIY 3D printer convention Maker Faire NY with the MITERS crew showing off some projects from the past year, as well as some older ones. Last year was my first time attending a full Maker Faire, although I've done the Cambridge Mini Maker Faire several times. Armed with a better understanding of exactly how many little kids with inattentive parents were going to try to touch, climb on, and ride the sharp and dangerous projects, I came better prepared this year:

Yes, tinyKart made it down again, this time with a new license plate. Getting it down was a little trickier than last year, since we had to bring nine people plus all the projects in one minivan and one Jeep. That meant going a step further than the two-piece configuration that made it down last year. This year, tinyKart was packed entirely flat and stuck in the back of the minivan along with all of my other small projects:

And I just sat in the seat the whole way down.

I almost didn't bring tinyKart this year, but I'm sort-of glad I did because it was able to finally get a tiny bit of "track" time on the Power Racing Series track at Maker Faire. The Power Racing Series is a relatively new racing league for modified Power Wheels-style cars. tinyKart is obviously not a modified Power Wheels, so it was ineligible to win any races. (Although as some places seem proud to point out, it was apparently eligible to lose them...) 

Still, it was fun to get a little track time in an ultralight kart that was never really designed for anything of the sort, which weighs 55lbs and can be brought down in the back of a minivan. If you want to see what it actually can do, here's Max taking it for some laps with little traffic to slow him down:

It's a viable go-kart with handling that is way better than it should be, given the custom and very flexible chassis. I got to run some laps in the wet and it was quite amazing. By the second day of the Faire, it had incurred a bit of race damage and was down to one wheel drive and a single disk brake. Then, it started raining. No matter, it was still awesome:

So, tinyKart is a little broken after this trip. It's been due for maintenance anyway, so this will be a good motivator to fix it up and finally put on new controllers. Other than that, it needs completely new spindles, since two of them got bent up in brushes with the track barriers. It also needs a new belt and a new steering linkage. (The part which is called a "fusible" in French for reasons I now understand more completely.) And some of the non-structural front frame got beat up. No major structural or powertrain damage though.

Kinda glad we kept those corners in the design.

Of course there were also many copters at this year's Faire. Here's the selection of MITERS flying objects that made the trip down:

From left to right, there was 4pcb (which didn't get to fly since it's mostly an indoor copter), my versatile Talon Quad, Nick's feather-light tricopter, and Banks' Derpcopter. There were several other groups with flying things at the Faire. One that particularly caught my eye was the AeroQuad booth, which had several nice FPV frames:

Generally, it was too crowded to fly around, but there were a few opportunities to do so at the field near the AeroQuad booth. My brother and I also decided to head in early on Sunday to get some aerial video before the crowds showed up. Of particular interest was the (real) Titan rocket, which is a bit over 100 feet tall. Here's some GoPro video from the Faire before it opened on Sunday:

The Talon has been flying great with FFv1.2s motor controllers and the modded KK2.0 firmware. It's mostly limited by my piloting skills and lack of FPV equipment at this point.

Photo credit: Matthew Honickman.

I also brought Pneu Scooter, and as luck would have it the rear tire got a leak the week before Maker Faire just like last year. So just like last year, I took the entire wheel/motor assembly apart, cleaned everything out, and replaced the wheel. I also took the opportunity to extend the phase wires so they would not have to be cut every time I need to replace the wheel.

After the wheel change, I also tried and failed to get a 3ph v4.0 controller in Pneu Scooter for the Faire. But since I ran out of time, I went back to the trusty v3.1 and it worked with no problems for the entire event. It's by far the best way to get around the venue when it's crowded.

That's it for the project updates, but here are some more pictures I collected from the Faire:

Chibikarts and hexarideablepods.

Ground clearance?

Runs on two D&D motors.

MITERS won an editor's choice award from Make.

I hope those are all used metro cards.

One of these things is not like the others...

Ben's scooter hauling most of MITERS back to the cars at the end of the Faire.

FF v1.1 and v1.2s Design Files

I'm finally getting around to collecting and organizing the hardware documentation for my two newest motor controller designs. These are the FF line motor controllers, which I've been testing for a few months now. They're small single-board three-phase motor controllers, designed for sensorless field-oriented control. v1.1 is the larger, higher-power version and v1.2s is the smaller, lower-power version.

FF v1.1 (left) and v1.2s (right).

Both versions share the same logic layout. The microcontroller used is the STM32F103C4, although the design should be pin-compatible with many other 48-pin STM32 microcontrollers, including some with floating-point capability. It can be programmed with a 3.3V FTDI adapter or wirelessly over XBee. The firmware is still very much a work-in-progress, but I've also uploaded two different firmware versions (IAR EWARM Kickstart Projects) here, for reference only:

1. Air Firmware (STM32_air.zip): Framework for closed-loop RPM control based on 1000-2000μs RC-style PWM input. Inner loop is field-oriented current control based on sensorless position estimate.
   
2. Ground Firmware (STM32_ground.zip): Framework for torque-controlled electric vehicles using field-oriented current control. The input is an analog throttle signal. There is an optional ramping start-up but it's not perfect.

Note that the firmwares are my working copies, not release versions. I won't even give them version numbers because they're that non-functional. Repeat: This will not run your motor. Each motor needs parameter tuning and the only way to do that right now is using hard-coded constants in the firmware. I'm only uploading them as examples that others can refer to for development. Also note that this hardware cannot do six-step BLDC control. It's designed with sinusoidal commutation / SVM and synchronous rectification in mind.

Both versions of the controller hardware also share the same gate drive solution, based on the Texas Instruments DRV8301. I call this the magic everything chip, because it's much more than just a nice 2A three-phase gate driver. It also has dual low-side phase current amplifiers, integrated gate and logic power supplies, integrated bootstrap diodes, and a completely independent buck controller with internal switch for creating a logic supply for the rest of the board.

Both versions also have the same I/O broken out, including pins for analog throttle, I2C, UART (shared with the FTDI programming port and with the XBee headers), RC-style PWM input, and three auxiliary inputs that can be either timer capture inputs (encoder), hall sensor inputs, phase voltage sensing, or general-purpose analog inputs. 3.3V and 5V supplies are also broken out to pin headers.

The differences between v1.1 and v1.2s are entirely in the power section of the board. v1.1 has a beefier power stage based on D2Pak-7 MOSFETs, while v1.2s has a smaller Super SO-8 MOSFET layout. The details and design files are below:

FF v1.1 [Design Files]

Size (board only): 3.00in x 1.50 in x 0.50in

Size (w/ external cap): 4.20in x 1.50in x 0.50in

Weight (board only): 28g

Weight (w/ wires and cap): 66g

Suggested MOSFETs: IRFS3004-7PPbf, IPB017N06N3 G, IPB010N06N, IRFS3107-7PPbf

Suggested External Capacitor: 680uF, 63V (x2 for high current)

Approx. Power: 48V / 30A (cont.), 75A (peak)
BOM Cost: $96.90 (1x), $74.38 (10x), $53.39 (100x)

This version of the controller was originally designed with large multirotors in mind, but it's also been tested on a number of ground vehicles at up to 75A acceleration current (the maximum phase current at full throttle). The continuous current capability is significantly lower due to the lack of large heat sink. 30A is my best guess with any of the MOSFETs listed above, but with adequate airflow it could be higher. The maximum voltage depends on the capacitors and MOSFETs used, but is limited to 50V by other components.

FF v1.2s [Design Files]

Size (board only): 2.00in x 1.50 in x 0.28in
Size (w/ external cap): 2.79in x 1.50in x 0.32in
Weight (board only): 11g
Weight (w/ wires and cap): 35g
Suggested MOSFETs: BSC016N04LS G, BSC010N04LS, BSC014N06NS
Suggested External Capacitor: 470uF, 35V (x2 for high current)
Approx. Power: 48V / 15A (cont.), 30A (peak)
BOM Cost: $56.89 (1x), $47.14 (10x), $33.32 (100x)

This version was designed with smaller multirotors in mind, although it should be fine on the not-so-heavily-loaded CineStar 6 as well. It's not really suitable for vehicles, but might work fine for robots / RC cars /  small servo-mechanisms. The maximum voltage and current depend on the MOSFETs and external capacitor chosen, but it should have no trouble at 15A continuous and 30A peak, higher with more air flow or heat sinking.

That's it for now. Later I hope to post a lengthy document outlining the sensorless position estimation algorithm at work in the reference firmware. Even later I hope to make a GUI for configuring the firmware for a particular motor. For now, you're on your own with that.

More FFv1.2s Testing / The Short-Lived FFv1.3ss

After successfully testing one FFv1.2s motor controller on the Talon quad, I got enough parts to complete a full set of six.

Unlike the first prototype, I built these in the "minimum thickness" configuration, meaning no XBee or XBee headers. They can only be programmed with an FTDI breakout board. They also use lower-profile pushbuttons and inductors. Here's a comparison to the "minimum thickness" configuration of FFv1.1:

The overall dimensions are 2.00in x 1.50in x 7mm and 11.3g for the FFv1.2s board alone. (FFv1.1 board-only dimensions are 3.00in x 1.50in x 12mm and 28.4g.) With 16AWG wiring, an external DC bus capacitor, and connectors, the FFv1.2s controller weighs in at 35.1g. This makes it a much better fit for the Talon quad than the 66.0g FFv1.1 with giant D2Pak-7 FETs at 14AWG wiring.

With a cameo by Twitch.

I also switched back to the KK2.0 flight controller to make the Talon quad as light as possible. (You will see why in a bit...) I did a bit of firmware hacking on the KK2.0 to enable the fast angle estimate, which I describe in the previous post. The result is quite amazing: it now has very precise and fast angle control. After the first indoor test from the previous post, I have been further tuning it and flying outside. It's wonderfully stable and easy to fly now, even in some wind.

The controllers are all running closed-loop speed control, so the signal received is directly commanding an RPM. So far this has been working well. Here's a data capture from some outdoor testing with the KK2.0 + FFv1.2s ESC combination:

It shows several seconds of rapid back-and-forth roll inputs, followed by a few seconds of hovering, then a few seconds of climb. The RPM tracks well, although there are some small and rapid oscillations similar to what can be sort-of seen in the indoor test video. The oscillations are especially apparent in the current data. This is, I suspect, because the inner rate loop gains were slightly too high. Testing in the wind with lower rate P gain yielded much smoother flight (still with wonderful fast self-leveling).

The reason for reverting to the lightest possible configuration for the Talon wasn't to go easy on the new controllers, though. It was to try an ambitious payload. This quad normally carries a GoPro camera, which weighs about 200g with its impact-resistant case. The heaviest thing it's carried is my handheld video camera, at 300g. But with the new motors, I suspect it could carry a lot more. Enter TOBL2.

Photo credit: ycraf.blogspot.com.

TOBL2 is the second generation of Max's multifaceted iPhone-controlled robot, probably best known for it's wall-flip ability. It will be making an appearance at Marker Faire NY in September and we thought it would be cool to try to skycrane it with a quadrotor. At about 1lb (450g), though, the first step was to see if the Talon quad could even lift it...

Well that was relatively successful. Other than the swaying, which can probably be minimized with a better rope configuration, the payload seems to be fine. Now we just have to see if TOBL can lower itself down somehow...

The Short-Lived FFv1.3ss

I've been watching Texas Instruments' line of motor drive chips for a while now. In addition to the DRV8301, which has performed flawlessly as a gate driver / current sense amplifier / buck converter controller on FFv1.1 and FFv1.2s, I've been wanting to try out the DRV8332. The DRV8332 is a fully integrated three-phase driver, meaning logic-in / FET half bridge-out. It goes up to 50V and the heatsinkable version (8332) has a phase current rating of 8A continuous, 13A peak. 

And it's tiny. Perfect for FFv1.3ss (super-small?), I thought, so I started a layout for a 1.00in x 1.00in controller based on the DRV8332. To show just how small it is, here's a comparison to the IXYS mini-brick modules I use on the 3ph line of motor controllers:

The 1.00in x 1.00in board is roughly half the board area as the IXYS module alone. The blue chip on the back of the board is the DRV8332 itself. Unlike the DRV8301, it doesn't include the nice buck converter controller or current shunt amplifier, so there was a good deal of work to do adding tiny versions of those in:

The MSOP-8 on the left side of the board is a dual op-amp, configured for low-side current sense differential inputs using two resistor networks. I really liked this layout. The cluster of components on the right side of the board are two switching power supplies. The first, a wide-input buck converter based on the  LT3991-5, would allow me to take full advantage of the 50V input range of the DRV8332 while still supplying an efficient 5V/500mA BEC for logic and receiver power. The second, a tiny boost converter based on the LT3460, would supply 12V/100mA for the gate drive.

Sadly, that's as far as I got before shelving this design. It has a fundamental flaw that I hadn't considered until this point: the FETs in the DRV8332 are not that great. Even though its current rating says it would be a viable controller for something the size of the Talon quad, the FET losses make it not worth it. Even at a relatively modest phase current amplitude of 5A, the 80mΩ per-phase resistance would add 3W of total dissipation to the controller (with sinusoidal commutation). Compare this to the minuscule 0.075W that FFv1.2s would dissipate with with its Super SO-8 FETs. 

At 150W/kg, the rough power-to-weight ratio for the Talon quad, the extra 2.9W of dissipation would be equivalent to 19.3g of weight. So, to justify the tradeoff, the FFv1.3ss board would have to weigh 19.3g (or more) less than the FFv1.2s. (Assuming the wiring and capacitors weights are fixed, as they would be for a given current.) Since the FFv1.2s boards are only 11.3g, excluding wiring and caps, there is no way the extra dissipation of the FFv1.3ss is justified. 

Factoring in the weight of the necessary heat sink for the DRV8332, I'm not sure there is a likely scenario where it would be justified based on a power-to-weight analysis. If volume is weighted more highly than weight, as it might be for some other applications like a mini robot, the DRV8332 might win out. It might also be justified on size alone at very low current where the efficiency is less of an issue. But in that case, there are things like the Toshiba TB6588FG that I used on 4pcb which could probably do the job.

It's too bad, because I was really starting to like this layout. But it seems like it wasn't meant to be, as far as flying things are concerned.

FFv1.2s: First Test

I got the boards for FFv1.2s, a slightly smaller version of my latest line of motor controllers:

The boards are from OSH Park (formerly DorkbotPDX PCB Order, you might be able to tell by the color scheme). It's a terrific deal for small boards: $5/in^2 for three boards. For example, this board was 3in^2, so I got six for $30. The total time from order to delivery was a bit under three weeks.

These boards have exactly the same logic section as v1.1, but an entirely redesigned, smaller power section. Instead of massive D2Pak-7 FETs, it uses Super SO-8s. These are extremely popular in RC ESCs because of their low cost, relatively high power density, and thin package (more compact and easier to heat sink). I'll be trying two different FETs: the Infineon BSC016N04LS G (40V, 1.6mΩ) and BSC028N06LS3 G (60V, 2.8mΩ).

One difficulty with using Super SO-8 FETs is that, although it's possible to solder them from the sides, good thermal performance will probably only be possible if the drain pad under the chip is reflowed. The DRV8301 magic chip needs its ground pad reflowed anyway, so this doesn't add any extra steps for me.

It's just one trip to the bagel toaster.

Even though v1.2s is only reduced to 2/3 of the area footprint of v1.1, there's also a significant reduction in height thanks to the low-profile FETs:

The left-most board is a v1.1 without any wires or external capacitors. The middle board is v1.2s with XBee headers fitted. The right-most board is v1.2s with no XBee headers. In the smallest configuration, it's 7mm in thickness. The tallest components are now the three pushbuttons, and even those are lower profile versions of the ones in v1.1.

Here's what it looks like wired up:

The total weight with 16AWG wire and connectors is 35g, compared to 66g for FFv1.1 with 14AWG wire. Most of the weight is in the wire and connectors. The FETs are nowhere near as beefy as the D2Pak-7s, but I think the 40V/1.6mΩ version might still be able to handle 20A continuous and 40A peak current. (Compared to ~40A continuous and 75A peak for v1.1.)

The first assembled board survived power-up without exploding, so therefore it was flightworthy.

Poor Talon quad - it really has become a test bed for just about every piece of hardware. It has so much stuff attached to it now in such a disorganized and heavy way. I put a single FFv1.2s on, loaded with identical firmware as the other three v1.1's. Since they're running closed-loop RPM control now, the slight mismatch shouldn't matter much. Here it is ready for its first test flight with the Chair of Safety still in place:

After a few successful indoor test flights, I also took it outside a few times with the data collection running. The data is from the v1.2s, which was fitted with the XBee. The other three v1.1's are running blind. Here are a couple data segments showing climbs and fast maneuvers:

RPM tracking looks good and the average current is around 5A, peak 10A. The FETs are room temperature and I suspect I won't be able to even get them warm until I try it out on the CineStar...

One more motor controller done. Time to start a new one. Here's the teaser:

FFv1.1 Air: Closed-Loop RPM Testing

With the ground firmware working well on a few test vehicles, I've moved back to the air firmware for the FFv1.1 motor controllers. (My motor controller page has finally been updated!) The challenge for the past week was to get the air firmware working in closed-loop RPM mode on the Talon quad, which has nice new motors and a new flight controller for testing.

Closed-loop RPM means that the input signal, a servo-style PWM pulse, commands a specific motor speed. (For example, 1200-1800μs could be mapped to 0-5000rpm.) In RC helicopter terminology, this is called "governor mode" and would be used to hold the rotor speed constant as the blade pitch is varied. It's not typically used on multirotors, since they have fixed-pitch propellers. But there are some performance advantages if it works well. It's also an interesting control system challenge, so I had to try it.

I had previously demonstrated closed-loop speed control with the large hexrotor motors, but the performance was very sluggish and at the time, I decided to use normal voltage (really duty cycle) control for the first test flight. It's the method that most commercial BLDC speed controllers use, and it's reasonably fast, limited only by the ESC's internal filtering. It's also a good approximation to RPM control since applied voltage is roughly proportional to motor speed in steady-state. (IR drop causes some non-linearity.)

The downsides of direct duty cycle control are that it offers no chance to limit motor current and it can't compensate for IR drop or slight differences in motors. Most of the multirotors I've used have cheap motors, and there's always one that's just a little worse than the others... Closed-loop RPM control can solve this problem by ensuring that the same command causes all the motors to spin at the same speed. 

Since I already have a current control loop from the ground firmware, adding an outer RPM control loop seemed like it would be easy. This was the loop structure I used in my first closed-loop RPM post:

Motor speed is measured by the flux observer and compared to the desired motor speed to create an RPM error. The error is sent through a PID controller and the output is the demanded current. While there's nothing wrong with this scheme, it happens to be fairly slow. There must be an RPM error in order for the PID controller to have an effect, so it's always chasing the target. To achieve faster performance, I added a feedforward term:

The feedforward term goes from RPM command directly to the current command, bypassing the PID (or in this case, PI only) controller. In steady state, motor current is proportional to the square of motor speed, due to the aerodynamic drag on the propeller. The target current is therefore set to the expected steady state current for a given RPM command, plus a P.I. term to handle transient (accelerating) current and any offset from the expected value. The constant of proportionality for the feedforward path is determined experimentally.

The speed-squared relationship of aerodynamic drag has other consequences for the closed-loop controller: 1) The damping ratio of the plant increases with speed. and 2) The damping ratio is different for increasing and decreasing speed steps. To deal with these effects, I made the gains for the outer PI loop speed-dependent and asymmetric. I don't like speed-dependent gains, but in this case it seems unavoidable for achieving good performance over a large speed range. Higher speeds get higher gains. Increasing speed gets a higher gain than decreasing speed.

The new feedforward structure, combined with speed-dependent gains for the RPM controller, improved the performance a lot. As a baseline, I implemented this scheme on the new Talon motors and tuned the PI gains to get the RPM step response as fast as possible.

::clamps quadrotor to nearest heavy object::

As expected, increasing the gains eventually led to oscillations. The test was a step input change from 2000rpm to 4000rpm. I stopped at a point where the overshoot was about 10% which was with a 0-100% rise time of 200ms. This is Plot #1 below:

To confirm this baseline, I put all the gains and plant specifications into a simulation of the controller/motor/prop system. What I found was that the real-life system was oscillating a lot more than the simulation, with the same gains. That meant there was an unaccounted-for bandwidth limit in the real controller. I spent a day tracking it down. I had already accounted for both the current and the RPM measurement filters, so it had to be something else.

The bandwidth-limiting element turned out to be the high-speed position filter I added a while ago. Above a certain speed, it merges the interpolated electrical angle with the angle indicated by a flux observer zero-crossing. At constant speed, the error between these two angles should be zero mean and the filter doesn't cause any lag. But during acceleration, the interpolated angle will lag the true angle by some amount. This lag was causing oscillation in the D-Axis current controller, which in turn was limiting the overall closed-loop bandwidth.

The solution was simple: I turned the high-speed position filter off. It seems not to be necessary now, possibly because I fixed the problem of flux offset at high speeds. Whatever the reason, the oscillation went away and the real step response looked a lot closer to what the simulation suggested it should (Plot #2). From that point, I made a few small changes to push to faster rise time:

• Changed the RPM estimator from updating once every mechanical cycle (7 electrical cycles) to once every 3 electrical cycles. This decreases the effective low-pass filter time constant in the RPM feedback path. The tradeoff is RPM resolution at high speeds, but 3 cycles seems like a reasonable compromise. Result of this change is Plot #3. The small overshoot in Plot #2 is eliminated.
  
  
• Doubled the gains. The result was a slight increase in rise time, but the overshoot also returned (Plot #4).  It was clear that increasing the gains more would bring back oscillations.

To improve the rise time (and the closed-loop bandwidth) further, I could speed up the inner current loop by increasing its gains or decreasing the time constant of its low-pass filtering. But the current measurements are noisy and having the filtering in place helps keep sensor noise from being amplified. (It's the classical controls trade-off between closed-loop bandwidth and noise rejection.)

I chose a different option, which was to add another feedforward path. This one goes directly from RPM command to voltage (duty cycle) output:

In some sense, this feedforward path is exactly the direct duty cycle control from before. A step increase in RPM immediately increases the duty cycle to the value that would be expected to produce that RPM in steady state. The output doesn't have to wait for the RPM or current error to build up, so the gains of the feedback controllers can be kept lower.

There is a downside, which is that the feedforward path bypasses the current limit. In the case of a large step increase in RPM command with a low-resistance motor, a short burst of current over the limit could occur before the PI controller has a chance to compensate for it. Depending on the system, a slew-rate limit on the feedforward path could be used to prevent this.

Plot #5 shows the effect of the RPM-to-voltage feedforward path. The 0-100% rise time is cut to under 100ms with acceptable overshoot and very little oscillation. The Q-Axis current instantly rises, rather than building up, giving a short burst of torque to speed up the motor. In this case, the current pulse seems within reason for what the MOSFETs can handle (although what's plotted is filtered current - the instantaneous value on the time scale of one PWM cycle is higher).

Satisfied with the step response, I loaded the new closed-loop control mode onto four FFv1.1's and set them up on the Talon quad:

And here is some data from the indoor test flight showing RPM command tracking:

Despite being very heavy (1.375kg), it flies nicely with the new motors, closed-loop RPM control, and new flight controller. It won't stay in this configuration, since it's too heavy to carry the GoPro now. But it will make a great test platform for the smaller FFv1.2s controllers that I have sitting on my desk waiting to be soldered. As for the larger FFv1.1's, they're most likely going back on the CineStar 6 next...

FFv1.1 Ground Firmware Testing / FFv1.2s

Charles was kind enough to volunteer his daily mode of transportation for motor controller testing:

Read: The previous controller melted, or something.

Melonscooter, so named for the "melon-sized" Turnigy C8080-170 brushless motor that drives it, has been through a lot of motor controllers. The C8080-170 no longer exists, but the longer variant, the C80100-130 is now available through Leaders Hobby (what you get if you send "HobbyKing" forward and backward through Google translate a few times) under the EMP brand name. I used to think this was the hardest motor to drive, within the set of small EV traction motors. Used to. Then I met this insane thing:

FreeFly David's custom e-bike motor.

After attempting to drive this two-turn monster e-bike motor with only marginal success, the C8080-170 looks rather tame. Especially since Melonscooter has fixed gearing and no freewheel, so it's entirely possible to kick start it. That, and the low-cogging 12-slot/14-pole configuration make it seem more feasible. The C8080-170's resistance (21mΩ line-to-line) and inductance are very low, but I had already pushed the overcurrent latching fault to 200A to deal with the current ripple on David's e-bike motor, so again this seems relatively manageable.

It looks much more legit with a 3d-printed case.

FFv1.1 is still undersized for the C8080-170 motor. Additionally, since Melonscooter runs a 40V battery pack, I'm using one of the FFv1.1 boards with the relatively wimpy 60V FETs (IPB034N06N3 G). Based on the e-bike testing, I decided the maximum phase current they would be able to handle for acceleration would be about 50A. At 3.4mΩ per FET, the conductive losses at 50A phase current add up to (3/2)*(50A)²*(0.0034Ω) = 12.7W. Add to that the switching losses, current sense resistor dissipation, and other parasitic resistances, and the power stage might be dissipating 20W or so of heat, which is a lot for a board with no heat sinks.

Tuning the sensorless FOC parameters for the C8080-170 took surprisingly little time, partially because I'm getting used to the steps required and partially because I already have good measurements of inductance, resistance, and back-EMF constant from this motor. It also helps that it could be push-start, since adjusting the open-loop ramp start takes a while. After a few iterations of parameter adjustment, it was ready for test driving:

It's way quieter than usual, due to the sinusoidal drive voltage. The current is low for what the C8080-170 can handle, so the acceleration is nothing spectacular. Although, due to a software error the acceleration currents in the video exceeded 50A by a bit. You can see the wireless data-logging software running in the video, but I stupidly overwrote all the test drive data, so I'll have to capture it again later.

The peak flux amplitude was about 5.5mWb. Multiply by 7 pole pairs to get the per-phase back-EMF constant, about 0.042V/(rad/s). That's peak line-to-neutral volts. Invert, divide by two, and convert units to get the approximate Kv: 124rpm/Vdc. This is substantially lower than the 170rpm/Vdc the motor gets with BLDC-style square wave control. Less speed per volt, more torque per amp.

The next step for FFv1.1 ground firmware testing will be upgrading to nicer FETs and improving heat sinking a bit. One FET option is the proven 75V IRFS3107-7, used on Cap Kart's half-bridge and the Victor 883107-7 controller. These have already shown that they can handle 75A acceleration current with no trouble. An even lower resistance option would be the 60V IPB017N06N3 G. It also has half the gate charge of the 3107-7, so it will cut down on the switching losses. I'm not sure I would use it with a 12S LiPo (44.4V nominal, 50.4V fully charged) system, but the current 60V FETs have proven sufficient for 12S A123 (39.6V nominal, 43.2V fully charged).

On to smaller things...

FFv1.1 (and v1.0, really, since it was virtually the same) have been very successful so far. The DRV8301 magic chip has proven its worth, since I have yet to see any noise problems at all. The target application for FFv1.0 and v1.1 was large multirotor motors, specifically for the CineStar 6, and I designed them with 20-30A continuous motor phase currents in mind. With good heat sinking or air cooling, they can probably handle 50A continuous phase current. But now I realize that it might be useful to have a smaller, lighter version for things in the 10-15A continuous phase current range. So it's time for a new revision, FFv1.2s:

The logic and gate drive sections of the board are exactly the same as v1.0 and v1.1. The power section has been entirely redone to use six Power SO-8 FETs. Power SO-8s are increasingly common thin, leadless SMT packages for power MOSFETs. There are a huge variety of lower-voltage FETs in this package including some amazing ones like the Si7192DP at 30V/1.9mΩ. They're also easy to heat sink from the top surface, since they're very thin. So even though the power stage looks disproportionately small, it should be able to handle a decent amount of power.

My target application for these is the smaller multirotor motors, such as the ones on my Talon quad. The FFv1.1 boards have already shown significant increase in efficiency on the Talon quad, but they eat up all their advantage by being much heavier than the Turnigy controllers it normally uses (65g from FFv1.1 vs. 19g for the Turnigy Plush 18A). I don't know if I'll get all the way down to 19g, but FFv1.2s should be close to that. Even though the board area is only 33% smaller, the weight should shrink by a lot more with the thin FETs and smaller capacitors.

Because the logic and gate drive section is the same as FFv1.1, it will still be a full-featured sinusoidal FOC setup with wireless capability through the XBee. (For minimum cost/weight configuration, the XBee will be left off, but it's useful to have the header there for wireless programming/debugging.) As usual, I will post the relevant design files pending testing.