Tuesday, November 18, 2014

Grand Canyon flight / Magneto Failure

So last week my wife and I left the kids with the grandparents and headed for the hills in my '67 Skyhawk for my 40th birthday.  Our plan was to fly from Palo Alto to the Grand Canyon by way of Las Vegas.

Day 1
Flight One: Palo Alto (KPAO) -> Shafter / Minter (KMIT) Mohave (KMHV)

Route on Skyvector.com

Departed as planned, but the haze in the south central valley was terrible. Bakersfield reported "Skies clear, visibility 2 1/2 miles" (That's not haze, it's fog!) So, I amended my destination and went over the hill to Mojave (KMHV) instead. While having lunch I double checked the rest of the route and decided since we were already in the Mohave desert to go ahead and continue via the Trona, CA corridor instead of going South to Palmdale.

Flight Two: Mohave,CA (KMHV) to Henderson, NV (KHND) via Trona Corridor

Route on Skyvector.com

I've done this route a few times now. This was the first time into HND that LAS approach refused to clear me into the Class B when coming east through the Columbia Pass... which means I had to descend under the shelf, continue east until I was due S of HND and then descend to within about 1000' of those hills to fly towards HND. No big deal (it was a very clear day) just not what I was expecting.

Day 3: KHND to KGCN (Grand Canyon Airport)

Route on Skyvector.com

- Flawless. Got radar service from HND and LAS on the way out, and was handed to LA Center for the rest of the flight. I had planned the flight to go over the Hoover Dam and BLD VOR, but Vegas Approach wanted us further south than that for arriving traffic. No big deal.

LA Center confirmed that I was familiar with the Grand Canyon special VFR rules (I was) and had no further questions after that. Winds were 20G30 on the ground, so it's probably good that the special VFR rules kept us 3K+ above it anyway. At 11,500 it was smooth.

