Near Crash in QHover after GPS Loss

robertlong13 · October 12, 2023, 9:09pm

I very nearly had a crash today on a quadplane running 4.3.8. During QHover takeoff, I lost my GPS module (and compass with it). As soon as the bird fell back to AHRS DCM, it started dropping like a rock. We managed to slow it down just before it hit.

QTUN.CRt locks up at 1.5m/s when the fallback to DCM happened, so the bird thought it was climbing as it dropped like a rock, which explains why it was descending more and more rapidly (next time, I’m gonna make sure I have QStabilize on a switch). What I don’t understand is why the baro and IMU were not enough to estimate climbrate. This lockup has to be a bug, right?

Onboard log here: AQ000_2023-10-12 11-48-00_hover.bin - Google Drive

robertlong13 · October 16, 2023, 6:31pm

The problem is reproducible. I armed the aircraft in QHover on the ground (VTOL power disconnected), and yanked the GPS module off. 7 seconds later, the QTUN.CRt locks up. AQ000_2023-10-16 13-34-00_ground.bin - Google Drive

robertlong13 · October 16, 2023, 9:18pm

This incident reminded me of another GPS loss incident we had a year ago on an ALTI Transition. At the time, I didn’t look at it as closely as I should have.

The same thing occurred, though this time the canonical climb rate locked when the aircraft was in a descent, so the aircraft tended to enter an uncontrolled climb rather than descent.

Log here: AT001_2022-12-12 14-33-39_full.bin - Google Drive

robertlong13 · October 23, 2023, 11:26pm

Got around to digging into this more again today. This is easily reproducible in sim.

github.com

ArduPilot/ardupilot/blob/def89ea600e9165ac9d7286758c741d03aac4020/libraries/AP_AHRS/AP_AHRS_DCM.cpp#L1171C18-L1182C18


      
          /*
            return NED velocity if we have GPS lock
           */
          bool AP_AHRS_DCM::get_velocity_NED(Vector3f &vec) const
          {
              const AP_GPS &_gps = AP::gps();
              if (_gps.status() < AP_GPS::GPS_OK_FIX_3D) {
                  return false;
              }
              vec = _gps.velocity();
              return true;
          }

So, the DCM can only estimate velocities if the GPS is present and has a good fix. This makes some sense I suppose, at least for x/y speed. But this behavior means that QHover can be a death sentence in a GPS failure (if you lose GPS at max climb rate, you can’t stop a descent, and if you lose it at max descent rate, you can have a flyaway). I think we need one of two things to change:

DCM should be able to measure climb rate some other way, like low-passed derivative of altitude.
The EKF should not necessarily fall back to DCM when losing only GPS.

I think I could probably implement 1, but the right answer is probably something along the lines of 2.