I was attempting a survey pattern over my farm with Arduplane today, when suddenly my plane cut throttle and began gliding for the ground. A couple panicked slaps at the switches later, and I was back in FBWA and pulled out. I switched to LOITER which worked fine for a round. I then attempted AUTO again to no avail and decided to land.
Upon recovering the logs, this appears to be the problem - POS.Alt snapped from relative to absolute GPS altitude, totally ignoring the baro. What happened? In fact, why is POS.Alt somewhere between GPS and baro altitude? I’ve been flying with Arduplane for years and have never seen this kind of altitude mishap.
The site says the logs are too large to upload, so here’s a screenshot of the event.
What happened, was that EKF switched to GPS altitude as the crazy deviation between estimates and GPS data , there are four messages warning about it.
(“EKFx IMUx is using GPS” and “EKFx IMUx Origin set to GPS”)
What is the GPS altitude of the actual start location ? - and; visually; is your impression that the mission kept stable 150m altitude in relation to the start point, until it started to sink ?
The starting GPS altitude as checked from previous logs is 725m. This correlates with Google Maps at 727m.
Visually, I flew a similar mission the day before at 100m, and this flight appeared to climb out to the requested 150m and maintained level flight until the failure. The photos taken before the failure look like they were taken from a constant altitude. Auto-throttle sounded steady at a moderate cruise and I nudged it up a bit on upwind legs to keep my groundspeed up in a fairly significant wind.
you’re starting with a pretty bad HDOP. then a few minutes into flight, once your GPS has aqcuired enough sats to get a HDOP below 2,5, it starts being used by EKF and your alt is reset respectively.
imho it’d be favourable to keep arming and respective checks enabled and not override safety checks that are meant to keep you from flying without a decent enough GPS fix.
Interesting, I didn’t think this was how ARMING_REQUIRE worked. I assumed ARMING_REQUIRE simply bypassed the need to hold rudder or send a GCS ARM command, but all normal arming health checks were still performed.
I have always just plugged in the battery, waited for the green light and long armed tone (which can take awhile, I assumed the health checks/GPS init are occurring then) and then pressed the safety button to enable the servos.
I assumed the rudder arm was just one more safety to avoid an unexpected takeoff. Does it actually change the way the arming checks are performed? If so, I will enable it.
Note that I’m flying without telemetry right now since switching to 900Mhz control, as I was running 900Mhz telemetry. I’m planning to wire up the FrSky telemetry pretty soon, after this incident.
in short terms, setting ARMING_REQUIRE = 0 pretty much removes the whole arming process and arms your FC after startup no matter what. this is particularly unfortunate if you don’t have any feedback from your FC, like notifications displayed on OSD or GCS.
honestly, back then when i was on 8-bit hardware with pre-EKF firmwares, i didn’t care too much about arming too. this has essentially changed with EKF requirements, and imho adds tons of safety and performance.
