Unusual behaviour - Solved: IMU failure

[DevonBadger]

Good evening.

Whilst away in Scotland, i have produced a fair few flights but lost my Pro 2 in the sea after a short, fairly uneventful flight whilst lining up for a

Having looked at the logs and my experience of the flight, i can't work out why the UAV behaved the way it did, however the height at the time of loss of control seems way off.

The app stated a weak signal before the gimbal swerved to the right and the UAV became unresponsive. I didn't have LOS at this point. RTH was set to 30m after loss of signal with the controller.

I've included the flight logs, if anyone can help decipher the issue i would appreciate it.

The loss of control happened at the end of the straight line leading towards the sea, the UAV heads to the left then to the right whilst losing altitude before hitting the sea.

Many thanks

 

[JohnLietzke]

I would suggest loading your logs or syncing you DJI account with Airdata.com. It will give you a mapped flight and some basic information. Visually seeing it might be helpful.

I will look over your logs later tonight if I have time. I do not have a lot of experience with the logs but I will give it a look anyway. Hopefully someone with more experience interpreting logs will give you some more experienced feedback.

 

[DevonBadger]

I have done that and looked at the flight data

I can't see a reason for the loss of control, hence posting up here hoping someone could shed some light or point out the obvious fault which would cause the issue

 

[Meta4]

I have done that and looked at the flight data

I can't see a reason for the loss of control, hence posting up here hoping someone could shed some light or point out the obvious fault which would cause the issue

Here's a summary of your flight data: DJI Flight Log Viewer - PhantomHelp.com

It would have helped if you mentioned that you were using a non-standard joystick mode as that makes it quite difficult to work out what you were doing and relate that to the drone's responses.
Which stick moves did you use to make the drone to rotate and to move sideways?

And because of this, you really need to give more details.
All you've said was: the height at the time of loss of control seems way off.
What makes you think that?
How much off?
How high do you think the drone was?
How high above the sea do you think it was?

Your roll data is a concern and may be related to your problem.
But because I can't work out what you were doing with your joysticks, it's hard to understand how and why.
At 2:15.7, 2:36.2, 2:47.6 and 2:53.3 the roll numbers briefly go higher than normal.
At 2:54.9 the roll data goes high and remains high until the end of the flight.
It looks like you started to have altitude stability difficulties after 2:47.7

Your drone was out of sight, 500 metres away and close above the sea and you were flying flat out in sport mode.
That's always a risky thing to do.

 

[Meta4]

The app stated a weak signal before the gimbal swerved to the right and the UAV became unresponsive. I didn't have LOS at this point. RTH was set to 30m after loss of signal with the controller.

The loss of signal happened when the drone was almost at sea level and losing altitude while rolling heavily to one side while you were still pushing it at full speed in Sport Mode.
In that situation failsafe RTH had no chance to work.
It looks like the only attempt to gain altitude was at 2:57.3, but only for 0.7 seconds.

 

[JohnLietzke]

Meta 4, Thanks for uploading it in Phantom Help. I know it is paid it was really nice of you to use your subscription. I also looked through the logs and saw nothing that would lead me to believe that there was a failure in the drone. As Meta4 pointed out in Sport Mode with all sensors disabled over an ocean is risky to fly. I did notice a slight cell variation noted in the battery of .122v in the battery cells highlighted in red. This is a very insignificant variation. I do not have enough knowledge to interpret if that variation is atypical or associated with a catastrophic battery failure. But mathematically it is roughly a 3% variation and depending on the voltage requirements it could have contributed to the failure. Some electronics can be very sensitive to voltage minor voltage variations. Hopefully someone with more experience with batteries and the electronics requirements will chime in.

If I were guessing, as you were flying over the ocean coastline where the wind is a significant factor and rapidly changes by location due to the natural topography coupled with your altitude of -53' and in sport mode with no sensors is that you skimmed the ocean or a wave made contact with the your drone or the wind caused your low flying drone to lose altitude into the ocean.

 

[boblui]

Near the end of the flight the craft banked hard to the right but it moved to the left at a speed of 28 mph. At the same time, the drone was dropping in altitude rapidly. I can think of several possibilities :

1) Some problems has occurred to the propulsion system.

2) The drone was suddenly hit by massive sinking air plus a very strong gust of wind from the west. What was the weather condition when it happened ? it has to be very cloudy for such violent air movement to occur.

3) The IMU went faulty and provided wrong indication of the roll angle to the flight controller. This can cause the FC to come up with wrong decisions on control actions.

If you can post the .DAT flight log file in the phone, may be there will be more clues.

 

[Meta4]

Meta 4, Thanks for uploading it in Phantom Help. I know it is paid it was really nice of you to use your subscription.

The Phantomhelp log viewer is free for anyone to use.

I did notice a slight cell variation noted in the battery of .122v in the battery cells highlighted in red. This is a very insignificant variation. I do not have enough knowledge to interpret if that variation is atypical or associated with a catastrophic battery failure.

0.1V is common and normal.
It certainly wouldn't cause any flight problems.

 

