Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow landing improvement suggestion #11172

Merged
merged 3 commits into from
Jan 26, 2019
Merged

Slow landing improvement suggestion #11172

merged 3 commits into from
Jan 26, 2019

Conversation

MaEtUgR
Copy link
Member

@MaEtUgR MaEtUgR commented Jan 8, 2019

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:

  • disabling the vertical thrust (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.
  • replacing the vertical position estimate's dervative (_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.

land_slow

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.

instead of the derivative of the vertical position which is
not the same value when using the ekf2 estimation.

Using the position derivative resulted in delayed landing because
the value for some reason often bumped over the theshold before
slowly converging towards zero while the velocity was within expected
accuary in all these cases.
@MaEtUgR
Copy link
Member Author

MaEtUgR commented Jan 26, 2019

@dannyfpv Thanks for testing. All three logs look perfectly fine, I specifically checked for the land detection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants