Mavic 2 Pro Wild Ride....

[Gryphon962]

.........

Unfortunately I cannot open what I think is the appropriate DAT file to dig deeper. Hopefully others will be able to point to a fault like an IMU crapping out, or something.

I've just read in another thread that the DAT file from the Mavic Air and the Mavic Pro 2 is encrypted and only DJI can read it.

Which explains why there are so many unresolved MP2 threads...

 

[DanMan32]

There are both txt and dat log files on the mobile device. The dat file on the mobile would likely only be missing info if the app/rc lost connection.

 

[Deleted member 94047]

@CrouchyUK
There should be another DAT file (probably a FLY075) since the last DAT file (FLY074) ends with the loss of connection with the remote controller. I am no flight analysis guru but you did experience all sorts of errors from what I can see in the even stream log and some of the data I can make sense out of from the DAT. There
is this disagreement between the two IMUs I can see starting around 2 minutes after motors start. And the event stream log is full of errors related with vision positioning, height control, and aircraft control. You will need to find the other DAT file and upload it and you will also need some one like sars104 or Budwalker to look at the data because I am in way over my head here.

 

[John Lord]

Again, DJI is correct about the possibility of your height not being what you thought it was.

I agree it wouldn't seem likely that lake surface would be at a different height than from takeoff point, it is possible.

Also I have seen displayed altitude drift from actual, and to the negative. So yes, it could say you're 33ft when you're actually less than that. They may have felt leaving a 13ft margin was not enough to be certain you'll clear the trees.

I'm not saying height was the cause of the issue, just that displayed height isn't as precise as you seem to think it is. You can't necessarily just say you show to be 33ft so you're guaranteed to clear a 20ft tree 500ft away.

You may have had marginal magnetic interference on takeoff which messes up the IMU once you clear the interference.

Logs will help figure out what happened.

The Mavic 2 was visually at the height it indicated on the controller i.e. 33ft. It was well clear of the cypress trees. The fact that there were two IMU messages of switching to backup and Upward Obstacle warnings, even though there were no visible obstacles points strongly to an onboard failure of the flight control system. Just prior to control being lost the only pilot input was a small amount left rudder and right aileron. DJI are quite clearly covering up a bug/flaw in the flight control system, which no doubt has quietly been corrected in a firmware update as there have been other instances of Mavic 2’s crashing when being flown around the 30ft-35ft over water.

At the end of the day we can talk about it as much as we like but it will not make a difference as DJI are a law unto themselves. They currently have a monopoly in the market with consumer drones and will crush any company coming in that they see as a threat and they could not care less about their customers. The Skydio looks promising but let’s hope that DJI doesn’t crush them as well.

 

[John Lord]

As was posted before DJI has the final say as to whether they will warranty a manufactured defect or just say it is pilot error. I was demonstrating my Mavic 2 to a co-worker and a client, showed them how the arms all fold out. Did all my checks, Mavic lifted off, hovered for 30 seconds, climb to 44 metres, went 69 metres horizontally, loud sounds start coming from the Mavic, Watched it rollover and crash. Picked up the drone, right rear arm was broken off, rear props still attached, front arms extended, props broke off and lying with in 2 metres of the Mavic. When I picked up the drone I turned the left motor and it felt stiff like a bearing had seized. Sent the Mavic to DJI, they analyzed the flight data said there was vibration in the left motor before lift off and that during the short flight the left arm collapsed causing it to crash. Pilot error is their determination of the flight data. I asked them to send me the flight data and all other related files, as I didn't downloaded it before I sent it to them. Their reply was that they would not send the data files as "it is classified information".

I have checked the internet for other mavic crashes and have found a number where the Mavic has suddenly rolled over during flight and crashed for no apparent reason. DJI refuses to admit there may be a problem with the motor. I have talk to other drone companies. One company bought 3 M200 and all 3 of them crashed with in 6 months under similar circumstances, DJI said the would only fix one under warranty and when it was returned DJI hadn't fixed the issue.

