Lost my second DJI drone....this time a Mavic Air 2

[PhantomFandom]

I saw many people criticizing MA2 for having a single IMU (versus other Mavic drones which have 2 IMUs), implying such a setup lacks redundancy and therefore is less safe. I personally disagree with such notion because I have never seen a modern "9-axis" IC failing even in extreme conditions and always wondered about algorithm which would choose one IMU over the other (felt like the software responsible for the switch could be a weak link, compromising safety rather than improving it).

I would tend to agree that the failure of an IC is rare, but it certainly is not impossible. I have in fact had an IMU failure on a P4. It has dual IMUs and one of them failed. The craft worked perfectly in every way on the backup IMU. I replaced the controller board and was back in business with dual IMUs.

The issue of having exactly 2 IMUs though is problematic for anything other than a hard and obvious failure. One would think that a better solution would be to have 3 units so that they can vote and more readily determine a soft failure where the IMU is still active but just giving errant readings. With only 2 of them, it would come down to either a random choice between the two or trying to correlate the readings with other instruments that are independent of the IMU. I don't know if the DJI firmware does this or if it is even feasible (with the processing power onboard) in real time to make those calculations while trying to keep the drone properly oriented.

 

[BudWalker]

This is really weird …..

Firstly, the FC totally ignored all other sensor outputs but just trusted IMU_ATTI_1_baraometer Smooth. There is no sensor fusion in the dronie quickshot mode ?

Secondly, I have always thought that IMU_ATTI_1_baraometer_Smooth is just the smoothed version of IMU_ATTI_1_baraometer_Raw. It’s obviously not the case here.

As the descent was due to screwed-up barometer readings, it has nothing to do with water reflection confusing the sensors but many just quickly jumped to that conclusion.

May be I have missed related reports but I am yet to see a substantiated case ( ie, proved by flight logs ) of drones going into water because of sensors being confused by water in some ways. My M2P has been flown very close to water surface many times and there has been no issue.

You're right. Barometer_Smooth is not just a smoother version of barometer_Raw. Smooth will get initialized to Raw but often will then diverge from Raw. I suspect that Smooth is the result of the FC fusing several different data.

This illustrates a problem with DatCon that has always existed. DatCon was developed at a time when there was absolutely no information about the contents of the .DAT file. It was all about industrial grade reverse engineering the contents. Out of the hundreds of plots that could be generated from a .DAT it was apparent that these 2 signals (Raw and Smooth) were related to height from the shape of their plots. Then came the guess that they were barometer related because heights were dependent on the barometric pressure at the time of the flight. After that was an experiment were a Mavic was put in an air tight bag and then squeezed to see that Smooth looked like a low pass (i.e. averaged) version of Raw.

There are many cases like this - where the labeling and/or interpretation of a data field has been influenced by the requirements of reverse engineering.

About 2 years ago it became apparent that the P4 and later platforms had .DAT files that were, to some extent, self documenting. In this particular case .DAT has the info
name IMU_ATTI_0
:
Op.float press0 0
:
Op.float alti0 0
:
were press0 and alti0 ends up being labelled by DatCon as Raw and Smooth, respectively. I suspect that if these labels were being used instead then flight analysts would have realized long ago that alti0 isn't just a smoothed version of press0.

But, using the self documenting information has it's drawbacks. First, it's just labels. That same .DAT has
name IMU_ATTI_0
:
Op.float ax0 0
Op.float ay0 0
Op.float az0 0
Op.float wx0 0
Op.float wy0 0
Op.float wz0 0
:
It's pretty easy to guess that ax0 is acceleration:X. But, who could guess that wx0 is gyro:X.

More importantly, the self documenting info is often incorrect. This is caused by the .DAT file corruptions that often occur in the .DAT. Those records have to be rejected which can then cause missing entries in the self documentation. It's also the case that the self documenting is just incorrect.

I've recently figured out how to make DatCon smarter about determining the properties of a corruption and how, in many cases, to fix that corruption. The next DatCon version is a major re-organization where many of the labels originating in the reverse engineering era will be replaced with those coming from the self documentation. I suspect this will be a rip-the-band-aid-off-it'll-eventually-be-better situation and I'm sure there will be those who will express the if-it-ain't-broke-why-fix-it view. I'm sympathetic.

 

