Mavic Air 2 crash, need to find drone for DJI Care refresh - analysis help much appreciated !!

[monohusche]

Hi there,

massive rookie mistakes on my side and feeling super stupid, but can't make it undone. What happened ?

I went flying yesterday in strong winds which was the main/initial mistake. After take off (I had picked a higher spot to avoid losing connection with the surrounding mountains), I quickly got the "Strong Winds" Warning. As I had the drone in sight, I switched to sports mode and turned around, so all good.

After flying around for awhile (back in N-Mode) with changing wind conditions (but on the upwind side), I made the second mistake to fly downwind. That's when things went south.

At around 11:15, the video transmission and signal got weaker (couldn't see anything and didn't switch to map mode...another mistake) and I was advised to "fly cautiously", so I started to turn around, but quickly got the "Strong wind signal" again at 11:20 (incl the confusing/misleading notification that RTH is not possible in this case, and I needed to fly manually).

At 11:32, I lost connection with the drone for quite a long time (35 secs) which put me into panic mode. Because I assumed (per above misleading notification), that RTH wouldn't work in these strong winds, so I had to maintain connection with the drone to be able to manually steer (and continue to receive tracking/gps info), so I raced down the hill to my car to go after it as it was moving away from me. This was the 3rd mistake as it meant that I wasn't able to use that precious time to navigate the drone manually and land it in same safe spot. but yeah, panic mode.....

By now, I have learnt that RTH will be activated if the connection gets lost, no matter what. So while I was in my car, the drone switched into "Go home" mode and started to ascend (fourth mistake as I had my RTH altitude at 100m which of course was way too high for the terrain and wind). So over the next couple of minutes, the drone was climbing up to 400m above sea level (takeoff alt: 300m + 100m RTH alt) while drifting downwind and depleting the batteries rapidly. During that time, the wind speed was around 16 m/s and the drone was flying straight into it but not making any progress but rather getting pushed back. I read here that in strong winds, the drone can tilt with 35 degrees and thereby achieve Sport mode speeds (19 m/s), but not sure whether that's possible in an RTH situation.

At around 16min, the battery level dropped to 10% and it changed to AutoLanding mode. This is the part that I don't get. Instead of going straight down aggressively (which would have resulted in lower winds), the horizontal movement was still stronger than the vertical one which meant that it stayed within the wind channel. Over the next 3:40min (until the last recorded position), it travelled for another 1.5km while only losing 280m altitude. Of course, at that point, I should have focused on getting it down safely, but I still had these connection problems.

My only hope now is to make a prediction about the trajectory of the fall. At the last recorded point, the altitude was 110m above sea level (and around 150m away from the ocean). I would have thought that with lower winds (closer to the ground) and zero rotors, that it would drop now more drastically, but that's just a guess of course.

EDIT: After syncing my flight logs with AirData, I downloaded the txt file from there and uploaded it to PhantomHelp, but it doesn't show any data even though the download finished.

thanks in advance, Nick

 

[DanMan32]

Auto land doesn't stop the motors. There's a maximum powered descent allowed.

If you're in heavy succumbing winds, of course it's going to keep going forward in as it descends. The AC has no control over the winds. Think of it as if the right stick was stuck forward. If it manages to get below the wind tunnel then it will start going straight down.

Indeed failsafe in wind issues becomes a catch-22, since if you descend, you might get less wind, but then signal can degrade and triggers RTH which then puts you back in heavier wind. Failsafe also can be set to hover and land, but that might not be any better.

Best to always fly out against the wind. That's mainly so you'll have enough power to get back home on low battery but also if signal is lost and caught in too high winds, it will be blown towards you instead of away from you.

 

[DanMan32]

Also, when describing altitude, use above ground level (AGL) rather than sea level. AMSL is only useful if you happen to be flying over a 300m (900ft) cliff overlooking the sea. Even then, you probably were not legal once over the cliff. Most locals limit altitude to 120m (400ft) AGL.

 

[boblui]

At the end of the flight, the cell voltage has dropped to an extremely low level of 2 volts for 2 of the 3 cells.

Furthermore, the speed of descent increased sharply from 2 mph to 14 mph in the last 6 seconds indicating that the motor power was rapidly dropping. It is possible that the the connection was lost because the drone just shut down and free fall followed.



Suggest to do a search starting from the last known point and go towards the beach. It is just a very short distance. The last-known point is over the Sha Tsui government detention center. You will have to judge whether or not to seek assistance from the center.

 

[monohusche]

Hi boblui,

thanks for the analysis. Prison staff has already searched along/downwind from the flight path, and I have thoroughly searched the beach as well, unfortunately to no avail.

But in summary, with rapidly accelerating zSpeed while slowing down horizontally and a remaining altitude of 113m, it seems safe to assume that it travelled less than 100m horizontally before crashing down. The prison fence is exactly 100m downwind from the last position which means that the drone should be inside the prison.

But obviously, this location is the "bad luck" portion of this desaster. I can't go in there and search myself, hence it is a dead end.

Which brings me to the landing behaviour which is still bugging me.

At 10% battery level, the flight status changed to "AutoLanding" with the key objective being to bring the drone down somewhat safely before the battery runs out. Maybe, "controlled/supervised" is the better word because free fall damage to bystanders can be avoided while the pilot would at least get somewhat correct last position coordinates (even if the drone gets destroyed).

At this point, the vertical distance that needed to be travelled (=sea level altitude) within the remaining battery time was 397m. As I had used up 90% of the battery for 16min of flying, one could extrapolate the remaining window for landing to be roughly 2min. This translates to a required descent speed of 3.3m/s which is close to the max descent speed in N-mode which is 3m/s according to the specs (as per DanMan32's comment).

When the battery eventually ran out 3:40min later (i.e. it lasted much longer than expected...probably due to decreasing winds), there was still a remaining altitude of 113m. At the same time, the average sink rate (zSpeed) during the landing was 1.3m/s which is less than half of the maximum descent speed of 3m/s. Or to put it differently: With a sink speed of 1.3m/s, it would have taken more than 5min to go down to sea level. Of course, there was not that much time left.

So the drone didn't sink fast enough (to make it) even though there was clearly enough remaining "speed buffer" to descend faster and actually landing the drone in a semi-controlled fashion, rather than dropping from 113m. The main difference is that I could actually try to "search and rescue" with reliable "last known coordinates" while in this case, it is impossible to predict where it actually came down.

It might have been destroyed in both cases, but at least, the DJI Care Refresh program would have applied at least.


would be great to get more insights into how the AutoLanding algorithm is supposed to work, especially how the sink rate is being calculated. One can clearly see from the zSpeed diagram above that the drone explicitly kept it at around 2mph which (to repeat again) is significantly lower than the max speed of 6.7mph.

I also rechecked my stick movements during the "blow away" because my memory is quite blurry due to me panicking. I only used "throttle up" very briefly during the entire "landing" (=4.5secs out of 3:40min) which means that the sink speed wasn't affected by my manual actions

 

[boblui]

Seems that something is going on here. I saw your follow-up post but it was deleted twice .....

Anyway, you asked about the expected behaviour of the drone in autolanding and why the speed of descent of your drone was just about 1 m/s which is less than half of the maximum descent speed stated in the spec ( 3 m/s ).

The chart shown in my post above is not the whole picture. This one shows the whole process of autolanding which was started at a height of 100 m above the takeoff point. The descent speed was 3.0 m/s at the beginning and it started dropping when the height reached about 40 m before finally settled at 1.0 m/s



My M2P has the same behaviour :



I think starting to slow down at a height of 40 m is reasonable. It's just like driving your car. You will start slowing it down as the car gets close to the intended parking position.

 

[monohusche]

yeah, I see where you are coming from.

But there is a significant difference between

1. AutoLanding during RTH (in which case the "height above takeoff" is relevant as the drone is landing exactly in the same spot where it took off, i.e. takeoff altitude == landing altitude) versus
2. AutoLanding due to a depleted battery (in which case the drone would be forced to land in a completely random spot which has no relation to the take off spot at all, i.e. takeoff altitude != landing altitude).

The behaviour that you observed from your M2P is also a RTH scenario, i.e. the drone is slowing down the descent 50m before reaching the actual ground.

Whereas when my drone reduced the descent speed, it was still around 350m above sea level (=landing altitude).

Following your analogy of a car slowing down when approaching the parking position, the drone should have slowed down 50m above ground level instead. Interestingly enough, the downloaded csv file contains a column called height_above_ground_at_drone_location(feet) which is empty for some reason.

Not sure why....the DJI engineers obviously considered this information relevant given they included this data point into the flight log.

So, in a steady windless situation (i.e. x/ySpeed == 0 mph), replacing "height above takeoff" with "height above ground" would be equivalent to changing the home point (and thereby the target landing altitude) to the current drone location and using the new coordinates as the reference.

In a "blow away" situation like mine (i.e. x/ySpeed != 0 mph), the home point (and hence height above ground) would have to be adjusted continuously, thereby resulting in a more dynamic descent rate.

But no matter what, the objective of getting the drone down to the ground safely hasn't been achieved. I would also consider that in such an emergency situation, reaching the ground in a controlled fashion is more important than slowly descending, ultimately resulting in a free fall which is much more dangerous than a zSpeed of 3m/s

 

[monohusche]

Seems that something is going on here. I saw your follow-up post but it was deleted twice .....

Anyway, you asked about the expected behaviour of the drone in autolanding and why the speed of descent of your drone was just about 1 m/s which is less than half of the maximum descent speed stated in the spec ( 3 m/s ).

The chart shown in my post above is not the whole picture. This one shows the whole process of autolanding which was started at a height of 100 m above the takeoff point. The descent speed was 3.0 m/s at the beginning and it started dropping when the height reached about 40 m before finally settled at 1.0 m/s

View attachment 120612

My M2P has the same behaviour :

View attachment 120613

I think starting to slow down at a height of 50 m is reasonable. It's just like driving your car. You will start slowing it down as the car gets close to the intended parking position.

by the way, it seems the issue of "disappearing posts" on here is due to the fact that I edited my response which resulted in a message box ("This message is awaiting moderator approval, and is invisible to normal visitors.").

So if I don't edit, my messages are visible immediately, otherwise not :-/

 

[boblui]

Following your analogy of a car slowing down when approaching the parking position, the drone should have slowed down 50m above ground level instead. Interestingly enough, the downloaded csv file contains a column for called height_above_ground_at_drone_location(feet) which is empty for some reason.

The data fields in the .csv file downloaded from the AirData are created by AirData. They are not direct copy of those in the original flight log ie, the .TXT file you uploaded to AirData .

It is impossible for the drone to know the height_above_ground_at_drone_location unless it has the up-to-date terrain height + building height database on board or it is equipped with long-range sensors to measure the distance from the ground beneath it. I have never seen such data field in the original .TXT or .DAT flight log file. However, in off-line processing, such terrain/building height data is available to some limited extent from sources such as Google maps so AirData is able to derive the information in some cases but those information is unlikely to be up-to-date.

 

[monohusche]

The data fields in the .csv file downloaded from the AirData are created by AirData. They are not direct copy of those in the original flight log ie, the .TXT file you uploaded to AirData .

It is impossible for the drone to know the height_above_ground_at_drone_location unless it has the up-to-date terrain height + building height database on board or it is equipped with long-range sensors to measure the distance from the ground beneath it. I have never seen such data field in the original .TXT or .DAT flight log file. However, in off-line processing, such terrain/building height data is available to some limited extent from sources such as Google maps so AirData is able to derive the information in some cases but those information is unlikely to be up-to-date.

That’s a fair point. So the drone would have to rely on the downward sensors/vision system to detect obstacles and stop/hover.

but doesn’t a max descent speed of 3m/s (in N-Mode, I.e. with obstacle avoidance activated) imply that the MA2 is actually capable of sensing/stopping in time ?

horizontally, the max speed in N-Mode is much higher (12 m/s) yet obstacle avoidance is still possible (I am assuming, the same sensors/software are used in this case)

I thought, that the additional constraint for zSpeed is due to other (aerodynamic) factors, like “Vortex Ring State”.

 

[boblui]

but doesn’t a max descent speed of 3m/s (in N-Mode, I.e. with obstacle avoidance activated) imply that the MA2 is actually capable of sensing/stopping in time ?

It is definitely able to stop in time. If you pull the throttle stick all the way down to make it descend at that speed, it will stop almost instantly when the stick is released. However the effectiveness of sensing the height over the ground is subject to a lot of environmental factors. Eg. if there is fog, the sensor will not be able to detect the ground until very close to it.

horizontally, the max speed in N-Mode is much higher (12 m/s) yet obstacle avoidance is still possible (I am assuming, the same sensors/software are used in this case)

The sensors used are different. The forward / backward obstacle sensing is done by 3D cameras whereas that at the bottom is done by IR sensor which has got a range of 8 meters only. There is a pair of 3D cameras at the bottom but they are used for XY positioning in vision mode, assisting orientation sensing and whether the ground is suitable for landing

I thought, that the additional constraint for zSpeed is due to other (aerodynamic) factors, like “Vortex Ring State”.

Probably. If you observe the craft when it is descending at maximum speed, it is slightly rocking about. If it goes down faster, it may become uncontrollable at some point.

 

[monohusche]

Okay, thanks for the valuable input, much appreciated!

lets see how DJI responds to my comments

 

[DanMan32]

The AC's behavior is going to assume altitude from takeoff.
The forced landing point in battery status is dynamic based on altitude. If you were 400m above TO altitude, it would have begun descent sooner than having reached 10%. But it was figuring you were at 100m, so 10% is enough to properly land.

Now it's been found descent speed is reduced when displayed altitude reaches 50m. The AC can't know you moved off a cliff and now you have 300m to go. You might have noticed the displayed altitude went negative once it went below TO altitude. It's only within around 3 to 10m AGL that it can use the bottom sensors to find actual altitude. Before that, it's strictly barometric relative to TO.