Mavic Air Fly-away

[Simmo]

Will you marry me?

 

[sar104]

Will you marry me?

Please move this to the "Classifieds" section.

 

[Helgegustav]

By the way - if your aircraft will power up and if you can retrieve the onboard DAT file for that flight, we can review the raw magnetometer data to determine exactly what happened.

I got it, how/where do I upload?

 

[sar104]

I got it, how/where do I upload?

How to retrieve a V3 .DAT File from the AC

Upload to Dropbox or similar and post the sharing link.

 

[Helgegustav]

@Helgegustav I hope u get sorted out bud. I think the lesson is clear, make your pre flight check a habit. While we love to think our drones are "toys" sometimes we forget that they are expensive machines capably of flying kilometers away at 60mph. Hope you back in the air soon mate and that u get all the assistance you need from DJI.

@sar104 thanks for the effort man it is really appreciated.

Yep, thanks. I'm going to be way more careful in the future.

How to retrieve a V3 .DAT File from the AC

Upload to Dropbox or similar and post the sharing link.

Oh, alright. I already had a .dat file from the FlightLogs folder taken from the app via iTunes, but I guess it's not the one needed because it is only 400 byte.

I'll look into it when I get home

 

[sar104]

Yep, thanks. I'm going to be way more careful in the future.



Oh, alright. I already had a .dat file from the FlightLogs folder taken from the app via iTunes, but I guess it's not the one needed because it is only 400 byte.

I'll look into it when I get home

OK - the file in question is on the aircraft itself, not the mobile device.

 

[BudWalker]

OK - the file in question is on the aircraft itself, not the mobile device.

@Helgegustav
Several Mavic Air pilots have been unable to retrieve the .DAT from the AC. The .DAT from the tablet may have enough data to analyze this incident. Look here to see how to retrieve the tablet .DAT. It will be in the FlightRecord/MCDatFlightRecords folder. The .dat referenced in post #65 was in the folder above that folder.

 

[Helgegustav]

How to retrieve a V3 .DAT File from the AC

Upload to Dropbox or similar and post the sharing link.

Just as BudWalker said, I had some trouble using the DJI Assistant, I grabbed the .dat from the FlightLogs folder instead. Hope its the right one.

Mavicdatfile

 

[sar104]

Just as BudWalker said, I had some trouble using the DJI Assistant, I grabbed the .dat from the FlightLogs folder instead. Hope its the right one.

Mavicdatfile

No - wrong file. That was a 450 s power up (not a flight) on 3/25/2018 at 1043Z.

 

[Helgegustav]

No - wrong file. That was a 450 s power up (not a flight) on 3/25/2018 at 1043Z.

My bad, updated the folder with another one now

 

[sar104]

My bad, updated the folder with another one now

Still no - that was a 593 s power up, with a motor start but no flight, on 3/25/18 at 0803Z.

 

[BudWalker]

Actually, I think that is the right .DAT - although it's a bit broken. The timeStamp matches the .txt flight timeStamp. The 593 sec duration comes from the fact that it landed 1 km away and the OP was able to find it because it was still transmitting it's location. There are a couple of gaps due to the loss of downlink before the OP got close enough to re-establish the downlink. The altitude, gpsHealth and numSats match up to the .txt in the first 75 secs



The .txt plot also contains the gpsUsed and visionUsed signals. For the first 42 seconds gps was not being used and vision was being used. That's why there was no switch to ATTI even though gpsHealth was too low to support GPS+ATTI. We've seen this in another flight (I'm on travel so I won't be able to reference it) At 46 secs gpsHealth increased to 4 causing gpsUsed to became true and visionUsed to became false. It was at this point that the fly away occurred presumably because GPS coords could be used but it was still confused about Yaw.

Another thing interesting about this is the Yaw and magYaw separation.

magYaw is -131° at launch which matches the OP's description of 220°. But, the initial Yaw is 156° in the .DAT and 43° in the .txt. Don't know what to make of that. It can also be seen that magYaw and Yaw started converging at around 35 secs and finally converged at 58 secs. Presumably normal flight could have been possible at this point if it were not for the fact that it was disconnected shortly thereafter.

 

[Slowcaptain]

Newbie here. I learned so many things from this thread. Absolutely amazing Sherlock Holmes-ey stuff by senior members here.
So glad I joined this forum.

 

[dbyantis]

Yes - that was the end result. Drifting at 16 m/s (35 mph) with attitude maxed out implies a wind speed of at least 25 m/s (i.e. over 50 mph).

Would be nice to change all of the incorrect "fly away" subject lines with "blown away". I think that new pilots need to be aware of the fact that they probably still have some ability to fly the done vs. giving up assuming it was "another" fly away.

 

[sar104]

Actually, I think that is the right .DAT - although it's a bit broken. The timeStamp matches the .txt flight timeStamp. The 593 sec duration comes from the fact that it landed 1 km away and the OP was able to find it because it was still transmitting it's location. There are a couple of gaps due to the loss of downlink before the OP got close enough to re-establish the downlink. The altitude, gpsHealth and numSats match up to the .txt in the first 75 secs
View attachment 34560