GCN: You're advised to remain with your aircraft upon landing until the FBO comes to get you, since there's a TSA area between the ramp and the FBO. Yay for security theater. (Taxiing my aircraft around is safe, but walking isn't!) Other than that oddity, and the $7.20/gal avgas, it's just like any other GA airport.

Day 4: KGCN -> "Dragon Corridor" (N) -> "Fossil Canyon Corridor" (S) -> KHND

Route on Skyvector.com

Scenic flight over the canyon tour corridors before departing west. We donned our O₂ cannulas again and took off into the same 20+ knot winds we landed in yesterday. GCN tower was very friendly and continued to provide traffic alerts as we did circling climbs south of the Supai sector to get to the required 11,500 feet for flying the corridors to the North. It was turbulent near the ground but smoothed out nicely once we were over 2k AGL.
Man, that is a big canyon! We continued north past the Dragon Corridor to the edge of Marble Canyon before turning back west and south. There was snow on the ground in the shadows north of the canyon. Monitoring the tour operator frequencies made us aware of the constant stream of helicopters criss-crossing the canyon beneath us. It's hard to imagine how they manage those beasts over those ridge lines at 8500 MSL in gusty 20-30kt winds, but they didn't seem fazed by it.

We picked up LA Center again south of the Fossil Canyon Corridor and flew back to Henderson without issue.

Day 5: KHND -> KMHV -> KPAO (Returning home)

Departed back the way we came, across Death Valley and through the Trona corridor. Stopped in Mojave for lunch and gas, only to discover upon my pre-flight check that my left magneto was no longer functioning at all. (It worked fine prior to departing Henderson.)

Returned to ramp, aborted flight, arranged a rental car from the neighboring Ford dealership. :(

Thankfully, Kenneth Hetge in Tehachapi, CA was available to do a field repair. It turns out both mags were due for an overhaul. The coil on the left one had cracked and finally died. Aero Services in Van Nuys overhauled both, replaced the coils, and Ken reinstalled them on the aircraft. Two days and two AMUs later I returned to Mojave with the rental car to retrieve my aircraft without further incident.

Some other airplane GoPro shots

Tuesday, June 24, 2014

FPV Flying, The FAA, and the rules.

This morning my inbox exploded with articles about the FAA's recent Interpretation of the rules for R/C flying. Specifically with their consideration for "First Person View" (FPV) flying. (Flying by reference to a video transmitter on board the model aircraft.)




Summary: According to the FAA, FPV flying in the US is not legal, even with a spotter.

Details:  [14 CFR Part 91 , Docket No. FAA-2014-0396, "Interpretation of the Special Rule for Model Aircraft"]:
Under the criteria above, visual line of sight would mean that the operator has an unobstructed view of the model aircraft. To ensure that the operator has the best view of the aircraft, the statutory requirement would preclude the use of vision-enhancing devices, such as binoculars, night vision goggles, powered vision magnifying devices, and goggles designed to provide a “first-person view” from the model.
Such devices would limit the operator’s field of view thereby reducing his or her ability to see-and-avoid other aircraft in the area. Additionally, some of these devices could dramatically increase the distance at which an operator could see the aircraft, rendering the statutory visual-line-of-sight requirements meaningless. Finally, based on the plain language of the statute, which says that aircraft must be “flown within the visual line of sight of the person operating the aircraft,” an operator could not rely on another person to satisfy the visual line of sight requirement. [...] While the statute would not preclude using an observer to augment the safety of the operation, the operator must be able to view the aircraft at all times.

My reaction:
On the surface, that seems rational. Where it falls apart is that FPV flying doesn't necessarily have to be done in locations or at altitude where such oversight makes any sense at all. I am 100% on board with the idea of preventing people from operating R/C aircraft without LOS at high altitudes in places where I might be in my Cessna. 

But does that mean it should be illegal to wear FPV goggles and fly around a field, away from any airports, at < 200 feet elevation? If my Cessna is ever there, it's because I'm doing an emergency landing. Randomly encountering an R/C aircraft (or bird, or baseball) is fine with me.

Does that mean it should be illegal to fly aircraft using FPV equipment under tree canopies (where there can't possibly be other aircraft?)

The FAA rule is draconian. FPV flying is becoming not just a hobby, but a sport. And by passing draconian rules like this the FAA is taking rational conversation off the table and ensuring that thousands of people will just disregard them and break the rules.

And that puts me at greater risk. Thanks a lot.   

FAA , if you are listening - let's have a conversation about this.  Blanket restrictions on very popular, widespread, and largely safe activities are not a good idea.  Let's discuss where FPV flying does and doesn't make sense.  Let's discuss where interference with aviation operations may and may not happen.  And let's discuss how to properly educate the FAA, pilot, and R/C communities about each other's activities, so we can coexist in a safe and harmonious way.  

Today it's a battleground, and each side is largely misrepresented by misinformation to the others.  This isn't the way forward.

Monday, June 16, 2014

Donkey Quad

Update:  Have one?  Building one?   Click Here: Donkey Quad Manual

A while ago I bought an inexpensive HobbyKing F330 frame, thinking I would use it with some SunnySky X2212-9 1400KV motors and 8" props I had.  Unfortunately, that turned out to be a very unstable combination.  It was fast as hell, and good at aerobatics, but I couldn't tune the shakes out of it.  I decided those motors were just too big for that small 330mm frame.

On a whim, I was looking at the cheapest 3S capable outrunners that HobbyKing sells when I ran across these ugly duckings here:

The Donkey ST2004-1550kv, "When pulling power matters and looks.. well.. just don't."

HobbyKing Donkey ST2004-1550kv
The mounts are nonstandard ugly aluminum tangs with holes in them.  The sticker oddly says "ST2204-1550kv" whereas the website part number os "ST2004-1550kv".  They have 3mm shafts, but don't include any collets or prop adapters.

But, they're dirt cheap, they work as advertised, and they're seemingly a lot more crash resistant than the similar-rated Park300 1400kv motors I used to use on a similar sized quad.

I had to use 4" zip-ties to attach them to the F330 frame.  I did it by threading the tie down through one hole, under the frame, up through the opposing tang, and then putting a cut off zip-tie "head" on the other end.  Repeat for the other set of tangs and you have a solid mount with no screws.  ;)
Mounted w/zip ties

Paired with some disused Afro 12A ESCs, a MultiWii MicroWii FC, OrangeRX R100 receiver, and some 7x4.5 props and I have a small, super light, fairly agile quad.  It's not the fastest one I own, but it's light and agile enough to do in-place flips or double-descending-rolls.

It turns out to be a joy to fly, and I've been spending more time with it than my more expensive quads.

Several people have asked me for a parts list, so here it is:
1F330 Frame
4Donkey ST2004-1550kv Brushless Motor
4Turnigy Plush 9g 10A ESC
1MultiWii MicroWii ATmega32U4 Flight Controller
1OrangeRX R100 DSM2 Satellite Receiver
1XT60 Male power connector
4Props: 7045, 7060, or 8038 (2 CW & 2 CCW)
43mm prop adapter
1ZIPPY Compact 2200mAh 3S 25C Lipo

A few build notes:

  • Use 4-inch zip-ties to attach the motors (described above)
  • You can use an XT60 to 3.5mm bullets power distribution cable instead, especially if you choose 10/12A ESCs that have 3.5mm bullets.  I built one this way, and one with directly soldered leads.
  • You'll have to bind the R100 to your transmitter with a separate receiver (or by flashing special Spektrum Satellite Bind Code to the FC first.)
  • This quad can actually carry a 2600mAh battery for 10+ minutes of flight time!
  • Add a lipo alarm to warn you when the battery is low.
I have two built right now.

One with 7060 phosphorescent props, UV LED strips on the arms, and a 4W spotlight:

The other with 8038 props, a GoPro Hero 2, Minim OSD board, and video transmitter on it:

Saturday, March 8, 2014

Ducky EDF Quad - Motor Mounts and Second Test

I had the EDFs mounted to the frame with zip ties for the first test.  That proved a bit unstable.  I also had the problem of the motor housings sticking down lower than the rest of the quad, which posted a threat to them on landing.

Talon motor mount
So, I decided to kill two birds with one stone by making some EDF mount brackets that extended vertically below the bottom of the motor housings.  The Turnigy Talon frame I used included these aluminum "T" mounts, intended to be mounted horizontally at the end of the tubular arms to allow you to mount the motor on top.  I simply turned them 90 degrees so that the flat face was vertical to align them with one of the two flanges protruding from the side of the EDF housings.

To mount the EDF flanges to them, I fabricated a mounting bracket to use as a clamp.  I used an old license plate frame that I cut into four equal length parts and drilled matching holes in:

Four mounts cut from a discarded license plate frame

Drilled and mounted to EDF with motor bracket

Mounted to quadcopter frame

I filmed a new test flight with the modifications.  I wasn't really thinking about the fact that I was filming during the flight, or I would have put more effort into keeping it closer to me.  Overall, it flies really well.  It has a slight left yawing tendency, but I suspect that is because I haven't really done anything to precision align the EDFs.  (I just eyeballed them and clamped them down.) 

I avoided using 100% power to see how it did on flight time.  With the flying you see it used about 70% of the battery life in just over 5 minutes.  So, not bad!

Wednesday, March 5, 2014

Attacking Conjecture : "Ducky" the EDF Quad

I decided, against conventional "wisdom", to construct a quadcopter that uses Electric Ducted Fans (EDFs) for thrust.  There is conjecture all over the internet as to why this is a bad idea, but I was having a hard time finding any real science or performance data to back it up.  So, why not build one and see what happens?

What are EDFs?

EDFs are basically small, higher pitch, higher rpm propellers (sometimes called "impellers" in this application, to differentiate them from conventional propeller design) inside a cylindrical duct with a tapered inlet and as little clearance between the blades and the duct wall as possible.  They look more like jet engines than conventional propellers.  Tangent: Modern jet engines actually are turbine driven ducted fans, called "turbofans."

The primary benefit of a ducted fan is increased efficiency of the propeller by preventing (or reducing) the phenomenon of "tip vorticies" and allowing a greater range of operating speed without "propeller stall."  There are also some secondary benefits related to the air being forced through the duct.  (E.g. more output consistency in turbulence than an "open propeller" since the propeller is effectively shielded and moving faster.)

They spin at tens of thousands of RPM (as opposed to merely a few thousand RPM like conventional R/C props), but being completely contained means they pose less of a hazard to people or objects that the aircraft might collide with and take up less horizontal space along the plane of the propeller.

At any rate, if you tell the R/C community that you want to use an EDF for a multirotor application, you immediately get a few reasons why "it won't work" or "it's not a good idea."  I'll dissect those here:

R/C Community Myth Number 1:  "You can't use EDFs for static thrust applications."

  • "EDFs are less efficient at static thrust than open props." 
  • "EDFs don't produce full power until they get a bite on the air moving through the duct."

(That last one is my favorite, because it's a visual description of complete and utter nonsense.)

The conjecture is that EDFs really only shine when moving through the air at high speed.  What's odd about this conjecture is that the full-scale aerodynamics and aviation community says exactly the opposite about ducted fans:

  "... the ducted fan is more efficient in producing thrust than a conventional propeller, especially at low speed and high static thrust level." [http://en.wikipedia.org/wiki/Ducted_fan#Advantages]

 "When compared to an isolated propeller of the same diameter and power loading, ducted propellers typically produce greater static thrust."  [Abrego & Bulaga, "Performance Study of a Ducted Fan System", NASA Ames, 2002]

This would seemingly make them more ideal for multirotors than open props, as multirotors spend most of their energy on vertical lift (which is mostly static.)

R/C Community Myth Number 2:  "EDFs don't change speed fast enough for multirotor stability."

  • EDFs have too much rotational inertia for the fine-power adjustments that the flight controller will need to make.
  • EDFs take too long to "spool up" (or down) to use for multirotors.

This one actually had me concerned.  Since EDF rotors spin at up to 10x the speed of conventional open props, it stands to reason that the inertia might be an issue.  Certainly, in the typical application of R/C EDFs - scale model jet fighters - it doesn't matter how fast the motor reaches a particular RPM or how much control "resolution" you have once it gets there.  So the performance characteristics in that regard are just largely unknown.

But that's just it.  They're unknown.  I could find absolutely no performance data about the power resolution or latency of R/C scale EDF systems.  It seems no one has measured it, yet many people are willing to state as canon that it's not good enough for this application.  The very definition of conjecture.

I decide the only way to find out is to buy some and try it.  After all, we're doing this for fun, right?  And what's more fun than potentially launching a completely uncontrollable aircraft with a massive LiPo battery on board?

R/C Community Myth Number 3:  "Without the adverse torque from the open propeller, you won't have any yaw ability."

I only saw this mentioned a couple of times, but Newtonian physics pretty much just disavows this one.  The opposing torque of each motor is proportional to the thrust it's producing.  I'm pretty confident there's enough torque there to yaw effectively.

Anyway... enough speculation.   I have plenty of reason to believe that this will work, in spite of the various opinions I've seen posted online that it won't.

First order of business:  Counter Rotating EDFs

I like the simplicity of quadcopters, but to build that I need counter rotating EDF rotors.  This turned out to be tricky, but I actually found a few.  I narrowed the ones I could find down to two likely candidates:
Both offered almost exactly the same amount of thrust at full power (4 pounds each!), but the Freewing ones are lighter and purport to draw slightly less power, so I decided to start with those.  Note: Both of the above are available from multiple vendors, so if you're shopping for them you might do a Google search on the names for comparison. 

So now that I know the size, weight, and power requirements of the EDFs I'm using, I put together the following parts list for the rest of the aircraft:

Testing the EDF / ESC combination

Once I got the EDFs, I tested one by connecting it directly to the "Throttle" output of the RX and hooking up the Multistar 45A ESC and battery.  I tethered the EDF to a block of wood and ran it at various power outputs on my back patio.  Observations:
  • Holy %#& this thing is loud!  It sounds like a vacuum cleaner from hell.
  • It produces a LOT of thrust, just as advertised.
  • It changes speed between 25% -> 50% -> 100% and back as quickly as I can move the throttle lever.  There is no noticeable "lag time".
I decide to proceed with the build!

Mounting the EDFs to the Talon frame

I found that rotating the Talon's included "T mounts" 90 degrees made a good vertical mounting post for the EDFs.  Initially I mounted them simply by wrapping long PVC zip ties around the EDF body and through the mounting holes of the T mount.  

There were two problems to this approach:
  • It eliminated the possibility of mounting the Talon's included "landing gear", as it went on the bottom of the (now rotated 90 degrees) T mount.
  • While it seems fairly stable on the Z axis, it allows the EDF to rotate a bit which will cause alignment issues (and possible yaw control issues) in flight.

Still, I deemed it good enough for testing, so with that decided on I went ahead and mounted the rest of the wiring and electronics:

Ducky, fully assembled!

Test Flights

I did two tests prior to the filmed flight test you see below.
  • Tethered test:  I tethered the quad to the ground using some long bungee cords and some heavy weights so that it couldn't fly away.  In this configuration, I did some run-up tests, hovered it (within the length of the 36" tethers) and saw that it actually flies and seems to be controllable.
  • Hover test:  Gingerly, I removed the tethers and basically did the same flight.. I flew it up to about 3 feet AGL and tested that I have control of it before bringing it back down and shutting it down.
After these two successes, I decided to do the first "free flight" test.  In this test I'm running on only one of the two 35C Lipo batteries.  Note:  This reduces the weight but probably also means I don't quite have full power available, as the battery is not quite capable of delivering the full 160 - 180 amps of current that the combination of the four motors could possibly draw.


It actually flies pretty damned well, given that I haven't made any changes to the default MultiWii 2.3 PID settings.  That high speed climb was a little crazy, given that I knew I was at the output limit of the single battery... but I couldn't help it.

That's all for now, but I promise there's more to come...

Tuesday, February 25, 2014

MultiWii board differences

A common question I get is:  "What MultiWii flight controller should I use?"

There are a few determining factors involved in this decision.  The primary considerations are:
  1. What microcontroller (µC) do you need
  2. What integrated sensors do you want?

What Microcontroller (µC) should you look for?

MultiWii is based on the Atmel corporation's 8 bit "megaAVR" series of µCs.  All the MultiWii boards I've seen are based on one of three µCs, but you could certainly port the software to others if you're good at microcontroller integration.

Below is a table of the three most common and their relevant specifications:

µC flash ram eeprom serial uarts usb ports
ATmega328p 32 kilobytes 2048 bytes 1024 bytes
ATmega32u4 32 kilobytes 2560 bytes 1024 bytes
ATmega2560 256 kilobytes 8192 bytes 4096 bytes

Those of you who are familiar with AVR µCs will notice I left off the number of digital, analog, and PWM pins.  The truth is that all three have enough for basic Multiwii applications, and how many of each are exposed to you is dependent on the individual board manufacturer, so it doesn't seem relevant to list those here.  If you want to do some really custom AVR stuff that might use the expanse of all the pins available, you'll need to research flight controller boards carefully (or better, fabricate your own!)

So, why are the specs that I listed relevant?


The flash memory is the program storage.  This is where you store the actual Multiwii software (plus the Arduino bootloader, if you want to program it via the Serial/USB interface.)

MultiWii with basic functions enabled compiles to about 24k.  Start adding additional functions like barometric altmeter, buzzer, or FAILSAFE and it starts to push 28k.   Add in GPS and it suddenly gets right to 32k, or possibly more.

This is important to note:  With all the functions enabled (GPS, Buzzer, FAILSAFE, BARO, &etc.) MultiWii will not fit on a 32k-flash storage µC along side a bootloader.   You can "sort of" get it all in there if you forego the bootloader and program it via the ICSP header, but even then you will be space constrained.  (My last build of MultiWii 2.3 that I put on an Atmega32u4 was 31.9k!)   This limitation is what pushed me from the Atmega32u4 to the ATmega2560.  I started writing custom code and ran out of space!!


Not generally a problem for MultiWii, but if you're into development / tinkering with the actual code then be careful if you're using the 328p.  If you run out of RAM, the flight controller will malfunction in ways that will make the multicopter fly completely out of control or do unexpected (possibly dangerous) things.  This happens because overallocation of RAM will cause values in memory to become corrupted, which is a Very Bad Thing(tm) when you're running a tight PID loop to maintain aircraft stability.  ;)


Again, not generally a problem for MultiWii in its default state, as it normally only stores a small amount of configuration data in eeprom.  But if you want to log data to non-volitile memory for later diagnosis then more is better.

Serial Uarts:  (Actually called USARTs on AVRs)

This one is often overlooked.  This is the number of serial I/O lines you can have on this µC.  MultiWii uses serial I/O for the following functions:
a) MultiWii GUI / Configuration
b) Telemetry data for OSD / HUD
c) GPS
d) Spektrum Satellite or OrangeRX / LemonRX Satellite receiver data
e) Re-flashing the software (via Arduino bootloader)