Unfortunately DJI could not care less about their customers and will invariably put a crash down to pilot error. Because DJI are dealing with individuals in the main or small companies they can get away with it. Personally I would never buy direct from DJI but from a retailer as in the UK we have consumer protection laws and it is the vendor who is responsible and a retailer will have a lot more clout with DJI than an individua.

 

[CrouchyUK]

I'm not the expert, but as the right guys arent around, this is what I see from your log in the views you posted.

With reference to the first plot, all looks good until

2:26.6 - controls go to center, but the attitude is well off level - could be wind?
2:37.5 - uncommanded yaw left
2:46 - uncommanded acceleration
2:48 - commanded height increase - and it climbs
2:53 - its now doing over 50mph with right stick in center

..and after that it seems to be getting intermittent control inputs, but nearly always full stick when you see that. Lots of stuff happening despite sticks in middle. Mode is P-GPS throughout (would be understandable if it was ATTI mode)

3:33 - it announces a RTH but carries on slowly gyrating with (mostly) no control input
3:46 - Sport mode - but still looks out of control - which is troubling as Sport mode should give you enough control authority to get it under control

Unfortunately I cannot open what I think is the appropriate DAT file to dig deeper. Hopefully others will be able to point to a fault like an IMU crapping out, or something.

Thanks for your input, it tallies with my understanding of the txt file. I am also aware that later in the flight whilst in Sports Mode my stick inputs were actually adding to the speed over the ground (water), but by then both me and the drone were very disorientated!

I think any further analysis would have to be in the dat files, but in that I am a complete beginner And don’t know where to start. Guess I will have to learn as the experts are busy elsewhere!

 

[DanMan32]

What you can do is post a thread about this in DJI's own forum. A moderator would usually jump in and have your case reviewed. I'd reword your point about your height because how you specifically objected at first with DJI's comment was actually correct on DJI's part. Focus more on what was said here on the DAT file analysis.

One thing though that needs to be looked at closely is the beginning of the flight that there wasn't any compass interference contributing to the IMU confusion. Granted if there was no warning to the pilot, then pilot can't be held responsible.

 

[BudWalker]

@CrouchyUK
There should be another DAT file (probably a FLY075) since the last DAT file (FLY074) ends with the loss of connection with the remote controller. I am no flight analysis guru but you did experience all sorts of errors from what I can see in the even stream log and some of the data I can make sense out of from the DAT. There
is this disagreement between the two IMUs I can see starting around 2 minutes after motors start. And the event stream log is full of errors related with vision positioning, height control, and aircraft control. You will need to find the other DAT file and upload it and you will also need some one like sars104 or Budwalker to look at the data because I am in way over my head here.

View attachment 83482

I’m on travel with just my iPad so can’t do more than be impressed with your analysis. From what I can see imu1Yaw seems to be the problem. Imu0yaw and the 2 magyaw are in agreement. If imu1Yaw is being used for navigation that would explain the fly away - it could see that it was east of where it should be, mistakenly thought it was facing east and was backing up. But it was actually facing west and then backing up (going east). You could check the pitch to see if it’s positive.

 

[BudWalker]

I'm not the expert, but as the right guys arent around, this is what I see from your log in the views you posted.

With reference to the first plot, all looks good until

2:26.6 - controls go to center, but the attitude is well off level - could be wind?
2:37.5 - uncommanded yaw left
2:46 - uncommanded acceleration
2:48 - commanded height increase - and it climbs
2:53 - its now doing over 50mph with right stick in center

..and after that it seems to be getting intermittent control inputs, but nearly always full stick when you see that. Lots of stuff happening despite sticks in middle. Mode is P-GPS throughout (would be understandable if it was ATTI mode)

3:33 - it announces a RTH but carries on slowly gyrating with (mostly) no control input
3:46 - Sport mode - but still looks out of control - which is troubling as Sport mode should give you enough control authority to get it under control

Unfortunately I cannot open what I think is the appropriate DAT file to dig deeper. Hopefully others will be able to point to a fault like an IMU crapping out, or something.

I suspect that you “can’t open the .DAT” because the DatHeader got split off into another .DAT. Try the options Accept excessive errors and Allow invalid DatHeader

 

[Deleted member 94047]