[boblui]

I suspect that Smooth is the result of the FC fusing several different data.

This is true at least in this case. The smooth is almost identical to OSD_height. The sensor fusion computation is deadly wrong here.

 

[sar104]

It's pretty easy to guess that ax0 is acceleration:X. But, who could guess that wx0 is gyro:X.

Actually that is one of the few records with an intuitive name. The lower case "w" is often used in place of "ω" (lower case omega), which is the standard physics notation for angular velocity.

 

[sar104]

sar104, this caught my attention. Could you please explain -- does MA2 have, in fact, two independent IMUs? Or is one of them just a dummy, a programming relict from other Mavic's codebases which were re-used for MA2?

I saw many people criticizing MA2 for having a single IMU (versus other Mavic drones which have 2 IMUs), implying such a setup lacks redundancy and therefore is less safe. I personally disagree with such notion because I have never seen a modern "9-axis" IC failing even in extreme conditions and always wondered about algorithm which would choose one IMU over the other (felt like the software responsible for the switch could be a weak link, compromising safety rather than improving it).

Your analysis of this crash seems to suggest there is indeed some critical programming error related to sensor integration. I am afraid that second IMU, if it truly exists in hardware, may complicate things even further for DJI and will make it more difficult to get rid of bugs.

I haven't seen any official statements on the existence of redundant IMUs in the MA2 but there are clearly two independent and different record sets in the flight log, so unless it is wasting processor cycles inventing data then I would have to conclude that it does have two IMUs.

 

[fGene]

I haven't seen any official statements on the existence of redundant IMUs in the MA2 but there are clearly two independent and different record sets in the flight log, so unless it is wasting processor cycles inventing data then I would have to conclude that it does have two IMUs.

This is important news! It's very unlike DJI not to advertise this fact, and even get some bashing for it -- which now seems to be based on wrong assumptions.

 

[fGene]

I would tend to agree that the failure of an IC is rare, but it certainly is not impossible. I have in fact had an IMU failure on a P4. It has dual IMUs and one of them failed. The craft worked perfectly in every way on the backup IMU. I replaced the controller board and was back in business with dual IMUs.

I agree sometimes a second IMU would be helpful, but I also heard stories about crashes caused by software confused by contradicting data and choosing the wrong IMU to rely upon.

The issue of having exactly 2 IMUs though is problematic for anything other than a hard and obvious failure. One would think that a better solution would be to have 3 units so that they can vote and more readily determine a soft failure where the IMU is still active but just giving errant readings. With only 2 of them, it would come down to either a random choice between the two or trying to correlate the readings with other instruments that are independent of the IMU. I don't know if the DJI firmware does this or if it is even feasible (with the processing power onboard) in real time to make those calculations while trying to keep the drone properly oriented.

I could not agree more. If go for the trouble of installing redundant sensors, why not do it properly and make the system robust enough to actually make sense. I would definitely much prefer 3 IMUS to either one or two of them, but I would still choose one over two because of the mentioned confusion factor.

 

[boblui]

The issue of having exactly 2 IMUs though is problematic ...... With only 2 of them, it would come down to either a random choice between the two or trying to correlate the readings with other instruments that are independent of the IMU.

... if it is even feasible (with the processing power onboard) in real time to make those calculations ....

I am pretty sure the firmware does not simply make a random choice when the readings of the two IMUs do not agree. The IMU is not the only sensor that can detect linear motion and rotation, the compass, barometer, camera at the belly, GPS can also do part of IMU's job so the firmware can do cross checking before coming up with a judgement on which sensors are trustworthy and which not.

Not sufficient computing power ? Even cheap drones like the Mini can do such cross checking. The other day I have done a test to fool my Mini's compass by sticking a magnet to it's body. The orientation of the craft shown on the FLY app was initially wrong but after moving the craft around for a while, it was able to correlate the IMU and GPS readings and come up with a correct judgement on the orientation of the craft.

 

[fGene]

I am pretty sure the firmware does not simply make a random choice when the readings of the two IMUs do not agree. The IMU is not the only sensor that can detect linear motion and rotation, the compass, barometer, camera at the belly, GPS can also do part of IMU's job so the firmware can do cross checking before coming up with a judgement on which sensors are trustworthy and which not.

