I did the "refresh" option in Assistant 2 for the 12-21 v01.03 without downgrading / upgrading. I don't see any change in the compass behavior or gimbal limit errors.
Firmware v01.03.0000 Compass Error.
- Thread starter Ewan Morrish
- Start date
I did the "refresh" option in Assistant 2 for the 12-21 v01.03 without downgrading / upgrading. I don't see any change in the compass behavior or gimbal limit errors.
Thanks for the update, so it seems some Mavics either have a faulty compass (too susceptible to interference) or they have noisy wiring. It seems for DJI to fix they will release an updated FW which is optimised for the noisy parts whilst still preventing the TBE. The other option is to RMA your drone and either have it replaced with a new one or have the noisy parts replaced.I did the "refresh" option in Assistant 2 for the 12-21 v01.03 without downgrading / upgrading. I don't see any change in the compass behavior or gimbal limit errors.
Very annoying I will start the RMA process today, this will be my 3rd replacement Mavic since September
I can't believe it!!!Thanks for the update, so it seems some Mavics either have a faulty compass (too susceptible to interference) or they have noisy wiring. It seems for DJI to fix they will release an updated FW which is optimised for the noisy parts whilst still preventing the TBE. The other option is to RMA your drone and either have it replaced with a new one or have the noisy parts replaced.
Very annoying I will start the RMA process today, this will be my 3rd replacement Mavic since September
I'm not convinced it's an RMA job yet.. I would hold out untill the next firmware ..
This would be a major hardware flaw if it was
I took pictures of my stickers to see if it changed. Mine was officially 'received' today. I shipped it using their pre-paid ground label on 12/14. 5 days to get there (from FL), one day to 'receive' it. I was hoping (against hope) to get it back before x-mas, since I have to large family gatherings where group aerial photos would have been nice... not to mention a neat way to promote the MP to family and friends.
Hopefully those who have replaced their Mavics due to the compass error could ensure the current FW is loaded then provide Datcom graphs showing the compass noise whilst flying max speed in sports mode. It would be interesting to see how the noise compares to the dodgy compasses.
Something tells me that you'll try flying sport mode, full elevator. When you do could you provide a Dropbox link to the .DAT so we can see if the back compass is better behaved?
Hi all,
I just had my first GPS to ATTI switch while running on compass 2. For about the last week, I have been starting every flight with a quick burst of sport mode until the compass redundancy message appears and I then verify I'm using compass 2. I verified compass 2 at the start of my flight today, and right after the ATTI event happened and I regained GPS mode I again verified compass 2 was still selected. Digging into the data from DatCon, I can see that compass 2 (Front) really was selected the whole time. Further, the data from compass 2 was nice and clean the whole time. Looking at many signals and trying to find the root cause, the main thing I note is some unstable oscillations in pitch, roll, magYaw right after a hard input stick combo of elevator and aileron. The delta between Yaw and magYaw was slightly high and rising at the time of the switch to ATTI, but not significantly higher than earlier in the flight... at least prior to the oscillations on magYaw.
In the last plot with pitch and roll, note Aileron and Elevator stick inputs are swapped which appears to be a minor DatCon issue right now. (Elevator should generate the large pitch changes) Anyway, after a strong Elevator (Aileron below) input that returns to zero, you will normally see a nice clean brake operation in pitch afterwards. However, in the final issue prior to ATTI, the brake operation turns into pitch,roll,yaw oscillations of large amplitude. It appears this is the primary cause of entering ATTI mode. With a quadcopter, the combined elevator and aileron inputs both returning to zero require a "coupled" brake operation as one rotor is low, one is high, and the combined brake will feed one rotor about twice as hard as a single axis motion would. It is my theory that something in the control system is not stable in this case and maybe some gains are too high or not correctly handling some nonlinear features. Perhaps the magYaw error plays into this as a third variable. At least we can say there is no noise or other issue with compass 2 (Front). This still gives me hope that firmware tuning can fix this in the next release.
Verifying that compass 2 (Front) really was in use the whole time prior to ATTI (flyCState == 1 is ATTI)
Looking at Yaw vs. magYaw prior to ATTI
Looking at pitch, roll, and stick inputs prior to ATTI (note Aileron and Elevator are swapped below)
I just had my first GPS to ATTI switch while running on compass 2. For about the last week, I have been starting every flight with a quick burst of sport mode until the compass redundancy message appears and I then verify I'm using compass 2. I verified compass 2 at the start of my flight today, and right after the ATTI event happened and I regained GPS mode I again verified compass 2 was still selected. Digging into the data from DatCon, I can see that compass 2 (Front) really was selected the whole time. Further, the data from compass 2 was nice and clean the whole time. Looking at many signals and trying to find the root cause, the main thing I note is some unstable oscillations in pitch, roll, magYaw right after a hard input stick combo of elevator and aileron. The delta between Yaw and magYaw was slightly high and rising at the time of the switch to ATTI, but not significantly higher than earlier in the flight... at least prior to the oscillations on magYaw.
In the last plot with pitch and roll, note Aileron and Elevator stick inputs are swapped which appears to be a minor DatCon issue right now. (Elevator should generate the large pitch changes) Anyway, after a strong Elevator (Aileron below) input that returns to zero, you will normally see a nice clean brake operation in pitch afterwards. However, in the final issue prior to ATTI, the brake operation turns into pitch,roll,yaw oscillations of large amplitude. It appears this is the primary cause of entering ATTI mode. With a quadcopter, the combined elevator and aileron inputs both returning to zero require a "coupled" brake operation as one rotor is low, one is high, and the combined brake will feed one rotor about twice as hard as a single axis motion would. It is my theory that something in the control system is not stable in this case and maybe some gains are too high or not correctly handling some nonlinear features. Perhaps the magYaw error plays into this as a third variable. At least we can say there is no noise or other issue with compass 2 (Front). This still gives me hope that firmware tuning can fix this in the next release.
Verifying that compass 2 (Front) really was in use the whole time prior to ATTI (flyCState == 1 is ATTI)
Looking at Yaw vs. magYaw prior to ATTI
Looking at pitch, roll, and stick inputs prior to ATTI (note Aileron and Elevator are swapped below)
Attachments
Scrappy pardon my ignorance but how do you tell from the first graph which compass is actually in use or selected?
Yes, you did. I was asking for a .DAT for a flight after it was returned. So that a comparison could be made.
Is there a button where I can say Like times 10?Yes, there is a aileron/elevator bug that I noticed right after DatCon 2.4.1 was released. It will be fixed in 2.4.2.
I'm supposing you know this but magYaw is computed by DatCon; the AC doesn't have this value. It probably has values like it that is used to detect situations where ATTi mode should be used. It's been a pretty good diagnostic.
There were many P3 flights where the onset of a Yaw/magYaw separation immediately preceded a switch from GPS_ATTI to ATTI. Quite often this was coincident with an abrupt attitude change not caused by control inputs, such as a gust of wind. It's my theory the switch to ATTI is the FC saying it can't be confident enough to navigate.
Would you mind posting a Dropbox link to the .DAT?
The signal "magZ" is being used by flight controller. You can then compare it's noise/shape signature to magZ.Front and magZ.Back to see which sensor is feeding it. (ignoring some static gain/offset differences) If you look at the plot, you will see the large noise bursts on magZ.Back don't show up on magZ. Hence the cleaner magZ.Front was in use.
Yes, there is a aileron/elevator bug that I noticed right after DatCon 2.4.1 was released. It will be fixed in 2.4.2.
I'm supposing you know this but magYaw is computed by DatCon; the AC doesn't have this value. It probably has values like it that is used to detect situations where ATTi mode should be used. It's been a pretty good diagnostic.
There were many P3 flights where the onset of a Yaw/magYaw separation immediately preceded a switch from GPS_ATTI to ATTI. Quite often this was coincident with an abrupt attitude change not caused by control inputs, such as a gust of wind. It's my theory the switch to ATTI is the FC saying it can't be confident enough to navigate.
Would you mind posting a Dropbox link to the .DAT?
Thanks Bud! Is the magYaw calculation in DatCon using roll and pitch to "rotate to horizontal plane"? I'm wondering if the lack of this maybe causes magYaw to oscillate prior to my ATTI event while Yaw from the FC is stable. (because aircraft is pitching/rolling heavily at the time) I found an example of this compensation here.
Here's a link to my GPS to ATTI issue on compass 2 with google drive: here
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?
Similar threads
DJI Drone Deals
New Threads
-
-
DJI Air 2S Fly More Combo (w/ 4th Battery) FOR SALE $650- Started by Dan AISCF
- Replies: 0
-
-
-
Forum statistics