I’m on travel with just my iPad so can’t do more than be impressed with your analysis. From what I can see imu1Yaw seems to be the problem. Imu0yaw and the 2 magyaw are in agreement. If imu1Yaw is being used for navigation that would explain the fly away - it could see that it was east of where it should be, mistakenly thought it was facing east and was backing up. But it was actually facing west and then backing up (going east). You could check the pitch to see if it’s positive.

I am sure you will revise your judgment on my analysis skills when you get to see the data yourself, but I will take that node of appreciation while it lasts - thank you You are right about the disagreement being between IMU0 Yaw and IMU1 Yaw. Here is how it looks.



As for the pitch values, I will just leave it here for you to look at. It gets to positive values around the 138 seconds mark but then it goes in to a a dive in to the negatives and back up again ... it is a like a seesaw to my eyes.



Also, from the event stream from FLY072, a compass calibration was requested for reason

[L-COMPASS][mag_cali_pt] distance_from_last 59277.3 m|

A calibration was done by the pilot and was accepted with an estimation error of ":[8.9]" - whatever that value means I do not know. However, what I don't get is the AC was already on the air before that compass calibration request and the subsequent calibration done by the pilot. It was my understanding that if a compass calibration was needed, the AC won't take off to start with.

 

[Citizen Flier]

As was posted before DJI has the final say as to whether they will warranty a manufactured defect or just say it is pilot error. I was demonstrating my Mavic 2 to a co-worker and a client, showed them how the arms all fold out. Did all my checks, Mavic lifted off, hovered for 30 seconds, climb to 44 metres, went 69 metres horizontally, loud sounds start coming from the Mavic, Watched it rollover and crash. Picked up the drone, right rear arm was broken off, rear props still attached, front arms extended, props broke off and lying with in 2 metres of the Mavic. When I picked up the drone I turned the left motor and it felt stiff like a bearing had seized. Sent the Mavic to DJI, they analyzed the flight data said there was vibration in the left motor before lift off and that during the short flight the left arm collapsed causing it to crash. Pilot error is their determination of the flight data. I asked them to send me the flight data and all other related files, as I didn't downloaded it before I sent it to them. Their reply was that they would not send the data files as "it is classified information".

I have checked the internet for other mavic crashes and have found a number where the Mavic has suddenly rolled over during flight and crashed for no apparent reason. DJI refuses to admit there may be a problem with the motor. I have talk to other drone companies. One company bought 3 M200 and all 3 of them crashed with in 6 months under similar circumstances, DJI said the would only fix one under warranty and when it was returned DJI hadn't fixed the issue.

I stated my positive experience with DJI Customer Service. But this sounds like a potentially real defect. I have seen reluctance to acknowledge similar types issues with various hardware/software manufacturers. Perhaps a user poll through this site could help determine the extent of issue? My M2P occasionally fails to show camera image prior to takeoff. One or more reboots typically resolves the issue. Others have reported similar issues. But DJI has not acknowledged this issue (to my knowledge). Like other manufacturers, they appear reluctant to confirmation certain issues/flaws that could result in costly recalls/warranties. I'm sure more knowledgable veteran pilots will be able to weigh in on this. Thanks for the heads up.

 

[DanMan32]

That could be your mobile or USB cable causing the issue.

 

[BudWalker]

I am sure you will revise your judgment on my analysis skills when you get to see the data yourself, but I will take that node of appreciation while it lasts - thank you You are right about the disagreement being between IMU0 Yaw and IMU1 Yaw. Here is how it looks.

View attachment 83507

As for the pitch values, I will just leave it here for you to look at. It gets to positive values around the 138 seconds mark but then it goes in to a a dive in to the negatives and back up again ... it is a like a seesaw to my eyes.

View attachment 83508

Also, from the event stream from FLY072, a compass calibration was requested for reason

A calibration was done by the pilot and was accepted with an estimation error of ":[8.9]" - whatever that value means I do not know. However, what I don't get is the AC was already on the air before that compass calibration request and the subsequent calibration done by the pilot. It was my understanding that if a compass calibration was needed, the AC won't take off to start with.

