Mavic 2 pro Crash _ IMU issue?

[cocoon]

Hello drone friends,

I have crashed my drone without doing anything.
I was flying from a second floor and suddently the drone flew away, turn itself on the back side and crashed.

This is a mavic pro 2, I am flying drone since 5 years...and it never happened before.

Here is the log

DJI Flight Log Viewer | Phantom Help

Upload and view flight logs from your DJI drones

www.phantomhelp.com

2 m 53 : the drone accelerate alone meanwhile the sticks are not doing anything.

Should it be an IMU error?

Thanks by advance

 

[boblui]

I was flying from a second floor and suddently the drone flew away,...]
2 m 53 : the drone accelerate alone meanwhile the sticks are not doing anything.

The flight log indicates that the drone flew backward by itself but it was taking a nose-down attitude when it happened so the accelerometer and gyro data do not match. Did you see the craft flying forward or backward ?

 

[cocoon]

the drone was on hovering mode next to me and suddendly the drone accelerate and fly up and then turn itself on the back side and crashed.

 

[JAW]

I was flying from a second floor.....

Balcony with iron railing?

 

[cocoon]

100% wood building, no metal at all

 

[cocoon]

[QUOTE = "cocoon, publicación: 1105173, miembro: 76047"]
Hola amigos de drones,

He estrellado mi dron sin hacer nada.
Estaba volando desde un segundo piso y, de repente, el dron voló, se dio la vuelta y se estrelló.

Este es un mavic pro 2, estoy volando un dron desde hace 5 años ... y nunca antes había sucedido.

Aquí está el registro

[URL unfurl = "true"] DJI Flight Log Viewer - PhantomHelp.com [/ URL]
2 m 53: el dron acelera solo mientras los sticks no hacen nada.

¿Debería ser un error de IMU?

Gracias por adelantado
[/CITAR]
Hello @sar104 , I would really apreciate your expertise on this case, thanks by advance

 

[slup]

[QUOTE = "cocoon, publicación: 1105173, miembro: 76047"]
Hola amigos de drones,

He estrellado mi dron sin hacer nada.
Estaba volando desde un segundo piso y, de repente, el dron voló, se dio la vuelta y se estrelló.

Este es un mavic pro 2, estoy volando un dron desde hace 5 años ... y nunca antes había sucedido.

Aquí está el registro

[URL unfurl = "true"] DJI Flight Log Viewer - PhantomHelp.com [/ URL]
2 m 53: el dron acelera solo mientras los sticks no hacen nada.

¿Debería ser un error de IMU?

Gracias por adelantado
[/CITAR]
Hello @sar104 , I would really apreciate your expertise on this case, thanks by advance

Put up the mobile device DAT log & let's have a look at that also ... the one for this flight ends with FLY035.DAT, those logs are in a subfolder, MCDatFlightRecords, in the folder that contains the TXT logs.

 

[cocoon]

[QUOTE = "error, publicación: 1110187, miembro: 108623"]
Coloque el registro DAT del dispositivo móvil y echemos un vistazo también ... el de este vuelo termina con FLY035.DAT, esos registros están en una subcarpeta, MCDatFlightRecords , en la carpeta que contiene los registros TXT.
[/CITAR]
Thanks for your feedback. Here are the files :

 

[slup]

Yes, it's the larger of the 2 DAT's ... strange that 2 is created with the same ending?!?

But OK ... just to check off if this could have been a yaw error due to magnetic disturbance during powering on.

Have here below in a 180/-180 y-axis chart stacked up the imuYaw (Green), the magYaw (Blue ... it's the compass) & the visual yaw reading VIOYaw (Red ... it's coming from the downward sensors, like a visual compass) ... all from IMU1 as that was the one used.

It's easy to see that it wasn't any magnetic disturbance that caused this ... both the Green & Blue initializes to the same value at power on & they follow each other well with only 10-12 degrees disagreement later in the flight. We can also see that the Red VIOYaw also follows the other 2 well. So everything seems to align well until everything goes haywire.



So if all above 3 data aligns what else ..?

