Firmware v01.03.0000 Compass Error.

[BudWalker]

@ScrappyMavic
Yes, it's rotated into the horizontal plane. What I did was an adaptation of this article Keeping a Good Attitude: A Quaternion-Based Orientation Filter for IMUs and MARGs
Section 4.2 derives what I call magYaw as a quaternion from the magnetometer data and the pitch/roll quaternion of section 4.1. But, I cheated a little. Whereas section 4.1 derives the pitch/roll quaternion from the accelerometer data I used the pitch/roll from the FC. I don't think that affects the value of magYaw in a material way. What do you think?

Maybe you can read this code

Quaternion qAcc = Quaternion.fromAngles(pitch, roll, 0.0);
        Quaternion x = new Quaternion(0.0, magX, magY, magZ);
        Quaternion magXYPlane = qAcc.times(x).times(qAcc.conjugate());
        double X = magXYPlane.getX();
        double Y = magXYPlane.getY();
        return Math.toDegrees(-Math.atan2(Y, X));

 

[germ]

I'm very interested to hear how the compass behaves in sport mode! Along with flight logs if possible! How long was your total repair time including shipping?

Repair time was 1 week , i shipped it last Thursday and got it back today. so that was quite fast. The weather's not too good right now , so i can't test. but as soon as it's not raining i will test and let you guys now the findings and the DAT

 

[ScrappyMavic]

@ScrappyMavic
Yes, it's rotated into the horizontal plane. What I did was an adaptation of this article Keeping a Good Attitude: A Quaternion-Based Orientation Filter for IMUs and MARGs
Section 4.2 derives what I call magYaw as a quaternion from the magnetometer data and the pitch/roll quaternion of section 4.1. But, I cheated a little. Whereas section 4.1 derives the pitch/roll quaternion from the accelerometer data I used the pitch/roll from the FC. I don't think that affects the value of magYaw in a material way. What do you think?

Maybe you can read this code

Quaternion qAcc = Quaternion.fromAngles(pitch, roll, 0.0);
        Quaternion x = new Quaternion(0.0, magX, magY, magZ);
        Quaternion magXYPlane = qAcc.times(x).times(qAcc.conjugate());
        double X = magXYPlane.getX();
        double Y = magXYPlane.getY();
        return Math.toDegrees(-Math.atan2(Y, X));

Ok, I'm no expert but that looks ok. Just for fun I implemented the equation here into Matlab based on magX/Y/Z and Pitch/Roll from DatCon. I ended up with a plot "matYaw" that almost matches your magYaw. (below) So that feels good.

The big question now in my data I think is why is magYaw oscillating prior to ATTI when Yaw from FC is not? I verified matYaw (magYaw from Matlab) looks about the same regardless of if I use front or back compass mag values. So a couple theories of the issue are:

1. True yaw really *is* oscillating. The FC values are bad for some reason.
2. Both front and back compass values are impaired or following some low frequency noise problem and yaw is not really oscillating.

Matlab verification of magYaw

 

[BudWalker]

Ok, I'm no expert but that looks ok. Just for fun I implemented the equation here into Matlab based on magX/Y/Z and Pitch/Roll from DatCon. I ended up with a plot "matYaw" that almost matches your magYaw. (below) So that feels good.

The big question now in my data I think is why is magYaw oscillating prior to ATTI when Yaw from FC is not? I verified matYaw (magYaw from Matlab) looks about the same regardless of if I use front or back compass mag values. So a couple theories of the issue are:

1. True yaw really *is* oscillating. The FC values are bad for some reason.
2. Both front and back compass values are impaired or following some low frequency noise problem and yaw is not really oscillating.

Matlab verification of magYaw
View attachment 2929

No...., it has to be because the magYaw is dependent on pitch


I checked the gyroZ to see if it was yawing. Both compasses can't be wrong...Lemme see if there was an error introduced when the code was changed to handle the Mavic. There is another yaw value that is the one used in the Go app display. The yaw used here is in the same record containing IMU and magnetometer data. Maybe that isn't the right one to use...

 

