DJI Mavic, Air and Mini Drones
Friendly, Helpful & Knowledgeable Community
Join Us Now

Not Enough Force/ESC Error – Possibly due to wrong commands?

Nina Zenik

New Member
Joined
Apr 13, 2020
Messages
2
Reactions
2
Location
Hungary
Hello everyone. For a year, I flew my Mavic 2 Pro frequently without any problems, but a couple of weeks ago crashed it. I might have caused the problem myself, but I'm not sure. Here's what happened.

It was a totally quiet morning, with no wind at all. The drone took off and I flew in a straight line with it for about a minute. At this point, while in flight, I turned the camera to the left by touching the screen of the Smart Controller and swiping my finger. Then I used the 5D button to recenter the gimbal. Actually, with this command the camera used to look vertically downwards first, and then, to the second click of the 5D it used to move to look horizontally. So I clicked the 5D button twice, as always, but this time something went wrong (around 01m 13.1s).

I saw on the display that the horizon was starting to tilt to the left and the drone was slowly drifting to the left. As the log shows, at 01m 19.9s the drone suddenly turned to the left, although I saw on the screen that the camera was pointed constantly forward. I tried to move the drone forward at 01m 21.9s, my screen showed that the camera was pointing in the direction of the flight, but the horizon was already tilted at an angle of about 45 degrees by this time. I still tried to control the drone for a few seconds, but it didn't respond, the video transmission also disappeared around 01m 30s. I waited a few more minutes to see if the drone would return home by some miracle, but then I sadly determined that it had probably fallen into the river. Luckily, I did not forget to check the flight path on the Smart Controller. I went to the location where the flight ended on the map: after a little searching in the area, I found the drone in a small park, among trees. There was no one there because it was early in the morning, but of course the drone was broken.

I would really appreciate it if anyone could tell me what could have happened.

 

Attachments

  • 20-04-09-02-13-50_FLY090.DAT
    1.8 MB · Views: 7
Last edited:
  • Like
Reactions: Capt KO
This is an example of a relatively uncommon problem that has been seen a few times, all on the Mavic 2 if I remember correctly. The IMU loses track of aircraft yaw, as can be seen by the IMU solution for position and velocity, compared to GPS reference:

Position.png

Delta_V.png

As you can see from the yaw arrows in the first plot, it appears to correspond to a sudden change in the aircraft yaw, which is also recorded in the txt log:

Yaw_1.png

But notice that the rapid yaw is not due to any rudder input - it just appears to happen. Looking instead at the DAT file, which contains the compass data and both IMU solutions:

yaw.png

You can see the compass calibration done before the flight, which looks good, and then mostly good agreement between the IMU0 and IMU1 magnetic yaw solutions (blue solid and dashed lines). The green IMU yaw values are primarily derived from the rate gyros after initialization by the compass. At 80 seconds, IMU1, which is the active IMU, reports a sudden CCW yaw, which neither the compass nor IMU0 detects. All other things being equal, that is therefore suggestive of a problem with the IMU1 rate gyros, specifically the z-axis rate gyro. But comparing the time integrals of the IMU0 and IMU1 z-axis gyro shows that it was not the problem:

gyros.png

Neither rate gyro detected that rotation. Which leaves the obvious question about IMU1 - what on earth was it thinking? The only explanation that we have come up with, which was later corroborated to some extent by the DJI response to a previous similar event, was that it was a computational error caused by processor overload.

In any case, it's clearly equipment failure, not that it helps if your Mavic is over a year old.
 
This is an example of a relatively uncommon problem that has been seen a few times, all on the Mavic 2 if I remember correctly. The IMU loses track of aircraft yaw, as can be seen by the IMU solution for position and velocity, compared to GPS reference:

View attachment 99246

View attachment 99247

As you can see from the yaw arrows in the first plot, it appears to correspond to a sudden change in the aircraft yaw, which is also recorded in the txt log:

View attachment 99248

But notice that the rapid yaw is not due to any rudder input - it just appears to happen. Looking instead at the DAT file, which contains the compass data and both IMU solutions:

View attachment 99249

You can see the compass calibration done before the flight, which looks good, and then mostly good agreement between the IMU0 and IMU1 magnetic yaw solutions (blue solid and dashed lines). The green IMU yaw values are primarily derived from the rate gyros after initialization by the compass. At 80 seconds, IMU1, which is the active IMU, reports a sudden CCW yaw, which neither the compass nor IMU0 detects. All other things being equal, that is therefore suggestive of a problem with the IMU1 rate gyros, specifically the z-axis rate gyro. But comparing the time integrals of the IMU0 and IMU1 z-axis gyro shows that it was not the problem:

View attachment 99265

Neither rate gyro detected that rotation. Which leaves the obvious question about IMU1 - what on earth was it thinking? The only explanation that we have come up with, which was later corroborated to some extent by the DJI response to a previous similar event, was that it was a computational error caused by processor overload.

In any case, it's clearly equipment failure, not that it helps if your Mavic is over a year old.
This incident is similar to three incidents I looked at here
Incidents caused by an incorrect IMU(1):Yaw
Like this incident they took place over water when the vision system was reporting an incorrect height. Then IMU(1):Yaw abruptly diverges from all the other measured and computed Yaw values.