[slup]

The stick mode used here was mode 3 ... mainly the functions for left & right stick have changed place comparing with default mode 2. But stick movements done by the OP, especially those done in panic in the end have nothing to do with the incident ... this wasn't a pilot error at all, & the loss of connection or those small battery cell deviations had nothing to do with this either.



Already out from the .TXT log the indications of an IMU failure is pretty evident ... looking into the velocity differences between the IMU & GPS reveal big deviations starting at 167sec into the flight, normally the difference is really small (between 0,1-0,5m/s) but looking from where the marker is placed in the chart below the green graph (diff North), the grey graph (diff East) & the black graph (diff height) show intermittent very big deviations. This usually is a good indicator of a IMU failure.

What's also seen is the graphs for the heading speed (blue, value from chart needs to be taken times 10) and the barometric height (red graph) ... both becomes jagged/erratic after the incident have started.


Another way to show this is to look at the calculated flight paths from the IMU & the GPS ... the red path is from the GPS & the green from the IMU.

Plain and simple ... the IMU just there at 167sec lost it's sense of where the AC was & into which direction it was pointing. The consequence then becomes exactly the same as during a yaw error due to a deflected compass at power on (... not the case here though). The AC goes past the stated specification for a M2 both when it comes to tilt angles & speeds in the end.



Jumping forward to 173sec we see this ... the IMU & GPS have a totally different view of where the AC is located, further more, looking at the yellow bar (indicating tilt direction) & compare to the flight path & wind direction it's apparent that the flight telemetrics & the heights can't be trusted, the yellow bar should be pointing into the wind/into the path direction... (blue bar is yaw direction).



To confirm this further the mobile device .DAT log is needed. Read up here on how to retrieve it --> Mavic Flight Log Retrieval and Analysis Guide (read under section 3.) The .DAT log for this flight ends with FLY075.DAT.

 

[DevonBadger]

Thank you all for your input.

When i realised the UAV had become unrepsonsive i tried to bring over land as quickly as possible but it wasn't responding.

The gimbal pointing to the right hand leg and rotor was a sign that something was amiss with the UAV.

I have flown this UAV plenty of times in Sport mode, over the coast and I am a commercial pilot here in the UK. I use this and other UAV's for my work so i have an idea when pilot error is evident, hence asking for those who have more experience in reading flight logs to input their knowledge and help me understand the fault.


Saying that, my only pilot error thought was i hadn't catered for the wind at this particular section of the coast, especially emerging from a sheltered estuary spot, but i knew my height from the sea surface was high enough to be recoverable. My spotter at the point of entry to the estuary claimed the UAV flew off to one side ( rather oddly in his words ) then flew back and dropped altitude into the sea but didn't report any significant wind deviation to the rest of the flight in speed or direction. Only the previous day i had being flying along this coast line with no such problems in very similar weather conditions.

Recently the UAV has come up with IMU re calibration before launching which i've done as well as compass re calibration, which is also done. These happen usually when i've not used the UAV for longer periods of 4 or 5 days. On this particualr flight i don't recall either being an flagged as an error before launch.

I've attached the .DAT logs for that particualr flight;

Thank you all again for your time and knowledge.

 

[skunky1]

Sorry for your loss.

Can you upload you cache video.

 

[DevonBadger]

Although i am set up to record video cache with the oldest being deleted to allow the newest to record, this hasn't happened.

My latest video cache is from July of this year, which are quite old videos.

I do, however, have several .REC files from the date of the incident of only 2kb in size.

 

[slup]

... my only pilot error thought was i hadn't catered for the wind at this particular section of the coast, especially emerging from a sheltered estuary spot, but i knew my height from the sea surface was high enough to be recoverable ...

Recently the UAV has come up with IMU re calibration before launching which i've done as well as compass re calibration, which is also done. These happen usually when i've not used the UAV for longer periods of 4 or 5 days. On this particualr flight i don't recall either being an flagged as an error before launch.

The wind in this case wasn't any cause for this incident at all ... either was not doing a IMU &/or a compass calibration ...

First off we check so everything is properly initiated at power on ... below in the chart we see that both IMUYaw (red) & magYaw (green, compass) is initiated to the same value at power on, which they are. The gyro (blue) also starts up at 0 as it should. The black graph shows the height above HP ... & we can see that all 3 sensors is agreeing reasonably well.

So the power on or the start up phase & ascent up to above 20m height was problem free & went as it should & the incident didn't originate from here ...

(Click on all graphs below to make them larger)



Jumping forward to where the incident starts, 167-170sec into the flight ... suddenly the IMUYaw (red) & the magYaw (blue) starts to develop a major disagreement. The green graph shows the calculated disagreement directly ... it's worst where I've placed the marker, above 130 degrees.



So which one fail, the IMU or the compass? Let's bring in the Gyro & compare it with the IMUYaw that this time is shown as unwrapped (adding & subtracting degrees by the turns & not locked to a Y-axis of +-180 degrees).

