DJI Air stopped taking instructions and crashed

[Sam789]

Hi Experts,
Yesterday (09-Oct-2021) while flying my drone it stopped taking instructions from controller. And after a while, it automatically started steering left and crashed into a tree. Fortunately, I don't see significant damage but I am too scared to fly it off again before checking what really happened. Here are the details -

1. I flew drone yesterday 4 times. The first time, there were few moments when gimbal was acting weird and tilting directions automatically.
2. The 2nd time it was fine.
3. The 3rd time t the drone was not responding for a second or 2 in mid of flight but then was working fine.
4. This was the worst. I was flying over a creek and shortly after the flight drone stopped responding completely while hovering over the creek. It was not too far from me and no obstacle between me and drone. I tried steering up and and side from the creek but it was not responding. The suddenly, it started steering side ways at a high speed and struck a tree. I was lucky that drone didn't crashed in water but landed on a foilage which must have reduced the impact. Here is the flight log DJI Flight Log Viewer - PhantomHelp.com

 

[eEridani]

DJI Flight Log Viewer | Phantom Help

Upload and view flight logs from your DJI drones

www.phantomhelp.com

Taking off before enough GPS sats were in view, so Home wasn't set until 41 seconds into the flight, those alone are conditions for a wild ride. Max altitude was set quite low; too. I'm thinking you were very lucky the drone didn't fly off into the sunset or decide to land in the river where it had set the Home point.

At 47 seconds your sticks were spinning the drone around and in full reverse (click through the rows in the link above). Can't say for sure why it continued at speed after you let go of the sticks - I'm guessing some GPS heading vs magnetic compass difference. But I'm a novice.

 

[Sam789]

DJI Flight Log Viewer | Phantom Help

Upload and view flight logs from your DJI drones

www.phantomhelp.com

Taking off before enough GPS sats were in view, so Home wasn't set until 41 seconds into the flight, those alone are conditions for a wild ride. Max altitude was set quite low; too. I'm thinking you were very lucky the drone didn't fly off into the sunset or decide to land in the river where it had set the Home point.

At 47 seconds your sticks were spinning the drone around and in full reverse (click through the rows in the link above). Can't say for sure why it continued at speed after you let go of the sticks - I'm guessing some GPS heading vs magnetic compass difference. But I'm a novice.

Thanks for the pointers. Lesson learned. Since I rarely used RTH, I didn't used to wait till the time home was set.Yeah, I am still confused why it kept on going even when I let go off the sticks. Also, My max flight altitude is set at 400m. Not sure why the logs and screen showed max flight altitude reached

Also, I would really appreciate if you can provide some context on how you are able to interpret these logs. I am not sure how you can differentiate between what sticks were doing vs what drone was reacting.

 

[Meta4]

My max flight altitude is set at 400m. Not sure why the logs and screen showed max flight altitude reached

You launched without waiting for GPS and for the drone to record its homepoint.
You flew for 41 seconds before the drone acquired full GPS signal and was able to record a homepoint (but not where you launched from).

