Plane: LAND_ABORT_DEGT aborts should level off and detect exact land point alt offset

[magicrub]

When LAND_DEG_ABORT triggers an abort, instead of pitching up right away it should level off and fly towards the NAV_LAND coords and detect the exact land point alt offset THEN pitch up and circle around. This ensures the rangefinder did not store an alt offset of a pit or tree on the approach.

Idea by user pompecukor on https://discuss.ardupilot.org/t/land-abort-deg-more-dangerous-than-not/21890

[pompecukor]

Here is a more acute part of this issue that might be easier to correct until the above it taken under someones wings: https://discuss.ardupilot.org/t/autolanding-multiple-code-issues-condition-for-uav-landed/22768/5?u=pompecukor

On normal lidar/rangefinder assisted landings, the lidar is engaged at a certain stage and is used for the landing instead of the barometric alt (correct? or is is just used for validation?).
You can see a message in mission planner and the telemetry log too "Range finder engaged at....."

This issue is. if the landing is restarted based on parameter: LAND_ABORT_DEG
Then a new "virtual" ground level is saved on the AP. This is is called Land_AltO. This if obviously an offset from the real ground level. Problem is that this many times is set incorrectly, for example it there is a and elevation of even just a tree under the plane at the time is marks to use this lidar.
Then when coming around for a new landing, it would ignore everything and use the sum of the Barmetric alt and Land_AltO to decided where the ground is. Completely ignoring whatever the lidar tells it, all the way to the end of touch down.
That is the "range finder engaged" phase gets skipped entirely on the second landing attempt and this is the problem. This is what I see from all my logs that ended with a restart. And this explains all the problems that happened there after.

As you can imagine, it the offset was made incorrectly. Then you have a guaranteed crash on the second landing even thought the lidar keeps giving correct altitude az 50Hz update or so.

so long story show, on the long run this issue will of course solve this more or less, but for a more immediate solution I think if would be good to add a line to start to use the range finder again on the second approach and save a few people from unfortunate crashes.

[magicrub]

Rangefinder should always engage, doesn't matter if you had previously aborted or not. If it does not, then that's a new bug.

[pompecukor]

It does not, I have checked multiple logs. If LAND_ABORT_DEG restarts the landing, then lidar is not used as I explained. I will go ahead and open issue.
Thank you for looking at it.

[pompecukor]

Correction to the above post. Lidar is used. However the AltO is offset and this offset is added to the lidar too with regards to landing. So the result is more or less the same. Even tought lidar says AGL is 10m off, if there was and offset on the AltO, then the AP will take the value as 10m+offset.

[magicrub]

The lidar is always treated as giving the most accurate altitude. The offset between what the lidar says vs what the baro says is applied to the baro after the abort so that this offset is already being applied and the slow is correct. The offset is therefor in theory zero on the next landing attempt. It's of course never zero especially as it's looking at terrain bumps but it should be only a few cm..

I still don't quite understand what you're talking about. Is there a problem?

[pompecukor]

Do you know what AltO is? You can see that in the dataflash log. It seems to be some kind of ground zero offset. As I have shown here. If the lidar is used to abort and correct the landing. Then on the second approach then the altitude based on which the UAV does all its flares and so on is not directly the lidar alt (which is what it should be), but rather the lidar alt + the new ofset of AltO. Please look at this thread. I tried to demo as best as I could. You can clearly see what happens. All reactions from the plane are done as if the ground was 6m lower than it really was. Even though the lidar was working. It was supposed to flare at 4m, but as the ground got offset by 6m, it hit the ground before flaring.
If you are up for a phone call or chat. Then maybe I can explain better.
You can see that stalker guy (last post) also sees the same in the dataflash. Yes, lidar was used in second approach, but not directly. The key again here is AltO. Maybe his explanation is better than mine. I quote

Based on the code, it assumes that the offset will remain constant during the second land. (doesn't use rangefinder alt, but use it as a correction to baro alt).

https://discuss.ardupilot.org/t/autolanding-multiple-code-issues-condition-for-uav-landed/22768/9

[pompecukor]

Tom please let me know if it still does not make sense. Seem I am doing a terrible job at explaining. The issue is there trust me. Let us get to the bottom of this. It is very dangerous at current iteration.

[magicrub]

I see. You're talking about a different issue (#7205) which is confusing me

[pompecukor]

My apologies. In my mind they are related a bit and both together work to generate the crashes.
Can you help?