Spooky Action at a Distance

[Logger]

Nor does it have to spin. The drones path spirals over the ground but the heading can remain essentially constant throughout without spin. At least mine did.

 

[BudWalker]

Certainly not intentionally. Was literally the second time I have used DJI Assistant and all I can recall doing was setting it to grab the VM as well. But may have done so accidentally.

barely but main thing is you have actually got the offending bit..



YES I sent it to DJI support with a note to say I am not looking for any special support, simply...
" ..passing this info on in the hope that the included files may be of assistance to your engineers in assessing and fixing whatever is causing this problem. "

They replied " I have forward the details to the team. Hope the next firmware will fix it.".

First, let me describe what happened. Then, I'll guess at the reasons behind the incident.

The Yaw value is the Flight Controller's notion of the A/C heading (i.e. which way it's pointing). The red arrow you see in the Go App is the Yaw value. Sometimes the FC gets confused and it's notion of Yaw is incorrect. Yaw isn't just the compass magnetometer values. It's computed from several sources and depends very little on the magnetometer values. magYaw is a value computed by DatCon and derived from the magnetometer data with a correction for pitch and roll. magYaw is just a DatCon diagnostic; it's not an actual FC value. But, it is useful in situations where the Yaw value is suspect.

Normally, Yaw and magYaw track each other closely. There may be some variations as the FC has to continually correct it's Yaw prediction. But, usually they are close. When the Yaw/magYaw separation gets large (> 25 degrees) then there is a possibility that the Yaw value is incorrect and the FC then switches to ATTI mode. That's what happened in this incident.

The Yaw/magYaw separation had been about 11 degrees (the geoMagnetic declination at the launch site is 12 degrees). At about 46 secs the Yaw/magYaw separation began increasing and was at 37 degrees at time 162.5 when the FC switched to ATTI from NaviGo. The TBE had already started.


But then, why was there a Yaw/magYaw separation? I really don't know why this happened. I really should know better, but I'll make a guess. @Logger you had made the point that this mission was identical to the two before it. But, what's different is the wind speed and direction. Since the FC has to correct for this these are actually different flights. But, still the FC should be able to reliably predict Yaw.

Again, this just a guess on my part that will probably be debunked or modified. The gyroZ error is about 5 times larger than what I've seen with the limited number Mavics for which I have a .DAT. totalGyroZ is a value computed by DatCon that integrates and then sums the gyroZ value. If the Mavic is stationary then any change in totalGyroZ is due to the gyroZ error. In this flight totalGyroZ changes 13 degrees in the 27 seconds before launch. That's 0.5 degrees/sec; about 5 times the usual 0.1 degrees/sec seen on the other Mavics I've looked at. The guess here is that this may have contributed to the Yaw/magYaw separation. This also the usual gyroZ error on the P3.

0.5 degrees/sec error is probably within spec. After all, the Mavic is probably smarter than a flight analyst wannabe and it didn't say an IMU calibration should be done. My P3 had 0.4 degrees/sec error until I calibrated the IMU. That error was then improved to 0.08 degrees/sec. You might want to try an IMU calibration and see if you get an improvement.

Still left unanswered with these incidents is why does the Mavic continue to navigate when it switches to ATTI mode. I'm supposing it should drift with the wind rather than trying to hover at the same spot.

 

[Ender]

...
But then, why was there a Yaw/magYaw separation? I really don't know why this happened. I really should know better, but I'll make a guess.
...

Thank you BudWalker for elaborating. You imply that the Mavic FV always uses inertial/cumulative Navigation to compute Heading from gyroZ, right ?
(Causing the trouble as consequence)
Are you sure on that ? I am new to DJI, i know that as a fallback on ArduCopter if compass fails but to use it on a regular base seems ... wild to me.

Greetings,

Ender

 

[BudWalker]

Thank you BudWalker for elaborating. You imply that the Mavic FV always uses inertial/cumulative Navigation to compute Heading from gyroZ, right ?
(Causing the trouble as consequence)
Are you sure on that ? I am new to DJI, i know that as a fallback on ArduCopter if compass fails but to use it on a regular base seems ... wild to me.

Greetings,

Ender