Have below placed the marker on the same place as in the chart above where the biggest disagreement was between IMUYaw & magYaw ... we see that the gyro (blue) doesn't agree at all with the IMUYaw (red). This means that the IMUYaw value most probably is wrong ... the gyro & the compass agrees.



At the same time we find below in the DAT event log ...


Either the IMU failed permanently or it was a computational error just there ...

 

[DevonBadger]

Thank you for such a detailed description of the fault slup, your knowledge is most thorough and conclusive.

IMU failure in flight, is this a particular issue with the Mavic pro2 model?

Do i have a case to approach DJI with the issue for a replacement?

Insurance wasn't possible at the time/place of these flights.

 

[slup]

Thank you for such a detailed description of the fault slup, your knowledge is most thorough and conclusive.

IMU failure in flight, is this a particular issue with the Mavic pro2 model?

Do i have a case to approach DJI with the issue for a replacement?

Insurance wasn't possible at the time/place of these flights.

Hardware failures are rare in comparison with pure pilot errors mostly coming from nothing else than ignorance ... but with that said, yeah it happens, have seen a lot of cases where the IMU fails, but not isolated to just the M2 series. In general, HW failures are rare & nothing you in general should be afraid of ... but instead plan for in the sense of ... "it can fall down". So flying over water, property & living thing's is always a higher risk.

If the M2 is within the warranty period this should be a no brainer for them to take, possibly a complication if you can't give them the AC. Another story if outside it ...

 

[DevonBadger]

Ok thank you slup.

I will contact DJi and see where i get with it.

I'll buy another body in the meantime whilst i wait for their reaction to the data.

 

[JohnLietzke]

slup,​

what software is that you are using? It looks incredibly useful for diagnostics when unexpended things happen.

 

[boblui]

As mentioned in my post earlier, the problem began with an uncommanded roll at 167 sec into the flight. The craft self-corrected it and then it happened again. After that the craft gradually lost altitude until it hit the water. With only the info in the .TXT file, I was not sure whether that rolling action was real or just false reading from the active IMU. The M2 is equipped with 2 IMUs and the .DAT file shows that their outputs agreed well as shown in the chart below. Now it's pretty certain that the uncommanded rolling did take place.



When the abnormal rolling happened, all motors except for the right-front motor slowed down and the current taken by the right-front motor abruptly increased from 8 A to 11 A. This is a strong evidence that something wrong happened to the right-front motor, may be it was jammed or the propeller has developed some problems creating more drag and less lift. As the result, the craft became unable to maintain the attitude and altitude as indicated by the log. Crash is ensured.






This is clearly a hardware fault. If the drone is still under warranty, you should be able to get a new one from DJI.

 

[slup]

...all motors except for the right-front motor slowed down and the current taken by the right-front motor abruptly increased from 8 A to 11 A. This is a strong evidence that something wrong happened to the right-front motor...As the result, the craft became unable to maintain the attitude and altitude as indicated by the log. Crash is ensured.

Motor failures usually don't create massive differences in IMU & GPS velocity, nor does it create IMUYaw & magYaw disagreements ... so the motor behavior you see isn't a cause to my understanding, instead the symptom of an IMU that feeds wrong & conflicting information to the Flight controller, which in turn commands the motors via the ECU's.

As this in the end create a yaw error, similar to what we see when a AC have been powered on in a magnetic environment, deflecting the compass, it's not surprising that the motors is affected. Also in these cases the AC speeds away, exceeds the specs for speed & tilt and show abnormal motor data. Looking at the DAT event log (shown above in an earlier post) confirms that the cause isn't motor related.

slup,​

what software is that you are using? It looks incredibly useful for diagnostics when unexpended things happen.

I'm using CsvView ... made by forum member Budwalker. You can get it for free here --> CsvView Downloads

 

[boblui]

Motor failures usually don't create massive differences in IMU & GPS velocity, nor does it create IMUYaw & magYaw disagreements ... so the motor behavior you see isn't a cause to my understanding, instead the symptom of an IMU that feeds wrong & conflicting information to the Flight controller, which in turn commands the motors via the ECU's.

As this in the end create a yaw error, similar to what we see when a AC have been powered on in a magnetic environment, deflecting the compass, it's not surprising that the motors is affected. Also in these cases the AC speeds away, exceeds the specs for speed & tilt and show abnormal motor data. Looking at the DAT event log (shown above in an earlier post) confirms that the cause isn't motor related.

When I first look at the .TXT file data, IMU / yaw error is what I first suspected because the crafted rolled to the right but moved to the left. What I could not explain was why the craft descended without any throttle input. We have seen many incidences of yaw error before and the resulting fly away or toilet bowling but the altitude could always be maintained. This is not the case here. Something else was wrong.

Erroneous IMU outputs can only cause the flight controller to issue wrong speed commands to the motors. It cannot command the amount of current drawn by the motor. For the same speed, the current depends only on the load. In this flight, other motors have reached the speed of the problemetic motor but the current drawn was just about 6.5 A compared with 11 A by the motor in trouble. I am therefore convinced that the problemetic motor not being able to provide the needed thrust is the primary cause of crash.