[BudWalker]

Ok, I'm no expert but that looks ok. Just for fun I implemented the equation here into Matlab based on magX/Y/Z and Pitch/Roll from DatCon. I ended up with a plot "matYaw" that almost matches your magYaw. (below) So that feels good.

The big question now in my data I think is why is magYaw oscillating prior to ATTI when Yaw from FC is not? I verified matYaw (magYaw from Matlab) looks about the same regardless of if I use front or back compass mag values. So a couple theories of the issue are:

1. True yaw really *is* oscillating. The FC values are bad for some reason.
2. Both front and back compass values are impaired or following some low frequency noise problem and yaw is not really oscillating.

Matlab verification of magYaw
View attachment 2929

Sorry I didn't see that you had referenced this when you said you implemented matYaw. I guess that means that magYaw probably doesn't have a bug. That's good and that's bad. Lemme look into the other values for roll, pitch, and yaw.

 

[BudWalker]

Ok, I'm no expert but that looks ok. Just for fun I implemented the equation here into Matlab based on magX/Y/Z and Pitch/Roll from DatCon. I ended up with a plot "matYaw" that almost matches your magYaw. (below) So that feels good.

The big question now in my data I think is why is magYaw oscillating prior to ATTI when Yaw from FC is not? I verified matYaw (magYaw from Matlab) looks about the same regardless of if I use front or back compass mag values. So a couple theories of the issue are:

1. True yaw really *is* oscillating. The FC values are bad for some reason.
2. Both front and back compass values are impaired or following some low frequency noise problem and yaw is not really oscillating.

Matlab verification of magYaw
View attachment 2929

There was another incident where a similar thing happened. The magYaw oscilllations came right at the end of a TBE.



It looks to me like smaller of your two magYaw oscillations also came at the end of a TBE.



@Logger , @Kilrah

 

[ScrappyMavic]

There was another incident where a similar thing happened. The magYaw oscilllations came right at the end of a TBE.
View attachment 2936
View attachment 2937

It looks to me like smaller of your two magYaw oscillations also came at the end of a TBE.
View attachment 2938
View attachment 2939

@Logger , @Kilrah

Thanks for pointing that out Bud. When I go to play the flight back in the Go app, it's fairly clear how I got 1 cycle of TBE prior to ATTI. Tonight I played with the "Sensitivity" and "Gain" values in Advanced Settings. I can see the effect on the aircraft, either slowing it's pitch/roll response or increasing it. Has anyone tested if TBE incidents can be increased/decreased with changing Sensitivity and Gain? It's my plan next flight...

 

[Logger]

What about flying backwards. Would this make the forward compass the noisy one
Hows the noise drop here as it rounds the bend!! Wasn't much wind but, seemingly enough for it to be able to to reduce power to maintain the 30mph I was asking for. Why is the MagZ so much thicker on the graph than the MagZBack?

 

[BudWalker]

View attachment 2953 What about flying backwards. Would this make the forward compass the noisy one
Hows the noise drop here as it rounds the bend!! Wasn't much wind but, seemingly enough for it to be able to to reduce power to maintain the 30mph I was asking for. Why is the MagZ so much thicker on the graph than the MagZBack?

The problem is caused by the proximity of the motor cables to the back compass and/or the back compass cabling. The front compass doesn't have that issue.

There are two reasons for the discrepancy between the magZ and magZ.Back thickness. The first is that by default the signals are plotted on different axes. I'm guessing you didn't press the "Multi Y Axis" button which would have then changed
to "Single Y Axis"

======>>>

The second reason, as pointed out by @ScrappyMavic , is that magZ.Back has a different gain and offset than magZ. So, even if you did select the Single Y Axis it wouldn't help. There are values in the eventLog stream that look to me to be the gain and offset values. But, I couldn't make them work. I.e. I couldn't use those numbers to derive magZ from magZ.Back.

