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

Wednesday, February 5, 2014

Tiny Unmanned Flying Things

Anyone who knows me well knows that lately I've been playing with remote-controlled flying things.   This post provides information and links to the small (nano) indoor flyable quadcopters I've been playing with.

I have built & modified a few quadcopters of various (small) sizes, from the tiny brushed-motor nano-quads like the HobbyKing Pocketquad & Syma X1 to a larger, more traditional brushless motor mini quad based on the Turnigy 345mm frame.  (More on that in a subsequent post.)

Throughout this endeavor I've been using (and customizing) the MultiWii flight control software, with various Arduino / Atmel-based flight control boards.  It's becoming a FAQ what hardware and systems I'm using, so in this post I'll detail my current setup.  Future posts will cover updates, new hardware, and a couple of crazy projects I'm working on.  ;)

Note: I buy a lot of parts made and sold by HobbyKing.com in China.  Their website is a bit... odd.. so I'll include the full name of each product in case the link to the product stops working as HK links tend to do.  Just search for the title of the item to find it if the links don't work.

Control Transmitter:

HobbyKing OrangeRX T-Six DSM2 Six Channel Transmitter (Mode 2)

Notes: I bought this transmitter because I wanted a DSM2 2.4GHz system, and it was cheap.  It's perfectly adequate, but I would eventually like 8 channels and the ability for the aux channels to have more than just "on-off" capability, so I might consider a Turnigy 9XR with custom firmware and the DSM2 TX module in the near future.

First nano quad: The HobbyKing Pocket Quad v1.1
HobbyKing Pocket Quad

Notes:  This is a pretty cool nano quad, but a note for the uninitiated:  It is not ready-to-fly.  It requires working knowledge of Arduino to get it set up, and some experience with Multiwii is helpful too.  It was a steep learning curve to get everything working on it.   For the firmware, I used rcgroups.com member Cesco's PQ customization of Multiwii which includes required changes for driving the mosfet / brushed-motor combination.

Once you get it working, though, it's a blast to fly, especially indoors.  It's agile enough to fly outdoors, but it's small enough that it's easy to lose your orientation and lose control of outside.  So be careful if you fly it outdoors.  I've now actually lost two of these things outside and not been able to find where they came down.  :-P

There's a long thread about the Pocket Quad (and its variants) at rcgroups.

Second nano quad: The Syma X1 MultiWii Conversion

Syma X1 with Micro MWC
After some more successes and failures with the PQ and some related hardware, I decided I was done with the "circuitboard as the frame" brushed motor quads.  They break too easily in a crash, which sort of negates the advantage of an otherwise resilient nano quad.

My current brushed-motor quad of choice is a modified Ready-To-Fly Syma X1 from Amazon.  Note, this thing comes ready to fly with an AWFUL cheap transmitter, and a flight controller that basically flies like a school bus drives.  It works, but it's not terribly exciting.

What I like about it, though, is the tiny carbon-fiber arms and the motor / gear / propeller combinations.  So, I bought it, gutted it, and replaced the flight control board with this really nifty Micro MWC flight control board from HobbyKing.  This FC is based on the Atmega328p, which I'm not a huge fan of, but it's plenty capable in this form factor as its worthwhile to sacrifice secondary UARTs and other such capabilities to get such a tiny and light package.  Seriously, the thing is the size of a postage stamp, includes the mosfets for the brushed motors, an integrated DSM2 receiver, and weighs < 2g.

The X1 is hilariously fun to fly with a MultiWii flight controller.  I can set the PID settings how I like, jack the rate up through the roof, and make the thing do crazy flips.  It becomes agile enough to fly outdoors on a windy day despite it's ridiculously light weight, and it's resilient enough to fly it into the ground without damage.

Note: Another similar option for this conversion is the WLToys V929

Important info about that HobbyKing Micro MWC flight controller, including instructions and custom firmware (again from Cesco, the king of "brushed motor" MultiWii modification) is in this long thread from rcgroups:  http://www.rcgroups.com/forums/showthread.php?t=1993117

More to come about my larger flying toys...