On Drones

When I assembled my quadcopter, I always intended it to become a drone, that is to say, with autonomous features. The typical use case for the hobbyist is intelligent failsafe, specifically return-to-home or "RTH" capability. As I've assembled the parts to accomplish this, it's made me consider how to achieve the same thing for my plane.

Multiwii on a MF'in Plane

There is always an Apprentice

As it is located on the 101 on my way to places like Santa Rosa, San Francisco, and environs beyond, I often visit the Salvation Army adult rehabilitation facility at Lytton Springs road, which is where they sort the majority of their unwanted junk. That means donations pulled back from thrift stores, items that they decided not to put into thrift stores to begin with because they didn't work, wouldn't ship well, or were too ungainly, and so on. It's a great place to find cheap furniture, but they also randomly have items of fairly high value. On one visit, I picked up an e-Flite Apprentice without the radio equipment or rubber bands, but otherwise complete and in fairly good condition. You can find these complete online with the transmitter for around $200 so it's not exactly an expensive plane, but as a result there's a good number of people who are using them to build drones.

Doing it on the cheap... new

It's worth noting that you should probably not run out and spend $200 on a plane for your project. You can hop on eBay and get a foamy flier with a 4-5 foot wingspan for around thirty bucks shipped. You can fill it with cheap servos for around ten bucks, and give it a cheap motor and ESC for less than twenty. There's no need to spend two bills. I got this plane as part of a lot that cost me ten bucks, with servos in it. All I had to buy to complete the airframe was the rubberbands to hold on the wing, which cost me about three dollars. In order to connect the wing (aileron) servos to the FC, I will need two servo extension cables, which I have already. They're about two bucks a ten-pack. The ESC in the plane is only 30A and the motor only 890kV; you can get a 30A ESC and a 1000kV motor on eBay for ten dollars. You'll probably pay that much for the prop and hub as well, though.

Flight Control

The Arduino Mega

While the control system for a quadcopter can actually be very simple, and people commonly implement quadcopter flight controllers ("FCs") with limited microcontrollers such as the atmega328, intelligently controlling an airplane is somewhat more difficult. Intelligent GPS autopilot control is available for Multiwii, but only the most rudimentary support is available if you use an AVR chip with so little program space and memory as the 328. Enter Arduino Mega2560. This is actually the second generation of the Arduino Mega platform, but it's considered to have replaced the original ATmega1280-based Mega. However, that's a lot of board to cram into a flying machine!

Mini Megas

Hence, the Mega2560 Pro Mini, a severely shrunken version of the Mega2560. I ordered one for $18 shipped. There's the even smaller and cheaper (by a couple bucks) inhaos Mega2560-CORE, which omits the USB to serial converter and replaces it with a female right angle header that I suspect most users will want to remove and replace with a male right angle header — I certainly would. Another option would be the Mighty Mini 1284p, which is essentially a miniaturized version of the original Arduino Mega albeit with a slightly better AVR. I decided that I wanted onboard USB to serial for convenience, and the newer processor. I will likely install double-row right-angle header strip down both sides of the unit, but I need to test-fit it in the airframe in order to decide.


I could have spent more and just bought a complete FC including sensors with this kind of power, but I didn't see any reason to do that. I didn't see any reason to spend big on sensors, either, for my budget foamy wonder. Still, I did spend a couple of extra dollars here, to go with the few dollars more that the FC board cost. The KK2.1.5 (and mini) use the Invensense MPU 6050, a fairly high-quality 6DOF (3 gyro, 3 accelerometer) sensor which is available on a board for about $5 shipped. I went with the MPU 9250, which is just a MPU 6500 6DOF sensor (functionally identical to the 6050) and an AK8963 3DOF magnetometer bundled into one package. Since I'm not sure whether my future GPS module will have a mag sensor at all as I haven't actually chosen one, it makes sense to have a good one on the sensor board. I also have a BMP180 barometric pressure sensor. In theory you don't need one, because as poor as GPS is at measuring altitude, it's better than depending on barometric pressure. In practice, I'd like to compare its performance, and it's a really tiny and practically free sensor which will be interesting to log. I'm planning to mount an air quality sensor on the plane eventually as well, and the two should go together nicely. I've got a microsd card slot, that was a dollar.

I will mount the inertial sensor board1 to the airframe, and use a cable to the FC, rather than trying to direct-mount the sensors onto it with glue or tape. The FC has a broad enough voltage regulator to run directly from a 3S LiPo, but it remains to be seen if the plane's ESC back-feeds too much noise for reliable operation. I don't know how much filtering is on that Mega2560 Pro Mini, but I suspect it's not very much given its small size.

