Slow landing improvement suggestion #11172
Merged
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.
Context
Search for "landing" after this comment: #9731 (comment)
hopefully fixes #9696
fixes #10732
hopefully fixes #10001
Test data / coverage
SITL still works. Release testing for the upcoming H520 update shows a massive speedup in land detection.
Describe problem solved by the proposed pull request
When introducing the flight tasks architecture almost the whole legacy position controller was replaced a lot of things were modularized and simplified from a developers perspective. One of the things that @Stifael found in the refactoring process was that the way the controller didn't execute on the land detection states like expected according to the current multicopter land detector design. So he fixed it and probably as a result landing with the default configuration takes longer since then. Because since then no one including me had the time to refactor the land detector and the problem is still present I'm:
setpoint.thrust[2] = 0.0f;
) already in the first land detection stage (ground contact). This brings the thrust down and hence further detection stages a lot quicker but in case of false positives gnerates more altitude loss in the time of wrong information. Based on past experience where the controller "by accident" did exactly that but it worked fine._vehicleLocalPosition.z_deriv
) with the vertical velocity estimate (_vehicleLocalPosition.vz
). These two values are not the same when using the ekf2 estimator. Based on log analysis when having landing issues:This picture shows the land detection states and after ground was detected once (red plot) it's discarded again because the vertical position dervative goes over the threshold of 0.36 which I indicated with the orange line. The drone is sitting steadily on the ground during this time and the vertical velocity (grey plot) represents that more accurately and also stays within the threshold.
Describe possible alternatives
Revisiting the land detection using IMU sensors would be the ultimate goal and I have ideas how to improve. But right now contributing the fix that works well in our current release tests seems like a viable in-between solution.
@PX4/testflights Could you test these changes starting with a bit of caution for each new vehicle? I've tested a lot with one vehicle and predict no issues but familiar faster land detection. But it's still a safety critical change.