Don't think you can disregard the velocity differences & the yaw disagreement ... have never seen a motor problem causing what we see here, have seen motor oddities as secondary issues though.
Unusual behaviour - Solved: IMU failure
- Thread starter DevonBadger
- Start date
IMU and GPS velocity difference
The fact is we don't understand much about how the IMU comes up with the IMU speed. Even if the IMU velocity is different from the GPS velocity, it only means that something is wrong with the IMU but except for a few cases I have seen in the past it's difficult to tell, in a deterministic manner, what the consequence will be. What I can be sure is that if the motors do not provide sufficient thrust, Newton told us that the craft can only goes down which is what has happened in this case.
Yaw disagreement
As said yaw disagreement will not cause loss in altitude because the IMU gives wrong indication only on where the north is. The craft can still tell which side is up and which is down. In this incident, the craft started its final descent at 172 second. It can be seen that the IMU speed VelD ( Velocity Down ) is positive for almost all the time meaning that the FC knew that the craft was going down. It could not save the craft because the right-front motor could not generate the required amount of thrust. I believe thats why the event log says "height_ctrl_fail".
Attachments
This is a strange one for sure. There are several indications that a rightFront propulsion problem developed. But, it wasn't severe enough to cause the usual tumbling in all three axes and high speed descent. More of a wobbling slow descent. Here is the time integrated gyro data.
Both roll and pitch oscillated some but stayed within an interval. Had this been the usual propulsion loss spin induced incident all three axes would have departed in a monotonic fashion.
The motor data corroborates a rightFront propulsion loss but is inconsistent regarding broken/loss prop vs motor problem. The increased speed indicates a propeller problem, but the increased current points to a motor problem.
It's also worth noting that the FC was having trouble maintaining Yaw as can be seen by looking the Z axis gyro data - commanded vs what was actually happening.
The FC wanted a 0.0 Z axis gyro value (the red curve) but was getting oscillations instead (blue curve).
Regarding the Yaw/magYaw separation that gave rise to the discrepancies seen in the velocities. MagYaw is computed from the magnetometer data and then compensated by using the roll and pitch data. I suspect that the unusually large roll and pitch values caused the magYaw value to be incorrect.
Both roll and pitch oscillated some but stayed within an interval. Had this been the usual propulsion loss spin induced incident all three axes would have departed in a monotonic fashion.
The motor data corroborates a rightFront propulsion loss but is inconsistent regarding broken/loss prop vs motor problem. The increased speed indicates a propeller problem, but the increased current points to a motor problem.
It's also worth noting that the FC was having trouble maintaining Yaw as can be seen by looking the Z axis gyro data - commanded vs what was actually happening.
The FC wanted a 0.0 Z axis gyro value (the red curve) but was getting oscillations instead (blue curve).
Regarding the Yaw/magYaw separation that gave rise to the discrepancies seen in the velocities. MagYaw is computed from the magnetometer data and then compensated by using the roll and pitch data. I suspect that the unusually large roll and pitch values caused the magYaw value to be incorrect.
The information keeps on coming.
Thank you all for your time and effor in helping dicipher the data.
I have located the details of this UAV and it is just about within the 24month warranty ( mid November )
Does anyone have any advice for applying for the warranty and what information i should approach them with as i no longer have the UAv in person?
Again, many thanks for your time
Thank you all for your time and effor in helping dicipher the data.
I have located the details of this UAV and it is just about within the 24month warranty ( mid November )
Does anyone have any advice for applying for the warranty and what information i should approach them with as i no longer have the UAv in person?
Again, many thanks for your time
Once in contact with DJI they will tell you what they want ... start up with one of these ways to get hold of them --> 7 Ways to Contact DJI Customer Support - DJI Guides
Your main info you have now when the AC is lost is the TXT & DAT logs ... they will certainly ask you to sync the logs so they can access them. Then they will do their own assessment & come back to you with their verdict.
Some very interesting reading thank you, so how do we all react after reading this do we calibrate the IMu's more often but somehow I doubt that will do the trick just maybe aggravate the problem.
You say we learn !!!!!!!
You say we learn !!!!!!!
You're correct doubting that ... calibrating the IMU will not prevent HW to fail.
The IMU can be calibrated in below occasions ... more than that will not do any good at all.
- When you first receive the drone
- If the DJI app tells you to
- If you notice that the drone drifts without your input
- After a crash or a hard landing
If you’re curious about the current status of your drones IMU, you can check this by going to main controller settings>advanced settings>sensors (GO4 app). You will see the “accelerometer bias” and “gyroscope bias” with bars underneath each that have one of these three colors: green (excellent), yellow (good) or red (poor). If the bias value is too large with either sensor, red or yellow will be present in the bars; in which case an IMU calibration would be appropriate. But remember, the app will give you a notification if you need a calibration whether you’re on this sensor screen or not.
After looking at a new case involving a Mini attempting to ascend to the moon on it's own ( Fly away immediately at launch ). I revisited this case and agree with slup that the IMU error may well be the primary cause. The evidence is shown below.
The IMU fuses all the sensor readings and come up with the desending speed. The CsvVeiw tool integrates the speed w.r.t. time to get the IMU-indicated height. In the last 10 seconds of the flight, the height shown on the app ( believed to be derived from the barometer reading ) kept decreasing ( blue line ) but the IMU-indicated height shows the opposite ( orange line ).
It appears that the flight controller ignored the heigh information from the barometer ( possibly also GPS ) and trusted the IMU only. The same is seen in the case involving a Mini mentioned above. As the result, the flight controller was not aware that the craft was descending so it didn't do anything to maintain the height. The craft ended up in punching into the sea this way.
There is the motor problem but it may not be the primary cause. Its still a mystery why the motor went wrong with the IMU at the same time.
The IMU fuses all the sensor readings and come up with the desending speed. The CsvVeiw tool integrates the speed w.r.t. time to get the IMU-indicated height. In the last 10 seconds of the flight, the height shown on the app ( believed to be derived from the barometer reading ) kept decreasing ( blue line ) but the IMU-indicated height shows the opposite ( orange line ).
It appears that the flight controller ignored the heigh information from the barometer ( possibly also GPS ) and trusted the IMU only. The same is seen in the case involving a Mini mentioned above. As the result, the flight controller was not aware that the craft was descending so it didn't do anything to maintain the height. The craft ended up in punching into the sea this way.
There is the motor problem but it may not be the primary cause. Its still a mystery why the motor went wrong with the IMU at the same time.
Last edited:
This is also shown in the chart back in post #9 by the graph ImuCalc:diffVelD ... the velocity difference between GPS & IMU is fluctuating approx. between +8 to -9m/s.
The position and velocities derived from either the barometer or GPS receiver are more reliable due to their independence from other data. The barometer position data is pretty simple. The GPS receiver velocities are derived from the doppler effect seen by the receiver.
The IMU position and velocities are fused values that depend on the barometer and GPS velocities. But, accelerometer data compensated with attitude information is also used. I suspect that tumbling (or, in this case, wobbling) leads to errors when compensating the accelerometer data which then causes position and velocity errors.
I checked some other Mavic incidents where tumbling occurred. Seems it's a common occurrence for IMU velocity discrepancies to start at the onset of tumbling. Here's an example taken from
Mavic Pro Crashed
Unless you have Refresh Plus, warranty is only 12 months, 6 months for some components. That's the main advantage for purchasing Plus within 6 months of original Refresh.
If i refer to the website; After-Sales Service Policies - DJI , it states 24 months unless a variation due to local law or regulations are in place.
I will speak with them this morning and see what happens.
Whilst i await the response from DJi ( so far they have asked for all the information ) i'm curious if there was any information given in the logs to the odd behaviour of the gimbal?
The gimbal was the first sign that something was very amiss with the UAV.
The general consensus is that an error with the front right rotor/motor could have been cause of the crash, however does the gimbal acting the way it did ( pointing up and to the right with no response to re aligning it with the controls ) have any bearing on this?
Again, i'm grateful for your time and knowledge of the information given.
The gimbal was the first sign that something was very amiss with the UAV.
The general consensus is that an error with the front right rotor/motor could have been cause of the crash, however does the gimbal acting the way it did ( pointing up and to the right with no response to re aligning it with the controls ) have any bearing on this?
Again, i'm grateful for your time and knowledge of the information given.
Without going into details about the root cause of this, where we can conclude that it's a strange case, but clearly HW related ... & not a pilot error.
What's more clear is that the AC made very large movements in all axis, movements over the limits according to the specifications ... with such movements the gimbal most probably went into it's limits & that caused you to see a strange gimbal behavior. So yes, the gimbal movement is related to the incident due to AC movements ... but not due to what induced those movements.
Result is in;
They have agreed to replace the unit, which is excellent news.
DJI did state a report would be available on the incident and I’ve asked for it to get their input to add to the wealth of information here.
Thank you again to Slup, Boblui & Budwalker for your in depth analysis and for those who offered advice.
I’ll update the thread with any information given by DJI relating to the incident in the future
They have agreed to replace the unit, which is excellent news.
DJI did state a report would be available on the incident and I’ve asked for it to get their input to add to the wealth of information here.
Thank you again to Slup, Boblui & Budwalker for your in depth analysis and for those who offered advice.
I’ll update the thread with any information given by DJI relating to the incident in the future
Yeah ... but what they wrote is actually inline with how extensive their reports usually are, they rarely go into the details ... the FC/IMU issue is clearly seen already in the mobile device DAT event log. So as they can't get access to the aircraft DAT with a higher frequency data collection they just settle with that.
Yes indeed, I should have worded it a little better by saying they have come up with nothing new other than what we already know.
Similar threads
