LAND_ABORT_DEG: More dangerous than not?

ArduPlane Plane 3.8
1

Hi all,

I would like to make sure that my understanding is correct about the above paraments. Particularly what it propagates as a fallback. Finally the issue I see it creating more often than not.

2017-10-08 14_33_01-Untitled - Paint.jpg925Ă—421 39.5 KB

My understanding, from the description, is that when using a rangefinder and say there was a long flight and hence some barometers drift. If on the landing approach, the recalculated glide slope based the lidar altitude is compared to the original one, which was based on the barometric altitude. And the difference is greater than angle X (as set in parameters), then the landing is aborted and redone.

So far so good. And I think very clear explanation too on the wiki. Plus it makes a lot of sense. What is unclear for me is what exactly happened on the 2nd try. It says in the wiki that the barometric altitude offset is readjusted. I am guessing, that it is readjusted to the lidar altitude. Correct? That would again only make sense. The landing at initiated once again with the new values, which in turn would make for a better/safer approach.

My question is, at what stage/positions/coordinate is the rangefinder altitude used to offset the barometer exactly? This, as it turns out, is very critical as I have seen from experience.

Here is the deal and this is what I have personly experienced multiple times. Many times the landing area is not entirely even. Maybe even at the designated touchdown point, but might have an up or down elevation on the approach. We are talking about commercial use, so no manicures landing field. And the landing is setup with wind direction factored in.

Looking at the picture attached. If the above function registers and corrects the offset based on readings from the lidar at a point that says 30m before the touchdown point (TDP) then the second attempt will end in a serious nosedive crash. I have experienced this multiple times. This is why I would like to know how/where the offset is taken from exactly.

My recommendation is, and I think this is what would make the most sense for all situations is to take and save the reading (and correction) from ass close to the TDP as possible, best would be to take it from the right when the plane is above the TDP exactly. That is the AGL that matters anyway, in regards to the landing.

I mean, what I would think best is on such an abort, not to climb but rather just to level off, but maintain exactly heading to the TDP, then mark the AGL there, correct bar with that, only climb after this. Turn around and come in for the second landing. Ignore lidar this (2nd) time, and only use barometer.

I have a feeling this is not what is going on now and this makes the lidar use almost more dangerous than not using it. I hope you see why.

Please anyone with thoughts, chip in. Also, someone with more understands than I, that can confirm if my assessment of what is happening currently: offset being corrected with data that is received way before the TDP. That if this is correct. Can you see any down side to the recommendation?

1 Like
2

It happens constantly (10Hz) when executing a NAV_LAND mission item and the rangefinder has been giving reasonable data for a couple seconds. There is an assumption that the ground is perfectly flat before the landing. This is obviously not always accurate but it is in most cases.

Good idea! I’ve created an Issue to track that new feature. It will surely give improved landings during the corner case of abnormal terrain before the landing point.

1 Like
3

I also created this issue which is a more generic solution to be used for all other abort triggers. It’s not related to the rangefinder offset detection stuff but the logic for it will tie into the other one

4

Flying level is a terrible idea on it, you would at least want to do a terrain follow off the lidar or you risk flying upslope into a hill by accident.

From an implementation side this would have to be part of FLIGHT_STAGE_LAND not LAND_ABORT.

5

Thank you Magic, I really appreciate it and I am sure, if fixed, will save a few people from crashing in the future.

6

@WickedShell

You have a point there of course. Terrain follow would be a great idea. I just hope it doesn’t make the implementation to complex and in essence, no one would want to touch it. :wink:

7

There is an big issue with your approach which I just realized. This is that most of us have lidar glued fixed to the frame (no stabilization.

So if the plane starts to pitch up (like 15 degrees) while flying over the intended touch down point (and not flying level over it) then detected range will be very wrong due to the laser no pointing down but 15 degrees forward.

The only way the above would be useful is if the plane is level when over the TDP.

Second issue would be that there are various rangefinders in the market. So can detect up to 110m others just 15m. It might as well be out of lidar range when over the TDP if expected to climb.

I hope you see my point.

8

khmmmm…
ardupilot/altitude.cpp line 358:

// correct the range for attitude (multiply by DCM.c.z, which
// is cos(roll)*cos(pitch))
rangefinder_state.height_estimate = distance * ahrs.get_rotation_body_to_ned().c.z;
9

If the Lidar height estimation is based on plane attitude, for people who mount the Lidar to a servo to always point at plane’s vertical, the reading will be wrong or there is a way to disable this height estimation ?

10

On plane this was never an option. (If you think about it you should need a two axis gimbal).
On Copter you can disable it in config.h but it needs recompile.

11

I just bought a Lidar and I plan to use it as obstacle avoidance and altimeter, mounting it on a two axis gimbal, so if the distance readings are affected by attitude on plane, it might be a problem, it would be great if it could be disabled.

12

I think we should move to another topic, instead derailing this one.
BTW, in plane there is no obstacle avoidance via lidar, only via ADBS. (Neither in Quadplane mode)

13

@pompecukor the rangefinder is assumed pointed directly down and as @Eosbandi pointed out the altitude measurement considers the aircraft attitude.

Also, there is a range finder param to set the distance limit.

14

Happy New Year Tom,

Yes, I am aware of the distance limit, we need to set that for each lidar.
Not I am also aware of the attitude correction.

Any luck with the other stuff?

15

which other stuff, the other issues I created? Sadly, no. Haven’t touched it. I have not forgotten though!

16

yes that one.

I even sent message the the ardu…initiative people that you suggested. if they would fix it for money (as a paid request). however i did not even get a reply from them till this day.