I'm also going to work on making an even cheaper Multiwii-controlled plane, with one of those $11 electric motor kits, or even with some junk I have lying around from previous exploits. I'll use an Arduino Nano clone, which was about $2.50 shipped. I have a BMP180 baro sensor for low-resolution altitude estimation, and a MPU-6050 board for accelerometers and gyros. I already have the RX. This plane will explicitly not have a GPS, and the purpose is simply to make a cheap, stable fun flier with a complete FC under $10. More on that later, when I find/choose/make an airframe. I've always wanted to turn one of those throwable foam planes that I often got at the mall as a kid into something you could fly.


I haven't picked out a GPS module yet; probably I will run the uBlox NEO-7M which is considered to supersede the NEO-6M, funny that. They seem to be about the same price, size, etc. I chose the NEO-6M for my quad build because it was known to work properly with Multiwii for KK. However, I would very much like to instead rip apart my Garmin USB dongle, which I suspect is hiding a serial GPS behind an interface chip. Then I'd probably have to make Multiwii speak the garmin protocol, which would be silly but probably not amazingly difficult as it is fairly well documented. This would save me fifteen bucks and have high hack value, meaning a lot of frustration.

The Minimalist Approach

Now, it's worth noting that you only need all this fancy kit if you're going to run GPS. If not, you can get away with a lot less hardware. A simple Arduino Pro Mini (or Nano) with a cheap MPU-6050 board (which is only around five bucks) will let you use Multiwii to control your airplane. That's enough to get auto-leveling flight!

It's worth mentioning that if you happen to have a Wii Motion Plus and a Wii Nunchuck lying around, you can get your gyro and accelerometer out of them. I am also seeing under-four-dollar nunchucks which claim to have motion plus built into them which makes very little sense but which is technically possible. If so, that would be an amazingly cheap way to get your sensors, and they would come along with a controller. To be fair, though, most cheap knockoff controllers have garbage buttons.

Flight Modes

Like Multiwii on a multicopter, there are multiple flight modes which are clear equivalents. The primary modes are ACRO[batic], Horizon, and Angle (also called level.) In ACRO mode, the FC will compensate for gusts of wind and the like, but motion is completely unconstrained. In Horizon mode, the plane will self-level if you let go of the sticks, but can still perform rolls and loops. In Angle mode, the maximum tilt angle is limited, and it's directly proportional to the position of the stick. Both Horizon and Angle mode are considered "stable" flight modes; the plane will recover from any position, given proper aircraft balance and sufficient maneuvering altitude.


This is not going to be an in-depth explanation of how setup is done, just an explanation of the benefits Multiwii brings to the setup process. A lot of this stuff really just helps you work around deficiencies of a cheap transmitter, but in this case, cheap is where we're going. First, there's the issue of transmitter centering. If you want to use multiple models with a single transmitter, you can easily get caught up diddling your transmitter trims when switching. Instead, why not just define the center point? The SERVO_OFFSET values in Multiwii let you change the center. Want to set the maximum speed at which a servo will move? SERVO_RATE has you covered. Want to change the direction of a servo, and your transmitter doesn't have switches for that? SERVO_DIRECTION lets you reverse individual servos.

It will also let you use your ailerons as flaps, also known as "flaperons". Many if not most cheap planes (including the Apprentice) use a Y-cable to drive two aileron servos from one receiver output, as the aileron servos must bear the greatest load and using a single servo with a linkage would not be practical. But if you have a radio channel to spare, and these days many of us do, you can use it to pitch the ailerons as flaps so that you can make slower landings. Many radios will let you implement flaperons in the transmitter, even cheap ones so long as they are programmable, through the "mixing" function — by connecting each aileron servo to its own radio channel, and basing what is sent on each channel from a mix of the pitch/roll stick input and whatever control you are using to set flap angle. Without gyro stabilization, however, you are limited to at best programming a profile which will be suitable for one set of conditions. The normal leveling operation of the flight controller will use the elevator automatically to retain pitch at a variety of speeds and angles of attack. Instead, one channel can be used for informing the flight controller of the desired roll, while another is used for flap angle. The two aileron servos are each connected to an output of the FC, which determines both their angle automatically in response to your controls.


This sort of thing is why I got interested in this subject to begin with; my curiosity as to how flight control systems worked was first piqued by the RAH-66 "Comanche" recon and assault helicopter project, the first helicopter which essentially flew itself in response to user input. If you took your hands off the controls, it would hover in place. Comanche was cancelled in February of 2004, probably because drones were looking like they would eventually do the job that it was meant to do — assuming that job would even be done. But now it seems that the trend is towards inherently unstable planes which, if possible to fly without computer control, remain yet impossible to fly well. As well, what if the flight controller could detect damage or suboptimal operation, for example an aileron which is unable to complete its full travel, and which used other control surfaces to compensate?