BTW, you can expose the Y axis for a signal by right mouse click on the signal legend and then selecting the "Axis Visible"


I noticed that your plot says the Mavic wasn't connected to the RC. Was it corrected and that value is incorrect?

 

[Logger]

Thanks for the explanation on how ot use those other features. Will try them out later. The aircraft was disconnected in the grey period as I was using Litchi. So the value is correct. As are the others later on.Green = autoland, White ATTI mode and Red low battery RTH.

 

[BudWalker]

Thanks for the explanation on how ot use those other features. Will try them out later. The aircraft was disconnected in the grey period as I was using Litchi. So the value is correct. As are the others later on.Green = autoland, White ATTI mode and Red low battery RTH.

The value "Not Connected" means not connected to the RC. Wouldn't matter which app you using. I 'spect it's right since it goes to "Not Connected" during that part of the flight furthest from the homePoint.

 

[Logger]

Exactly, it was indeed disconnected as expected and showing "no signal" on the RC. It would matter which app in regard to my flight plan though as had I not been using Litchi and instead DIGo it would have carried out a signal loss RTH. Where as Litchi sticks to the plan

 

[BudWalker]

Exactly, it was indeed disconnected as expected and showing "no signal" on the RC. It would matter which app in regard to my flight plan though as had I not been using Litchi and instead DIGo it would have carried out a signal loss RTH. Where as Litchi sticks to the plan

I always thought it's the A/C that "sticks to the plan" or not. Besides how can the app initiate an RTH if the RC isn't connected. I think what happened was that the A/C won't do an RTH if it is doing a mission. Doesn't matter if it's a mission coming from Litchi or the Go App. Either one downloads the mission to the A/C and then the mission is under control of the A/C. Isn't that how it works?

 

[Logger]

Agreed. But would never been able to create this mission with DGIGo app as I would have to first fly it first to record and create it. This would not have been possible as it would have done the RTH at that point. Otoh with litchi creating the mission is done separately and uploaded.

 

[BudWalker]

Agreed. But would never been able to create this mission with DGIGo app as I would have to first fly it first to record and create it. This would not have been possible as it would have done the RTH at that point. Otoh with litchi creating the mission is done separately and uploaded.

I get it now.

 

[ScrappyMavic]

One quick update on TBE. I tried to reproduce my stick inputs that lead to TBE on two different flights using full battery. One with almost zero wind, one with 15 mph wind. In both cases I tried many different "gain" and "sensitivity" settings, with many different aircraft orientations, etc. I was never able to reproduce the TBE event. So, it's much harder to reproduce these things than I thought. Also no clear impact on causing more of them from gain and sensitivity settings.

 

[Ewan Morrish]

Hi Guys,
Geez what a long and extensive thread this is becoming! Good to see i'm not the only poor bugger with this issue, far from it, it would seem. So, in summary should I send my bird back to DJi or wait for new FW to see if that fixes the issue? If its a physical issue with the AC, i'd expect to better get the drone replaced? Thoughts?.

Ewan.

 

[leesmavic]

Wouldn't it be great if stick movements were recorded and then there was a way to 'upload' those stick commands to another AC? Easy way to test how other Mavic would handle the situation. Testing TBE-ness of a Mavic...

 

[Logger]

One quick update on TBE. I tried to reproduce my stick inputs that lead to TBE on two different flights using full battery. One with almost zero wind, one with 15 mph wind. In both cases I tried many different "gain" and "sensitivity" settings, with many different aircraft orientations, etc. I was never able to reproduce the TBE event. So, it's much harder to reproduce these things than I thought. Also no clear impact on causing more of them from gain and sensitivity settings.

Doesn't surprise me at all. The TBE of mine displayed above in post #106 occurred during a WPT mission which I have recorded and flown numerous times before and since in varying wind strengths..

 

[M Akbar Marwan]

Hi,
today I got firmware upgrade notice to 1.03.0200.
have you guys tested it yet?