RTH crash

[Meta4]

I believe the system failed because, regardless of the barometric pressure, the purpose of the VPS is to prevent crashes, and the sensors should recognize obstacles and halt the descent. If it indeed recognized the obstacle 5.4 meters below, there should have been enough time to stop the drone.

The issue is much more likely due to the limitations of the VPS system when dealing with a 3-dimensional mess of leaves and thin branches, rather than a simple solid surface.

The problem lies in the fact that the data log shows a vertical speed of zero, yet the drone was still descending.

You explained that vertical speed is calculated from barometric pressure. If the speed is based on barometric pressure and it indicates that the drone is not descending, but in reality, the drone is still descending, then the algorithm is incorrect because it relies on inaccurate or unreliable data.

Observe the height on your screen when you move the drone up and down just small distances.
It senses small changes in height quite accurately.

I believe that once an obstacle is recognized, the drone should come to a stop and prompt the operator for further instructions.

Your VPS data showed that it didn't pick up the vegetation until it was just 5.4 metres away.
That's just half the distance it could read the ground after you launched.

Obstacle avoidance and VPS are not magic and cannot work perfectly in every situation.
The manual lists a number of situations that can make things difficult for the sensors.
Particularly note the last one.

The Vision Systems cannot work properly over surfaces without clear pattern variations or where the​

light is too weak or too strong. The Vision Systems cannot work properly in the following situations:​

a) Flying over monochrome surfaces (e.g., pure black, white, red, or green).​

b) Flying over highly reflective surfaces.​

c) Flying over water or transparent surfaces.​

d) Flying over moving surfaces or objects.​

e) Flying in an area with frequent and drastic lighting changes.​

f) Flying over extremely dark (< 10 lux) or bright (> 40,000 lux) surfaces.​

g) Flying over surfaces that strongly reflect or absorb infrared waves (e.g., mirrors).​

h) Flying over surfaces without clear patterns or texture (e.g., power poles).​

i) Flying over surfaces with repeating identical patterns or texture (e.g., tiles with the same design).​

j) Flying over obstacles with small surface areas (e.g., tree branches​

 

[Droning on and on...]

The lesson for me is to check the reported height, or even better, to use Return to Home (RTH) mode only until the drone reaches the home point and begins descending. At that point, I will stop RTH and land manually. Thanks again for your assistance. Understanding the deficiences helps ensure safe flying.

I think a more important lesson regards your choice of takeoff location.

Given the worst-case GPS (in)accuracy, you should always take off with a clear, level radius around the takeoff point of about 30ft/10m. This accounts for the worst case – a catastrophic failure of the RC or the drone that disconnects, but the drone is still able to successfully execute a RTH.

It also makes any RTH safer, control or not.

 

[Kajtek]

The issue is much more likely due to the limitations of the VPS system when dealing with a 3-dimensional mess of leaves and thin branches, rather than a simple solid surface.

Observe the height on your screen when you move the drone up and down just small distances.
It senses small changes in height quite accurately.


Your VPS data showed that it didn't pick up the vegetation until it was just 5.4 metres away.
That's just half the distance it could read the ground after you launched.

Obstacle avoidance and VPS are not magic and cannot work perfectly in every situation.
The manual lists a number of situations that can make things difficult for the sensors.
Particularly note the last one.

The Vision Systems cannot work properly over surfaces without clear pattern variations or where the​

light is too weak or too strong. The Vision Systems cannot work properly in the following situations:​

a) Flying over monochrome surfaces (e.g., pure black, white, red, or green).​

b) Flying over highly reflective surfaces.​

c) Flying over water or transparent surfaces.​

d) Flying over moving surfaces or objects.​

e) Flying in an area with frequent and drastic lighting changes.​

f) Flying over extremely dark (< 10 lux) or bright (> 40,000 lux) surfaces.​

g) Flying over surfaces that strongly reflect or absorb infrared waves (e.g., mirrors).​

