Help me understand what happened here: hard crash due to DJI NFZ causing aircraft lose of control and hit tree

[KB9Radio]

By the way, you can't legally fly at 150 meters in the US. I know you probably weren't at that height, but your message talked about the 150 meter limit. The legal limit is 400 ft (121.9 meters).

 

[Meta4]

My concern is it this bug repeats itself next time it will be a flyaway or a total crash that wrecks it beyond hope of repair.... if indeed its a firmware bug the DJI should be responsible

It's not a "firmware bug"

Can you describe your launch spot?
What was the surface you launched from?
Did you place the drone and power up or did you move the drone after powering up?

 

[Meta4]

By the way, you can't legally fly at 150 meters in the US. I know you probably weren't at that height, but your message talked about the 150 meter limit.

What message?
He never went higher than 97 metres so whatever the message was, it wasn't relevant.

 

[KB9Radio]

What message?
He never went higher than 97 metres so whatever the message was, it wasn't relevant.

I was only trying to let the author of this thread know that you can't legally fly 150 meters in the US, nothing to do with any crash and didn't think I had indicated that it did. I don't care about the crash and had nothing to do with it. But I read it and the first thing that caught my eye was the 150 meter restriction mention, there is no such thing that I am aware of.

 

[MikeyBatts]

Was Everything updated firmware, batteries and calibrated Compass, IMU?

 

[theDRONEranger]

Hope you can find the cause of the crash. If firmware fault, DJI should get you back up and running, with minimal down time.

I, for one, am certainly glad the crash did not happen when you were flying over the traffic. I realize the google map is not real-time, but as wide as the road is, I would imagine there was a respectable amount of traffic. I am also sure you were playing leap frog to safely cross rather than maliciously jeopardizing the drivers’ and passengers’ lives at the time.

 

[slup]

This was an interesting one, really hard to find a conclusive reason here ... but I give it a try.

First of all ... if this flight had been performed with any other drone than a M2 it had been a disaster from start any way ... even without the HW failure I think it was.

The AC was launched here ... pretty sure that those concrete constructions was filled with steel. All set for a classical yaw error due to a magnetic disturbed power on spot.



Here below we see what happens in detail ... & how the M2 use it's unique function to prevent yaw error's due to magnetic disturbance.

Have never seen that high values for the magnetic field modulus (dark green graph) as here just before take off ... usually the values are around 1400-1500, but here it was above 4700. So the environment was severely magnetic disturbed.

As soon as the take off starts at 9,5sec the magmod (dark green graph) falls down toward normal levels & by that let the compass (blue graph) point correctly ... this immediately create a imuYaw & magYaw disagreement of 62 degrees. But here the M2 do it's magic & re-initializes the IMU(1) (Light green graph) at 10,8sec & on 2.1m ultrasonic height.

No real yawing was going on as the gyro (purple graph) was mainly constant.



The flight proceeded then without any oddities until 88sec when the AC came to a stop after a short throttle command to adjust the height down to 93m.

From here something is starting to go haywire ... looking at the velocity difference between the GPS & the IMU below show this clearly ...



Just seconds later the AC faces a imuYaw/magYaw dissagreement of nearly 180 degrees ... here seen by the purple graph on a 180/180 Y-axis.



And here on a sat map where the green bar symbolize imuYaw pointing direction & the yellow the magYaw ...



So what went suddenly wrong ... up on 93m height ..?

In order to check off if it was the IMU or the compass that failed I've below first put up a comparison between the unwrapped gyro together with the unwrapped imuYaw ... can be somewhat difficult to see but firstly the graphs aren't similar shape wise ... secondly, the gyro rotates nearly 2 times more degree wise compared to the imuYaw.



Then I compared the imuYaw with the magYaw in order to conclude which of the 3 (IMU, Gyro or Compass) that deviate degree wise regarding the amount of turning ... this shows that the magYaw & the gyro are reasonably in agreement ... & by that should be showing correct, It also shows that the imuYaw(1) rotate half of what the others register.

This is what causes the big nearly 180 degree disagreement between the imuYaw & the magYaw ... & as the turning is in reality twice as large as what the IMU think's, it now doesn't have knowledge of the real heading & will with this counteract with the wrong motors & fail in position hold ... making it flyaway in speeds exceeding the spec.

So was the IMU(1) failure the root cause ... or was it actually something else that failed that in the end made these consequences?

Usually only one of the 2 IMU's fail ... but if we check off how well both of the IMU's are tracking with the compass (which follows the gyro well) we see this ... The blue graph show the re-initialized imuYaw(1), it shows a very small disagreement on approx. a couple degrees ... this up to 88sec into the flight. The red graph shows the other one, IMU(0) ... it doesn't track with the magYaw at all to begin with, but as the time goes it is slowly corrected by the gyro & compass values & around 60sec into the flight the disagreement is small enough so it wouldn't set off a Yaw error flyaway if it had been the active IMU.

But strangely also IMU(0) goes heywire at 88sec and tops out on a imuYaw/magYaw disagreement on 110 degrees ...



Looking deeper then ...

During below period the AC is drifting & rotating uncommanded ... even though no yaw error have started yet ...



Here below we see that the AC is rolling over to left with a slight up pitch ... & moving at around 2m/s during this period on a couple of seconds before the yaw error starts.



Checking into the motor data shows a odd behavior for the left front motor ... both rpm, command & current draw wise.

RPM:



Command:



& Current draw:



So even though I'm not 100% sure I think the root cause to this incident was on a level above the IMU ... a failing Flight controller? ... this as both IMU's suffered errors & that the motors was commanded without a heading failure initially, no stick inputs in very light winds. Never the less ... this should fall on DJI, contact them & they will guide you to what they need.

Then lastly ...

What triggered initial forced autoland?

The area I was flying under only had a NFZ altitude restriction of 150meters, I was well under that height at all times.

Don't know if you was aware of that the altitude restriction zone of 60m was starting just on the other side of the road ... when you ascended up after take off & turned towards the bridge you got really close to it ... can't say how precise DJI fly zone maps are ... but here is how it was.

 

[boblui]

What triggered initial forced autoland?

Usually the .DAT file gives some hint on the reason behind but for this one, nothing at all. Just a few days ago, another member reported the M2 going into autolanding and the symptoms are exactly the same as those in your case ( Mavic 2 Pro crashed with IMU switch - what went wrong? ) . The common symptoms are :

1) the reason for autolanding is indicated in the .DAT file
2) autolanding was preceded by the "Not Enough Force/ESC Error" warning.

Not sure if this is a new feature of the new M2 firmware ( .670 ). I have tried to reproduce it with my M2 but it didn't happen.

Even if IMU disagree, why would it go up to 56mph? during forced autoland?

Not being able to sense the direction ( or more technically, the yaw angle ) correctly is a common reason for fly away. When the craft receives no commands to move horizontally, ie, during hovering or landing, it will try to hold it's GPS position and in doing so, it needs to know the direction it is pointing to correctly. Imagine this :

- the drone is at position A and because of the wind it has drifted to position B
- B is to the south of A
- the drone decided that it should move north to get back to A
- If the direction sensed by the IMU is off by 180 degrees , the drone will actually be moving south without realizing it.
- as the result, the drone will be moving further and further away from A
- seeing the position error increasing, the drone will accelerate to correct the error more quickly.
- a vicious cycle will then be developed making the drone fly straight away . That's why your drone went to 56 mph by itself.

How did you read the .DAT?

I use CsvView that can be downloaded from here : CsvView Introduction

 

[adiru]

Thanks for the detailed, I will reread it a few more times and digest the info... For sure I will reach out to dji about this. Checking my previous logs on airdata Ive never encounted the ESC error until recently (the crash incident) and this was right after the firmware update.

Also, I have taken off and launched from this exact location dozens of time, in fact this isnt the first time I flew this exact flight route, and my intent was to get into position and take some panoroma pictures but before I could do so it started autolanding, which it never used to before.

I wonder if this flyaway behavior maybe wouldnt have happened had autoland not kicked in... back month ago the first time I decided to fly at this spot I checked DJI fly safe website and it listed 150m max alt restriction on both sides etc and I did not see a 60m lower restriction nearby the web map. Even after the crash I went back to the DJi flysafe map and see 150m as the only alt restriction, Im not seeing a 60m restriction. I did recently update the NFZ map, maybe it changed and there is a discrepancy between the map database dji updated to the aircraft and that of whats listed on their website for this location but in any case, see my first page original post the screenshot from yesterday is showing 150m on both sides, im not seeing a 60m lower restriction. My gps was full bars at all times it was clear weather no winds so hard to believe it could be due to gps margin of error when in the past I flew this same path, from same spots, and no forced autolandings...

In any case other than cosmetic damage the mavic still intact and flyable, ( knock on wood so far ) luckily I think the tree leaves and branches slowed it down before it crashed onto ground.

Im reaching out to dji with everything to provide them with info and I will see what they say, I really hope the recent firmware update was not somehow a contributing factor, directly or indirectly to this, but if it was a flight controller or other hardware problem then dji needs to take a look to fix this.

Thanks again

 

[Meta4]

I wonder if this flyaway behavior maybe wouldnt have happened had autoland not kicked in

The autoland was not the cause, it was just coincidental as explained above.

I really hope the recent firmware update was not somehow a contributing factor, directly or indirectly to this, but if it was a flight controller or other hardware problem then dji needs to take a look to fix this.

It had nothing to do with firmware.
If it did this would be happening all over the place.
It was due to your choice of launching spot, so Ill ask again (because it's important).
Can you describe your launch spot?
What was the surface you launched from?
Did you place the drone and power up or did you move the drone after powering up?

 

[slup]

...It was due to your choice of launching spot...

The yaw error that was created initially after take off was fixed just a couple seconds later ... this as it was a Mavic 2. The re- initialization of the imuYaw is clearly seen in the DAT log & depicted in the first chart in post #27.

So this later incident at 88sec up on 93m height wasn't a ordinary yaw error due to a magnetic disturbed power on spot at all ...

Can you describe your launch spot?
What was the surface you launched from?
Did you place the drone and power up or did you move the drone after powering up?

All info about this in the beginning of post #27 ... the DAT log shows that the initial magMod readings was very high & dropped down immediately after leaving the take off spot. If the flight had been done with any other AC than a M2 the later suspected HW failure hadn't been noticed due to a sticking yaw error & following uncontrolled flight ... but as it was a M2 it was sorted out.

I wonder if this flyaway behavior maybe wouldnt have happened had autoland not kicked in...

Don't think that the autolanding had anything to do with what happened ... according to the log the landing started after that the AC oddities started.

...see my first page original post the screenshot from yesterday is showing 150m on both sides, im not seeing a 60m lower restriction.

In the pic in your first post the 60m altitude zone is clearly shown ... see the grey line. You need to click on the upper side of that line to get the info square about that.

 

[Meta4]

The yaw error that was created initially after take off was fixed just a couple seconds later
... So this later incident at 88sec up on 93m height wasn't a ordinary yaw error due to a magnetic disturbed power on spot at all ...

So there was a genuine yaw error condition that was "fixed"and soon after there was a similar but unrelated mysterious hardware problem that was unnoticed earlier.
And you're not concerned at the amazing coincidence and are attributing the issue to a rare and mysterious hardware problem?

All info about this in the beginning of post #27

I can read but still haven't heard from the OP in his own words despite asking several times.

 

[slup]

So there was a genuine yaw error condition that was "fixed"and soon after there was a similar but unrelated mysterious hardware problem that was unnoticed earlier.
And you're not concerned at the amazing coincidence and are attributing the issue to a rare and mysterious hardware problem?

Yeah ... after looking through the DAT log I'm pretty confident about that the initial short (2sec) yaw error didn't have any thing to do with what happened over a minute later in the flight.

Have seen the M2's imuYaw re-initialization several times before ... a really neat functionality all AC models should have, but have never seen that this action have made both IMU's fail simultaneously & locked one motor keeping it's revs constant way above the rest for no reason as a result.

 

[BudWalker]

This was an interesting one, really hard to find a conclusive reason here ... but I give it a try.

First of all ... if this flight had been performed with any other drone than a M2 it had been a disaster from start any way ... even without the HW failure I think it was.

The AC was launched here ... pretty sure that those concrete constructions was filled with steel. All set for a classical yaw error due to a magnetic disturbed power on spot.

View attachment 112016

Here below we see what happens in detail ... & how the M2 use it's unique function to prevent yaw error's due to magnetic disturbance.

Have never seen that high values for the magnetic field modulus (dark green graph) as here just before take off ... usually the values are around 1400-1500, but here it was above 4700. So the environment was severely magnetic disturbed.

As soon as the take off starts at 9,5sec the magmod (dark green graph) falls down toward normal levels & by that let the compass (blue graph) point correctly ... this immediately create a imuYaw & magYaw disagreement of 62 degrees. But here the M2 do it's magic & re-initializes the IMU(1) (Light green graph) at 10,8sec & on 2.1m ultrasonic height.

No real yawing was going on as the gyro (purple graph) was mainly constant.

View attachment 112017

The flight proceeded then without any oddities until 88sec when the AC came to a stop after a short throttle command to adjust the height down to 93m.

From here something is starting to go haywire ... looking at the velocity difference between the GPS & the IMU below show this clearly ...

View attachment 112019

Just seconds later the AC faces a imuYaw/magYaw dissagreement of nearly 180 degrees ... here seen by the purple graph on a 180/180 Y-axis.

View attachment 112020

And here on a sat map where the green bar symbolize imuYaw pointing direction & the yellow the magYaw ...

View attachment 112021

So what went suddenly wrong ... up on 93m height ..?

In order to check off if it was the IMU or the compass that failed I've below first put up a comparison between the unwrapped gyro together with the unwrapped imuYaw ... can be somewhat difficult to see but firstly the graphs aren't similar shape wise ... secondly, the gyro rotates nearly 2 times more degree wise compared to the imuYaw.

View attachment 112022

Then I compared the imuYaw with the magYaw in order to conclude which of the 3 (IMU, Gyro or Compass) that deviate degree wise regarding the amount of turning ... this shows that the magYaw & the gyro are reasonably in agreement ... & by that should be showing correct, It also shows that the imuYaw(1) rotate half of what the others register.

This is what causes the big nearly 180 degree disagreement between the imuYaw & the magYaw ... & as the turning is in reality twice as large as what the IMU think's, it now doesn't have knowledge of the real heading & will with this counteract with the wrong motors & fail in position hold ... making it flyaway in speeds exceeding the spec.

So was the IMU(1) failure the root cause ... or was it actually something else that failed that in the end made these consequences?

Usually only one of the 2 IMU's fail ... but if we check off how well both of the IMU's are tracking with the compass (which follows the gyro well) we see this ... The blue graph show the re-initialized imuYaw(1), it shows a very small disagreement on approx. a couple degrees ... this up to 88sec into the flight. The red graph shows the other one, IMU(0) ... it doesn't track with the magYaw at all to begin with, but as the time goes it is slowly corrected by the gyro & compass values & around 60sec into the flight the disagreement is small enough so it wouldn't set off a Yaw error flyaway if it had been the active IMU.

But strangely also IMU(0) goes heywire at 88sec and tops out on a imuYaw/magYaw disagreement on 110 degrees ...

View attachment 112023

Looking deeper then ...

During below period the AC is drifting & rotating uncommanded ... even though no yaw error have started yet ...

View attachment 112024

Here below we see that the AC is rolling over to left with a slight up pitch ... & moving at around 2m/s during this period on a couple of seconds before the yaw error starts.

View attachment 112025

Checking into the motor data shows a odd behavior for the left front motor ... both rpm, command & current draw wise.

RPM:

View attachment 112026

Command:

View attachment 112027

& Current draw:

View attachment 112028

So even though I'm not 100% sure I think the root cause to this incident was on a level above the IMU ... a failing Flight controller? ... this as both IMU's suffered errors & that the motors was commanded without a heading failure initially, no stick inputs in very light winds. Never the less ... this should fall on DJI, contact them & they will guide you to what they need.

Then lastly ...



Don't know if you was aware of that the altitude restriction zone of 60m was starting just on the other side of the road ... when you ascended up after take off & turned towards the bridge you got really close to it ... can't say how precise DJI fly zone maps are ... but here is how it was.

View attachment 112029

I agree this incident was not caused by a geomagnetically distorted launch site . @sar104 did some experiments that showed the M2 can and does recover from a geomagnetically distorted launch site by adjusting Yaw after launch. This one is pretty impressive. The magnetic field strength was so strong that I wonder if it wasn't just a bending of the available geomagnetic field - was there a magnet close to the M2?

Anyway, another possibility is that the propulsion problem caused the incorrect IMU1:Yaw to occur. Looking at the Z axis commanded vs actual angular velocities.

Although the commanded was being held steady the speed and current data was synchronized with the actual angular velocity excursions.

I'm thinking it's possible the leftFront prop was partially damaged and controlled flight was still possible but with instability in roll, pitch and yaw. Since there were no significant control inputs the FC concluded that Yaw needed to be adjusted.

Just a theory.

 

[TomSull]

The autoland was not the cause, it was just coincidental as explained above.

It had nothing to do with firmware.
If it did this would be happening all over the place.
It was due to your choice of launching spot, so Ill ask again (because it's important).
Can you describe your launch spot?
What was the surface you launched from?
Did you place the drone and power up or did you move the drone after powering up?

Unfortunately, it CAN be the firmware. Just because it's not a commonly encountered issue doesn't mean it's not a firmware bug. Having written and debugged networking drivers and protocol stacks (years go), when you have multiple threads of execution in a complex system, you can always have bugs that only revel themselves when a combination of real time events occur. You simply can't rule out a firmware bug just because the incidence of occurrence is rare, but hopefully, it's not; concurrency bugs can be very difficult to find and eliminate. I've encountered and fixed quite a few of these.

 

[slup]

A bit off the subject as such but just to show the usefulness of the mobile device DAT log ... to the questions put up earlier in the thread about:

-Can you describe your launch spot?
-What was the surface you launched from?
-Did you place the drone and power up or did you move the drone after powering up?

All relevant questions to get answered if a yaw error is suspected due to a magnetic disturbed power on spot (which is initially somewhat relevant to this incident)

If knowing that the imuYaw (red) & the magYaw (green) is initialized to the same degree value at power on ... and that the TotalGyroZ (blue) always start up at 0, we can here below in the DAT log from the incident see that it's what have happened ... & that means that the mobile device with the app running was attached to the RC, with in turn was connected to the AC during powering on & could record from the beginning.

Putting in the gyroComposit (darker green) gives us info about any AC movements in all directions combined ... here below it is flat lining until the motors is started in the blue background stripe in the chart ... meaning the AC was stationary between the power on & motor start with following take off.

Further adding in the magmod (purple) gives us a value of the magnetic field modulus during the power on & the following stationary period until take off. If knowing that a normal magmod value usually is around 1300-1500 the reading here of 4736 catches your attention ... that high value is maintained until the AC starts to gain height after take off. Already on a couple meters height (black) the magmod value have fallen considerably ... clearly indicating that the AC have left a highly magnetic area behind. (this incident's magmod reading is very clear though ... usually a bit more subtle with lower value differences).

By this we have read out the important answers to above questions ... that can induce a yaw error due to a magnetic disturbed power on spot.

 

[JimThomson]

Thank you this was a very revealing issue. Because I had exactly the same issue this year. In my case the drone damaged required me to send it back to DJI. However with all the data in front of them they did not admit fault. They did take their sweet time looking at the issue, so I am sure they have all the data in front of them to do an update to correct this issue.

 

[JimThomson]

Thank you this was a very revealing issue. Because I had exactly the same issue this year. In my case the drone damaged required me to send it back to DJI. However with all the data in front of them they did not admit fault. They did take their sweet time looking at the issue, so I am sure they have all the data in front of them to do an update to correct this issue.

 

[ajkm]

Irrespective of issues of Yaw error, I would note with concern that you have used that location to launch a drone “dozens of times before.” To take off that close to a substantial 4-lane road and what certainly appears to be one with considerable traffic would, imho, be irresponsible and asking for problems (and a potential accident). If the drone had had a flyaway earlier in the flight, it could very easily have impacted (and I don’t mean physically, although that is also possible) on the safety of the traffic. If it had hit a bridge support and dropped onto the roadway, it could have caused significant damage.

I would also second the comment and question why the OP would mention 150m as the “altitude restriction” when 120m is the national (and at this stage, possibly international in many places) standard restriction.

 

[In The Zone]

So I was flying the other day in an area that has no other NFZ restrictions other than an altitude restriction of 150 meters. Right as I'm about to come in for a landing, the Mavic 2 seems to have a mind of its own, and basically flew a horizontal track at immense speed across the field and struck a tree at high speed before crashing to the ground causing damage to the foot and the battery completely popped out in the process.


View attachment 111986


Why did it do this instead of coming straight down or allowing me time to land it myself? I was handflying it and taking pictures and it was clear day, perfect weather, no winds, and everything was fine (got full GPS lock etc) no obstructions and wasn't flying near buildings or anything and then it started complaining about entering no fly zone, however where I'm at it was an altitude restriction and I was flying WELL UNDER the 150 meter restriction so that shouldnn't have even been a factor or point of contentionn at all...

In any case, what caused the crash was the Mavic going crazy and suddenly decided to basically track horiztonally on the ground at high speed until it struck a tree...

Later I tried to get export of the logs from the aircraft itself but I tried on Windows 7 machine, and two different Windows 10 machines, and all were brand new installs of the latest DJI Assistant app (for desktop PC) for the Mavic 2 version (I also tried the generic old DJI Assistant 2 app etc) but it will just spin and spin and not ever actually show me any logs to even allow me to export to provide to DJI.

I know these logs on the aircraft are encrypted but I should at least be able to export them to send to DJI upon request and its not even letting me do that!



View attachment 111987

That really SUCKS but if you can't produce your flight logs this will be labeled as pilot a

So I was flying the other day in an area that has no other NFZ restrictions other than an altitude restriction of 150 meters. Right as I'm about to come in for a landing, the Mavic 2 seems to have a mind of its own, and basically flew a horizontal track at immense speed across the field and struck a tree at high speed before crashing to the ground causing damage to the foot and the battery completely popped out in the process.


View attachment 111986


Why did it do this instead of coming straight down or allowing me time to land it myself? I was handflying it and taking pictures and it was clear day, perfect weather, no winds, and everything was fine (got full GPS lock etc) no obstructions and wasn't flying near buildings or anything and then it started complaining about entering no fly zone, however where I'm at it was an altitude restriction and I was flying WELL UNDER the 150 meter restriction so that shouldnn't have even been a factor or point of contentionn at all...

In any case, what caused the crash was the Mavic going crazy and suddenly decided to basically track horiztonally on the ground at high speed until it struck a tree...

Later I tried to get export of the logs from the aircraft itself but I tried on Windows 7 machine, and two different Windows 10 machines, and all were brand new installs of the latest DJI Assistant app (for desktop PC) for the Mavic 2 version (I also tried the generic old DJI Assistant 2 app etc) but it will just spin and spin and not ever actually show me any logs to even allow me to export to provide to DJI.

I know these logs on the aircraft are encrypted but I should at least be able to export them to send to DJI upon request and its not even letting me do that!



View attachment 111987

That really SUCKS but if you can't produce your flight logs this would be considered pilot error. Possibly compass calibration was not done or not done correctly is the only thing I can think of.