Mavic Air Fly-away

[sar104]

I was speculating the same over on

How many times do you have to calibrate the compass?

specifically that the FC Yaw value wasn't initialized correctly. It was further speculated that it was related to the FW version. But, I don't think so because these incidents have occurred using FW dated Feb 8 2018 (@Helgegustav ) while other other flights using FW dated Feb 8 2018 didn't have a problem.

Just spit balling here. Is it possible that incorrect Yaw initialization happens when the MA is powered up while being moved about by the pilot? (Shouldn't make any difference; I do this all the time with my MP) If there is a slight delay between reading magYaw and initializing Yaw this could cause the error. OTOH, a stationary MA wouldn't have the incorrect Yaw initialization problem. The .DAT from the MA itself would show if this happened for these incidents. Unfortunately, the tablet .DAT doesn't have initial 1 or 2 secs of data required to determine this.

Maybe. But one other question to throw in with that - why do the two IMUs end up initializing at such different values? Slightly different initialization times perhaps? And also, once initialized, as the aircraft is further moved around, why do the rate gyros not update the initialized yaw values accordingly, as they would do in flight?

So another test might be to deliberately power up a MA while rotating it to see if that leads to this effect.

 

[BudWalker]

Maybe. But one other question to throw in with that - why do the two IMUs end up initializing at such different values? Slightly different initialization times perhaps? And also, once initialized, as the aircraft is further moved around, why do the rate gyros not update the initialized yaw values accordingly, as they would do in flight?

So another test might be to deliberately power up a MA while rotating it to see if that leads to this effect.

And also, once initialized, as the aircraft is further moved around, why do the rate gyros not update the initialized yaw values accordingly, as they would do in flight?
I thought they did. Here's IMU(0) (IMU(1) is similar). Yaw follows the gyros pretty well. At time 35 secs the Yaw correction starts to happen until finally at 55 secs it's been corrected.

 

[Keule]

That issue made me also think about the startup sequence i am doing with these 2 aircrafts:

Mavic Pro:
- goto the desired launch site.
- put AC on the ground
- power ON AC
- leave AC alone
- proceed ...

Mavic AIR
- goto desired launch site.
- having the AC in the hand, turning it around so that i can see the power button
- pressing power ON, while the AC is still facing the bottom to me
- after a short while, maybe 1-2 seconds, i turn the AC in its horizontal position and put it on the ground
- leave AC alone
- proceed ...

Could this sequence irritate the startup process of the IMU's or compass? Or is the time frame to short?

 

[BudWalker]

That issue made me also think about the startup sequence i am doing with these 2 aircrafts:

Mavic Pro:
- goto the desired launch site.
- put AC on the ground
- power ON AC
- leave AC alone
- proceed ...

Mavic AIR
- goto desired launch site.
- having the AC in the hand, turning it around so that i can see the power button
- pressing power ON, while the AC is still facing the bottom to me
- after a short while, maybe 1-2 seconds, i turn the AC in its horizontal position and put it on the ground
- leave AC alone
- proceed ...

Could this sequence irritate the startup process of the IMU's or compass? Or is the time frame to short?

Congratulations! You've been chosen to do the test. One thing that might help is to turn on the RC and start the Go App before powering up the MA.

 

[Keule]

turn on the RC and start the Go App before powering up the MA.

No problem ... I always have the RC and GO4 app ON before powering ON the aircraft.
I have 3 flights from yesterday which i did the startup sequence as described above.
The GO4 app is 4.2.4 (Crystal Sky). Is that helpful?

 

[BudWalker]

No problem ... I always have the RC and GO4 app ON before powering ON the aircraft.
I have 3 flights from yesterday which i did the startup sequence as described above.
The GO4 app is 4.2.4 (Crystal Sky). Is that helpful?

I'm not sure.. Can you retrieve the .DAT for those flights? Here is how it's done with a tablet.

How to retrieve a V3.DAT from the tablet

And, are you able to power on while stationary on the ground?

 

[Keule]

Can you retrieve the .DAT for those flights?

As we speak, i have the CS .DAT and the .TXT retrieved. I am zipping them and provide a sharing link.
Standby ..

 

[sar104]

And also, once initialized, as the aircraft is further moved around, why do the rate gyros not update the initialized yaw values accordingly, as they would do in flight?
I thought they did. Here's IMU(0) (IMU(1) is similar). Yaw follows the gyros pretty well. At time 35 secs the Yaw correction starts to happen until finally at 55 secs it's been corrected.
View attachment 35074
View attachment 35075

I should have been clearer - it certainly does after the log starts, but I meant if the yaw is initialized before the log starts and while the aircraft is moving, why does it not get updated by the rate gyros so that yaw and magyaw are still in agreement at the start of logging?

 

[Keule]

And, are you able to power on while stationary on the ground?

This takes a little bit longer ... i'm on it.

 

[Keule]

@BudWalker Here's the link: ..........

edit: removed link.

 

[sar104]

When holding the aircraft when starting it, I wonder if the yaw calculation has a problem if the aircraft is turned upside down before being placed on the ground. There should be no undefined orientations using the quaternion representation (unlike with Tait_Bryan angles), but I'd be curious to see the results of that operation too.

 

[BudWalker]

I'm offline for the next 6 hours or so. I'm sure you guys will have it all figured out by the time I get back

 

[Jameslavis]

This is interesting. I power up controller, app then AC. Since I often hand launch, I often hold it in one hand vertical and turn on. Then launch or set it on launch pad and send it up. Never ever had an issues.

 

[PavleAU]

What about when you power on and the device requests a calibration of the compass? Surely this process would mean that the initiated yaw values are 'mucked up' using the above hypothesis that it's from moving the aircraft after power on.

When I power on my air, the aircraft takes about 30 seconds to initialise and then in the next 20 - 30 seconds it advises that the home point has been updated. During this process, the maps on the GO4 app also don't update immediately and regularly the aircraft is showing the previous flight location and direction. I usually wait up to 45 - 50 seconds before launch after powering on for everything to update. This usually consumes 1 - 2% of battery.

If a pilot is powering on and taking off as soon as the GO4 app registers that you can start flight, I would be confident to say that the critical values to ensure a safe flight have not been registered and you're taking a huge risk. By waiting a further 20 - 30 seconds, you give the aircraft the time to capture all of the required parameters.

I've got ~60 successful flights to date and a first time DJI owner so perhaps I am a little cautious but happy to share any of my flight logs if it helps in this investigation.

Really appreciate all of the great info here, much of which is over my head ;-)

 