a) & e) are used on the ground when you're configuring / testing things.  As such, this port can be shared with functions b, c, or e.  You don't really want to share it with d though, as that will prevent you testing / diagnosing issues with your TX/RX configuration.

b) is nice if you're doing any sort of First Person View (FPV) flying.

c) is optional, but a nice capability.  There is support for doing GPS over the i2c bus instead, but it's more limited in capability (as of 2.3)

d) I really like the super-tiny "satellite" style DSM2 receivers, and the fact that they communicate over the serial bus... but it requires a dedicated serial port that you don't share with anything else for reliability.  If you use a "traditional" R/C receiver (one output per axis) then this won't apply.

So as you can see, depending on the capabilities & combination of features, you can easily outgrow the 328p or 32u4 µCs single serial port capability.

USB ports:

This is really an extension of functions a and e above (Serial Uarts).  Having onboard USB simply saves you from using a USB -> FTDI adapter to perform those functions.

What Sensors do you want?

All Multiwii multirotor flight controllers include at least one sensor (gyro) on the integrated i2c bus.  Most include additional sensors.  Below is a breakdown of the sensor types and their functions.  I won't bother trying to list the individual sensor part numbers because they vary wildly.  You can look those up on your own.  ;)

gyro  - The most basic sensor needed to make multirotor stability possible.  All FCs should have one of these.