h) Flying over surfaces without clear patterns or texture (e.g., power poles).​

i) Flying over surfaces with repeating identical patterns or texture (e.g., tiles with the same design).​

j) Flying over obstacles with small surface areas (e.g., tree branches​

The bush that the drone hit was not a branch but rather dense foliage. Therefore, the VPS should recognize it as an obstacle, and it actually did. The problem lies somewhere else and starts with wrong reported height.
I know that there are no perfect systems, and understanding limitations is crucial.

After analyzing other RTH landings, I noticed that the drone slows down before it sees the ground based on the estimated height, which, as I learned, depends on changes in barometric pressure. In all other instances of safe RTH landing, my drone started to decrease its default descending speed of 18 km/h at around 40-35 meters above the ground. When the VPS detected the ground, the speed was reduced to around 4-5 km/h (down from 18 km/h). This speed allowed the drone enough time to come to a full stop and avoid a crash.

The barometric pressure reading is reliable when it is accurate. However, in my crash, it initially started to report the wrong height (as you noticed and explained to me), and later, when the drone was still descending, it reported no change in pressure, which indicated no vertical speed and no descent, even though the drone was actually descending. Thank you all for discussion, I learned a lot.

 

[Kajtek]

I think a more important lesson regards your choice of takeoff location.

Given the worst-case GPS (in)accuracy, you should always take off with a clear, level radius around the takeoff point of about 30ft/10m. This accounts for the worst case – a catastrophic failure of the RC or the drone that disconnects, but the drone is still able to successfully execute a RTH.

It also makes any RTH safer, control or not.

Good point.

 

[Meta4]

Therefore, the VPS should recognize it as an obstacle, and it actually did. The problem lies somewhere else and starts with wrong reported height.

But it couldn't measure the height above the bush until it was half the distance it could measure solid ground from.
That's a limitation if you want to autoland on that bush.

After analyzing other RTH landings, I noticed that the drone slows down before it sees the ground based on the estimated height, which, as I learned, depends on changes in barometric pressure.

Not at all.
Barometric pressure and the height shown by the barometric sensor aren't used at all for slowing the drone's landing.
The height from the barometric sensor only shows the height of the drone relative to the launch point (+/- a little for air pressure changes).
It does not tell anything about how high the drone is above the ground or obstacles below it.
A system relying on this would be useless because you can land anywhere, not just where you launched.
If the drone used a barometric sensor to slow descent, your (with a huge error) would never have slowed.

Your drone uses the infrared sensors in the VPS to measure (not estimate) height above whatever is below the drone.

The barometric pressure reading is reliable when it is accurate. However, in my crash, it initially started to report the wrong height (as you noticed and explained to me), and later, when the drone was still descending, it reported no change in pressure, which indicated no vertical speed and no descent, even though the drone was actually descending.

The barometric sensor plays no part in slowing descent to the ground.

 

[Droning on and on...]

The bush that the drone hit was not a branch but rather dense foliage. Therefore, the VPS should recognize it as an obstacle, and it actually did. The problem lies somewhere else and starts with wrong reported height.
I know that there are no perfect systems, and understanding limitations is crucial.

You seem to have an incomplete understanding of the downward VPS system.

There are two different types of sensors, cameras, and IR ToF.

The cameras implement Optical Flow sensing for positioning, and are responsible for position hold while hovering.

The ToF sensors are what determine AGL height when in range (<~30ft). It senses distance quite accurately over hard, flat, uniform surfaces. It is very bad sensing distance over sparse, highly variable "surfaces" like trees, bushes, garbage bins, tall grass, etc.

You are simply mistaken that the bush under the drone was a good "surface" in terms of the height sensor. It was not. The height errors seen in your log are completely explainable, and expected.

The fact is, it was correctly sensing that there were myriad different "heights" below it in the leaves, branches, twigs of the Bush. Dense foliage is not dense at all compared to a concrete sidewalk.

 

[Kajtek]

But it couldn't measure the height above the bush until it was half the distance it could measure solid ground from.
That's a limitation if you want to autoland on that bush.

Not at all.
Barometric pressure and the height shown by the barometric sensor aren't used at all for slowing the drone's landing.
The height from the barometric sensor only shows the height of the drone relative to the launch point (+/- a little for air pressure changes).
It does not tell anything about how high the drone is above the ground or obstacles below it.
A system relying on this would be useless because you can land anywhere, not just where you launched.
If the drone used a barometric sensor to slow descent, your (with a huge error) would never have slowed.

Your drone uses the infrared sensors in the VPS to measure (not estimate) height above whatever is below the drone.


The barometric sensor plays no part in slowing descent to the ground.

I admire your patience.

Okay, so barometric pressure is used to calculate vertical speed and height in reference to the starting point. The distance from the ground is calculated by an infrared sensor. Based on my analysis of other safe RTH landing I found consistent behavior that when the drone was reaching a height of around 40-30 meters, it started to slow down. If the height is measured by infrared sensors, it should always slow down at this height when it detects an obstacle.

The foliage of the bush was dense, and even if the sensors couldn't see the leaves, they should have detected the ground 40 centimeters below the top of the bush. My drone only slowed down when I cancelled the RTH; until that point, it was descending at the full default speed. It seems that the drone didn't detect the ground at all around the small bush and below it, almost like there was a deep hole in the ground.

Anyway, the system failed to detect the obstacle and didn't slow down the drone. Is this a limitation of the system or was it a malfunction (a glitch) at that time?"

 

[Kajtek]

You seem to have an incomplete understanding of the downward VPS system.

There are two different types of sensors, cameras, and IR ToF.

The cameras implement Optical Flow sensing for positioning, and are responsible for position hold while hovering.

The ToF sensors are what determine AGL height when in range (<~30ft). It senses distance quite accurately over hard, flat, uniform surfaces. It is very bad sensing distance over sparse, highly variable "surfaces" like trees, bushes, garbage bins, tall grass, etc.

You are simply mistaken that the bush under the drone was a good "surface" in terms of the height sensor. It was not. The height errors seen in your log are completely explainable, and expected.

The fact is, it was correctly sensing that there were myriad different "heights" below it in the leaves, branches, twigs of the Bush. Dense foliage is not dense at all compared to a concrete sidewalk.

You are right that I don't have a complete understanding, which is why I ask questions, draw conclusions, and seek critique. I truly appreciate the time and knowledge of those who know more than me. I don't expect a perfect system, but I want to understand its limitations.

It appears that the system was unable to detect the ground around a single small bush, or perhaps it experienced a temporary malfunction, which we know can happen

 

[Yorkshire_Pud]

I admire your patience.

Okay, so barometric pressure is used to calculate vertical speed and height in reference to the starting point. The distance from the ground is calculated by an infrared sensor. Based on my analysis of other safe RTH landing I found consistent behavior that when the drone was reaching a height of around 40-30 meters, it started to slow down. If the height is measured by infrared sensors, it should always slow down at this height when it detects an obstacle.

The foliage of the bush was dense, and even if the sensors couldn't see the leaves, they should have detected the ground 40 centimeters below the top of the bush. My drone only slowed down when I cancelled the RTH; until that point, it was descending at the full default speed. It seems that the drone didn't detect the ground at all around the small bush and below it, almost like there was a deep hole in the ground.

Anyway, the system failed to detect the obstacle and didn't slow down the drone. Is this a limitation of the system or was it a malfunction (a glitch) at that time?"

It might save a lot of debate if you would post a flight log that demonstrates this behaviour.
If needs be and if your drone is still serviceable, fly a flight to get that log.
An RTH height of say 350ft, would show the RTH landing-phase descent-speed at heights well above your 40-30m threshold and, possibly, the slow down as the drone descends through that threshold.
I can't check this since I do not have a mini 3.
With other drones I might possibly have noticed a descent speed reduction 'at height' but I am inclined to suspect that if I could find such a log I would find that the 'height' would correspond to the upper limit of VPS range.

 

[Kajtek]

It might save a lot of debate if you would post a flight log that demonstrates this behaviour.
If needs be and if your drone is still serviceable, fly a flight to get that log.
An RTH height of say 350ft, would show the RTH landing-phase descent-speed at heights well above your 40-30m threshold and, possibly, the slow down as the drone descends through that threshold.
I can't check this since I do not have a mini 3.
With other drones I might possibly have noticed a descent speed reduction 'at height' but I am inclined to suspect that if I could find such a log I would find that the 'height' would correspond to the upper limit of VPS range.

I posted the flight log, but for some reason, the files could not attach, so I provided a link to the log on my OneDrive.

Here is the folder that includes the flight log, CSV file, an Excel file containing only the last seconds of the flight, and two screen recordings. One recording captures my very first flight, which ended with a successful return-to-home (RTH) landing that I was able to cancel because the drone was just a few meters away from my starting point. The second recording documents an RTH attempt that resulted in a crash. During this attempt, the drone did not slow down, and when I canceled RTH, it was descended at full speed and was too close to the ground."

Shared

Folder

1drv.ms

 

[Droning on and on...]

You are right that I don't have a complete understanding, which is why I ask questions, draw conclusions, and seek critique. I truly appreciate the time and knowledge of those who know more than me. I don't expect a perfect system, but I want to understand its limitations.

It appears that the system was unable to detect the ground around a single small bush, or perhaps it experienced a temporary malfunction, which we know can happen

Sure, things malfunction. However the logs don't show anything malfunctioning. They show VPS trying to detect the distance of the surface below it when there is no surface below it. Rather, there is a bush.

What distance do you say that bush was from the drone? Measured to what point on the bush? Were all parts of the bush under the drone that same distance? If not, then why is the point/leaf you pick the one that represents the distance to the bush? It's only the distance to that leaf.

The drone's ToF sensor is not any better at sorting that out than you are. Hence the quite variable VPS distance when moving over things that are not solid and uniformly flat. A ToF sensor simply measures the time it takes for an IR pulse reflection to return. Like radar. A flat, dense surface will return a narrow, tall, well-defined peak. Using the speed of light and the time between the pulse and the return, we can calculate the distance.

A bush full of leaves, branches and twigs returns a wide, long, noisy return with short, multiple peaks. There is no clear choice of what point in that wide return represents the distance to the bush. It all does.

 

[Yorkshire_Pud]

@Kajtek I think you misunderstand me or I you, that's the crash flight, we have that log already. But, in post 27, you say " Based on my analysis of other safe RTH landing I found consistent behaviour that when the drone was reaching a height of around 40-30 meters, it started to slow down"
I am suggesting you post a log that contains one of these
"other safe RTH landings"
that shows
"when the drone was reaching a height of around 40-30 meters, it started to slow down" .

 

[Kajtek]

Sure, things malfunction. However the logs don't show anything malfunctioning. They show VPS trying to detect the distance of the surface below it when there is no surface below it. Rather, there is a bush.

What distance do you say that bush was from the drone? Measured to what point on the bush? Were all parts of the bush under the drone that same distance? If not, then why is the point/leaf you pick the one that represents the distance to the bush? It's only the distance to that leaf.

The drone's ToF sensor is not any better at sorting that out than you are. Hence the quite variable VPS distance when moving over things that are not solid and uniformly flat. A ToF sensor simply measures the time it takes for an IR pulse reflection to return. Like radar. A flat, dense surface will return a narrow, tall, well-defined peak. Using the speed of light and the time between the pulse and the return, we can calculate the distance.

A bush full of leaves, branches and twigs returns a wide, long, noisy return with short, multiple peaks. There is no clear choice of what point in that wide return represents the distance to the bush. It all does.

You are right. The system is not smart enough, however, when I tried to fly the drone into the bush horizontally, it always avoided it. I attempted this several times, and each time the drone successfully detected the obstacle (leaves) and avoided it.

The bush's foliage has a distance of just a few centimetres between the leaves. If the drone's algorithm were intelligent, it would detect such an obstacle with an uneven surface for safety purposes. It should slow down the drone, or even stop and prompt for further instructions. In fact, the drone actually did this once during RTH landing. It stopped and requested confirmation for a safe landing.

What I am saying is that either there was a malfunction or the algorithm could be, and should be, better.
My drone is fine, tested later had three safe RTH. I am trying to learn what fooled the drone (that it did not recognize the bush as an obstackle) . If this is small bush, then next time I will pay attention and maybe next firmware or next model will be smarter.

 

[Meta4]

You are right. The system is not smart enough, however, when I tried to fly the drone into the bush horizontally, it always avoided it. I attempted this several times, and each time the drone successfully detected the obstacle (leaves) and avoided it.

You are comparing the performance of two completely different sensors.
Your drone has forward facing visual sensors for obstacle avoidance.
They are very different from the downward facing infrared height measurement sensors.
They work differently, their ranges are different and they do different things.

What I am saying is that either there was a malfunction or the algorithm could be, and should be, better.

There was no malfunction or faulty algorithm.
You just ran into the limitations of that sensor type when dealing with the situation you gave it.

My drone is fine, tested later had three safe RTH. I am trying to learn what fooled the drone (that it did not recognize the bush as an obstackle) .

The downward facing sensors are not obstacle avoidance sensors.
If they were you'd never be able to autoland the drone, because the ground is an obstacle.

You don't have to let RTH bring the drone home for you.
You can fly it back yourself.
And you certainly don't have to let it autoland for you.
You can cancel at any time and manually pilot the drone to land exactly where you want it to land rather than depending on dumb automation to do it for you.

 

[Kajtek]

You are comparing the performance of two completely different sensors.
Your drone has forward facing visual sensors for obstacle avoidance.
They are very different from the downward facing infrared height measurement sensors.
They work differently, their ranges are different and they do different things.

There was no malfunction or faulty algorithm.
You just ran into the limitations of that sensor type when dealing with the situation you gave it.

The downward facing sensors are not obstacle avoidance sensors.
If they were you'd never be able to autoland the drone, because the ground is an obstacle.

You don't have to let RTH bring the drone home for you.
You can fly it back yourself.
And you certainly don't have to let it autoland for you.
You can cancel at any time and manually pilot the drone to land exactly where you want it to land rather than depending on dumb automation to do it for you.

Alright, I understand. Let me rephrase.
I apologize for the lack of precision in my previous wording.
Can we agree that bushes can be considered obstacles, and the sensors on the drone should be capable of detecting their presence during descent?
The ground itself is not an obstacle, but when the drone detects the ground, it slows down, stops at a height of 1 meter above the ground, and lands gracefully. That is the behavior I observed during a safe RTH landing
However, if there is an obstacle such as a bush in its path during descent, the drone should either avoid it or come to a stop. The algorithm should be capable of recognizing bushes as obstacles and preventing the drone from colliding with them, just as it does during horizontal movement. If the algorithm fails to do so, it indicates that it is not sufficiently advanced.

If the drone is capable of recognizing the ground as the ground, then it should also be able to recognize any other obstructions as obstacles and avoid them. However, if the drone fails to detect dense foliage (I understand that it may not see individual branches, power lines, or if the lighting conditions are too dim), it indicates that the sensors are not advanced enough. Nevertheless, it appears that the sensors are capable of recognizing obstacles during horizontal movement. If the sensors used for horizontal movement are different from the downward-facing sensor, then I hope that the next generation of the drone will address this limitation and improve upon it.

Anyway, what I am saying is that the system could be improved, and I acknowledge that the current version has limitations in recognizing bushes as obstacles. I will test it by updating my home point to a location with a wide bush, then fly away and initiate RTH function to observe if the drone will stop above the bush, recognizing it as an obstacle, or if it will approach the bush at full speed.

 

[Meta4]

Can we agree that bushes can be considered obstacles, and the sensors on the drone should be capable of detecting their presence during descent?

No .. the obstacle avoidance sensors are looking forwards, not downwards.
The VPS infrared sensors won't see and avoid obstacles, their only job is to measure the distance to whatever is below the drone.
I thought I'd made this clear in my previous post.

However, if there is an obstacle such as a bush in its path during descent, the drone should either avoid it or come to a stop. The algorithm should be capable of recognizing bushes as obstacles and preventing the drone from colliding with them, just as it does during horizontal movement. If the algorithm fails to do so, it indicates that it is not sufficiently advanced.

No .. forget algorithms, forget the idea that the VPS can recognise obstacles and prevent collisions.
There's no algorithm failing.
There's an operator expecting the VPS sensors to do things they were never designed to and are incapable of.

I will test it by updating my home point to a location with a wide bush, then fly away and initiate RTH function to observe if the drone will stop above the bush, recognizing it as an obstacle, or if it will approach the bush at full speed.

RTH autolanding is dumb automation.
Why not take command and do the landing yourself and you'll be able to land exactly wherever you want?

 

[Droning on and on...]

You are right. The system is not smart enough, however, when I tried to fly the drone into the bush horizontally, it always avoided it. I attempted this several times, and each time the drone successfully detected the obstacle (leaves) and avoided it.

Yes, and that is expected. OA cameras work completely differently than the ToF sensors. As mentioned before, ToF sensors are like radar – they send out a pulse, and look for a single, strong return reflection to find distance.

OA and positioning cameras continuously capture full images and compare subsequent frames to each other. For positioning, a technique called Optical Flow Analysis is used to determine how much the image has shifted from one frame to the next, and the Flight Controller then makes compensatory adjustments to stay over the same location.

OA operation uses two methods together to determine an obstacle is in the way, and roughly how far away it is: 1) The change in size and position of objects in view and the rate of change in size frame to frame, and 2) there are two cameras, and the stereoscopic divergence of the two views gives information about whether or not an approaching object will interfere, as well as distance hints.

