Copter: Improvements to Land Detector

[priseborough]

Reduces likelihood that false negatives will cause the landed_maybe event to not trigger. Failure for this event to trigger means that the softening of the position controller tilt demands do not occur, making tip-overs more likely. Refer to https://3drsolo.atlassian.net/browse/IG-1352.

It also implements a two-stage landing detector as discussed here:

https://docs.google.com/document/d/1M-bzxihxDvbzpRvWbymCrYfP5FVklOGAKqfya_zXM4E/edit#heading=h.69wxjlnmz00c

Has been flight tested with multiple landings to verify the correct sequence of events:

1) Equivalent throttle demand reduces to minimum as height controller continues to lower the set point until the leash stops it. 2) The land complete maybe event (EV.Id 17) is recorded about a second later. This is what causes the position controller to relax. 3) About 0.5 seconds later, the second stage check start event (EV.Id 12)is recorded and the ESC demand upper limit is is set to half the average value in hover. 4) 1 second later the land complete check event is recorded (EV.Id 18) and the copter disarms (EV.Id 11)

Following this test, the length of the second stage test was increased to 2sec https://github.com/3drobotics/ardupilot-solo/pull/257/commits/7ecf63e695685628b4f951d6b820863c70f52490 There was no downside to extending it by another second becasue with the motor thrust limited, there is no increase in tip-over risk and it further reduces the chances of a false positive.

Logging of the filtered accelerations is available, so here are the inputs to the land detector. There is plenty of noise margin in the first stage land detector threshold of 1.0 m/s applied to the 3D accel and the second stage land detector threshold of 1.0m/s/s applied to the Z accel. The 3D accel check is vulnerable to errors in the attitude reference that cause a bias in the horizontal components.
Failure of the 3D accel check to pass should not cause a tip-over unless the attitude reference has large errors because the softening of the position controller is based on min throttle condition only.

Throttle punches and drops in stabilise mode at the end of flight showed that the vertical acceleration took less than 100ms to rise above the threshold of 1.0 when the average ESC demand was dropped to 1500, which was higher than the esc limit applied post touchdown, so the is falling test is robust to inadvertent triggering of the first stage test.

[priseborough]

Logging of land detector accel data was already added by Benoit

[priseborough]

Flight test logs have been attached to the Jira ticket.

[wsilva32]

I performed a 4 auto landings, all completed successfully. I noted that disarm takes noticeably longer than before (maybe 2-3 seconds longer than usual). I'll post the logs on JIRA.

UPDATE 1: After evaluating the 4 landings, the time from Land Complete Maybe to disarm was approximately 2.8 seconds.

UPDATE 2: Looking at acceleration spikes in the Z axis, it took an average of about 4.194 seconds from touchdown to disarm.

UPDATE 3: Understood that the extra time is a result of slowly ramping down the max ESC output to prevent tip overs. Simply noting this as it slightly changes the previous UX (but hopefully improves UX by preventing flip overs!)