View attachment 34561
The .txt plot also contains the gpsUsed and visionUsed signals. For the first 42 seconds gps was not being used and vision was being used. That's why there was no switch to ATTI even though gpsHealth was too low to support GPS+ATTI. We've seen this in another flight (I'm on travel so I won't be able to reference it) At 46 secs gpsHealth increased to 4 causing gpsUsed to became true and visionUsed to became false. It was at this point that the fly away occurred presumably because GPS coords could be used but it was still confused about Yaw.

Another thing interesting about this is the Yaw and magYaw separation.
View attachment 34562
magYaw is -131° at launch which matches the OP's description of 220°. But, the initial Yaw is 156° in the .DAT and 43° in the .txt. Don't know what to make of that. It can also be seen that magYaw and Yaw started converging at around 35 secs and finally converged at 58 secs. Presumably normal flight could have been possible at this point if it were not for the fact that it was disconnected shortly thereafter.

I spent some time looking that file thinking it was correct, but abandoned it because the location data made no sense and the IMU yaw was different to the txt file. But you are correct - it does seem to match the timestamp, duration and some other data.

IMU location, in particular, is obviously wrong. Comparing GPS with IMU shows the following:



If you look at what that means in terms of distance travelled, according to GPS, we get:



That's vaguely credible. The IMU location data, on the other hand, give this:



Those axes are in km - that's not a typo.

Overall, this DAT file has left me simply confused. Is the file corrupted? I don't see how significant data can differ between the txt and the DAT.

 

[sar104]

Would be nice to change all of the incorrect "fly away" subject lines with "blown away". I think that new pilots need to be aware of the fact that they probably still have some ability to fly the done vs. giving up assuming it was "another" fly away.

Note, however, that it turns out those data were spurious, due to the IMU yaw values used to calculate them being incorrect as a result of a large compass error.

 

[laurens23]

That's an insightful post, and I understand your argument, but it puts the cart before the horse. You are correct that in P-GPS mode the aircraft will attempt to match track with heading, but it cannot make a course correction until it detects a track. So, even in P-GPS mode, elevator and aileron translate to pitch and roll changes on which the FC will superimpose course corrections to maintain track.

Now if the IMU heading is 180° off then as far as the FC is concerned, initial motion when forward elevator is applied will be in the opposite direction than it expected - it will detect, effectively, that it is moving backwards instead of forwards. Its response will be more forward pitch, not less, to attempt to move in what it wrongly thinks is the forwards direction, which will push it even faster in the direction it is facing. Now we have uncontrolled flight, but forwards, not backwards, probably followed by a high wind warning flag when it is unable to correct for what it detects (incorrectly) as drift that it cannot counter.

On the question of whether I'm guessing - no - it's based on a combination of knowing how sensor fusion works in GPS modes and looking at logs of this actually happening. In this particular example the initial FC response was due to drift rather than stick inputs, but in other cases it has been stick input that triggers the uncontrolled response. The results are both consistent with theory.

So you are entirely correct that the goal of the FC in P-GPS mode is to translate elevator to "fly a track in the direction of the current heading", but your proposed mechanism to do that is not quite correct. It's not going to fly backwards on application of forward elevator because it doesn't know that it is facing the wrong direction, and once it moves in the wrong direction, it assumes that's due to wind and applies even more forward pitch, rather than immediately concluding that its yaw value is out by 180°. Does that make sense?

Thanks, TIL. That makes it clear for me, and based on your third paragraph I'm trusting your explanation is the actual implementation they use.

edit: this whole threat is a facinating read

 

[BudWalker]

I spent some time looking that file thinking it was correct, but abandoned it because the location data made no sense and the IMU yaw was different to the txt file. But you are correct - it does seem to match the timestamp, duration and some other data.

IMU location, in particular, is obviously wrong. Comparing GPS with IMU shows the following:

View attachment 34569

If you look at what that means in terms of distance travelled, according to GPS, we get:

View attachment 34570

That's vaguely credible. The IMU location data, on the other hand, give this:

View attachment 34571

Those axes are in km - that's not a typo.

Overall, this DAT file has left me simply confused. Is the file corrupted? I don't see how significant data can differ between the txt and the DAT.

I’m restricted to my iPad for the next couple of days. Try this. The Mavic Air has two IMUs. Specify Engineered then DatDefined and then look at lat long in IMU(1). The units are radians.

There are other discrepancies beyond what you pointed out. GPS:heightMSL does a jump discontinuity at one point. But, it’s the same flight. I don’t think the .DAT is corrupted. It does have gaps though as does the .txt.

I’ll need to take another look but I’m not particularly surprised that gps coords jump. GpsHealth was inadequate at first.

@Helgegustav did the AC sit at a geomatically distorted location before being moved to the launch site? Inside a vehicle? Or on a truck tailgate (my flying buddy and I did this)? This would explain why magYaw was correct but Yaw was compromised at launch.

 

[Helgegustav]

Well no. It had been staionary for 3-4 days if I remember correctly, laying on my desk at home.

 

[BudWalker]

Well no. It had been staionary for 3-4 days if I remember correctly, laying on my desk at home.

After batteryOn was it moved from one location to a different location for launch? Or, was it powered on and launched without moving it?