I’m guessing that you haven’t tried the geoPlayer? Try firing up the GeoPlayer along with the two SigPlayers you’ve shown. Then move the mouse/cursor over that interval where the imu1Yaw goes rogue. The GeoPlayer will show what the AC was doing.

 

[BudWalker]

I am sure you will revise your judgment on my analysis skills when you get to see the data yourself, but I will take that node of appreciation while it lasts - thank you You are right about the disagreement being between IMU0 Yaw and IMU1 Yaw. Here is how it looks.

View attachment 83507

As for the pitch values, I will just leave it here for you to look at. It gets to positive values around the 138 seconds mark but then it goes in to a a dive in to the negatives and back up again ... it is a like a seesaw to my eyes.

View attachment 83508

Also, from the event stream from FLY072, a compass calibration was requested for reason

A calibration was done by the pilot and was accepted with an estimation error of ":[8.9]" - whatever that value means I do not know. However, what I don't get is the AC was already on the air before that compass calibration request and the subsequent calibration done by the pilot. It was my understanding that if a compass calibration was needed, the AC won't take off to start with.

Looks like the usual calibration being required because of moving >50 km from last flight. Maybe you thought the M2 was flying because time >0.0 ? If there was no flight then CsvView/DatCon will set the time axis offset so 0.0 coincides with batteryOn.

 

[Deleted member 94047]

I’m guessing that you haven’t tried the geoPlayer? Try firing up the GeoPlayer along with the two SigPlayers you’ve shown. Then move the mouse/cursor over that interval where the imu1Yaw goes rogue. The GeoPlayer will show what the AC was doing.

Thanks for that great tip, I learned something today But the geoplayer only shows yaw and magyaw for IMU(0). When I run it along with the other sigplayer (IMU0Yaw v IMU1Yaw) and track my mouse along the graph of the later, the geoplayer shows where the AC was at that time along the path but doesn't show its orientation. Probably me not getting it, first time I have tried the geoplayer.

 

[Deleted member 94047]

Looks like the usual calibration being required because of moving >50 km from last flight. Maybe you thought the M2 was flying because time >0.0 ? If there was no flight then CsvView/DatCon will set the time axis offset so 0.0 coincides with batteryOn.

Yeah, I get that. But then, there is this

45.034 : 2167 [L-TAKEOFF]alti: -22.481876 tors: -176.682831
45.204 : 2175 [L-VISION][VIO]receive vio data befor current ts||
45.992 : 2215 [L-COMPASS][mag_cali_pt] distance_from_last 59278.4 m|
46.650 : 2248 [L-FMU/MOTOR]safe_near_grd:true
48.027 : 2317 [L-COMPASS][mag_cali_pt] distance_from_last 59278.8 m|
49.045 : 2368 [L-COMPASS][mag_cali_pt] distance_from_last 59278.3 m|
50.063 : 2419 [L-COMPASS][mag_cali_pt] distance_from_last 59278.5 m|
50.203 : 2426 [L-FMU/LED]action changed. mag calibration: step1(0)
51.081 : 2470 [L-COMPASS][mag_cali_pt] distance_from_last 59279.0 m|
52.099 : 2521 [L-COMPASS][mag_cali_pt] distance_from_last 59279.2 m|
53.117 : 2572 [L-COMPASS][mag_cali_pt] distance_from_last 59279.2 m|
53.676 : 2600 [L-FMU/MOTOR]safe_near_grd:false
54.135 : 2623 [L-COMPASS][mag_cali_pt] distance_from_last 59278.6 m|
55.153 : 2674 [L-COMPASS][mag_cali_pt] distance_from_last 59278.5 m|
57.948 : 2814 [L-COMPASS][scale cali(0)] fill num:[141]
57.948 : 2814 [L-COMPASS][scale cali(0)] estimation error:[8.9]
57.948 : 2814 [L-COMPASS][scale cali(0)] succeed! bias:329.3 342.1 -19.4 scal:3.337 3.370 3.426|
57.948 : 2814 [L-COMPASS][save data] app cali all success
57.948 : 2814 [L-COMPASS][save data] in user index mode
57.948 : 2814 [L-COMPASS]mag cali pos and time saved success!
57.948 : 2814 [L-COMPASS][mag_cali_pt]lat:0.607221, lon:0.565380
57.948 : 2814 [L-COMPASS][mag_cali_pt]height:-3.8, date:20320302
57.948 : 2814 [L-COMPASS]req gimbal recover when cali end
57.967 : 2815 [L-IMU]