accelerometer - Often integrated into the same chip as the gyro.  Required for "auto level" modes: angle, horizon.  Also required for FAILSAFE and autonomous flight.

magnetometer - Provides magnetic compass heading.  Recommended for GPS autonomous flight.  required for "heading hold", "headfree" flight modes

barometer / barometric altimeter - required for Altitude Hold.  Recommended for GPS autonomous flight.

Flight controllers with all of the above are common.  Many also expose the I2C bus pins so you can add your own.  Be careful if you tinker with the I2C bus.  If you cause bus delays or errors that interfere with the accelerometer it will make your aircraft unstable in flight.  ;) 

GPS - pretty self explanatory, this is required for "position hold", "return to home", and the (currently experimental) waypoint navigation being developed.  The GPS units that are supported come in a few flavors.  The most basic support is a NMEA serial output GPS connected to one of the serial input lines.  Adding uBlox or MTK protocol support can lighten some of the load from the flight controller.  Look in the Multiwii config.h and GPS threads on Multiwii.com's forum for more information.

Note: Multiwii supports GPS over the i2c bus, but it's not being maintained and doesn't support the new experimental autonomous "waypoint navigation" that's being worked on by EOSBandi, so if I were building / buying a new MultiWii system I wouldn't depend on i2c GPS.