I believe short-term corrections (which are crucial to keep the drone balanced in the air) can be performed only by IMU (3-axis gyros + 3-axis accels most importantly). Compass is helping too but it way too imprecise and slow to actually contribute in short term. GPS doesn't tell the software anything about drone's orientation, only position and speed (integrated position over time), the barometer is even less helpful in this regard. VPS only works in certain condition (height, light) and cannot be universally relied upon, besides integrating their data is quite computationally expensive.

So I fully agree with PhantomFandom that soft failure of one of two IMUs can be a major concern, but if there were three, a simple voting algorithm could be implemented easily and be potentially very beneficial.

 

[boblui]

I believe short-term corrections (which are crucial to keep the drone balanced in the air) can be performed only by IMU (3-axis gyros + 3-axis accels most importantly). Compass is helping too but it way too imprecise

If IMU1 detects a rotation of 10 degree, IMU2 50 degree and the compass 45 degree, you can tell with good confidence that IMU1 is not to be trusted. The absolute reading of compass is not reliable because of potential existence of magnetic interference but I cant see why it cannot detect a delta accurately. Like wise, the absolute coordinate from GPS is subject to an error of a few meters but the delta is way smaller than that. Just see how well a drone can hold position base on GPS.

the barometer is even less helpful in this regard. VPS only works in certain condition (height, light) and cannot be universally relied upon

Same logic as above.

GPS doesn't tell the software anything about drone's orientation, only position and speed (integrated position over time),

Check out this post on how my Mini managed to get the correct orientation reading when the compass is way off : Compass error demonstration . I am convinced that it used the GPS and IMU data in the process.

besides integrating their data is quite computationally expensive.

True in the IBM PC era but today ? I am not sure if I can agree with that.

 

[fGene]

If IMU1 detects a rotation of 10 degree, IMU2 50 degree and the compass 45 degree, you can tell with good confidence that IMU1 is not to be trusted.

Like I said, the compass is slow, the gyros are orders of magnitude faster. In your example, if the drone was initially relying on the first IMU (which presumably soft-failed in flight) than by the time it detects discrepancy based on compass data the drone would already be tumbling down from the sky with data from all sensors all over the place (avalanche effect) and no way of telling which is correct.

In short, data from IMU can be only substituted by data from another IMU because it is very time-critical, and in my opinion the decision to switch between them can be reliably made only by integrating data from yet another, third IMU.

The absolute reading of compass is not reliable because of potential existence of magnetic interference but I cant see why it cannot detect a delta accurately. Like wise, the absolute coordinate from GPS is subject to an error of a few meters but the delta is way smaller than that. Just see how well a drone can hold position base on GPS.

Again, the GPS data is irrelevant as it can't substitute, or even compliment, IMU data. These sensors provide completely different, unrelated measurements.

Check out this post on how my Mini managed to get the correct orientation reading when the compass is way off : Compass error demonstration . I am convinced that it used the GPS and IMU data in the process.

I am not sure how it is related to IMU failure we're discussing.

True in the IBM PC era but today ? I am not sure if I can agree with that.

I think it is true and will remain true. No matter how powerful the CPU is, there are always other things that it can do if it were even more powerful. To illustrate: on MA2 obstacle avoidance is automatically turned off when the drone is filming at 4k60 H.265.

 

[BudWalker]

From what I've seen it seems that different FC algorithms are being run on each IMU. So it's not an attempt at HW redundancy but, rather an attempt at software diversity.

 

[BudWalker]

If IMU1 detects a rotation of 10 degree, IMU2 50 degree and the compass 45 degree, you can tell with good confidence that IMU1 is not to be trusted. The absolute reading of compass is not reliable because of potential existence of magnetic interference but I cant see why it cannot detect a delta accurately. Like wise, the absolute coordinate from GPS is subject to an error of a few meters but the delta is way smaller than that. Just see how well a drone can hold position base on GPS.

Generally, a defective compass calibration will present as a distorted response. The delta won't be uniform across all orientations. The error may be +10 ° in one direction and -10 ° in another direction.

The reason the drone can hold position better than the normal GPS accuracy is that the location is computed by fusing the IMU, magnetometer and GPS data.

 

[sar104]

