Mavic Mini uncontrolled fly away

[sar104]

I found the DAT file on my android phone. See the attachment.

That's not the DAT file - it's the txt log that you supplied previously. The DAT file will be in the MCDatFlightRecords subfolder and will have a filename ending FLY021.DAT.

 

[sar104]

I hadn't seen that thread before. However, it turns out that the successful RTH was pure chance - several errors cancelled out. And it was not a magnetically distorted launch site - it was a faulty compass. I've posted the explanation in that thread.

I forgot to add the link to the other thread:

Mavic Mini out of control - saved by RTH

Yes that is correct. I took off from the ice quickly, and usually let it hover until everything is locked in. Since I was planning to just fly strait up and pan around directly above I wasn’t expecting it to start flying away like it did. May not be anything inside the trailer. Outside where it...

mavicpilots.com

 

[ManiakjeNL]

That's not the DAT file - it's the txt log that you supplied previously. The DAT file will be in the MCDatFlightRecords subfolder and will have a filename ending FLY021.DAT.

Sorry, i'm a bit of a newbie with this hahah.

see attachment again for the correct file.

 

[sar104]

Sorry, i'm a bit of a newbie with this hahah.

see attachment again for the correct file.

That's the one. It wasn't a magnetically distorted launch point, unless the entire region is distorted, which seems unlikely. The compass is simply not working. And it looks like another case where the yaw rather randomly and fortuitously ended up correct due to a combination of errors in the initial value and the subsequent vision and gyro data. I'm not sure why the IMU calculated more rotation than either the VIO system or the pure inertial solution, but it was lucky that it did.



At 60 seconds the IMU yaw, which was incorrectly initialized and subsequently ignored the spurious compass data, ended up at 50° (wrapped). The aircraft was actually pointing at around 60° at the time - close enough for navigation using just the rate gyros for rotation.

That is just like the case I linked to above in post #22.

 

[slup]

That's the one. It wasn't a magnetically distorted launch point, unless the entire region is distorted, which seems unlikely. The compass is simply not working. And it looks like another case where the yaw rather randomly and fortuitously ended up correct due to a combination of errors in the initial value and the subsequent vision and gyro data. I'm not sure why the IMU calculated more rotation than either the VIO system or the pure inertial solution, but it was lucky that it did.

View attachment 95401

At 60 seconds the IMU yaw, which was incorrectly initialized and subsequently ignored the spurious compass data, ended up at 50° (wrapped). The aircraft was actually pointing at around 60° at the time - close enough for navigation using just the rate gyros for rotation.

That is just like the case I linked to above in post #22.

One time , is one time ... two times start to look like a habit (freely translated from Swedish ? )

Can the AC have been stored in a stronger magnetic field ... have any clue to why the compass behaves like it does?
Which signal do you use inertial yaw (gyro) relative CsvView .... do you know that?

 

[sar104]

One time , is one time ... two times start to look like a habit (freely translated from Swedish ? )

Can the AC have been stored in a stronger magnetic field ... have any clue to why the compass behaves like it does?
Which signal do you use inertial yaw (gyro) relative CsvView .... do you know that?

It certainly looks a bit like a magnetized and hugely out of calibration compass.

The inertial yaw calculation is not in the DAT file and not generated by DatCon as far as I know. It's related to IMU_ATTI_0__totalGyro_Z but it is integrated in the earth frame of reference to get just yaw rotation, rather than in the aircraft frame of reference. You have to do the frame of reference conversion on all three rate gyros using the aircraft rotation quaternions before integrating:

ait = (axt*(1 - 2*(qyt^2 + qzt^2)) + 2*ayt*(qxt*qyt - qzt*qwt) + 2*azt*(qxt*qzt + qyt*qwt))
ajt = (2*axt*(qxt*qyt + qzt*qwt) + ayt*(1 - 2*(qxt^2 + qzt^2)) + 2*azt*(qyt*qzt - qxt*qwt))
akt = (2*axt*(qxt*qzt - qyt*qwt) + 2*ayt*(qyt*qzt + qxt*qwt) + azt*(1 - 2*(qxt^2 + qyt^2)))

where x, y, z are the aircraft FOR unit vectors and i, j, k are the earth FOR unit vectors.

 

[slup]

Thank's @sar104

@BudWalker ... anything that can be integrated in CsvView ?

 

[sar104]

One time , is one time ... two times start to look like a habit (freely translated from Swedish ? )

A bit like the more conservative and well-known:

"Once is happenstance. Twice is coincidence. The third time it's enemy action."

And so we wait...

 

[ManiakjeNL]

Everyone thanks for analyzing the dat file. So can i avoid this problem in the future or is my drone broken?

 

[sar104]

Everyone thanks for analyzing the dat file. So can i avoid this problem in the future or is my drone broken?

Your drone appears to need calibrating and/or demagnetizing and then calibrating. Without further data there is no way to know whether the outcome will be successful.

 

[Prismatic]

Your drone appears to need calibrating and/or demagnetizing and then calibrating. Without further data there is no way to know whether the outcome will be successful.

If recalibrating the compass doesn't work, an attempt to fly could again spiral out of control. And I'm not sure I'd trust this unit even if it said the calibration succeeded. ?