If you follow the Facebook group you may have seen some of this discussion already, but I’m hoping that by collating the findings of that thread into a properly structured forum post we might promote a more critical conversation.
Please note that I do not want this to sound like a brash ‘Betaflight does this, why can’t Ardupilot?!’ complaint. Instead my aim is to logically reason through some features which have been very widely adopted & tested within the Betaflight community over the course of many years, but which are seemingly quite rarely used & in a more nascent stage of development & testing in the Ardupilot scene, to highlight where the Ardupilot implementation is slightly confusing (to somebody who has used both platforms for ~5 years).
Background
I have been building & flying racing quads with Betaflight since 2016 & larger copters/planes with Ardupilot since 2017.
Betaflight uses switch arming & this is widely acknowledged as an important safety feature, both for the safety of the pilot/observer(s) & the safety of their equipment. Being able to reliably & near instantly cut power to the motors, especially in the event of a crash or failed landing, is critical.
When I first started working commercially with DJI drones in 2016, stick arming was something I really didn’t like. Back then the Phantom 3 was slightly notorious for how its top-heavy nature combined with the relatively small footprint of its landing gear could lead it to topple/flip when attempting to land on even just slightly uneven ground or in slightly windy conditions. When this happened, there was nothing the pilot could do but frantically hold the stick disarm command while watching the motors trying to dig the propellers into the ground (often breaking them).
Incident
A few days ago I unfortunately experienced a similar incident with Arducopter on my latest Y6 build. I gently landed the copter & began holding down throttle/left rudder. I now know that landing detection failed & this stick input was interpreted as a flight input rather than as the disarm command. The copter throttled up & took off with the throttle still held fully down, then rapidly yawed to the left before the down throttle took over & the copter hit the ground & bounced upside down. All I could do was continue holding down & left, hoping that landing/crash detection would now kick in & the copter would disarm.
Solution
When beginning to troubleshoot this incident, I discovered that Ardupilot does in fact support switch arming, via RCx_OPTION = 41.
Now at this point I will mention that I am well aware that the ‘correct’ way to respond to this incident in the opinion of the wider Ardupilot community would be to investigate & fix whatever caused landing detection to fail in the first place. However, even if this incident hadn’t happened, knowing as I do now that switch arming is an option, I would still want to move to using switch arming instead of stick arming. Switch arming is the method that I am personally more comfortable with & confident in, while overloading multiple commands onto a single physical control, as is the case with stick arming, is something I have never liked.
If you want to contribute to the conversation about the cause of the failed landing & how to address it, please do so in this earlier thread, leaving this new thread specifically for the topic of switch arming & AirMode.
New Problem
I now have switch arming enabled, along with stick arming disabled via ARMING_RUDDER = 0. However I am now encountering another problem which is related to AirMode. I am very well accustomed to AirMode from flying Betaflight & in fact I keep AirMode permanently enabled on all of my Betaflight quads - it is a huge quality of life improvement for FPV acro flying.
However Ardupilot’s approach to AirMode is causing me problems on two counts -
-
Airmode raises the motors idle throttle from MOT_SPIN_ARM to MOT_SPIN_MIN
-
Switch arming automatically enables AirMode in Acro & Stabilize modes, with no option to disable it
The purpose of AirMode is to allow the pilot to completely cut the throttle, to the point that the motors do not produce any effective thrust (eg MOT_SPIN_ARM), but while still allowing the flight controller to spin up the motors as & when required to perform attitude adjustments (whether to maintain attitude instead of tumbling, or in response to pilot commands).
Thus the fact that AirMode raises the motors idle throttle to MOT_SPIN_MIN, which by definition is the “point at which the thrust starts”, seems rather curious to me. Is this simply a workaround to prevent unintentional mid-air disarms when stick arming is still enabled & the throttle is held low for extended periods, potentially while also giving left rudder inputs? Or is it perhaps just a workaround to keep stabilization active, which would normally be inactive at MOT_SPIN_ARM?
Regardless of the design decision, the unfortunate outcome is that switch arming a copter in Stablize results in it idling on the ground with the motors spinning overly fast, at “the point at which thrust starts” rather than at the ‘true’ idle speed.
I have been unable to find any way to disable AirMode in this situation. The wiki says that RCx_OPTION = 84 can be used to directly enable/disable AirMode in Acro & Stabilize modes, even though devoting an entire RC channel to this purpose would be quite unfortunate. The wiki doesn’t confirm whether this option actually overrides the automatic enabling of AirMode by switch arming & I have been unable to test it as my Y6B running stable Copter 4.0.7 on an Orange Cube does not have 84 in the list of supported options. If I set a switch to 84 anyway, the flight controller unsurprisingly responds with an invalid option error.
tl;dr
-
Why does AirMode raise the motors idle speed from MOT_SPIN_ARM to MOT_SPIN_MIN? This seems counterproductive with regards to the ultimate goal of AirMode & leads to overly high idling behaviour on the ground.
-
Why is it not possible to prevent switch arming from automatically enabling AirMode, or to have a global parameter to enable/disable it?