Let's look at how the Gyro tracks with the IMU. Below I've put up the imuYaw again but this time unwrapped (meaning that the value will add & subtract by the AC turning & the y-axis isn't locked value wise ... like this, 3 full turns CW & 1 full turn CCW = 360+360+360-360=720 degrees).

The imuYaw (Green) tracks reasonably well with the Gyro (Black) until 38sec into the flight ... but then something happens, the Gyro behaves erratic & don't follow the imuYaw anymore. When you later on in the flight deactivate the Tripod mode (the broader greenish background) the Gyro really goes it's own way & comparing the degree change from there to when the AC speeds away we see that the imuYaw changes 1,7 degrees but during the same time the Gyro register a change of 46 degrees.



My take on this is that the Gyro malfunctioned causing the AC to become extremely unstable in flight & making it hard for the IMU to properly counteract to outside factors ... like wind influence. With that wrong Gyro data fed into the IMU it must have messed all computations up... sort of the same effect like a yaw error due to magnetic disturbance, the AC loses it 's knowledge where it is heading.

Just in the end we see from the DAT event log that the FC mainly gives up ...

 

[BudWalker]

Yes, it's the larger of the 2 DAT's ... strange that 2 is created with the same ending?!?

But OK ... just to check off if this could have been a yaw error due to magnetic disturbance during powering on.

Have here below in a 180/-180 y-axis chart stacked up the imuYaw (Green), the magYaw (Blue ... it's the compass) & the visual yaw reading VIOYaw (Red ... it's coming from the downward sensors, like a visual compass) ... all from IMU1 as that was the one used.

It's easy to see that it wasn't any magnetic disturbance that caused this ... both the Green & Blue initializes to the same value at power on & they follow each other well with only 10-12 degrees disagreement later in the flight. We can also see that the Red VIOYaw also follows the other 2 well. So everything seems to align well until everything goes haywire.

View attachment 113981

So if all above 3 data aligns what else ..?

Let's look at how the Gyro tracks with the IMU. Below I've put up the imuYaw again but this time unwrapped (meaning that the value will add & subtract by the AC turning & the y-axis isn't locked value wise ... like this, 3 full turns CW & 1 full turn CCW = 360+360+360-360=720 degrees).

The imuYaw (Green) tracks reasonably well with the Gyro (Black) until 38sec into the flight ... but then something happens, the Gyro behaves erratic & don't follow the imuYaw anymore. When you later on in the flight deactivate the Tripod mode (the broader greenish background) the Gyro really goes it's own way & comparing the degree change from there to when the AC speeds away we see that the imuYaw changes 1,7 degrees but during the same time the Gyro register a change of 46 degrees.

View attachment 113992

My take on this is that the Gyro malfunctioned causing the AC to become extremely unstable in flight & making it hard for the IMU to properly counteract to outside factors ... like wind influence. With that wrong Gyro data fed into the IMU it must have messed all computations up... sort of the same effect like a yaw error due to magnetic disturbance, the AC loses it 's knowledge where it is heading.

Just in the end we see from the DAT event log that the FC mainly gives up ...

View attachment 113993

The .DAT got split into two separate .DATs. The original complete .DAT can be constructed by concatenating the separate .DATs with something like

bash> cat 20-09-16-05-55-04_FLY035.DAT 20-09-16-05-55-22_FLY035.DAT > FLY035.DAT

and then submit FLY035.DAT to CsvView or DatCon

The smaller first .DAT contains the DatHeader that is necessary to determine the clock speed. Without it the default clock speed 4.5 MHz is used instead of the Mavic2 clock speed 3.8477 MHz.

 

[slup]

The .DAT got split into two separate .DATs. The original complete .DAT can be constructed by concatenating the separate .DATs with something like

bash> cat 20-09-16-05-55-04_FLY035.DAT 20-09-16-05-55-22_FLY035.DAT > FLY035.DAT

and then submit FLY035.DAT to CsvView or DatCon

The smaller first .DAT contains the DatHeader that is necessary to determine the clock speed. Without it the default clock speed 4.5 MHz is used instead of the Mavic2 clock speed 3.8477 MHz.

Yeah, suspected it was something like that ...

But please explain in more detail @BudWalker, this could be good to know. Where do I use that command line ... in DatCon, in a Windows command prompt or something else?

 

[BudWalker]

Yeah, suspected it was something like that ...

But please explain in more detail @BudWalker, this could be good to know. Where do I use that command line ... in DatCon, in a Windows command prompt or something else?

The example I showed works if you have a linux style command line interpreter. I think that probably works in Windows power shell as well. If all you have is a DOS shell then I think something like
DosShellPrompt> type 20-09-16-05-55-04_FLY035.DAT 20-09-16-05-55-22_FLY035.DAT > FLY035.DAT
will work.

 

[slup]

The example I showed works if you have a linux style command line interpreter. I think that probably works in Windows power shell as well. If all you have is a DOS shell then I think something like
DosShellPrompt> type 20-09-16-05-55-04_FLY035.DAT 20-09-16-05-55-22_FLY035.DAT > FLY035.DAT
will work.

Success in Windows Power Shell with that command line Thank's @BudWalker ??

 

[cocoon]

Yes, it's the larger of the 2 DAT's ... strange that 2 is created with the same ending?!?

But OK ... just to check off if this could have been a yaw error due to magnetic disturbance during powering on.

Have here below in a 180/-180 y-axis chart stacked up the imuYaw (Green), the magYaw (Blue ... it's the compass) & the visual yaw reading VIOYaw (Red ... it's coming from the downward sensors, like a visual compass) ... all from IMU1 as that was the one used.

It's easy to see that it wasn't any magnetic disturbance that caused this ... both the Green & Blue initializes to the same value at power on & they follow each other well with only 10-12 degrees disagreement later in the flight. We can also see that the Red VIOYaw also follows the other 2 well. So everything seems to align well until everything goes haywire.

View attachment 113981

So if all above 3 data aligns what else ..?

Let's look at how the Gyro tracks with the IMU. Below I've put up the imuYaw again but this time unwrapped (meaning that the value will add & subtract by the AC turning & the y-axis isn't locked value wise ... like this, 3 full turns CW & 1 full turn CCW = 360+360+360-360=720 degrees).

The imuYaw (Green) tracks reasonably well with the Gyro (Black) until 38sec into the flight ... but then something happens, the Gyro behaves erratic & don't follow the imuYaw anymore. When you later on in the flight deactivate the Tripod mode (the broader greenish background) the Gyro really goes it's own way & comparing the degree change from there to when the AC speeds away we see that the imuYaw changes 1,7 degrees but during the same time the Gyro register a change of 46 degrees.

View attachment 113992

My take on this is that the Gyro malfunctioned causing the AC to become extremely unstable in flight & making it hard for the IMU to properly counteract to outside factors ... like wind influence. With that wrong Gyro data fed into the IMU it must have messed all computations up... sort of the same effect like a yaw error due to magnetic disturbance, the AC loses it 's knowledge where it is heading.

Just in the end we see from the DAT event log that the FC mainly gives up ...

View attachment 113993

Thanks so much for your time and feedback.
The question is how can I correct thie error?
Do I have to change the gyro? Can I still trust into my drone?