Read more about the Multiwii Flight Modes mentioned above here:
http://www.multiwii.com/wiki/index.php?title=Flightmodes  (Sadly outdated but mostly still accurate.)

So, hopefully this will help you figure out which Multiwii-capable flight controller is right for your application!  At this point, I actively fly at least one multirotor with each µC listed above.

Happy flying!

Turnigy Fiberglass Mini Quad: Sharky

Meet "Sharky", my first non-indoor quadcopter.   (Shown next to one of my brushed-motor nano quads for scale.)

I wanted to graduate to a larger quad, but not something huge, so I decided this 345mm span "mini" quad was the way to go.  I liked the size and design of this quad.

The "pseudo-airplane" shape on the frame looked more like a shark than an aircraft to me, hence the name.

We'll start with what I initially built:

I fly this with my existing OrangeRX T-Six DSM2 transmitter.
I run MultiWii 2.3 with some minor modifications on the 32U4 flight controller.

Side note:  I have made the following changes since the initial build:

  • Upgraded the flight controller to the MultiWii Pro (Atmega 2560 based)
  • Switched to 2-blade 8x4 props.  (Easier to balance.)
  • In the process of upgrading the motors to SunnySky motors - but that might require new ESCs.

As originally built, this is a pretty amazing and capable quad.  It's fast, responsive, and climbs like a bat out of hell.  It only took minor tuning to the original MultiWii PID settings to make it fly how I wanted.  With the 2200 mAh battery it can fly for 12 minutes in basic "normal" flight, or 6-7 minutes of "aggressive" / aerobatic flight.

