Pixhawk 4 could not be disarmed after landing, and logging stops with ESC at no-zero output

[echoGee]

Describe the bug The drone took off in position mode(EKF aided by motion capture system), moved few meters and landed. After landing, the drone was disarmed(using the RC switch), but the props continued to increase in throttle

Symptoms:

1. Drone failed to disarm with RC disarm switch and the z estimate shot up by few meters.
2. Baro and IMU data not logged during the period when disarm was send(300.6 - 301.2 sec)
3. Warning for [ecl/EKF] EKF ev hgt timeout - reset to baro was not logged.
4. Disarm RC command should always log output of the sensors if the motors are armed

To Reproduce Steps to reproduce the behavior:

1. Drone switched on '...'
2. Takeoff in position mode with EV position data
3. move around a bit.
4. Land in position mode
5. While on the ground with idle PWM, lose motion capture data for around 200ms
6. Disarm the drone and it doesn't disarm.

Expected behavior Losing mocap data should graciously degrade position accuracy, without uncertain jumps. Disarm RC should always disarm.

Log Files and Screenshots https://review.px4.io/plot_app?log=7a62d51d-a1ca-40fe-b7ea-44733e6993bd

Data from around when the issue happened. Issue occurs between 300 and 302 seconds

Drone (please complete the following information):

• X configuration multicopter.
• Pixhawk 4

[echoGee]

This is a video of rosbag replay of the issue on rviz:

[julianoes]

How did you try to disarm? And at what time (as time in the flight review plots)?

[echoGee]

Was disarmed around ~294.8 sec and attempted a second time at ~299 sec, using the disarm rc channel.

Orange is the rc channel for arm in the last chart below:

[julianoes]

Ok, the most likely issue here is that landed was not detected yet, presumably because you lost mocap data for a bit. Therefore, it did not disarm. I believe you need to wait long enough with throttle all the way down until the props are truly at idle. You might also just use auto-disarm to prevent having to get the disarm moment right.

Losing mocap data should graciously degrade position accuracy, without uncertain jumps.

I agree with this one. And it might improve with 1.11.

Disarm RC should always disarm.

This is by design only for stabilized. The risk is accidental in-flight disarming (trust me, I've done it). If you need authoritative (but potentially dangerous) force disarm, I suggest to use a kill switch.

[echoGee]

Ok, the most likely issue here is that landed was not detected yet, presumably because you lost mocap data for a bit. Therefore, it did not disarm. I believe you need to wait long enough with throttle all the way down until the props are truly at idle. You might also just use auto-disarm to prevent having to get the disarm moment right.

There was atleast 2 seconds or more of time on the land with idle throttle which should be enough to detect land. Right ? See https://user-images.githubusercontent.com/518314/86965953-5368e700-c136-11ea-8fb6-39be5721829f.png

Losing mocap data should graciously degrade position accuracy, without uncertain jumps.

I agree with this one. And it might improve with 1.11.

Could you point to few fixes or issues that could have helped the issue in 1.11 ?

Disarm RC should always disarm.

This is by design only for stabilized. The risk is accidental in-flight disarming (trust me, I've done it). If you need authoritative (but potentially dangerous) force disarm, I suggest to use a kill switch.

I am using the kill switch now. But the issue still remains on the fusion and landing not detected.

[julianoes]

There was atleast 2 seconds or more of time on the land with idle throttle which should be enough to detect land. Right ?

Right, it depends on quite a few inputs though. I would have to look in detail at all data and what the land detector does. I'm afraid I don't have bandwidth to do that. If you find a consistent case where the land detector doesn't perform as it should, and understand it, then we could of course change/improve it.

Could you point to few fixes or issues that could have helped the issue in 1.11 ?

No chance. I just know that there are continuously fixes coming up around ekf2.

@bresch mocap data lead to a position jump in the log file above. Is this expected? Or do you know if this has been improved since 1.10?

I am using the kill switch now.

Makes sense I'd say, for your use case.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[echoGee]

This is still an issue.