Well, I didn't write the FC code so I don't actually know. And, I've seen way more P3 .DATs than Mavic .DATs. But, I think the way it works is that Yaw is set from the magnetometers shortly after batteryOn. After that Yaw is computed from from gyros and accelerometers and probably other inputs as well. The magnetometers have much less influence than the gyros and accelerometers. The way it was explained to me is that the gyros and accelerometers are on an inner control loop and the magnetometers are on an outer control loop.

There are two P3 flights that I looked at where magYaw was correct but Yaw was different by 90 degrees (this was confirmed by the video). It took 2 minutes before the Yaw was corrected to have the same value as magYaw.

EDIT: I should add it was clear the P3 was navigating from the incorrect Yaw value and not from the magnetometers.

My experience with all this comes from writing the software that reads the .DAT and creates the graphs. Maybe you could suggest some other data to look at and/or tests to perform that would give us a better understanding how all this works.

 

[Ender]

Hi Budwalker,
i see, problem is i am useless as i am used to interpreting / analysing Arducopter logs.
Thats why i know that cumulative Gyro Values are used as a kind of "poor mans" replacement for a working compass.
Thats an awful method to compute heading so thats why i wondered why DJI would use gyro data for that task.
Thats the cool thing about ArduCopter, you can simply look up the routine in the source and then you KNOW

So sorry for "interrupting your flow", your analysis is by far the most detailed i have seen yet on that issue.
Hopefully those DJI Engineers supossedly hunting the bug put at least half the determination on finding the cause for these issues...

Ender

 

[Kilrah]

Mag is slow, noisy and of questionable reliability, so is usually used with "lower priority" than gyro in IMU sensor fusion algorithms. The main data source is the fast gyro, with the mag being used to detect and mitigate its drift as well as to provide an absolute value at startup. A large gyro drift is certainly not a good thing, becasue it kind of pushes to rely more on the mag.

@BudWalker, what do you think of the kind of "sinusoidal cycle" on MagYaw in the capture above when Yaw doesn't move at all? Could that be a local/temporary magnetic disturbance? Would be interesting to see the 3 axes / Mod at that time...

 

[BudWalker]

.... "interrupting your flow"...

Say what?!?. I think it's great you took the time to read the post and add something to the discussion. Wish there were more of you.

 

[Ender]

Mag is slow, noisy and of questionable reliability, so is usually used with "lower priority" than gyro in IMU sensor fusion algorithms. The main data source is the fast gyro, with the mag being used to detect and mitigate its drift as well as to provide an absolute value at startup. A large gyro drift is certainly not a good thing, becasue it kind of pushes to rely more on the mag.

Ah thanks, makes sense is there anywhere one can look up these things for DJI ?

Ender

 

[BudWalker]

Mag is slow, noisy and of questionable reliability, so is usually used with "lower priority" than gyro in IMU sensor fusion algorithms. The main data source is the fast gyro, with the mag being used to detect and mitigate its drift as well as to provide an absolute value at startup. A large gyro drift is certainly not a good thing, becasue it kind of pushes to rely more on the mag.

@BudWalker, what do you think of the kind of "sinusoidal cycle" on MagYaw in the capture above when Yaw doesn't move at all? Could that be a local/temporary magnetic disturbance? Would be interesting to see the 3 axes / Mod at that time...

If this were the P3 I would guess that the magYaw is correct. I.e. the Mavic is actually yawing whilst it is TBEing. Not sure what you meant by 3 axes/Mod but take a look at these.




You could do these yourself since you're an accomplished CsvView user

 

[Kilrah]

Woops, thought he had sent you the DAT privately.

 

[BudWalker]

I forgot that DAT is unusual. Lemme send you different file when I get home in an hour or two

 

[BudWalker]

Woops, thought he had sent you the DAT privately.

This is the Dropbox link to the .DAT
Dropbox - FLY154.DAT
Attached to this post is a .zip containing the .csv. which when loaded into CsvView will be the same as having loaded the .DAT

 

[Kilrah]

Thanks, will check tomorrow, too late now

 

[Logger]

Thanks BudWalker, amazing what you have can extrapolate from the data.