All of this is more than accurate enough to stop or reroute 20-30ft when approaching an obstacle. It is way too inaccurate for landing, and further doesn't work at all when a uniform, flat surface is in view – usually the case while landing. Just as the VPS cameras can't figure out anything from a uniform flat surface, OA cameras can fail too with a uniform, flat, single-color wall in front of the drone, and the drone crashes.

This is why OA generally doesn't have problems with bushes. It's not directly measuring the distance. It's analyzing movement.

 

[Kajtek]

No .. the obstacle avoidance sensors are looking forwards, not downwards.
The VPS infrared sensors won't see and avoid obstacles, their only job is to measure the distance to whatever is below the drone.
I thought I'd made this clear in my previous post.


No .. forget algorithms, forget the idea that the VPS can recognise obstacles and prevent collisions.
There's no algorithm failing.
There's an operator expecting the VPS sensors to do things they were never designed to and are incapable of.

RTH autolanding is dumb automation.
Why not take command and do the landing yourself and you'll be able to land exactly wherever you want?

I think you may not understand what I want to know when you recommend manual landing. Nevertheless, if there is a function that is convenient, the function should work within its limitations.

RTH is no longer a dumb automation; although it is not perfect yet, it has improved significantly. It was initially simple when first introduced, but now it is called Smart RTH, and its purpose is to prevent crashes like the one I experienced.

