Px4-autopilot: Landing Detector Improvement needed to avoid uncommanded Throttle Cut During Flight

[keenanjohnson]

Bug Report

Filing a bug report from the original thread here: http://discuss.px4.io/t/uncommanded-throttle-cut-during-flight/5852

Several people have experienced an unexpected / commanded throttle dip with multi rotor vehicles using PX4 1.7.3.

Here are some log files that were recoverable:

Equipment and software:
PX4 Version: 1.7.3 Stable
Pixhawk Cube 2.1
Transmitter: Taranis X7 with Orange RX 2.4 GhZ DSMX transmitter module
Receiver: Spektrum Racer Receiver (SPM4648)

1. Occurs at about 04:41 (there appear to be two dips in the throttle log)

https://logs.px4.io/plot_app?log=e149c039-ffee-4ca6-a479-1e77856df206

2. Occurs at about 10:01

https://logs.px4.io/plot_app?log=30e3d454-18d3-4aac-9d21-6be86641f9b0

And here is a log file that resulted in a crash:

Equipment and software: 3DR IRIS
Indoor: PX4Flow + Teraranger one
PX4 Version: 1.7.3 Stable
Pixhawk 1
Transmitter: 3DR transmitter
Receiver: 3DR original receiver

The drop happens at 1:11; crash at 1:12. All RC commands seemed to be normal.
https://logs.px4.io/plot_app?log=57df1304-7bc0-4366-8cbf-9b4233d023ba

[dagar]

Can you verify the links? They don't seem to be loading.

[dagar]

If you still have the log locally please plot and compare thrust (actuator_controls.control[3]) and vehicle_land_detected.landed.

[keenanjohnson]

Hmmmm well that's no good. I can repost the ones I have. I'll also plot that and share it here.

[dagar]

I'm wondering if the url is messed up. Check your email to see if you have something different.

[keenanjohnson]

Huh yeah for some reason the number 1,2,3 was appended to each corresponding link. I fixed the links above.

[keenanjohnson]

Here is that plot you requested from the first log:

[keenanjohnson]

And here are the images for the other two logs. It doesn't appear that there is any false landing identification happening.

[RomanBapst]

@MaEtUgR @Stifael If you guys have an idea what could be causing this please let us know. I checked the landing detector and it indicated ground_contact but i assume this is due to the throttle cutting in the first place.

[RomanBapst]

@MaEtUgR @Stifael I think we found the problem- at least for the first log.
The vehicle detects ground_contact although the throttle is at 57% percent.
To me this would mean that this comment here lies
https://github.com/PX4/Firmware/blob/master/src/modules/land_detector/MulticopterLandDetector.cpp#L41

In the log you can see that the z velocity setpoint goes above the land_speed_threshold used in the landing detector. Once this happened GROUND_CONTACT_TRIGGER_TIME_US useconds after the landing detector detected ground contact which causes the position controller to cut thrust and demand zero attitude, here
https://github.com/PX4/Firmware/blob/master/src/modules/mc_pos_control/mc_pos_control_main.cpp#L2606

The logged acceleration setpoints in the vehicle_local_position_setpoint message confirms that the thrust_setpoint was clamped.

[RomanBapst]

@MaEtUgR @Stifael From the code it looks like ground_contact can also be detected if hit_ground is true. I think this was the problem in this case (but the vehicle was actually not hitting the ground).
I did noticed in the log that the vz tracking performance of this vehicle is not really amazing which might have had an influence in the detection.

[Stifael]

yep, that is what I just wanted to write. I give shortly an explanation of what happened and how we could possibly make it more robust:

[Stifael]

blue: thrust
green: alittude +30 (offset added)
red: ground contact
pink: velocity in z-direction
blue light: velocity in z-direction that better agrees with position estimate (=z-deriv)
black: velocity setpoint

parameters which effect ground-contact:
LNDMC_Z_VEL_MAX: threshold used to detect if vehicle has vertical movement. The value is set to 0.5.
MPC_LAND_SPEED:
threshold to check if vehicle wants to go down. It is set to 0.7. The threshold to check if vehicle wants to go down is 0.9 * landspeed = 0.63.
If 0.5 x 0.63 < LNDMC_Z_VEL_MAX, then 0.5 x 0.63 is used as threshold for vertical movement. in our case that is the case. hence threshold for vertical movement is 0.315.
low thrust threshold: this threshold is a function of hover and minum thrust. This threshold is not satisfied in our case.
The velocity estimate used to detect no motion is z-deriv. I am actually surprised that this is in the firmware, because originally that came from a PR where I concluded that it does not have much of a benefit. Anyway, in our case it is apparent that shortly before the ground-contact detection, the z-deriv is below 0.315, but the velocity setpoint is larger than 0.63. In addition, the altitude estimate is opposite in sign to desired velocity setpoint (the vehicle wants to go down, but the estimate in altitude estimates a upward motion).
A quick fix to make it more robust is to increase the landspeed to 1m/s and lower LNDMC_Z_VEL_MAX to 0.4 or 0.3. The lower the landspeed, the more vulnerable is the detection. 0.7 m/s is very low, which means the requested descend threshold is already achieved if the velocity setpoint is above 0.63, which is close to what the estimation variance for altitude can be. In fact, ground effect during landing can even lead to no descend at all if the descend speed is low.

@priseborough can you comment on why z-deriv is really needed?

[priseborough]

It's needed because of a incompatibility with the vertical velocity state estimation errors that can be present and the fact that the control loops and other logic that handle that level of estimation error. We can check for errors before taking off, but still need to be able to recover safely if they build during flight (for example if temperature change causes accel bias to change rapidly).

[thomasgubler]

@RomanBapst what is your plan here? Do you have a improvement/fix planned?

[RomanBapst]

@thomasgubler To be honest I didn't realize I was assigned to this.
I can have a look at this and try to fix it, however, I should note that I was not involved in the development of the current land detection estimator and thus I need some time to go over the implementation.
Furthermore, collaboration with one of the developers would make a lot of sense since they might be aware of certain pitfalls.

Some points worth to discuss:

• use of accelerometer data to further assist in landing detection (that is actually a TODO item in the current code)
• evaluate current dependency of landing detection on velocity control and estimation performance

As a first step I will look at the code and see what it currently does.

[Stifael]

@RomanBapst @thomasgubler taking the acceleration into account (acceleration vs thrust) would be helpful. Besides of that, one of the biggest problem with the landdetector is that it is highly dependent on the estimation performance and a few thresholds which have to be adjusted based on the estimation quality. i don't know how to solve that, but the point is that it makes no sense to ask for a velocity demand of let's say 0.7 m/s but the estimation can have an offset of 0.5.

[Stifael]

As a side note: it also would make sense to restructure the landdetector such that not only one state can be valid at a time, but several. In fact, the goal was to move the landdetector to vehicle model.

[Stifael]

By the way, the docu is in the dev guide: https://dev.px4.io/en/tutorials/land_detector.html

[MaEtUgR]

Most of the time such thrust holes occured when the parameter MPC_THR_HOVER was completely off the acutal thrust which is necessary to keep the vehicle hovering. Because this value gets used by the land detector and if the thrust is a lot below it it goes into the first stage of land detection which has cutting down thrust as verification action. Shortly after it realizes that this is not the case and prevents false positive land detection by continuing altitude hold. I think this case is pretty similar but the actual hover thrust seems to be above the default configured 50% and there must be another threshold producing the issue.

@RomanBapst The idea for future improvements with the accelerometer is pretty simple as soon as you know the factor between thrust and resulting acceleration ([0,1] thrust -> thrust in Newton -/mass-> Acceleration) because the acceleration measurement in body z-axis follows the commanded total thrust very closely while flying until you hit any external influence like the ground... just plot thrust with the correct scale over accelerometer.z.

[keenanjohnson]

We had this occur again here: https://review.px4.io/plot_app?log=1cde75d4-12de-4b1c-b2bf-5d1c02261d7d

[keenanjohnson]

And again: https://review.px4.io/plot_app?log=1e67961c-6a20-48c6-b85f-0d4565337a53

[VTOLDavid]

Hi. I am testing a VTOL tailsitter quad plane and land detector does not work properly if there is wind. If the wing is producing lift and there are positive gusts (an increase in wind) it usually thinks that has Ianded and cuts throttle for an instant. I think that during a gust it reduces thrust and does not descend, so enters in maybe landed state, furthermore MPC_THR_HOVER depends on the wind. In the other hand when reaches ground it starts bouncing and tips over. I think that the code should detect the impact of ground using the accelerometer. There is nothing in flight that can produce an acceleration equivalent to the ground contact. If when the shock of the ground is detected the thorttle is set to 0 it shoud land perfectly.

Here you can see the shock detected for the accelerometer during the first ground contact in a bouncy auto land.

[Stifael]

@VTOLDavid agreed, vtol landdetection requires a different implementation.
We also have thought about using accelerometer together with thrust setpoint as indicator, because once the vehicle is hits ground, the diff between the two is distinct and differs significantly from normal flight. Maybe something to follow up.
In general, I think it makes not much sense to apply the multi-copter landdetector to vtols

[VTOLDavid]

@Stifael Seems a good solution, but I would try to detect the shock of the impact and use the thust sp to avoid false ground contacts. But I doubt that motors acceleration could be detected as a ground contact since it is smaller and slower than the ground contact shock.
I think that if the only thing that the land detector did during landing was to wait for the shock of the ground and then cut throttle, it would work perfectly for all airframes.

How is it done in ardupilot?

[Stifael]

I think that if the only thing that the land detector did during landing was to wait for the shock of the ground and then cut throttle, it would work perfectly for all airframes

I disagree and almost certain that it will lead to false positive land-detection. It is still better to have a conservative land-detector over one that detects by mistake.
Nonetheless, you are more than welcome to push a better solution. I am sure the community will be thankful.

[Stifael]

here is the one from Ardupilot

[VTOLDavid]

Of course that it could lead to false positive land-detection if it is not done properly, but it is a valuable information that should be used. Distinguish a shock from a flight produced acceleration should be posible. Furthermore the freefall detector, that works very well, would be there if that happens.

Right now the configuration that enables to autoland a VTOL and not to start bouncing on the ground (maybe it can be tunned better) gives a lot of false land detections during flight as I explainded before.

The ardupilot implementation seems similar... But there is a interesting comment:

// land detector can not use the following sensors because they are unreliable during landing
// barometer altitude : ground effect can cause errors larger than 4m
// EKF vertical velocity or altitude : poor barometer and large acceleration from ground impact
// earth frame angle or angle error : landing on an uneven surface will force the airframe to match the ground angle
// gyro output : on uneven surface the airframe may rock back an forth after landing
// range finder : tend to be problematic at very short distances
// input throttle : in slow land the input throttle may be only slightly less than hover

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

Closing as stale.