I believe short-term corrections (which are crucial to keep the drone balanced in the air) can be performed only by IMU (3-axis gyros + 3-axis accels most importantly). Compass is helping too but it way too imprecise and slow to actually contribute in short term. GPS doesn't tell the software anything about drone's orientation, only position and speed (integrated position over time), the barometer is even less helpful in this regard. VPS only works in certain condition (height, light) and cannot be universally relied upon, besides integrating their data is quite computationally expensive.

So I fully agree with PhantomFandom that soft failure of one of two IMUs can be a major concern, but if there were three, a simple voting algorithm could be implemented easily and be potentially very beneficial.

One slight correction - GNSS provides both position (timing) and velocity (Doppler shift) directly - it is not relying on the time-derivative of position to determine velocity.

 

[sar104]

This is important news! It's very unlike DJI not to advertise this fact, and even get some bashing for it -- which now seems to be based on wrong assumptions.

The Mavic Air 2 specifications on the DJI website clearly state "Single IMU", so I cannot explain the existence of dual IMU records in the DAT file.

@BudWalker - any ideas?

 

[SkyeHigh]

I haven't seen any official statements on the existence of redundant IMUs in the MA2 but there are clearly two independent and different record sets in the flight log, so unless it is wasting processor cycles inventing data then I would have to conclude that it does have two IMUs.

According to DJI’s own published Specs there is only one IMU.

Mavic Air 2 - Specifications - DJI

From 48MP photos to a 34-minute max flight time, find out everything you need to know about Mavic Air 2.

www.dji.com

But then they aren’t renown for accurate/complete documentation. ;-)

 

[fGene]

From what I've seen it seems that different FC algorithms are being run on each IMU. So it's not an attempt at HW redundancy but, rather an attempt at software diversity.

Now I'm totally confused. Currently there are well-established ways of integrating 6-axis data (let's leave compass data out of for now). A long time ago such algorithms were Euler-angle based and indeed susceptible to gimbal lock effect, a condition which would probably justify using a second IMU; however now they are mostly quaternion-based and highly robust. I don't understand what benefit could be gained by taking a different software pathway. Could you please explain?

 

[BudWalker]

Now I'm totally confused. Currently there are very established ways of integrating 6-axis data (let's leave compass data out of equation for now). A long time ago such algorithms were Euler-angle based and were indeed susceptible to gimbal lock effect, which would probably justify using a second IMU, but now they are mostly quaternion-based and highly robust. I don't understand what benefit could be gained by taking a different software pathway. Could you please explain?

I'm not that familiar with the 6-axis integration algorithms. But, after that step the results then have to fused with GPS, ultrasonic height, barometer and vision system data. It's this part that I'm supposing is done in different ways.

There have been several incidents where Yaw has been abruptly changed in one IMU and not the other. The gyro data (excuse me, I mean the angular velocity data ω ) clearly shows the rotation didn't actually happen. The FC was adjusting Yaw to what it thought it should be. Since this happened with just one of the IMUs I'm speculating that there must be some type of secondary non-conventional fusing that's different for each IMU.

 

[BudWalker]

The Mavic Air 2 specifications on the DJI website clearly state "Single IMU", so I cannot explain the existence of dual IMU records in the DAT file.

@BudWalker - any ideas?

What can I say? I think this would tend support the idea that each IMU record is the result of different fusing algorithms. The small differences in the acceleration and gyro (oops angular velocity) data could be the result of slightly offset sampling times. I.e. they both come from the same sensors but sampled at different times.

Too bad we can't see the on board .DAT which might show the raw data for each set of sensors.

 

[boblui]

Generally, a defective compass calibration will present as a distorted response. The delta won't be uniform across all orientations. The error may be +10 ° in one direction and -10 ° in another direction.

In my example, I am assuming that the compass is correctly calibrated, only the external magnetic field is distorted. If all sensors are bad then the fused result will not be any better.

The reason the drone can hold position better than the normal GPS accuracy is that the location is computed by fusing the IMU, magnetometer and GPS data.

I have some doubt on this because without GPS, the drone will be in ATTI mode and we have all seen the resulting magnitude of drift in position. With GPS avaiable, it holds position a lot better. GPS can detect change in position very accurately by sensing the doppler shift. Every GPS satellite seen by the drone acts like a laser gun pointing to it. That's how GPS speedometers work.