Plane: Lidar/Rangefinder completly ignored on second approach when LAND_ABORT_DEG triggers landing restart

pompecukor commented 6 years ago

Issue details

When LAND_DEG_ABORT triggers an abort landing. On the second landing approach the lidar is completely ignored by the AP and only uses the new ground offset. This is a major risk as many time just a tree or a pit gives the lidar the wrong value causing it to offset the ground level. Then on second approach it does not consider whatever the lidar report, just goes for new "virtual" ground level, like in Die Hard 2. This can and does end in hard crash into the ground, with plane skipping flare stage and all thinking that it is still airborne even tough it is long laying flat on the ground. Sometime even the props keep spinning.

Version

3.8.3 beta (started using lidar with 3.8 beta 05, the problem has be present from the start for me)

Platform

[ ] All [ ] AntennaTracker [ ] Copter [ x ] Plane [ ] Rover [ ] Submarine

Airframe type

Fixed wing

Hardware type

Pixhawk2.1

Logs

https://www.dropbox.com/s/rkrpaeid95d7z9f/2017-11-05%2016-48-54.bin?dl=0

This is a major issue for me (has caused me multiple loss and damage) and took a long time to nail the what was really going wrong. Can I pay someone to fix this ASAP? Ultimately sorting this (related issue out too would be very desired:https://github.com/ArduPilot/ardupilot/issues/7052#issuecomment-342759892

PS, the part of the code that controls manual landing abort/restart (your know.... with throttle to max), should also be verified if it has same bug. I never tested with that, but can imagine they would be using same subroutine to keep the code clean.

PS2: Here is some more post on this issue that let me to finding the culprit. Posted more similar logs there too https://discuss.ardupilot.org/t/autolanding-multiple-code-issues-condition-for-uav-landed/22768

magicrub commented 6 years ago

if this is true, then it's new behavior. Repeated aborted landings with a baro offset worked correctly in the past.

pompecukor commented 6 years ago

Did you look at the log? I have a few of them, not just one. Also sent you a video privately. I have been getting the same problem since 3.8 beta 05 I think.

pompecukor commented 6 years ago

Short video explanation (this from the log posted just above, the end of it): https://youtu.be/D41V59b9Ftg

magicrub commented 6 years ago

I'm looking into it.

pompecukor commented 6 years ago

Thank you sir. Really appreciated.

magicrub commented 5 years ago

sorry, I seem to have been distracted for the last 1.3 years. I'll take a look at this again soon :)

pompecukor commented 5 years ago

/hug

magicrub commented 5 years ago

I think I found the problem, rangefinder is fine.. it's the mission that changed. Upon a rangefinder determining the slope is too steep, the rangefinder correction is stored here. Then later, we're flying around to repeat the landing and we're told the whole mission has moved up or down via that offset.

That is a changed behavior where before it was a baro offset, now it's a mission offset. However, this should not effect the ability for the rangefinder to work the second time but clearly the behavior has changed and I don't know why.

magicrub commented 5 years ago

Hmm, looks like it was changed a long time ago! Here's where it changed. https://github.com/ArduPilot/ardupilot/commit/4da3236c07770acc3bb981fb1616b023e61a9e4a

pompecukor commented 5 years ago

"Changed" as in fixed? I haven't dared enable it since the issues over a year ago.

ArduPilot / ardupilot