There have been a few drawbacks to this design:

  1. The fiberglass frame is not very tolerant of crashes.  It breaks easily, particularly on the arms just inside from where the motors mount. 
  2. The fiberglass frame transmits vibration really well, so balancing the motors & props is important.  This is why I ended up switching to 2-blade props- they're much easier to balance than 3-blade ones.
  3. The Atmega 32U4 microcontroller has some hardware limitations that I eventually ran into with MultiWii.  More on that in a subsequent post.
  4. The Park300 motors damage easily.  I initially tried repairing them with new bearings / shafts, but had about a 25% success rate doing so.  A couple of motor failures caused catastrophic crashes.  This is why I'm switching to slightly larger motors.

Overall, though, this has been an amazing quad to learn on.  If you're building one:  Buy 2 frames, at least 3 complete sets of props (2 CW & 2 CCW), and 6 motors (2 spares.)  You'll be glad you did after your first crash, as you can get in the air again while you're waiting for replacements for your spares to come in the mail.  ;)

I strapped a really crappy "Redleaf" 720p camera (not recommended) on board and took this video the second time I took it out to fly it:

Later, I added a 200mw 5.8GHz video transmitter and a Gopro Hero2 camera...

... and tried my hand at some "First Person View" (FPV) aerobatics:

I decided that FPV flying is really fun, so I've been doing a lot more of that since.

More to come...