After a GPS_GLITCH without RC control, set mode to LAND. #299
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.