Recently, there have been several incidents with the Mavic 2 and Mavic Air that involve problems with IMU(1). Generally, IMU(1):Yaw value becomes incorrect leading to erratic flight and/or a fly away. It's been observed by a few members that these incidents often occur over water leading me to suspect that the vision system data was somehow involved in these incidents. It's not clear, at least to me, how the Vision System and the Flight Controller interact. In three of these incidents the VS and FC data exhibited similar characteristics. In particular, incorrect VS height data is a precursor to each incident. It's unclear why exactly incorrect VS height would lead to an incorrect IMU(1):Yaw value - I haven't quite connected all the dots.
Version 3.6.8 of CsvView/DatCon includes the VIO data used in this investigation. I haven't had much experience with the VIO data, but it seems that VIO:velN, velE, velD correspond to the IMU velocities and VIO
osX, posY, posZ are X, Y, and Z positions computed by the vision system. There is also a VIO quaternion that DatCon converts to VIO:roll, pitch and yaw. These are blank if the vision system isn't computing values for these values. These data align pretty well with the actual velocity, position and attitude data. In a normal flight the vision system is inactive above 15 to 30 AGL and not producing data. E.g., in this flight VIOosZ data is produced for less than 15 meters altitude and agrees with the actual height.
These incidents occur while over water and the vision system is producing data that looks OK except that the VIOosZ data is incorrect. This happened in these incidents
1) Mavic 2 Pro Wild Ride.... .
2) Strange,sudden uncommanded left yaw and motion during a flight... . DAT log is here
19-03-26-04-36-03_FLY024.DAT
Shared with Dropbox
www.dropbox.com
3) Drift to right, IMU calibration? .DAT log is here
FLY076.DAT
Shared with Dropbox
www.dropbox.com
With the first incident ( Mavic 2 Pro Wild Ride.... ) the incident begins around 114 secs when the M2 is lowered to 12 meters above water. The VS becomes active but the VIOosZ data is an incorrect 4.6 meters. Similar to the other two incidents this occurs over water suggesting that the VS is unable to accurately determine height over water.
There is good agreement between IMU(0):Yaw, IMU(1):Yaw and VIO:Yaw. Then over the next 6 secs IMU(0):Yaw and IMU(1):Yaw both diverge but VIO:Yaw remains correct. The vision system sputters a few times and finally turns off at 134 secs. IMU(0):Yaw begins to slowly return to the correct value. But, IMU(1):Yaw diverges even further from the correct Yaw value causing the erratic flight.
It's clear from the magnetometer data that the M2 has not changed it's heading; i.e. actual Yaw is constant even though the two IMU:Yaws have changed.
Using the gyro data to determine if the M2 actually rotates or not is a bit more involved. As noted previously, Mavic 2 Pro Wild Ride.... there is reason to suspect the incident was caused by a bad IMU(1) gyro package. The error rate for each gyroZ should remain constant. Therefore
IMU(0):gyroZ - IMU(1):gyroZ = constant
Integrating both sides
IMU(0):totalGyroZ - IMU(1):totalGyroZ = D(t) where D(t) is linear w.r.t. time
In this incident D(t) isn't linear w.r.t. time, especially preceding the incident.
However, 1) a non-linear D(t) is a common occurrence in M2 .DAT files, and 2) D(t) was linear in the other two incidents. IMHO, the non-linear D(t) isn't a contributing factor in this incident.
I plan to do some test flights over water in an attempt to reproduce this behavior. I hope that disaster can be avoided since my M2 has been reconfigured where Sport mode has been replaced with ATTI mode.
@sar104, @CrouchyUK, @gnirtS , @DanMan32 , @John Lord
Version 3.6.8 of CsvView/DatCon includes the VIO data used in this investigation. I haven't had much experience with the VIO data, but it seems that VIO:velN, velE, velD correspond to the IMU velocities and VIO
osX, posY, posZ are X, Y, and Z positions computed by the vision system. There is also a VIO quaternion that DatCon converts to VIO:roll, pitch and yaw. These are blank if the vision system isn't computing values for these values. These data align pretty well with the actual velocity, position and attitude data. In a normal flight the vision system is inactive above 15 to 30 AGL and not producing data. E.g., in this flight VIOosZ data is produced for less than 15 meters altitude and agrees with the actual height.These incidents occur while over water and the vision system is producing data that looks OK except that the VIO
osZ data is incorrect. This happened in these incidents1) Mavic 2 Pro Wild Ride.... .
2) Strange,sudden uncommanded left yaw and motion during a flight... . DAT log is here
19-03-26-04-36-03_FLY024.DAT
Shared with Dropbox
3) Drift to right, IMU calibration? .DAT log is here
FLY076.DAT
Shared with Dropbox
With the first incident ( Mavic 2 Pro Wild Ride.... ) the incident begins around 114 secs when the M2 is lowered to 12 meters above water. The VS becomes active but the VIO
osZ data is an incorrect 4.6 meters. Similar to the other two incidents this occurs over water suggesting that the VS is unable to accurately determine height over water.There is good agreement between IMU(0):Yaw, IMU(1):Yaw and VIO:Yaw. Then over the next 6 secs IMU(0):Yaw and IMU(1):Yaw both diverge but VIO:Yaw remains correct. The vision system sputters a few times and finally turns off at 134 secs. IMU(0):Yaw begins to slowly return to the correct value. But, IMU(1):Yaw diverges even further from the correct Yaw value causing the erratic flight.
It's clear from the magnetometer data that the M2 has not changed it's heading; i.e. actual Yaw is constant even though the two IMU:Yaws have changed.
Using the gyro data to determine if the M2 actually rotates or not is a bit more involved. As noted previously, Mavic 2 Pro Wild Ride.... there is reason to suspect the incident was caused by a bad IMU(1) gyro package. The error rate for each gyroZ should remain constant. Therefore
IMU(0):gyroZ - IMU(1):gyroZ = constant
Integrating both sides
IMU(0):totalGyroZ - IMU(1):totalGyroZ = D(t) where D(t) is linear w.r.t. time
In this incident D(t) isn't linear w.r.t. time, especially preceding the incident.
However, 1) a non-linear D(t) is a common occurrence in M2 .DAT files, and 2) D(t) was linear in the other two incidents. IMHO, the non-linear D(t) isn't a contributing factor in this incident.
I plan to do some test flights over water in an attempt to reproduce this behavior. I hope that disaster can be avoided since my M2 has been reconfigured where Sport mode has been replaced with ATTI mode.
@sar104, @CrouchyUK, @gnirtS , @DanMan32 , @John Lord
Last edited:
