Yes, yes I do need more flying things.

My fleet of flying things has grown quite a bit over the last few months, and I'm not just referring to Kerbal ships. First off, a little pocket quad!

This is the HobbyKing Pocket Quad, a tiny < 30g single-PCB quadrotor that comes ready to bind to a Spektrum transmitter. (Well, first you had to glue the motors in place with hot glue, and then discover that the entire craft vibrates like crazy unless you glue them much lower in the booms than the product images indicate.) The newer model (v1.1) comes with plastic motor mounts, which is nice. And it really is a pocket quad, no joking:

Well, maybe time for cargo pants...

Having built a single-PCB miniature quadrotor, I know how tough they are to make stable compared to their big counterparts. The propeller slew rates and sensor bandwidth required to keep up with the fast mechanical time constant of a miniature/micro quad are hard to achieve even in a completely rigid system. Throw in nasty mechanical resonance excited by high RPM motors and you get a controls nightmare.

This quad is so small that I feel like quantum mechanics might be coming in to play as well. The heart of the control system is a MultiWii-compatible sensor suite (MPU-6050 flavor) and ATmega32u4. So, you can tune it using the MultiWii GUI which is well known and easy to use. It has directly-controlled brushed motors, so there's no problem of slow brushless ESCs to deal with.

And, oh yes, important point: it does fly.

Out of the box (actually, it came in a static bag), it's not quite as graceful as a Walkera Ladybird. But that could be mostly due to the less-than-ideal motor mounting in the v1.0 frame that I got. Or it could be that it requires a bit of MultiWii fine-tuning. Since I recall one of the very first almost unbelievably stable nano quadrotors was based on MultiWii, I'm not surprised this one is also pretty easy to fly.

Speaking of MultiWii, I still have one laying around that I used to write some dirt-simple attitude estimation code. The ultimate goal is to create a flight controller out of less than 500 lines of code .(It's Arduino C code, so the 500 line limit assumes some libraries to take care of low-level things like I2C reading.) The point isn't to improve on the MultiWii control code, just to strip down quadrotor flight control to its absolute simplest functional form. Something to bridge the gap between control theory and actual, readable C code that people can understand without digging through abstracted libraries.

Anyway, such a project, if it does pan out, will require a new airframe. Actually, that's a complete lie and I just wanted a new airframe.

This is a size I have yet to play with - an F330. (Thanks for the frame, DGonz.) It's a good bit smaller than the Talon, which is probably a good thing for testing a completely custom flight controller. I have a hunch that it's actually a really good size for a GoPro-carrying quad...if you can work out the vibration isolation problem that plagues small GoPro quads. Anyway, even if it proves useless for GoProing, it will make a nice test frame that is essentially free.

The motors are Turnigy Air L2210C-1200's, also from HobbyKing. On one hand, they are well-built, have extremely low cogging, and good Kv/resistance combination for their size. On the other hand, they suffer from the axial play issue that makes small outrunners awful. (The rotor can is not axially preloaded, so it loosens slightly and then makes a ratcheting noise as it moves due to magnetic forces.) 

And on the third hand that you didn't even know you have, the prop adapters are terrible. They are extremely tall, which makes them almost useless for quads for the same reason that gluing the motors in the Pocket Quad as they are pictured in the product image is awful. Having the props so far away from the boom is a recipe for vibration, since any imbalance now has a huge moment arm for twisting the boom. I have attempted to modify them as much as possible to get the props down closer to the booms, but it might be hopeless. Maybe time to try out some different options.

One thing that was very helpful on this build was the 4-way XT60 to 3.5mm bullet splitter.

For ESCs, I used the same FFv1.2s's that have served me well on the Talon for quite a while now. They're a little big for this size frame, but I managed to fit them in sideways in a way that doesn't seem too inefficient.

And some lighting.

And until I create my mythical sub-500 line flight controller, it'll use a KK2 running the latest firmware (v1.6), which is pretty solid. Blah blah Stability blah GPS blah...it's less than $30, it has an LCD on board for tuning, it reliably arms and disarms on command, and I thoroughly understand the control code at work inside of it (because I can go read it myself), which makes me actually trust it. Maybe to people who treat every flight controller as a magic black box the perception of value and reliability is very different...

Oh, I forgot one other important reason why I wanted an F330: It fits in a backpack. This had only hypothetical benefit to me until the day after I completed this quad and went on my very first West-coast hiking trip with high-mountain-and-high-voltage-loving Tyler, as well as some other timezone-shifted MIT people. We went on a "tame" (Tyler's definition, not mine) hike up to Pratt Lake. I asked if there would be some flat, open area around the lake from which to take off and land.

"Yes."

I did find one rock with a flat enough top to take off and land from on the 30º rock slope. The picture above is actually from the quad's GoPro just before returning to my little landing pad rock. Unfortunately the video itself is not very pretty at this point due to the wonderful world of CMOS and vibrations. But the stills were worth the quick test flight.

A view of the lake from about 75-100ft up. Yes, I could have simple climbed back up the rock slope to get virtually the same picture. But dammit this is the future and there must be flying robots involved.

Spying on the rest of wilderness-MITERS (label stolen from Amy) from behind a tree.

So the next step for the F330 project is to travel down the wonderful road of vibration minimization and isolation. Precision propeller balancing, custom prop adapter turning, motor replacement, motor balancing, and silicone/memory foam padding are all stops I might visit along this path. Finding the magic combination to mechanically filter the prop vibrations (~50-100Hz in this case) is an annoying but straightforward task. In addition to making the video more tolerable, it will reduce gyro noise at that frequency, which should simplify the control task a lot.

There's one last new addition to the fleet. This one is also small and from HobbyKing, but it only has one rotor (gasp).

Well, two rotors actually.

It's a Turnigy FBL100, HobbyKing's counterpart to the Blade mCP X. These are nano-scale flybarless helicopters, which are such a giant leap from the counter-rotating-blade mall toys from not that long ago that I had to have one. I've never flown a collective-pitch RC helicopter before, so I figured this would be a good way to start learning. The trick is is that the blade pitch can be negative, meaning you can fly inverted and do other crazy RC helicopter things. And by "you" I mean not me. 

But it was easy enough out of the box for me to simply hover. It has active 3-axis electronic stabilization (in lieu of a flybar) using three very tiny and very cool linear servos controlling a CCPM swash plate, as well as a feedback-controlled tail rotor. That used to be a lot of controls to fit in a tiny package, but not anymore, this is the future. I do wish I could tweak the controls and the pitch/throttle curves. (You can do the latter, if you buy the transmitter module for use with your own radio instead of using the stock included transmitter.) But even with just stock setup it's fun.

And then you add a strobe light and it becomes 10x more fun (and ~3x more difficult to fly):

NAB 2013: Where are the gyros? / New video editing software.

A couple weeks ago I was at the NAB Show with Freefly for the MōVI launch, the first product I've helped work on at the new job. That meant spending a lot of time doing the chicken head dance and explaining to people that there aren't actually spinning flywheel gyros on things anymore...

It's a camera gimbal, similar to what would be mounted to a helicopter or multirotor, that you can also carry around in your hands while it stabilizes the camera. (If you read this blog, I'm sure you know all about control systems and active stabilization so this probably doesn't amaze you as much as it still amazes the non-technical public...)

Since I spent nine hours a day at the booth talking to people about gyros (Wait, is this Maker Faire all over again?), I didn't get as much time as I would have liked to wander around this expansive tradeshow, which covered three whole buildings. (It's about 10x the size of the EVER Monaco Expo / car show I've been to a couple times.) There were definitely a lot of camera-carrying multirotors this year.

Here is just one of many....

I was mostly impressed by how it folded up.

There was also a giant two-story indoor flying tube where DJI showed off some of their products. And several outdoor booths with all manner of flying cameras ranging from GoPros up to big-budget cinema cameras like the RED Epic. Speaking of RED, they had a clean room installed on the show floor where they were doing live sensor upgrades to their new 6K / 100fps sensor. (So to watch the video it produces, you need nine HD screens in a 3x3 grid and it has to play in 4x slow motion...)

Most of the camera stuff at NAB is way outside my budget, but one thing that excited me was the Blackmagic Pocket Cinema Camera, which was also just announced at the show. It shoots raw or high bit-rate compressed 1080p video onto normal (but expensive/fast) SD cards. If I were planning to upgrade from my Panasonic HD camcorder in the near future, the $995 price is not that bad. The only real problem for me is that it weighs 355g, (maybe less than 500g with a small lens?), so I would be instantly tempted to put it on a multirotor, and then I would be at risk of crashing it all the time. I doubt it's as durable as my GoPro...

I think of all the NAB Show things I saw later read about on the internet, the one that caught my attention most was new, free-ish video editing software called Lightworks, by EditShare. I was pretty disappointed that the new Windows 7 edition of Windows Live Movie Maker is a stripped-down piece of crap, even compared to the at least somewhat functional WMM from the Windows XP era. (The old WMM had an active user community with lots of third-party add-ons for people who wanted to use it as an actual tool.) So a new piece of editing software that doesn't cost hundreds or thousands of dollars was definitely something I wanted to try out. And it looks like a very nice tool.

Maybe I was attracted to Lightworks because the desktop layout is almost indistinguishable from that of a CAD program:

Which of these is the video editing software and which makes 3D models?

Despite being a relatively new program (I'm using the Windows beta version), the interface feels very smartly developed and intuitive. Combined with a set of quick-start video tutorials, I didn't have to spend much time at all to learn how to do simple things like make clips, arrange a timeline, trim ins and outs, work with audio tracks, and add simple effects like fades and dissolves. The options for moving a cut are particularly nice: you can make clips on either side of the cut longer or shorter independently or have one get longer and the other get shorter at the same time (to keep sync). Maybe this is a pretty standard feature in professional editing software, but it's my first time using it and I can't imagine how to ever work without it now.

The only part of the workflow that was not quick and easy was exporting video. Importing from various formats works great, but exporting to something other than a hardcore (and huge) editing format was a challenge for me. H.264 support is through Quicktime, maybe? The new beta version may support native H.264 without Quicktime but I failed to make that work. So in addition to buying the Pro version of the software, you have to also have Quicktime Pro to create H.264 files? And then after all that the H.264 output had no audio (a known bug). Luckily, you can export the audio track as a .WAV, so after fooling around for a few hours to get the H.264 export to work, I still had to use my trusty all-purpose MEncoder shell program to reattach the audio.

I'm sure the export quirks will be worked out in newer versions of Lightworks, though. If the software stays the same price ($60 for the Pro version with full codec support, including H.264?), then it's an amazing deal for a real editing tool.

To test out the software, I've finally gotten around to collecting up all my random GoPro clips from around MIT, flying with my Talon quad. No fancy stabilized 3-axis gimbal for me (well, no gimbal at all...just taped to the bottom of the quad), so get ready for a rough ride:

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

Camera Test: HD Wing Camera II

Recently HobbyKing released a new version of the Wing Cam, which I had previously tested as Kramnikopter's on-board camera. The original 720p Wing Cam suffered from the rolling shutter problem that a lot of the small on-board cameras have, where the video gets all wavy due to vibrations. But, with good shock mounting it worked okay. And it's cheap. You would not be terribly upset if you crashed one of these.

The new HD Wing Cam II is more expensive, at about $90, but it has a full HD sensor with the same resolution and frame rate options as the GoPro HD Hero 2, which is $300. This includes 1080p at 30fps and my favorite, 720p at 60fps. It also has the advantage of being lighter than the GoPro and it has a 120º field-of-view lens instead of the GoPro's 170º ultra-fish-eye.

The real question, then, is video quality. I bought one to test and made a quick mount for it using some spare GoPro hardware:

This mount is now interchangeable with the GoPro mount and has one geometric advantage: It can point straight downward. I still haven't gotten around to making longer landing gear, so for the time being the plan is still to take off and land on the cameras...

To get a fair comparison, I used the same Talon Quad frame with the same shock mounting for both cameras. They were shot within minutes of each other, so the lighting was about the same for both. I also tried to point at roughly the same things, but it was windy so I just kinda flew around the field.

Overall, the GoPro HD Hero 2 is the clear winner in terms of video quality. It seems to be less affected by vibration, which may just be a side-effect of its much larger mass. But it also has much better exposure control. With the HD Wing Cam II, the exposure changes too much as it goes from looking at >50% sky to looking at >50% ground. The GoPro had spot metering off (the default) in the video, and it does a better job of setting the exposure.

Random though: Somebody should make a firmware mod that does 720p 60fps with alternating exposures that can be later combined into 720p 30fps HDR video.

I can still see using the HD Wing Cam II for some things. It would be great for pointing straight downward, where it wouldn't have the exposure problems it has when looking at the horizon. The less-wide FOV is nice. (The GoPro's "narrow" FOV options are not good - they're very noisy.) The Wing Cam is also cheaper and lighter by a lot, which is important if you want to use a small quad frame and not worry too much about crashing. Overall, the price:performance and weight:performance ratios are about the same for the original Wing Cam, the HD Wing Cam II, and the GoPro.

4pcb Instructable

I finally got around to creating an Instructable for my PCB Quadrotor. 4pcb is a "low-level" build, perfect for people who don't like black-box components and want to do everything from scratch. But it's also simple to put together and Arduino-based for easy coding. I'd love to see a swarm of them flying around some day, but I really want to see derivative designs, like a hexrotor version!

I've updated the documentation on my own 4pcb page to redirect to the Instructable as the primary source of information for how to build it.

In other news, Talon hexrotor!

For $75, you get about $300 worth of carbon fiber and machined aluminum parts that fit together into a 625mm hexrotor. I won't be doing much with it for a while, since I have to get my huge hexrotor flying with custom ESCs, but I couldn't pass up the deal.

FFv1.1: Air, Land, and...well that's it.

FFv1.1 is the new minor revision of my small motor controller, which has so far tested successfully on the Cinestar hexrotor motors. The controller is sized for 24V (6S LiPo), 30A continuous and 60A peak current, and uses the same Sensorless, Sine-Commutated Field-Oriented Current Control (SSCFOCC) that I've been using on Pneu Scooter.

Unlike most of my other controllers, the FF series has power and logic integrated on a single board, optimized for size. This is enabled by the TI DRV8301 pre-driver, which so far has been working very well despite my fear of integrated power/signal ICs. Since I haven't had any obvious hardware problems, the only change in the v1.1 minor revision is the layout of the DC bus capacitors:

Instead of two 10mm electrolytic capacitors sticking up at a weird angle, I opted for a bank of large 50V ceramic capacitors, eight in total, on the board. The ceramics are more expenisve, but they should also improve the high frequency filtering of the DC bus. Because they are much higher cost per energy, I also planned to use a single large electrolytic capacitor sticking off the side of the board.

One problem with developing a controller that might be used on a hexrotor is that you need six of them. So, for v1.1, I got a 5x2 panel of boards from MyRO, a not-shady Chinese board manufacturer (~2 week turn). At this point I should thank the folks from FreeFly Cinema who donated the Cinestar frame and backed the first round of FF controller development.

Here's the fresh panel:

The individual boards are v-scored, so they're easy to break apart by hand. One reason I wanted to get the boards as a panel is so that I could batch-process the soldering. And damn, it was a lot of soldering.

I mostly solder everything by hand with a magical Weller WD1001 station, but in order to do the DRV8301's power pads, I used paste and a reflow oven.

95% finished Side 1. This side has the XBee radio headers.

95% finished Side 2, with the microcontroller and gate driver.

In total, it took about 14 hours of soldering spread over three days and not including the time to attach wires and connectors to the finished boards. It's probably the second longest soldering job I've ever done. But I think I probably cut the time in half by doing the whole panel at once instead of working with individual boards.

The finished product, without heat shrink covering and connectors, looks like this:

The three blue wires are motor phase outputs, the red and black are DC inputs, and the three-wire connector is the servo-style PWM input. There's also a 6-pin header for programming with an FTDI adapter, although so far I've been programming wirelessly by XBee. In this configuration, the total footprint not including wires is 4.25"x1.5"x0.5". Without the programming header and electrolytic capacitor, the minimum footprint is 3.0"x1.5"x0.5". The weight including wires and connectors is about 65g.

For the six boards that will wind up on the hexrotor, I used IRFS3004-7 FETs (40V, 1.25mΩ) and a 680μF/35V electrolytic capacitor. The remaining four use Infineon FETs, IPB034N06N3 G (60V, 3.4mΩ) and 330μF/63V capacitors. These are prototypes for a higher voltage, lower current version, and in particular I wanted to test them on some ground-based vehicles. I left these four connected from the panel:

Quad-core motor controller.

The reason for this is because I wanted to test them on a 4WD vehicle:

The vehicle, ChibiKart, is a 4WD miniature go-kart with custom in-wheel motors. The controllers are shady eBay specials that do sensorless BLDC at about 25A peak for $28. While I definitely can't compete with them in cost, I can match their power and four FFv1.1 boards could fit in a single one of their enclosures. (I may actually try this, now that I think about it.)

It's probably a better idea than a McMaster-Carr bag.

After some initial testing (video below), the controllers performed well with 25A peak current but had trouble ramp-starting all four motors at the same time. The eBay controllers can do it on level ground, but with limited torque for the first instant while the back EMF zero crossings are still noisy. My eventual goal is to have a sensorless start at full rated torque, although it may require more than simple open-loop ramping. For scooter (or e-bike) use, the simple ramp start or a manual push start would be sufficient.

Like most of my motor controllers, FFv1.1 is set up for wireless data acquisition. Here's some data from one of ChibiKart's test runs:

The regenerative braking on pedal lift had a nice feel. I'm eager to implement a better ramp-start and get tinyKart running on sensorless DirectDrive like I've been saying I would do for months.

But for now, back to multirotors. The main purpose for the other six FFv1.1 boards is to test fly on the Cinestar 6 hexrotor. Before I feel comfortable enough to do that, though, I decided I should flight test the controllers on my Turnigy Talon quadrotor. It's a much more manageable size (500mm from center-to-center), but it can carry a substantial payload so it wouldn't mind the extra weight of large controllers and heavy-gauge wiring.

I was going to heat shrink the controllers, but decided to leave them bare for testing until I'm confident they don't have any bad solder joints. So, I just zip-tied them to the frame for now:

To accommodate the output signal from the KK multirotor control board, I wrote a simple PWM input routine using a spare timer on the STM32. It measures pulse length and adjusts voltage magnitude directly (no current control.) However, the voltage phase is still feedback-controlled to keep d-axis current at zero. This is a unique control scheme not possible with normal Field-Oriented Control. It should retain the "feel" of an airplane-style RC ESC but have optimal torque per amp at all speeds.

For the PWM input, I used a digital low-pass filter to limit the spin-up rate of the motors. I initially did this in lieu of current control to limit the maximum amount of current the motors would see under normal operation. However, after flying with a relatively fast input filter (τ = 33ms), I encountered the other reason why one might want to filter the input: vibration noise.

The PWM input under hover conditions would actually fluctuate by about +/-50μs (+/-8% of full range). This noise is almost certainly from the gyros on the KK board, and I don't blame the cheap controller because I had major gyro noise issues with the Pololu minIMU-9 too on 4pcb. Gyro noise due to mechanical vibration has been by far the most hassling part of building multirotors for me. In any case, it was actually beneficial to increase the input filter time constant to about 50ms and turn down the control gains slightly to reduce how much the ESCs would amplify the gyro noise.

Lastly, video of both ground and air testing:

So far the controllers are working as planned. This marks the first time I've ever tested eight controllers in one day without blowing anything up.

KKv0.0 Camera Platform

After a not-so-successful attempt to mount my HD video camera to a Turnigy Talon quadrotor frame, I concluded that the camera is a bit too heavy for this configuration, and that better vibration isolation material would be needed. A GoPro is much more well-suited to the task, so maybe that will happen in a future version. But I also ordered one of these $37 720p minicams, which have gotten mixed reviews. It's much lighter than either of the alternatives and I would be much less sad if I lost it in a crash.

For now, though, I decided to explore vibration isolation options without solving the problem of having a too-heavy camera on this motor/prop combo. The two materials I tried in v-1.0, felt and closed-cell foam tape, both failed to damp whatever frequency of mechanical vibration was causing the camera to be shaky. So, I went for a known solution of memory foam (e.g. McMaster PN 86195K314).

There's a 1/4-20 screw going into the bottom of the camera that, with a large washer, sandwiches the camera mount in between two pieces of memory foam. Here's what it looks like on the frame:

The improvement in video clarity was impressive, though it didn't eliminate the vibration completely. The camera is still too heavy, so the whole thing is hard to fly and the motors and ESCs get hot. But here's the result:

4pcb: 3S/370mAh Testing

Previously, I promised some PCB quadrotor testing on a 3S/370mAh battery instead of its former 2S/460mAh. They're both Turnigy nano-tech packs with a 25-40C discharge rating, so I am only trading mAh capacity for more voltage. In actuality, the 3S does store more energy (1110SmAh vs. 920SmAh to use a nonexistent unit of energy). Accordingly, it's also physically larger:

3S/370mAh (left) vs. 2S/460mAh (right)

And, it weighs more. The 2S/460mAh weighs 30.0g, while the 3S/370mAh is 36.6g. (In both cases, this comes out to about 113Wh/kg, which seems reasonable for a small power-cell pack where much more of the weight is packaging and connector.) Generally, adding 6.6g of weight to a micro quad is going to hurt a little, but if you're going to add weight somewhere, the battery is a good place to do so.

Theorem 1: "LiPoCopter Theorem" As the ratio of battery weight to total weight (LiPoCopter ratio) of an RC helicopter/multirotor increases, it is increasingly likely to be able to fly with properly chosen motors, props, and ESCs.

Proof: Consider the extreme case: a helicopter made out of a LiPo (possibly one of these, with two rotors attached to it like a LiPo-bodied Chinook). It is certainly possible to choose a set of components {motor, prop, ESC} which will allow this to fly. As any helicopter/multirotor approaches this ratio of battery to total weight, there will be some set of components which allow it to fly.

A respectable LiPoCopter Ratio of 26.4% (formerly 22.8%).

Of course, I don't get to choose an arbitrary set of components for 4pcb; I'm stuck with the existing motors, props, and controllers. I had a hunch that it would fly better, though, since the ESCs would very much like to see more voltage. They're rated for 7-42V, so running on 2S (7.4V) is very borderline. 3S (11.1V) gives much more margin for voltage sag under load. The weakest motor would tend to reach command saturation well before the 2S battery was dead, leading to drifting and ultimately instability.

The improvement on 3S was immediately apparent, with no additional work required. Here's a comparison of the motor commands for full-length flights on 2S and 3S:

2S/460mAh

3S/370mAh

In the 2S/460mAh flight, the average command to hover starts at about 200 (out of 255) and increases as the battery voltage drops, up to about 220. The problem is the front motor: after some time, it begins to saturate and when it does, it can't produce any extra thrust to counteract for disturbances. In flight, this causes the quad to pitch forward, especially on throttle-up, and makes it difficult to fly. You can see I had to land several times to let it re-stabilize. The total flight time was about 6 minutes, but the last 2-3 minutes were me fighting to keep it in the air. Usable flight time was about 3-4 minutes and even at the end of the flight, the battery was still above 7.4V (only 50% discharged).

The 3S flight is one continuous stretch of over 8 minutes in the air. The average command to hover starts at about 165 and increases to about 185 as the battery voltage drops. This leaves plenty of margin for stability, so even though the front motor command is still highest, it never saturates. The problem of uncontrollable pitch as the battery gets discharged is eliminated. One side-effect of having higher voltage is that all the gains are now too high, causing small/fast oscillations (compare the width of the lines in the above images). This should be easy to fix. After 8 minutes, all four motors start to taper off in power. And all of the battery capacity was used:

3S/370mAh after 8 minute flight. Total voltage: 9.02V.

Luckily, I bought four of the 3S/370mAh packs, so I now have enough capacity for 32 minutes of continuous flying. Just in time for demo season.