In this flight totalGyroZ changes 13 degrees in the 27 seconds before launch. That's 0.5 degrees/sec; about 5 times the usual 0.1 degrees/sec seen on the other Mavics I've looked at. The guess here is that this may have contributed to the Yaw/magYaw separation.

Only thing I can add to this, is the launch site was sloped at about 10 degrees. Initial launch site (home point) was flat, but Litchi mission was set to land each time at final WPT which was a clear area nearby, albeit sloped. So it took off from flat first time them landed after each loop or part loop on a slope (Including the TBE flight). Could pre-flight tilt be implicated, as I suspect it was off level in hte pre-launch phase?

WRT to the suggestion to do an IMU cal, I am somewhat reluctant. My Mavic has done ~ 150 flights in ~ 14 hours flight time. Only ever had a single compass swing out of the box. It has been over a week since this event with no recurrences. But I am watching it like a hawk.

 

[BudWalker]

Thanks BudWalker, amazing what you have can extrapolate from the data.

In this flight totalGyroZ changes 13 degrees in the 27 seconds before launch. That's 0.5 degrees/sec; about 5 times the usual 0.1 degrees/sec seen on the other Mavics I've looked at. The guess here is that this may have contributed to the Yaw/magYaw separation.

Only thing I can add to this, is the launch site was sloped at about 10 degrees. Initial launch site (home point) was flat, but Litchi mission was set to land each time at final WPT which was a clear area nearby, albeit sloped. So it took off from flat first time them landed after each loop or part loop on a slope (Including the TBE flight). Could pre-flight tilt be implicated, as I suspect it was off level in hte pre-launch phase?

WRT to the suggestion to do an IMU cal, I am somewhat reluctant. My Mavic has done ~ 150 flights in ~ 14 hours flight time. Only ever had a single compass swing out of the box. It has been over a week since this event with no recurrences. But I am watching it like a hawk.

Can't imagine how pre-flight tilt could be an issue.....

Absolutely. At this point it's all just a theory. If DJI says anything interesting please post it.

 

[Logger]

DJI are not going to say anything to me unfortunately. They have closed my case and marked it as solved would you believe!

 

[BudWalker]

.....
WRT to the suggestion to do an IMU cal, I am somewhat reluctant. My Mavic has done ~ 150 flights in ~ 14 hours flight time. Only ever had a single compass swing out of the box. It has been over a week since this event with no recurrences. But I am watching it like a hawk.

But, if you ever do an IMU calibration could you retrieve a .DAT so we can see if if made a difference in the gyroZ error?

 

[CBA]

I am able to get this error consistently. I don't understand half the things you all are talking about but if i can help in anyway, I'd be happy to.

 

[Willik]

This is very interesting and I am very scared now ... does anyone PLZ know if this issue was solved by the latest FW update (26.12.2017) ?
Thanks.
W.

 

[erkme73]

It depends on what you consider "fixed". The short answer is yes. The new firmware has the flight controller switch from the rear compass to the redundant front compass if it gets too noisy. That should eliminate the compass and gps data discrepancies. It will also trigger a "strong magnetic interference" warning on the app while flying.

IMHO, the reason why I consider this a software fix to a hardware problem is because the firmware only addresses the symptoms, not the cause. The cause is the higher current giving off too much RF noise under full throttle. DJI 'repaired' my unit (replacing it with another MP), and subsequent flights showed that the noise was significantly reduced on the rear compass. Enough that it never switches to the front. It also cured the TBE issue, and I get no interference warnings. The rumored hardware fix is better shielded/twisted wires to help reduce the RF noise.

The reason DJI has two compasses is for redundancy. If the normal operating parameters have the flight controller switching from the rear to the front, that redundancy is gone.

I have no idea at what point this issue was addressed from a build/manufacturing standpoint. I can only imagine that the currently produced units have the proper shielding and will perform as my replacement unit does. At some point, whenever that change occurred - say after SN 150XXXX - you're safe. I don't think DJI would acknowledge the issue, let alone at what SN the improvement was implemented. So just speculation on my part.

That said, if I had a new unit now, the acid test would be to fly it with the latest firmware, balls-out in sport mode, as aggressively as possible for as long as possible. If you see no interference warnings, you're hardware is probably current and OK. You can also take the DAT file generated from that aggressive flight and have @BudWalker look at it for compass noise.