There are two classes of GPS failsafe: failsafe.GPS_GLITCH and failsafe.EKF, in increasing order of severity. This deals with the former. The logic described below was first introduced in Ardupilot-Solo v1.4.0 and applies only to Site Scan, which has a significantly reduced set of operating conditions compared to Ardupilot more generally.
If Solo is in a flight mode (i.e. LOITER), that requires stick control and close operator attention, a GPS_GLITCH failsafe triggers a switch to ALT_HOLD. This behaviour is preserved.
If the user is in a flight mode (i.e GUIDED) that does not require stick control, it is not safe to assume that the operator will be paying close attention. Previously the behaviour was to do nothing until the GPS failsafe escalated to EKF. This was based on the assumption that GUIDED mode flight generally takes place far away from obstacles, and so a relatively minor and brief degradation in position accuracy is "less bad" than the consequences of completely giving up on position control and switching to a non-GPS flight mode.
This assumption has been called into question after a recent event where a user managed to take off in GUIDED mode with a damaged compass. (The compass failed after passing pre-flight checks and before takeoff). In this case, a GPS_GLITCH occurred immediately after takeoff, at which point remaining in GUIDED mode allowed for erratic flight at low altitude that would have been avoided had the drone switched into a non-GPS flight mode.
The dataflash flight log is available upon a reviewer's request.
This PR changes the GPS_GLITCH failsafe functionality so that if such an event occurs and the current mode does not require stick control (i.e. GUIDED), the mode is changed to non-GPS-assisted-LAND. If the failsafe condition escalates to EKF, the drone will continue to land without GPS. If the failsafe condition clears, the mode will change to loiter, and the drone will hover in place until commanded to move either by user action or a battery failsafe.
There are two classes of GPS failsafe: failsafe.GPS_GLITCH and failsafe.EKF, in increasing order of severity. This deals with the former. The logic described below was first introduced in Ardupilot-Solo v1.4.0 and applies only to Site Scan, which has a significantly reduced set of operating conditions compared to Ardupilot more generally.
If Solo is in a flight mode (i.e. LOITER), that requires stick control and close operator attention, a GPS_GLITCH failsafe triggers a switch to ALT_HOLD. This behaviour is preserved.
If the user is in a flight mode (i.e GUIDED) that does not require stick control, it is not safe to assume that the operator will be paying close attention. Previously the behaviour was to do nothing until the GPS failsafe escalated to EKF. This was based on the assumption that GUIDED mode flight generally takes place far away from obstacles, and so a relatively minor and brief degradation in position accuracy is "less bad" than the consequences of completely giving up on position control and switching to a non-GPS flight mode.
This assumption has been called into question after a recent event where a user managed to take off in GUIDED mode with a damaged compass. (The compass failed after passing pre-flight checks and before takeoff). In this case, a GPS_GLITCH occurred immediately after takeoff, at which point remaining in GUIDED mode allowed for erratic flight at low altitude that would have been avoided had the drone switched into a non-GPS flight mode.
The dataflash flight log is available upon a reviewer's request.
This PR changes the GPS_GLITCH failsafe functionality so that if such an event occurs and the current mode does not require stick control (i.e. GUIDED), the mode is changed to non-GPS-assisted-LAND. If the failsafe condition escalates to EKF, the drone will continue to land without GPS. If the failsafe condition clears, the mode will change to loiter, and the drone will hover in place until commanded to move either by user action or a battery failsafe.