Drone out of control, no crash

[VZ2]

Interesting. I'm wondering if IMU shares gyro and accelaration sensors input with gimbal processor or gimbal has it's own set of sensors... If you tied up the bird and span motors you can test this theory.

PS: if you take the quad in hand and move it around, would gimbal respond on that movement?
Or if you want to test motors, just remove props...

 

[VZ2]

I just took a look inside mavic pro and Gyro/Accelerometer PCB is in beetween stereo cameras at front.
So, IMU is using it as input for flight stabilization as well as for gimbal.
If problem is with the gimbal flex cable only then it should not affect the flight characteristics, only weird gimbal behavior.
If quad cannot get into stable hover then problem might be along Gyro/Accelerometer path.

 

[slup]

Dear all,

thanks for all the reply and your input. Also thank you very much for the warm welcome to this forum!

Before I will try the next flight, I would like to fully analyze the situation. The gimbal is defective for sure. I have ordered a ribbon cable from Amazon and if time allows, I will try to fix the gimbal by myself.

@slup: I have attached the requested file to this post and I am very curious what you can see in it. Which software do you use for analysis?

@fguthrie There were no signs of a bird contact, no scratches, no feathers.

@spamgnome I also thought about the possibility of a miscalibrated controller. My understanding is that you can see the stick inputs in the log file visualization (DJI Flight Log Viewer - PhantomHelp.com) and they seem to be fine.

Best regards and thanks for your help!
Alexander

Have looked over the mobile device DAT log ... unfortunately I can't find anything abnormal (besides the uncommanded yawing).

It's clearly something that makes the AC rotate but the source isn't the motors or props ... All motor data correlate well with each other when stacking up motor RPM's together with their command percentage & current draw.

Also the rotation isn't only into one direction as it should have been if one motor/prop was acting up ... it changes uncommanded a couple times until you can land it.

At 45sec (when the incident starts) it rotates slightly CCW
At 47-54sec you manually rotates the AC back CW
From 54sec it continues to rotate CW
At 79sec it changes direction to CCW
At 97-98sec it goes CW
And back to rotating CCW between 98-133sec
And from 133 until you land the rotation is CW

Also the IMU, the compass & the gyro agrees well and all show the same motion ...

So ... all this with a shifting yaw direction together with agreeing sensor data & no abnormal motor data makes me think that the main culprit in this case is coming from the AC flight control directly.

Looking into the event log show a big time gap ... nothing is written between 81sec until 362sec, that's not normal at all. Furthermore, just before the logging stops we see that some fails is logged ... then empty until you have landed.

All this looks like that the main flight controller came to a complete brainfart ... that can explain the erratic behavior as it in this case could have issued very strange commands to the ESC's that in turn made the AC fly like it did.

This is the first time I see something like this ... perhaps @BudWalker can see something I'm missing or can better pinpoint the reason?

 

[IalexI]

@VZ2: Gimbal is completely out of function. It moves to a wrong position and stays there. I removed the propellers and spun up the motors; I believe they are fine (see attachment).

 

[slup]

@VZ2: Gimbal is completely out of function. It moves to a wrong position and stays there. I removed the propellers and spun up the motors; I believe they are fine (see attachment).

As said earlier... the gimbal isn't the root cause, a failing gimbal will not make the AC go haywire. The gimbal was most probably damaged in all those erratic AC movements.

 

[BudWalker]

Have looked over the mobile device DAT log ... unfortunately I can't find anything abnormal (besides the uncommanded yawing).

It's clearly something that makes the AC rotate but the source isn't the motors or props ... All motor data correlate well with each other when stacking up motor RPM's together with their command percentage & current draw.

Also the rotation isn't only into one direction as it should have been if one motor/prop was acting up ... it changes uncommanded a couple times until you can land it.

At 45sec (when the incident starts) it rotates slightly CCW
At 47-54sec you manually rotates the AC back CW
From 54sec it continues to rotate CW
At 79sec it changes direction to CCW
At 97-98sec it goes CW
And back to rotating CCW between 98-133sec
And from 133 until you land the rotation is CW

Also the IMU, the compass & the gyro agrees well and all show the same motion ...

So ... all this with a shifting yaw direction together with agreeing sensor data & no abnormal motor data makes me think that the main culprit in this case is coming from the AC flight control directly.

Looking into the event log show a big time gap ... nothing is written between 81sec until 362sec, that's not normal at all. Furthermore, just before the logging stops we see that some fails is logged ... then empty until you have landed.

All this looks like that the main flight controller came to a complete brainfart ... that can explain the erratic behavior as it in this case could have issued very strange commands to the ESC's that in turn made the AC fly like it did.

This is the first time I see something like this ... perhaps @BudWalker can see something I'm missing or can better pinpoint the reason?

View attachment 122342

I agree. This seems to be a Flight Controller issue and not some sensor issue. This chart shows the commanded Z axis angular velocity (ctrl_horiz_ang_vel:gyro_cmdZ) and what actually happens (ctrl_horiz_ang_vel:gyro_fdbkZ).

The actual gyroZ is very close to the commanded gyroZ.