Beyond that, what's exceptionally fascinating about drones (or whatever you want to call semi-autonomous aircraft) to me is that even completely toy-level examples of them use technology that is unavailable to pilots of actual airplanes, outside of massive commercial jets. Real helicopters are massively complicated and delicate to fly, yet enough computer to make it trivial to control, literally like a video game, is smaller than your cellular phone and uses less power. You can build one yourself for ten dollars. No, I wouldn't want to put my life in the "hands" of such a rinky-dink little system either, and I can see the clear public interest in not permitting anyone to operate their actual helicopter with an Arduino, but it's still not difficult to imagine low-cost intelligent flight control systems in public aviation. In fact, it is difficult to imagine them not eventually becoming mandatory, as stable airframes have. It's even possible to imagine them becoming available for the purpose of stabilizing aircraft at high speeds, at which they might not otherwise be stable, so long as the aircraft is still self-stable at lower speeds — notably during landing.

What about the quad?


My SK450 quadcopter is actually in the middle of a refit, and will be done before I even have the FC for the plane, let alone a GPS module. I decased the transmitter and I'm removing the header pins so that I can replace them with right angle. I'm only waiting on a PPM encoder, which is in turn only necessary because the KK board only has five PWM inputs and I want to use the sixth channel on my TX as AUX2 to control GPS flight modes (position hold and return to home) while the fifth channel (AUX1 on the KK) is in use selecting between Level, Horizon, and Acro flight modes. I have already mounted the GPS module and antenna to my top board, the former to its underside with the existing hardware and the latter to the rear top with glue. I will probably replace this antenna with a 9x9mm "watch" antenna, pending its arrival and a reception test. That will let it fit better onto the top board, which I hope to enclose in the future.

Propeller balancing

This is by far the least fun aspect of the entire process. I've finally got my antenna balancer somewhere close to balanced. As poorly balanced as most props are "out of the box", this still permits massive improvement. First I demagnetized the balance shaft, which actually did help. It's probably the main reason why Dubro (and most other expensive) balance shafts are made of aluminum. Then I bent the shaft, which also helped. Some file work on the cones got them pretty close to being balanced, too. However, the shaft itself is not in perfect balance, which means that I can never get a "perfect" result. I've gone to filing on just the tip of the heavy prop, which does a lot less damage to the smooth surface than any other option and which works just fine. On the other hand, at least I don't have to actually make props, which is what people had to do during the earlier years of model aviation.

Last thoughts?

You are not going to save a whole bunch of money by building your own FC if you want GPS, and you don't have visions of grandeur that make you suspect you will need more I/O or program space than you can get from something trivially available. You might as well buy an Ardupilot Mega, you can get one with a cute plastic case for around thirty bucks, or even a bare board for a mere twenty-five. It's got a MPU-6000, a baro sensor, and an onboard flash chip for datalogging. It's hard to beat that. If you want a slightly fancier sensor package, and access to absolutely every I/O pin on the atmega2560, then you can actually do the same thing without spending any more money and get a 3DOF mag sensor to boot. But if you're not convinced that you need to do it from scratch, just buy the APM. I'm really just doing it to get the USB port. On the other hand, if you're building a small and cheap flier without GPS, then absolutely build your own FC out of a nano or pro mini (~$3) and a MPU-6050 (~$5) along with a BMP-180 (~$2). That will be teeny tiny, especially if you're clever with glue and magnet wire, and provide a very competent FC that can control a quad or plane.

  • 1. It's just sensors, therefore it's not actually an IMU, or inertial measurement unit. The flight controller together with the sensor board is that.

Add new comment

(If you're a human, don't change the following field)
Your first name.
(If you're a human, don't change the following field)
Your first name.
(If you're a human, don't change the following field)
Your first name.


  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • You may link to images on this site using a special syntax
  • Web page addresses and e-mail addresses turn into links automatically.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Internal paths in single or double quotes, written as "internal:node/99", for example, are replaced with the appropriate absolute URL or path. Paths to files in single or double quotes, written as "files:somefile.ext", for example, are replaced with the appropriate URL that can be used to download the file.
  • Filtered words will be replaced with the filtered version of the word.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <q>


  • Lines and paragraphs break automatically.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>

Drinking Game

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <p> <br> <pre> <h2> <h3> <h4>
  • Images may be embedded like: [image:node_id align=alignment hspace=n vspace=n border=n size=label width=n height=n nolink=(0|1) class=name style=style-data node=id] Leave off any attributes you don't want.
  • [img_assist|...] tags will be displayed, maybe. Please don't make more of them.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.