AP_Arming: Check that sticks are neutral

[WickedShell]

This is designed to catch the situation where someone has slowly nudged the trim sticks over by accident and has not noticed it. The problem with this is that they will be taking off and can be commanding a large input when they think they are neutral, which leads to erratic (and scary) flights.

This checks that the roll/pitch/throttle/yaw channels are inside of their deadzone before allowing arming. It's done as an arm rather then prearm check because I needed access to the method to check if the user was attempting to rudder arm or not.

This was bench tested with real hardware and behaved as expected.

[tridge]

also, throttle trim is otherwise unused, so should be ignored even without sprung throttle

[tridge]

needs a check for RC failsafe

[rmackay9]

For the record, I think this is going to lead to too many false positives and cause user pain and support calls which will likely fall on my plate :-(. Still, for the sake of keeping the vehicles consistent I'll compromise and let it in but as discussed I reserve the right to say, "I told you so" when we hit troubles during the next beta period.

I think we should make the check less strict. So perhaps 2x the deadzone would be better. I.e. we catch really large deviations from center but not just a single PWM value off from center.

[WickedShell]

Made the changes from the call, this no longer checks throttle by default and will check for a failsafe. This does allow you to explicitly check the throttle if you want to via a RC_OPTIONS bit.

EDIT: Also fixed the missing doc from f299a4a

[rmackay9]

The "has valid input" check timesout and becomes false if there's been no input in a while? I'm thinking of the case where the user turns on the receiver, then turns it off before arming (from the GCS). I'm also thinking of the two types of receivers we have, the ones that that output no pulses and the ones that pull the throttle low.

[WickedShell]

@rmackay9 So I wanted to say yes, it just does that, however it appears that based on all the vehicles that's not actually the case. has_valid_input only looks at if it has an RC failsafe or not, and ignores the no RC receiver case entirely. I think this might need some more fixups, as the has_valid_input call is used in AP_Tuning, RC_Channels::read_aux_all, RC_Channels::read_mode_switch() which is a bit worrisome. To work around this in the AP_Arming code I added a check to ensure the last RC input was received within the last second, and ever. But this is a bit of an odd patch I admit.

[tridge]

make it 2 option bits, one for RPY, one for throttle, RPY option bit should be on by default

[peterbarker]

Michael and I are in agreement this should probably by looking at control-in rather than in-dz. But this is what was agreed upon at the devcall, so don't think this should block this going in.