[synaesthesia]

I had a similar near miss, caused by being impatient and not fully considering the conditions - getting the drone off the ground before it was fully ready, in conditions I had measured to be "OK" (it was windy but nothing major).

Of course, those measurements didn't take into consideration that outside of the shelter of the buildings around me (ie: 20 meters upwards) the wind was moving significantly faster than the drone was capable of holding it's own against.

 

[AMRE2ME2]

I just signed up to this forum. Just bought an Air. This is the first post I've read start to finish because I have heard of issues with these things flying off so I wanted to learn as much as I could about how to prevent that happening to me. The one thing I haven't been able to find is a correct startup checklist. I've found a couple but they are different.
Can someone post the correct startup sequence? Including things like checking that the A/Cs directional arrow is actually pointing in the correct (same) direction as the A/C.

And thank you to those that have responded to this post with the technical data, it is an amazing read.

 

[BudWalker]

I should have been clearer - it certainly does after the log starts, but I meant if the yaw is initialized before the log starts and while the aircraft is moving, why does it not get updated by the rate gyros so that yaw and magyaw are still in agreement at the start of logging?

I suspect this is due to the fact that gpsUsed==false and visionUsed==true in the initial part of the flight. I had posted this previously but it got buried.
Mavic Air Fly-away

We've seen other incidents where the expected response to Yaw/magYaw separation is suspended if gpsUsed==false and visionUsed==true. Normal processing is then resumed when that changes (i.e. gpsUsed==true and visionUsed==false).

Dji Newest drone Mavic flyaway Edition

And, I did check the other MavicAir incident
Another Flyaway
It exhibits the same problem.

 

[BudWalker]

@BudWalker Here's the link: DJIFlightRecord_2018-04-03_[13-23-43].zip

OK, thanks for those. I think this should classified as a science fair project that didn't go anywhere. None of the 3 flights you submitted showed any evidence of a compromised Yaw at launch. But, it's clear to me (and I think @sar104 ) that these incidents occurred because Yaw was compromised at launch But, what is the root cause that then caused the compromised Yaw.

 

[sar104]

Here are the three data sets from those flights. I agree that none show a seriously compromised initialization of yaw. I am slightly puzzled by three sets of ATTI records - ATTI_0 and ATTI_1 are obviously the two IMUs, but what is ATTI_MINI0_s?

The first one - FLY087 - appears to be the one where you are moving it around more. All of them show a consistent offset of around 5° between IMU0 and IMU1 yaw.

 

[sar104]

OK, thanks for those. I think this should classified as a science fair project that didn't go anywhere. None of the 3 flights you submitted showed any evidence of a compromised Yaw at launch. But, it's clear to me (and I think @sar104 ) that these incidents occurred because Yaw was compromised at launch But, what is the root cause that then caused the compromised Yaw.

I wonder what happens if yaw is initialized when pitch is close to ± 90°?