multiwii/multiwii-firmware — pull request #5 by tomsun (2013-03-23 20:25:11+00:00)
Title: Move elevon servos to the output rail on the NANOWII in FLYING_WING mode

### Premise

I ordered [Hobby King's NanoWii board](http://www.hobbyking.com/hobbyking/store/__22322__MultiWii_NanoWii_ATmega32U4_Micro_Flight_Controller_USB_GYRO_ACC.html) since it comes with a 6-axis sensor in a nice 3 cm x 3 cm form factor, which means it fits quite small models.

![HK NanoWii front](http://www.hobbyking.com/hobbyking/store/catalog/22322.jpg)
![HK NanoWii back](http://www.hobbyking.com/hobbyking/store/catalog/22322-3.jpg)

I am primarily looking at fixed-wing applications at the moment. With that premise, NanoWii's config.h provides two modes that sound somewhat relevant; AIRPLANE and FLYING_WING.

### Problem: figuring out how to use elevon mixing

[The Wiki page on Multicopter Types](http://www.multiwii.com/wiki/index.php?title=Multicopter_Types) is the closest thing to a end-user manual I found that mentions these airframe types, but it doesn't really explain how to use them, so I started experimenting a bit, trial-and-error style:

I briefly tried out AIRPLANE mode, which seemed to work as expected. I hooked up a few servos to the output rail and they responded to my transmitter (4-channel setup) in a consistent, usable manner in passthrough mode. The particular airframe I intend to set up with the NanoWii first however, is a flying wing, which means I need MultiWii to provide elevon mixing, which seems to be exactly what the FLYING_WING mode does. When hooking up the servos the same way I got no reaction from the servos... The indicators in MultiWiiConf.app showed that MultiWii responded to sensor input as desired. What I didn't know was where MultiWii expected me to hook up the servos...

...until some hours later when I found [this diagram](http://multiwii.googlecode.com/svn/trunk/Doc/Diagrams/7%20Connection%20diagram%20flying%20wing.png):
![flying_wing diagram](http://multiwii.googlecode.com/svn/trunk/Doc/Diagrams/7%20Connection%20diagram%20flying%20wing.png)

What is the motivation for using A0 and A1 as elevons? Does that make sense on [some specific hardware](http://www.quadkopters.com/wp-content/uploads/2012/12/crius-mwc-1.jpg) that is common or happens to be used by some particular developer? Or is flying wing mode an experimental thing that nobody cares about? The elevons are mapped to A0 and A1 via more generic-sounding SERVO* constants though... It seems to me that something called "servo n" would be preferable to map to an output that provides power and ground pins if at all possible, regardless of use-case.

Is this something that the person adding support for a specific board is supposed to consider re-mapping on a board by board basis (and per airframe type in case you run out of friendly pins - for example nanowii + hexacopter)? Or is this something MultiWii leaves to the end-user to figure out with the help of a soldering iron? Mapping A0 and A1 (and hence possibly servo 1 and 2 although I haven't verified that in the code) to servo-unfriendly pins [seems](http://www.multicopter.ch/images/product_images/popup_images/80_0.jpg) to [be done](http://www.multiwii.com/wp-content/uploads/2011/01/multiwii-mega-all-in-one.jpg) on [other boards](http://www.multiwii.com/wp-content/uploads/2011/01/flyduino.jpg) too.

### Suggested solution

If I would solder directly to the board (and I probably will take that approach later when I deal with a smaller model) and having found that diagram, this isn't really an issue, since the A0 and A1 are broken out on the HK NanoWii board.

By default however, it would be nice (i.e. more user-friendly and more intuitive) to have the elevon signals on the board's output rail which provides power and ground pins for the servos.

The attached branch provides _a_ way to accomplish that on the board I'm using. It re-maps servo 1 and 2 to pins on the output rail that appear not to do anything useful in FLYING_WING configuration. Written for and tested a couple of hours the air with the "release-2.1" tag. Rebased on top of and tested briefly on the ground with the commit that the SVN repo claims corresponds to the 2.2 release ([no corresponding tag in the git repo currently](https://github.com/multiwii/multiwii-firmware/issues/4)).

###### A few caveats:

- I only tested with my FrSky D4FR receiver hooked up in SERIAL_SUM_PPM mode.

- I did not hook up any other peripherals or test any of the optional features. Does the servo constants I moved out-of-the-way (servo 5 and 7) have a theoretical purpose in this situation? Any other side-effects I should be aware of?

### Commit message

At least on Felix Nessen's NanoWii and Hobby King's NanoWii - both of which
suggest that board definition NANOWII should be used - Arduino pins 10 and 5
map to the second and third channels on the output rail that provides power
and ground pins next to each signal pin.

FLYING_WING mode uses SERVO_1 and SERVO_2 as elevons, which by default
are mapped to Arduino pins A0 and A1, which are accessible on these boards,
but lack the convenient power and ground pins. This commit re-maps the pins
for SERVO_1 and SERVO_2 (and SERVO_5 and SERVO_7) to the mentioned pins
on the output rail in this situation.

This change is probably only beneficial to you if you use one of the
mentioned boards AND want to fly in elevon mode AND you choose to use
pin headers and standard servo connectors instead of soldering
directly to the board.

AIRPLANE mode seems to map aileron, elevator and rudder to the second,
third and fourth channels (Arduino pins 10, 5, and 6) on the output rail
as desired, regardless of this change.

The throttle channel seems to map to the first channel on the output
rail in both AIRPLANE mode and FLYING_WING mode.

http://flyduino.net/documents/NanoWii_manual.pdf
http://www.hobbyking.com/hobbyking/store/__22322__MultiWii_NanoWii_ATmega32U4_Micro_Flight_Controller_USB_GYRO_ACC.html
http://multiwii.googlecode.com/svn/trunk/Doc/Diagrams/7%20Connection%20diagram%20flying%20wing.png