In the manual (https://dl.djicdn.com/downloads/DJI_Mini_3_Pro/UM/DJI_Mini_3_Pro_User_Manual_EN.pdf), it states:
Landing Protection
Smart RTH or Auto Landing activates Landing Protection, which operates as follows:

1. Once Landing Protection determines that the ground is suitable for landing, the aircraft will land gently.
2. If the ground is determined unsuitable for landing, the aircraft will hover and wait for pilot confirmation.
3. If Landing Protection is not operational, DJI Fly will display a landing prompt when the aircraft descends to 0.5 m from the ground. Push the throttle stick down for one second to land.

You mentioned, "The VPS infrared sensors won't see and avoid obstacles; their only job is to measure the distance to whatever is below the drone." My drone did not properly use these sensors. It failed to measure the distance to the objects below as it should according to your statement (the bush and ground around in this case), and it didn't recognize that it was unsuitable for landing, as the manual indicates.

If you forget algorithms than you cannot fly a drone. It will be a brick. Computers function on algorithms "if this, then that" There is an algorithm for autolanding and if failed. The sensors are capable to measure distance and the existence of an autolanding algorithm is evident from all my (and all other) safe RTH landings, where they worked according to the algorithms

This omission of the expected or required action is called a failure.

Anyway thank you for your input and lessons on sensors.

 

[Kajtek]

Yes, and that is expected. OA cameras work completely differently than the ToF sensors. As mentioned before, ToF sensors are like radar – they send out a pulse, and look for a single, strong return reflection to find distance.

OA and positioning cameras continuously capture full images and compare subsequent frames to each other. For positioning, a technique called Optical Flow Analysis is used to determine how much the image has shifted from one frame to the next, and the Flight Controller then makes compensatory adjustments to stay over the same location.

OA operation uses two methods together to determine an obstacle is in the way, and roughly how far away it is: 1) The change in size and position of objects in view and the rate of change in size frame to frame, and 2) there are two cameras, and the stereoscopic divergence of the two views gives information about whether or not an approaching object will interfere, as well as distance hints.

