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	1	0
ATmega32u4	32 kilobytes	2560 bytes	1024 bytes	1	1
ATmega2560	256 kilobytes	8192 bytes	4096 bytes	4	1

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?

Flash:

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

Ram:

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

Eeprom:

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!