The reason you thought it stopped responding is that there is an altitude restriction when you fly without GPS (that's Atti Mode).
It's explained on p48 of your manual:
Height is restricted to 16 feet (5 meters) when the GPS signal is weak and Downward Vision System is activated.
Height is restricted to 98 feet (30 meters) when the GPS signal is weak and Downward Vision System is inactivated

Your VPS sensors were activated, so the altitude topped out at 5 metres and the drone wouldn't climb any higher, without acquiring good GPS data.

The crash happened at 48.7 seconds and the data after then contains some false values as a result of the impact.

 

[eEridani]

Control input is shown on the PhantomHelp website I linked. That link is your decoded flight log. You can click the rows to see the control positions on the right along with drone orientation.



Then, if you want to dig deeper the CSV file that you can download from PhantomHelp.com, you can find way too much info on what is happening, where the drone is headed, how fast, etc. A lot of the analysis is based on experience, there are others here with far more time looking at logs than me, I am outright noob.

So I'm winging it - lol

If you want to play with looking at your logs from scratch, start here:

DJI Flight Log Viewer | Phantom Help

Upload and view flight logs from your DJI drones

www.phantomhelp.com

 

[slup]

From take off to 11,5sec into the flight your craft had horizontal hold by means of the VPS sensors on the belly of your MA1 ... was in OPTI mode, 5 satellites locked but with a nav health of 0 from max 5 ... meaning the flight controller disregarded the sat position & considered it to be unreliable.

At 11,5sec ... then probably out over the water your MA1 went into ATTI mode as the VPS sensors no longer could lock on to the surface below. With ATTI mode you didn't have any horizontal hold at all & no auto braking when releasing the sticks ... the craft will mainly drift with what ever is affecting it ... like wind.

At 41,8sec your MA1 had acquired 9 satellites & the nav health was up on 4 ... in this moment your HP was recorded. Here you was hovering over the water.

So ... so far nothing out of the ordinary, you made a mistake when you took off in a hurry without a proper HP recorded ... if you had lost the RC connection your craft had failsafed & RTH and landed in the water as your failsafe action was set to GoHome.

But none of the above explain the uncommanded movement that followed soon after that the MA1 had got a proper GPS position though ... my belief is that you being in ATTI mode earlier had saved you from what's described below as you hadn't any horizontal hold.

From the path it took & later ended up in a tree, I suspect that you also had a yaw error due to powering on your MA1 in a magnetic disturbed spot there on the bridge.

In order to say for sure ... & give you another lesson learned we need to access the mobile device .DAT log from the flight. It's located in the mobile device you flew with ... in the same place as the .TXT log you already have shared, but in a sub-folder there named MCDatFlightRecords. The correct .DAT log ends with FLY085.DAT. Retrieve it and attach it in a new post here.

 

[Phantomrain.org]

You launched without waiting for GPS and for the drone to record its homepoint.
You flew for 41 seconds before the drone acquired full GPS signal and was able to record a homepoint (but not where you launched from).

The reason you thought it stopped responding is that there is an altitude restriction when you fly without GPS (that's Atti Mode).
It's explained on p48 of your manual:
Height is restricted to 16 feet (5 meters) when the GPS signal is weak and Downward Vision System is activated.
Height is restricted to 98 feet (30 meters) when the GPS signal is weak and Downward Vision System is inactivated

Your VPS sensors were activated, so the altitude topped out at 5 metres and the drone wouldn't climb any higher, without acquiring good GPS data.

The crash happened at 48.7 seconds and the data after then contains some false values as a result of the impact.

So if the drone is above the restricted height when it enters Atti mode other than it being in Atti mode is it compromised in any other way ?

Phantomrain.org
Gear to Fly in the Rain.

 

[eEridani]

@slup - Maybe you can enlighten us on why the drone yaw and yaw360 were out of sync early on and finally corrected by rotating the drone so they aligned (towards end of flight). If launched from the bridge, that might explain some error, though, 180 off seems unlikely. But I'm still learning the DJI foibles.... lol.

 

[slup]

@slup - Maybe you can enlighten us on why the drone yaw and yaw360 were out of sync early on and finally corrected by rotating the drone so they aligned (towards end of flight). If launched from the bridge, that might explain some error, though, 180 off seems unlikely. But I'm still learning the DJI foibles.... lol.

Don't follow you I'm afraid ... nothing regarding the rudder input & the AC reaction on the yaw axis was out of sync, all stick inputs generated a equivalent rotation of the AC ... besides just in the end from about 48,7sec ... that uncommanded movement was most probably related to the crash into the tree.

It's all shown directly from the TXT log here ...



What's concerning though, is the totally uncommanded horizontal movement during a speed ramp just after that a proper GPS position had been acquired.

Comparing the deviations between the GPS & IMU velocities show big deviations in both Northerly & Easterly direction (should be very near to 0m/s) ... this usually mean a yaw error (wrongly initiated IMUYaw) due to a power on in a magnetic disturbed spot which deflected the compass or a IMU error. In order to determine which ... & say anything about the actual cardinal direction the AC was pointing the DAT log is needed.

 

[BudWalker]

Don't follow you I'm afraid ... nothing regarding the rudder input & the AC reaction on the yaw axis was out of sync, all stick inputs generated a equivalent rotation of the AC ... besides just in the end from about 48,7sec ... that uncommanded movement was most probably related to the crash into the tree.

It's all shown directly from the TXT log here ...

View attachment 136347

What's concerning though, is the totally uncommanded horizontal movement during a speed ramp just after that a proper GPS position had been acquired.

Comparing the deviations between the GPS & IMU velocities show big deviations in both Northerly & Easterly direction (should be very near to 0m/s) ... this usually mean a yaw error (wrongly initiated IMUYaw) due to a power on in a magnetic disturbed spot which deflected the compass or a IMU error. In order to determine which ... & say anything about the actual cardinal direction the AC was pointing the DAT log is needed.

View attachment 136348

I suspect that @eEridani was referring to the difference between yaw and yaw[360]. Yaw has the range [-180°, 180°] whereas yaw[360] has the range [0°, 360°]. So yaw = -90° translates to yaw[360] = 270°.

 

[slup]

I suspect that @eEridani was referring to the difference between yaw and yaw[360]. Yaw has the range [-180°, 180°] whereas yaw[360] has the range [0°, 360°]. So yaw = -90° translates to yaw[360] = 270°.

Yeah ... I suspected that but couldn't figure out from where he read off the Yaw value on a 360 scale. But apparently he used the csv file from PhantomHelp ... it's additional in their log conversion.

@eEridani ... below you have the yaw angle from the csv, one expressed on a 180 degree scale & another on a 360. Have placed the chart marker as close to zero I could get. North is on both scales 0 ... on the 180 scale CCW to South is negative, & CW to south is positive ... meaning that -179,9 degrees & 179,9 degrees both is nearly straight South & creates that big jump in the graph.

On the 360 scale the same nearly straight South should be 179,9 degrees & 180,1 degrees counted CW from North (0 degrees) ... on this scale no big jump will occur when the yaw direction passes South.

 

[eEridani]

Here's the data I am referring to: where the drone yaw and yaw360 swap 180; about when the gps signal becomes solid, then not. lol. Drone goes from gps to atti, too. a bit weird.




Bud might have answered my question ... I'll need to let the info soak in a bit longer.

 

[BudWalker]

Here's the data I am referring to: where the drone yaw and yaw360 swap 180; about when the gps signal becomes solid.
View attachment 136353

Starting at 0° sweep CCW to -155.7°. That results in the same direction as starting at 0° and sweeping CW to 204.3°.

 

[eEridani]

ps: Can I assume yaw and yaw360 come from the same place? Or are the two values derived independently?

And - probably what I should have asked in the first place - is there a glossary of these CSV values I can refer to?

 

[slup]

Here's the data I am referring to...

It's nothing out of sync there ... Yaw & Yaw360 is expressed on different axis.

Both indicate a CCW rotation ... the Yaw starts on -155,7 degrees & Yaw360 204,3 degrees. Both these values indicate a South Westerly direction.



When the CCW rotation stops both values are the same ... this due to that both scales count positive from 0 degrees (North) & haven't ended up before 180 degrees counting CW from 0.

 

[eEridani]

@slup - my mind goes berserk when faced with figuring out what direction a set of gears turn ... think this is is a similar problem for me. I was designing circuits and repairing electrical appliances at age 10 - so no clue why simple mechanics confound me.

Thanks.

 

[slup]

ps: Can I assume yaw and yaw360 come from the same place? Or are the two values derived independently?

It's the same just expressed on 2 different scales.


Look at it this way ... Below a full turn, the inner values are Yaw, the outer are Yaw360

And - probably what I should have asked in the first place - is there a glossary of these CSV values I can refer to?

Mostly live & learn I'm afraid ...

 

[eEridani]

It's the same just expressed on 2 different scales.
Mostly live & learn I'm afraid ...

Thanks again. I made assumptions about the data sources - mag compass vs gps heading. I guess I'll need to start my own field glossary - two many variables to keep straight.

ps: hopefully someone will catch that play ... lol.

 

[Sam789]

From take off to 11,5sec into the flight your craft had horizontal hold by means of the VPS sensors on the belly of your MA1 ... was in OPTI mode, 5 satellites locked but with a nav health of 0 from max 5 ... meaning the flight controller disregarded the sat position & considered it to be unreliable.

At 11,5sec ... then probably out over the water your MA1 went into ATTI mode as the VPS sensors no longer could lock on to the surface below. With ATTI mode you didn't have any horizontal hold at all & no auto braking when releasing the sticks ... the craft will mainly drift with what ever is affecting it ... like wind.

At 41,8sec your MA1 had acquired 9 satellites & the nav health was up on 4 ... in this moment your HP was recorded. Here you was hovering over the water.

So ... so far nothing out of the ordinary, you made a mistake when you took off in a hurry without a proper HP recorded ... if you had lost the RC connection your craft had failsafed & RTH and landed in the water as your failsafe action was set to GoHome.

But none of the above explain the uncommanded movement that followed soon after that the MA1 had got a proper GPS position though ... my belief is that you being in ATTI mode earlier had saved you from what's described below as you hadn't any horizontal hold.

From the path it took & later ended up in a tree, I suspect that you also had a yaw error due to powering on your MA1 in a magnetic disturbed spot there on the bridge.

In order to say for sure ... & give you another lesson learned we need to access the mobile device .DAT log from the flight. It's located in the mobile device you flew with ... in the same place as the .TXT log you already have shared, but in a sub-folder there named MCDatFlightRecords. The correct .DAT log ends with FLY085.DAT. Retrieve it and attach it in a new post here.

Thanks a ton for your detailed analysis. I see lot of replies on the thread but they are beyond my grasp. Here is the DAT log

 

[slup]

... Here is the DAT log

Yeah ... besides that you took off without waiting for a recorded HP ... which could have turned out to be fatal if you had lost the AC/RC connection, you also powered on your MA1 near something magnetic that deflected the compass & by that initialized the IMU Yaw into a wrong direction (your MA1 mainly thought that it was pointing in a direction that wasn't true in reality).

As you had such a bad GPS position in the beginning your MA1 didn't have any horizontal positional hold ... meaning that the flight controller didn't intend to keep any position at all by means of using different motors to counter a possible drift, it instead only kept the height & if it were any horizontal drift it would just let it drift & leave that to you.

But as soon as you got a proper satellite lock with a good navhealth the MA1 started to hold position & started to counter effects of the wind there by using different motors to correct any positional errors. The only problem was that the MA1 didn't have the true facts about the heading direction ... so when a drift occurred it activated the wrong motors & by that just made the positional error larger ... & tried again, & again, but the error just got bigger & it started to ramp up the speed & flew away.

It's easily seen in the chart from the DAT log here below ...

The flight starts in the left side in the chart, the green graph is the IMUYaw (wrongly initialized), the red one, magYaw (compass). The black graph is the magmod (magnetic field).

To the left, before take off the green & red agrees rather OK (not exactly the same values which indicate that you powered on the MA1 before the RC & app) as the compass still is located in the magnetic disturbance.

Then comes the pink & green background stripes which is motor start & take off ... after that it's clear that your MA1 leaves the magnetic disturbed area ... the black magmod changes largely & the red (compass) correct itself, but the green IMUYaw remains wrong.

Then comes the broader blue background stripe which is ATTI mode & a bit later at 41,912sec after take off you get GPS lock & you gets the full effect of the Yaw error as the flight controller start to provide horizontal hold.

The blue graph is a calculation to more clearly see the deviation between the IMUYaw & magYaw ... at most it reaches 87 degrees (at 43,8sec). A nearly 90 degrees deviation usually results in a circular flyaway path ... exactly what we see here in your flight.

(Click on the chart to make it larger)


So the take away from this is that this whole incident was due to pilot errors ... nothing else. It consisted of 2 pilot errors out of both could have killed your MA1.

1.
Always wait until a HP is recorded (the lady voice announce clearly when it's been recorded) before you fly out horizontally from your take off spot. Otherwise it will be recorded in a unknown spot along the flight path when the navhealth reaches a sufficient level ... & in a case of a AC/RC disconnect the drone will return to that spot & not to where you took off ... in your flight the HP was located over water.

2.
Then ... after powering on the drone ALWAYS check the drone icon on the map in the app & confirm if that icon is pointing in the same direction relative other map objects as the drone does in reality ... if it doesn't, power the drone down, move away to another take off spot quite a distance from the first & power up again & repeat. In this way you can be sure that all is good & the IMU have been initialized by an undisturbed compass & you don't have to see your drone flyaway at speed.