Very strange issue with Mavic Air

[Carsco]

HI.
I was flying my Mavic Air to a train station 3km away.
See the screen recorder, please:
Video screen recorder

(0'49") After reach the station I stopped at 4km and then turned around and went back.

(1'02") Suddenly the camera drone lost its horizon and then, after a sharp hit (1'13"), it lost its GPS signal entering ATTI mode and fell 10 meters.

(1'26") Then it recovered, but no camera horizon, (1'41") then another strike, (1'44") then I activated RTH.
(1'49") After a few seconds another strike.
(1'58") At this point, during a good part of the RTH, the drone remained with the camera horizon not leveled, and made the return journey by walking sideways. All movements are not made by me, but by the drone itself!
See the map: aircraft seems proceed with bow forward but it walks by side!
See the camera horizon!

(2'54") I raise the camera. The aircaft continues to yaw left (I cannot do nothing... I'm in RTH).
(3'38") Aircraft tries to yaw in right direction but loses horizon.
I'm not sure of real direction... I have to believe the map and the decreasing distance!
I start to control the altitude, going to 25-30m (I'm on a high hill).

(3'58") Aircraft returns to yaw left.
(7'37") Aircraft starts to yaw correctly to right but camera loses horizon.
(8'10") Right yaw, right camera horizon.

No other issue from this point.
I stopped the RTH and recoved aircraft by hand landing.

After a few minutes, after battery change, I flew for 2 or 3 minutes in sport mode stressing the aircraft. No issue.
All normal!

What's happened?
Bird strike? Propellers (Master Airscrew) are perfect!
IMU?
Compass?

It was a beautiful day, there was no wind, app doesn't warns me anytime.
Anyway, the attitude meter (low-left side fo the screen) shows only a few wind from left to right (on the way, right to left at return).

This is the FlightRecord on AirData:
Airdata

How I can have other data, like motor speed (to see if was a bird strike?)
Thanks.

 

[Yorkshire_Pud]

The motor speeds are in the DATs, on the drone and screen device, both are probably encrypted and unreadable though if you have the DAT on the screen device it might be worth seeing if CsvView and or DatCon will process it.
CsvView Downloads
If you have sync'ed your logs the DAT on the screen device has probably been deleted.
The log on Phantomhelp = DJI Flight Log Viewer - PhantomHelp.com
its csv is more useful than Airdata's.

If you process the phantomhelp csv with CsvView you can get graphical charts of various things, they are quite useful.

 

[slup]

Suddenly the camera drone lost its horizon and then...it lost its GPS signal entering ATTI mode...
then I activated RTH...and made the return journey by walking sideways...

After a few minutes, after battery change, I flew for 2 or 3 minutes in sport mode stressing the aircraft. No issue. All normal!

Was this drone or battery modified in some way... over 19min flight time with 27% still left in the battery when landed?

This could certainly be due to a bird strike... but it's then puzzling why the GPS level dropped from 5 to 0 making the drone revert to ATTI (15-16 sats was locked in all the time & you were flying without anything that could cover any parts of the sky). Going to ATTI isn't typical for a bird strike... & that the GPS level goes to 5 again once you activate RTH is also odd.

The IMU indicate a yaw outbound direction of approx. 114 degrees... & the drone returns in RTH in a direction of approx. 66 degrees, that's a directional change of 180 degrees so that seems correct. I would say that the "crabbing" flight you think you saw actually was due to that the gimbal was pointing sideways... not the complete drone.

If just looking at the pitch & roll movements before & after the ATTI period... it looks like they are oscillating (especially in roll), this could indicate a IMU problem. (Blue background=ATTI & Pink=RTH)



Maybe the mobile device stored DAT log can give us more to go on... it's stored in the mobile device you flew with & in the same folder as the TXT log you shared, but in a subfolder there named MCDatFlightRecords, the correct one is ending with FLY043.DAT (& this isn't encrypted for this drone). Retrieve it & share it in a new post in this thread.

 

[Droning on and on...]

Talking about home points and possible failures of RC's in another thread, that seems like a near zero risk... This thread is a reminder that stuff breaks, even when it rarely does.

Glad the drone regained its sanity and you got it back.

Still have my MA1, still one of my favorites

 

[Carsco]

Was this drone or battery modified in some way... over 19min flight time with 27% still left in the battery when landed?

Yes. I've a modified battery with MA2 cells.
27-28 minutes of flight with MAS propellers.

I knew that the DAT was in the drone and that the Mavic Air was encrypted, unlike the Spark (which I know well).
I found the DAT where you told me and I place it here:

DAT file

I hope it can help.
Anyway, I'll do a IMU calibration soon.

Talking about home points and possible failures of RC's in another thread, that seems like a near zero risk... This thread is a reminder that stuff breaks, even when it rarely does.

Glad the drone regained its sanity and you got it back.

Still have my MA1, still one of my favorites

YES! But I don't think it was an RC problem.
I was sure it was a bird attack (the area is full) but I didn't see one in the SD card video.

I have flown in very much worse wind conditions and have never had any problems, always with DroneMask like an airplane (I fly in mode3).
Mavic Air 1 is still a rock.

 

[slup]

...I found the DAT where you told me and I place it here:

DAT file

Will take a closer look tomorrow... but from a quick peak into the DAT it indeed looks like a genuin IMU and/or possibly a flight controller issue.

 

[Carsco]

What can I do to prevent it from happening again?

Will take a closer look tomorrow... but from a quick peak into the DAT it indeed looks like a genuin IMU and/or possibly a flight controller issue.

If it's IMU issue, what can I do to prevent it from happening again?

Also: see the return track in the map: it's not rectilinear path!
My forward path is more straight than the RTH path, like drunk aircraft!

 

[Droning on and on...]

YES! But I don't think it was an RC problem.
I was sure it was a bird attack (the area is full) but I didn't see one in the SD card video.

I have flown in very much worse wind conditions and have never had any problems, always with DroneMask like an airplane (I fly in mode3).
Mavic Air 1 is still a rock.

Sorry for the confusion... wasn't implying you had an RC problem, I was using an RC failure – exceedingly rare – as an example in another thread why not to skip establishing Home Point before takeoff.

Your experience just caught my attention as another "exceedingly rare" failure, we shouldn't get complacent about problems just because they're so rare.

Same if it's birds

NM – simple thought that turns out hard to explain

 

[slup]

I found the DAT...

If we first find out which IMU that was used in this flight...

The OSD:yaw signal trace from the TXT log is from the IMU used... it looked like below over the whole flight.


From the DAT log we then put up the yaw traces from both IMU's & compare them to the one in the chart above from the TXT in order to determine which IMU that was used in the flight... The red trace below is from IMU(0) & the green is from IMU(1). Comparing yaw between the TXT & DAT concludes that the green IMU(1) was in use.

To determine if the IMU(1) actually was correct I've also put up the compass trace (blue)... but that doesn't mimic the green IMU(1) at all instead it actually follows the unused red IMU(0) pretty well.

So let's see what the gyro says... the purple trace is the gyro, value wise it shouldn't show the same as the IMU, but shape wise it should mimic the IMU trace. Before the ATTI period (pink background color) it's shape is rather odd, it says that the drone rotates more & more in a CW direction... but this isn't seen in any of the IMU's or from the compass, on the contrary, it should over time slowly rotate CCW similar to the red IMU(0) & the blue compass. After the ATTI period during the RTH the purple gyro mimic the (unused) red IMU(0) pretty well shape wise.

The last sensor value regarding rotation is from the VIO:yaw... it's a "redundancy compass" like value coming from the visual positioning sensor on the belly of the drone. This VIO:yaw works as long as the VPS sensor is close enough to the ground below... we have a trace (in black) most of the period before the ATTI period but it's missing most of the RTH period. What we have mimic both the unused red IMU(0) & the blue compass rather well.

Lastly we have your screen recording that clearly shows movements similar to the unused red IMU(0) & the blue compass.



So if we try to draw some conclusions out of all this...

It's clear that the flight controller used IMU(1) & commanded the drone according to that... but the recorded rotations from that IMU doesn't agree with the unused IMU(0), the compass, the parts we have from the VIO:yaw & partially (especially after the ATTI period) the gyro movement. This indicate that the drone didn't move in accordance with the info the flight controller was told by IMU(1) which was in use.

We have seen behaviours like this before, but it's really rare & it's hard to say if the real root cause is due to failing HW or if it's random computational errors.

If digging down into the DAT log event stream we find these errors just before & during the ATTI period...

30811 [L-FDI][CTRL]: fault on , horiz_ctrl_fail
31500 [L-FDI][FDI] ns atti(0) tilt is outlier
31500 [L-FDI][FDI] ns atti(1) tilt is outlier
31501 [L-FDI]NS(0) FUSION(0): fault on , disagree
31501 [L-FDI]NS(0) FUSION(1): fault on , disagree
31501 [L-FDI]fatal error: no ns with level < 4 !!!
31566 [L-FMU/LED]action changed. imu error:ns_abnormal(3)

All of these strongly indicate that the flight controller lost it's trust in the data that was feed to it by IMU(1)... & that explains the ATTI period due to a GPS Level lowered to 0 (so the ATTI period wasn't due to anything with the GPS).

Can add that many of the above error messages remained until you landed... That the following flight went well could indicate that a (power) reset of the system was needed in order to clear the issues you had in the incident flight.

So... no bird was involved in all this.

...If it's IMU issue, what can I do to prevent it from happening again?

I'm afraid that failures like this aren't pilot related... they are more dependent on DJI's programming of the flight controller. The only thing you can do is to realize that all man made thing's aren't failsafe & with that understanding fly in a way that if it happens you don't cause harm to something or somebody.

 

[Lob's Falcon]

If we first find out which IMU that was used in this flight...

The OSD:yaw signal trace from the TXT log is from the IMU used... it looked like below over the whole flight.

View attachment 163898
From the DAT log we then put up the yaw traces from both IMU's & compare them to the one in the chart above from the TXT in order to determine which IMU that was used in the flight... The red trace below is from IMU(0) & the green is from IMU(1). Comparing yaw between the TXT & DAT concludes that the green IMU(1) was in use.

To determine if the IMU(1) actually was correct I've also put up the compass trace (blue)... but that doesn't mimic the green IMU(1) at all instead it actually follows the unused red IMU(0) pretty well.

So let's see what the gyro says... the purple trace is the gyro, value wise it shouldn't show the same as the IMU, but shape wise it should mimic the IMU trace. Before the ATTI period (pink background color) it's shape is rather odd, it says that the drone rotates more & more in a CW direction... but this isn't seen in any of the IMU's or from the compass, on the contrary, it should over time slowly rotate CCW similar to the red IMU(0) & the blue compass. After the ATTI period during the RTH the purple gyro mimic the (unused) red IMU(0) pretty well shape wise.

The last sensor value regarding rotation is from the VIO:yaw... it's a "redundancy compass" like value coming from the visual positioning sensor on the belly of the drone. This VIO:yaw works as long as the VPS sensor is close enough to the ground below... we have a trace (in black) most of the period before the ATTI period but it's missing most of the RTH period. What we have mimic both the unused red IMU(0) & the blue compass rather well.

Lastly we have your screen recording that clearly shows movements similar to the unused red IMU(0) & the blue compass.

View attachment 163899

So if we try to draw some conclusions out of all this...

It's clear that the flight controller used IMU(1) & commanded the drone according to that... but the recorded rotations from that IMU doesn't agree with the unused IMU(0), the compass, the parts we have from the VIO:yaw & partially (especially after the ATTI period) the gyro movement. This indicate that the drone didn't move in accordance with the info the flight controller was told by IMU(1) which was in use.

We have seen behaviours like this before, but it's really rare & it's hard to say if the real root cause is due to failing HW or if it's random computational errors.

If digging down into the DAT log event stream we find these errors just before & during the ATTI period...

30811 [L-FDI][CTRL]: fault on , horiz_ctrl_fail
31500 [L-FDI][FDI] ns atti(0) tilt is outlier
31500 [L-FDI][FDI] ns atti(1) tilt is outlier
31501 [L-FDI]NS(0) FUSION(0): fault on , disagree
31501 [L-FDI]NS(0) FUSION(1): fault on , disagree
31501 [L-FDI]fatal error: no ns with level < 4 !!!
31566 [L-FMU/LED]action changed. imu error:ns_abnormal(3)

All of these strongly indicate that the flight controller lost it's trust in the data that was feed to it by IMU(1)... & that explains the ATTI period due to a GPS Level lowered to 0 (so the ATTI period wasn't due to anything with the GPS).

Can add that many of the above error messages remained until you landed... That the following flight went well could indicate that a (power) reset of the system was needed in order to clear the issues you had in the incident flight.

So... no bird was involved in all this.


I'm afraid that failures like this aren't pilot related... they are more dependent on DJI's programming of the flight controller. The only thing you can do is to realize that all man made thing's aren't failsafe & with that understanding fly in a way that if it happens you don't cause harm to something or somebody.

Thank you, Slup! This is my favorite analysis based on it's intricacies and diagnosis of rare phenomena. WOW

 

[hiflyer201]

Yes. I've a modified battery with MA2 cells.

sure would like to hear more about that. The longest flight that I've had with either of my 1's was 15 minutes and it landed with about 22 % How many flights do you have on the modified batteries?

 

[Carsco]

Can add that many of the above error messages remained until you landed... That the following flight went well could indicate that a (power) reset of the system was needed in order to clear the issues you had in the incident flight.

So... no bird was involved in all this.

What a great analysis!
Thanks a lot, Slup!

Here there are the DAT and TXT of the next flight, done only for testing aircraft after battery change. Just a handful of maneuvers in sport mode, absolutely in VLOS.

Can you find any other errors?

I just recalibrated IMU but I cannot try now the drone.
Thanks again!

sure would like to hear more about that. The longest flight that I've had with either of my 1's was 15 minutes and it landed with about 22 % How many flights do you have on the modified batteries?

About 20 or 25 flights... I've two of these.

 

[slup]

...Here there are the DAT and TXT of the next flight

Can you find any other errors?

Nothing abnormal is logged in this flight...

Below the same traces as in my last post, both IMU's, the compass, the VIO:yaw & the Gyro (check the legend below the chart for which is which). Both IMU's follow each other well, IMU(1) was used. The compass aligns well also (some deviations up on 20 degrees when flying in a northerly direction, but 20-30 degrees from a MA1 is pretty normal), & the gyro also follows shape wise. (Pink background is Sport mode).

(Click on the chart if you want to study it closer)


The only error in the event stream is this...

9550 [L-BATTERY]get_cell_voltage_callback_ack failed!||

... which is common from a MA1 DAT log & doesn't mean that something is wrong (my own MA1 DAT logs are always littered with this message in every flight).

I just recalibrated IMU...

Just so you know... it doesn't hurt to do it but it mainly only see to that the drone doesn't drift back & forth into the same direction during a hover, the calibration make the IMU know where the drone is flat & not tilted in any direction.