state: drift
58.387 : 2836 [L-FMU/LED]action changed. Normal Flash(0)
58.387 : 2836 [L-FMU/LED]type:0, normal flash action:
58.387 : 2836 [L-FMU/LED]c0:0,15;c1:0,3;c2:0,13;c3:2,3;c4:0,10;c5:0,3;c6:0,10;c7:0,3
58.846 : 2859 [L-FMU/VERSION]Mc ID :163DG17001K7H1
58.846 : 2859 [L-FMU/VERSION]Bat SN :0P2AFBE53411HP
58.846 : 2859 [L-FMU/VERSION]Mc Ver :v3.4.0.52
58.846 : 2859 [L-FMU/VERSION]Bat Ver :v2.74.7.12
58.846 : 2859 [L-FMU/VERSION]svn Ver :b26747862d39271637712390cbe585e37b789160
58.846 : 2859 [L-FMU/VERSION]Time :commit:2018-11-13 22:10:48 /build:2018-12-31 17:44:30
60.982 : 2966 [L-TAKEOFF]alti: -22.086361 tors: 178.650284
61.321 : {tska}INFO:recorder 1 configuare done, change sm to SM_WRITE[550]||
61.461 : 2990 [L-FMU/MOTOR]safe_near_grd:true
62.558 : {tska}INFO:recorder 0 configuare done, change sm to SM_WRITE[2838]||
63.177 : 3076 [L-FMU/MOTOR]safe_near_grd:false
63.955 : 3115 [L-IMU]

state: fixed
​

I don't know what to make of it. Was the calibration done while the AC was still airborne??​

 

[CrouchyUK]

Wow thanks guys I am getting a real insight now as to what may have happened- even that it may not have been a mysterious whirlwind or the chump on the sticks!.

So the IMU's went out of agreement- IMU1 going off on it's own wild ride? I can confirm that the compass recalibration was done at first power up as demanded by the SC- but then at least 1 or 2 reboots of the drone as I tried to fathom out the gimbal problem.

I found FLY075 as well if that helps.

I will read your various analysis above and try to understand more. but my concern now is if this will happen again and I won't be as lucky.....

 

[BudWalker]

Yeah, I get that. But then, there is this


I don't know what to make of it. Was the calibration done while the AC was still airborne??

Yikes! That’s a new one on me. I’ll be taking a look at this one when I get back.

@sar104

 

[BudWalker]

Thanks for that great tip, I learned something today But the geoplayer only shows yaw and magyaw for IMU(0). When I run it along with the other sigplayer (IMU0Yaw v IMU1Yaw) and track my mouse along the graph of the later, the geoplayer shows where the AC was at that time along the path but doesn't show its orientation. Probably me not getting it, first time I have tried the geoplayer.

Yeah, CsvView 3.6.7 will allow you to see imu1 in the GeoPlayer. In the interim you can launch a SigPlayer with imu1Yaw and imu1magYaw along with the GeoPlayer.

 

[sar104]

Also, from the event stream from FLY072, a compass calibration was requested for reason

A calibration was done by the pilot and was accepted with an estimation error of ":[8.9]" - whatever that value means I do not know. However, what I don't get is the AC was already on the air before that compass calibration request and the subsequent calibration done by the pilot. It was my understanding that if a compass calibration was needed, the AC won't take off to start with.

It will takeoff with the distance/time calibration request active. It looks like it won't but it will accept a motor start CSC and will then desist with the calibration request.

Yeah, I get that. But then, there is this
I don't know what to make of it. Was the calibration done while the AC was still airborne??

Yikes! That’s a new one on me. I’ll be taking a look at this one when I get back.

@sar104

However, the aircraft was not airborne. There was no motor start in FLY072.DAT.