Update tools.mk to select OS specific Android SDK
Update tools.mk to select OS specific Android SDK
corrected a comment
updated make android_sdk_update routine
Gtest: update to 1.7
I2C VM: fix unsigned comparison caught by clang

Found this potential bug when working on unit tests for
OSX.
UnitTests: add tests for error correcting library
StabilizationSettings: add fields for TPA

This is taken from BrainFPV's TPA branch
Stabilization: allow scaling PID settings by constant

This was first implement by BrainFPV and is based on an
algorithm from MultiWii. The Kp and Kd terms are reduced
by a fixed scale. Currently this is hardcoded at 1.0.
Stabilization: call ZeroPids zero_pids

This is for consistency with the rest of the code that tries
to avoid CamelCase in the firmware side.
Stabilization: implement TPA based on throttle setting

Calculate the desired PID suppression based on throttle
settings. This is similar to an algorithm used by MultiWii
and empirically works well. It creates a piecewise linear
suppression of PIDs versus throttle.

i.e. the Kp will look like this:

     -------------         <-- rateKp
                  \
                   \
                    \      <-- rateKp * (1 - attenuation / 100.0)
                 ^
                 |
                 threshold

For safety the maximum allow attenuation the firmware will pay
attention to is 90%
GCS/Stabilization: add Expert fields for TPA
Stabilization/TPA: fixes from review
Stabilization/MW: implementation of the multiwii control algorithm

There are a few notable differences between this approach and our
existing control algorithm.
 - uses TPA (which we have and this builds upon)
 - the roll and pitch PD settings are also scaled by stick position
 - "proportional" component doesn't actually have an error signal
    but rather applies the stick input to the output and has a
    feedback component from the gyros.

For now I have tried to preserve variable names reasonably between
the multiwii implementation
  https://github.com/multiwii/baseflight/blob/master/src/mw.c

This will need further cleanup before merging - either giving it
separate settings if we want to make it exactly (numerically)
equivalent when switching between the two, or rescaling to make
the settings work similarly to our existing ones and giving a
mechanism to easily translate the PIDs from MultiWii.
Stabilization/MW: remove arbitrary scales from multiwii mode

These were from 8 bit controllers that had to be super efficient
on floating point calculation. No longer needed and this makes
the parameters more similar to existing ones.

- reduces the Kp increases teh Kp term by a factor of 80
- increase Ki by 8192
- increase Kd by ~10
Stabilization/MW: do not scale input by 500 in multiwii rate

This is how it is scaled in their code, but because the output
is also +/-500 and ours is +/- 1 this is inconsistent.

It also makes the sticks completely saturate the output.
Stabilization/MW: document converting from MultiWii to our units

The MultiWii control loop has lots of arbitrary constants. Here I work
out how to convert from one representation to the other so people can
reuse those settings. In our code we use physically we defined units
such as accounting for the loop rate and the units of the gyro.
Stabilization/MW: make setting for the RollPitchRate and YawRate

These settings suppress the control loop for stronger inputs and are
a large part of the feeling of MultiWii that people like.
Stabilization/MW: zero integral for strong yaw or fast flips
Stabilization/MW: rework to use common pid code

This gets the benefit of the bandpass filtered derivative
code and resusing the scaled integral code. These two
changes made it feel a lot more precise and locked in for
me.

Because the Ki term has a strange scaling of input to get
the predicted "rate" we use a setpoint with that strange
value and apply the Kp term outside the pid_apply method.

This also means the derivative term sees that strange
setpoint so currently I am testing with a DerivativeGamma
of 0.