I gave up trying to figure out the connection between the an incorrect VIO:posZ and the subsequent problems. But, this has happened enough times that I think they are related.
 
  • Like
Reactions: slup
This incident is similar to three incidents I looked at here
Incidents caused by an incorrect IMU(1):Yaw
Like this incident they took place over water when the vision system was reporting an incorrect height. Then IMU(1):Yaw abruptly diverges from all the other measured and computed Yaw values.

I gave up trying to figure out the connection between the an incorrect VIO:posZ and the subsequent problems. But, this has happened enough times that I think they are related.

I did take a look at the vio data in this case, but when it is reporting, which is very sporadic, it appears to be approximately correct. Are you seeing a discrepancy?
 
I did take a look at the vio data in this case, but when it is reporting, which is very sporadic, it appears to be approximately correct. Are you seeing a discrepancy?
That's right, the VIO yaw, pitch, and roll data all look consistent with both IMU data. Until posZ departs from relativeHeight - probably because it's over water. Then IMU(1):Yaw abruptly diverges from all the other measured and computed Yaw values.

It's all described in
Incidents caused by an incorrect IMU(1):Yaw

I'm not saying I can explain the reason. But, I am saying it's happened enough times that I think there is a relationship. This has also happened with the MavicAir
 
That's right, the VIO yaw, pitch, and roll data all look consistent with both IMU data. Until posZ departs from relativeHeight - probably because it's over water. Then IMU(1):Yaw abruptly diverges from all the other measured and computed Yaw values.

It's all described in
Incidents caused by an incorrect IMU(1):Yaw

I'm not saying I can explain the reason. But, I am saying it's happened enough times that I think there is a relationship. This has also happened with the MavicAir

Are you referring to the brief vio posZ burst of data just before the unexplained yaw?

vio.png

At first sight the values are approximately correct, but in fact the water surface is actually 60 m lower than the takeoff elevation, so it is well off. I agree that the timing of those vio data are suggestive, and it is a little odd that it is reporting vio height data at over 100 m.
 
  • Like
Reactions: BudWalker
This is an example of a relatively uncommon problem that has been seen a few times, all on the Mavic 2 if I remember correctly. The IMU loses track of aircraft yaw, as can be seen by the IMU solution for position and velocity, compared to GPS reference:

View attachment 99246

View attachment 99247

As you can see from the yaw arrows in the first plot, it appears to correspond to a sudden change in the aircraft yaw, which is also recorded in the txt log:

View attachment 99248

But notice that the rapid yaw is not due to any rudder input - it just appears to happen. Looking instead at the DAT file, which contains the compass data and both IMU solutions:

View attachment 99249

You can see the compass calibration done before the flight, which looks good, and then mostly good agreement between the IMU0 and IMU1 magnetic yaw solutions (blue solid and dashed lines). The green IMU yaw values are primarily derived from the rate gyros after initialization by the compass. At 80 seconds, IMU1, which is the active IMU, reports a sudden CCW yaw, which neither the compass nor IMU0 detects. All other things being equal, that is therefore suggestive of a problem with the IMU1 rate gyros, specifically the z-axis rate gyro. But comparing the time integrals of the IMU0 and IMU1 z-axis gyro shows that it was not the problem:

View attachment 99265

Neither rate gyro detected that rotation. Which leaves the obvious question about IMU1 - what on earth was it thinking? The only explanation that we have come up with, which was later corroborated to some extent by the DJI response to a previous similar event, was that it was a computational error caused by processor overload.

In any case, it's clearly equipment failure, not that it helps if your Mavic is over a year old.

Thank you very much for your thorough analysis. It represents a level of expertise that I'm unfortunately very far from. I really appreciate your help.

So I understand it's equipment failure. Do you think it is enough to mechanically repair the aircraft, or could there be a processor problem that could re-emerge?
 
  • Like
Reactions: Capt KO
Thank you very much for your thorough analysis. It represents a level of expertise that I'm unfortunately very far from. I really appreciate your help.

So I understand it's equipment failure. Do you think it is enough to mechanically repair the aircraft, or could there be a processor problem that could re-emerge?

Hard to say since it seems to be a very rare occurrence, with no data at all on whether it has ever recurred.
 
  • Like
Reactions: Nina Zenik
Thank you very much for your thorough analysis. It represents a level of expertise that I'm unfortunately very far from. I really appreciate your help.

So I understand it's equipment failure. Do you think it is enough to mechanically repair the aircraft, or could there be a processor problem that could re-emerge?
IMHO, this is due to a design flaw. Any other M2 would likely have behaved the same way. Fusing IMU and vision data to obtain AC attitude and position data must be a complicated business. It appears, at least to me, that VIO data was incorrect but used anyway by the FC to determine Yaw. From the looks of it the abrupt change in IMU(1):Yaw indicates that the fusion scheme is, at least partly, rules-based. I.e. it's not your usual numerical scheme that smooths out the onset of incorrect estimates.
 
Lycus Tech Mavic Air 3 Case

DJI Drone Deals

New Threads

Forum statistics

Threads
130,583
Messages
1,554,094
Members
159,588
Latest member
gfusato