All of this is more than accurate enough to stop or reroute 20-30ft when approaching an obstacle. It is way too inaccurate for landing, and further doesn't work at all when a uniform, flat surface is in view – usually the case while landing. Just as the VPS cameras can't figure out anything from a uniform flat surface, OA cameras can fail too with a uniform, flat, single-color wall in front of the drone, and the drone crashes.

This is why OA generally doesn't have problems with bushes. It's not directly measuring the distance. It's analyzing movement.

Thank you for your explanation. I understand that what you explained is for the detection of forward obstacles (or side or back in Mavic 3). There is an algorithm for autolanding, and the drone has optical and infrared sensors that are used for landing. If there is no flat uniform surface, why do you say it is too inaccurate? The system should, according to the manual, recognize that whatever is below is not suitable for landing, unless it is fooled (water is a good example). In my crash, the bush is easily recognizable as something at some distance. If it was detected as it should have been, then even if the drone did not recognize it as suitable for landing, it should have slowly descended on the bush or stop.

 

[Meta4]

You mentioned, "The VPS infrared sensors won't see and avoid obstacles; their only job is to measure the distance to whatever is below the drone." My drone did not properly use these sensors. It failed to measure the distance to the objects below as it should according to your statement (the bush and ground around in this case), and it didn't recognize that it was unsuitable for landing, as the manual indicates.

If you forget algorithms than you cannot fly a drone. It will be a brick. Computers function on algorithms "if this, then that" There is an algorithm for autolanding and if failed. The sensors are capable to measure distance and the existence of an autolanding algorithm is evident from all my (and all other) safe RTH landings, where they worked according to the algorithms

This omission of the expected or required action is called a failure

There are limitations to what the IR sensors can do and what conditions they can work with.
I'm tired of typing the same thing over and over to someone who just doesn't want to understand.