Note that the commanded gyroZ is oscillating from one extreme to the other at about 1Hz. Normally, this would converge to small corrections needed to maintain a given Yaw. This behavior could be caused by the Yaw control algorithm that has been slowed down, possibly because of insufficient compute resources. GyroZ is commanded to achieve a particular Yaw but the FC can't respond in time once that Yaw is achieved. The result is a Yaw overshoot requiring a commanded gyroZ in the opposite direction.

It's possible the on board .DAT will yield more info about the cause. It has higher frequency data. It also has the system_monitor records. Take a look here
How to retrieve a V3 .DAT File from the AC
to see how to retrieve the onboard .DAT.
@lalexl

 

[IalexI]

@slup @BudWalker thanks for the in-depth analysis. I had a look at the data and can follow your conclusions.

The AC FLY167.dat can be downloaded here:

FLY167.zip

drive.google.com

 

[BudWalker]

@slup @BudWalker thanks for the in-depth analysis. I had a look at the data and can follow your conclusions.

The AC FLY167.dat can be downloaded here:

FLY167.zip

drive.google.com

I took a quick look and don't see any more to add to what we know. Have you tried flying it since that incident? The problem existed until the MP had landed.

 

[IalexI]

Dear friends,

I just wanted to let you know that I received the ribbon cable today and I have already installed it.

When I powered-on the drone, I couldn't believe that the gimbal actually works again!

However, I now get an error message with the compass. I tried to calibrate it again and could see that "compass 1" is disconnected. I assume it's the compass in the front, which I needed to move in order to get to the gimbal assembly?

When I have time later this day, I will open the case again and see if I have disconnected anything.

At least a partial success story. Let's see if everything is ripped apart again during the first flight

Best regards
Alexander

 

[IalexI]

Dear all,

I have some more information for you:

1.) the compass error was related to a disconnected cable. After fixing this, the drone now boots without any issues and error messages.
2.) the old ribbon cable did not have any visible damage. However, I noticed that the back cover of the camera part is missing (screws are present). It could be that this piece was missing from the factory, but I am not sure. Does anybody have an idea how to get this part?
3.) I have successfully completed the first test flight. I let the craft hover at a height of 60 meters for about 10 minutes. No issues noticed.

So, what do we make out of this? Was it a software problem? An unknown interaction between the failing gimbal and flight stabilization?

If you don't have any better suggestion, I would now slowly increase the difficulties of the next flights and see how it behaves.

Best regards
Alexander

 

[Thomas B]

Dear all,

I have some more information for you:

1.) the compass error was related to a disconnected cable. After fixing this, the drone now boots without any issues and error messages.
2.) the old ribbon cable did not have any visible damage. However, I noticed that the back cover of the camera part is missing (screws are present). It could be that this piece was missing from the factory, but I am not sure. Does anybody have an idea how to get this part?
3.) I have successfully completed the first test flight. I let the craft hover at a height of 60 meters for about 10 minutes. No issues noticed.

So, what do we make out of this? Was it a software problem? An unknown interaction between the failing gimbal and flight stabilization?

If you don't have any better suggestion, I would now slowly increase the difficulties of the next flights and see how it behaves.

Best regards
Alexander

Well done!
I think you should begin cautious testing.

 

[IalexI]

Dear all,

further testing with the drone went without any issues.

If you are right that any gimbal error should not have an influence on flight behavior, this is a strange problem.

I also forgot to mention that I could see that the drone was spinning and wobbling when I landed it last week. So, in fact it had a hard time to stay in the air.

Best regards,
Alexander

 

[IalexI]

Dear all,

I just wanted to follow up.

I did further testing with this Mavic and all flights have been without any issues.

I started to trust it again and even took it to long distance flights (6 miles round trip) which worked perfectly.

So, this issue was either temporary or it was fixed by a new ribbon cable.

Best regards
Alexander

 

[Yogi053]

Well done Alexander. Stay safe!

 

[hjmavic]

Interesting and well documented story

 

[Harrier]

Good job!! [emoji2]

 

[Zonian]

Dear all,

I just wanted to follow up.

I did further testing with this Mavic and all flights have been without any issues.

I started to trust it again and even took it to long distance flights (6 miles round trip) which worked perfectly.

So, this issue was either temporary or it was fixed by a new ribbon cable.

Best regards
Alexander

Wow! I really hate to hear of these "unknown" issues or glitches...glad you are back flying. Still no issues since Feb 6 ??

 

[Tyranttrent2020]

That's not a crash. Is that a mavic 2 zoom by chance, it's got a car of the limp noodle it's the gimbal twitching around making it look like it's crashing but I assure you the bird is flying solid. You can try a firmware refresh but most people I hear are getting replacements. Trippy the first time it happened to me thought I was having a wicked heroing crash but the truth is these birds don't crash gracefully. Grab a brick and throw it through the air that's what these do. Do not fly over people you won't get any warning it will just be that brick. Good luck.

 

[Eden from Africa]

Well done Alex, hellavu job flying that back to dry land!!

 

[keat63]

Maybe run the motors without props initailly.