Judging from the IMU Altitudes recorded in the logs, having the VPS altitude suddenly go to 0 might just mean the VPS system is outside of its effective range. The IMU altitude continues to reflect what I remember of the flight profile, so I suspect that this behavior (VPS altitude) is normal.
Fly Away
- Thread starter brianmcg
- Start date
Judging from the IMU Altitudes recorded in the logs, having the VPS altitude suddenly go to 0 might just mean the VPS system is outside of its effective range. The IMU altitude continues to reflect what I remember of the flight profile, so I suspect that this behavior (VPS altitude) is normal.
As was mentioned above, I always let my P4P hover at 10' (above head height) for about 30 seconds to analyze how effective the internal sensors and controls are working. Once, due to metal near the launch point, it failed the stable hover test and I brought it down immediately.
I've flown over water often and found no issue with control or VPS settings. I like to stay above 50' to give a margin for safety.
Finally, I usually fly before sundown to get video or images with full dynamic range and then post process the video to get the "darkness" effect I am looking for. This gives better dynamic range and more stable flight. It also prevents flight after sundown to comply with the US FAA regulation.
I've flown over water often and found no issue with control or VPS settings. I like to stay above 50' to give a margin for safety.
Finally, I usually fly before sundown to get video or images with full dynamic range and then post process the video to get the "darkness" effect I am looking for. This gives better dynamic range and more stable flight. It also prevents flight after sundown to comply with the US FAA regulation.
@brianmcg , both of these flights exhibited a TBE (toilet bowl effect) prior to the fly away
Maybe more could be learned about the cause by looking at the .DAT file for these incidents. Look here
How to retrieve a .DAT
to see how to retrieve it. They will be large so you'll need to Dropbox or GoogleDrive them and post the links here.
Maybe more could be learned about the cause by looking at the .DAT file for these incidents. Look here
How to retrieve a .DAT
to see how to retrieve it. They will be large so you'll need to Dropbox or GoogleDrive them and post the links here.
Thanks, BudWalker! Here's the link to my dropbox DJI Logs folder. Two .DAT files - one from the crash flight and one from earlier in the day. I'll need to confirm that I've also got the .DAT from the first fly away (non-crash).
Dropbox - DJI Logs
I'm very interested in what you learn.
I looked at the crash flight (FLY114). The second file (DJI_ASSISTANT_EXPORT_FILE[2017-06-13 23-34-32].DAT) didn't contain any FLYXXX.DAT files. Maybe you didn't select an FC when you were using DJI Assistant 2?
There some very strange and complicated behavior in FLY114. I'm gonna guess that
1) the compass needs calibrating, or
2) the compass is broke; the gain is too high, or
3) the gyro is broke; the gain is too low
4) you've installed an external device that is interfering with the compass, or
I'm leaning towards 2 and/or 3.
At 8.8 secs left rudder is applied. The P4 rotates CCW but it's not clear how much it rotates. TotalGyroZ, which is computed from GyroZ, says the it rotates 50 degree and the magnetometers say it has rotated 168 degrees. Yaw, which is computed mostly from the IMU says the rotation is 80 degrees.
Note that the two graphs have different vertical scales.
MagYaw and totalGyroZ are computed by DatCon and was created for the purpose of checking the Yaw value that is computed by the Flight Controller. Usually when there is a discrepancy, magYaw will agree with either totalGyroZ or Yaw. But, that assumes properly functioning hardware. That's why a broke compass and a broke gyro should be considered.
This flight is also strange for the fact that a compass error was declared at 9.77 secs but did not get recorded in the normal places. Either in the .DAT or in the .txt. It did however, get recorded in the eventLog stream
9.779 : 1104219352 : 11979 [L-GPS](0)Lost. Reason:compass yaw err large
15.865 : 1131606952 : 12283 [L-FMU/FSM]not near ground
16.179 : 1133019613 : 12299 [L-GPS](0)Lost. Reason:gps disable
16.779 : 1135719508 : 12329 [L-GPS](0)Lost. Reason:compass yaw err large
16.979 : 1136619656 : 12339 [L-GPS](0)Lost. Reason:gps disable
20.379 : 1151919530 : 12509 [L-GPS](0)Lost. Reason:compass yaw err large
22.179 : 1160019342 : 12599 [L-GPS](0)Lost. Reason:gps disable
22.579 : 1161819743 : 12619 [L-GPS](0)Lost. Reason:compass yaw err large
22.779 : 1162719336 : 12629 [L-GPS](0)Lost. Reason:gps disable
29.999 : 1195209798 : 12990 [L-GPS](0)Lost. Reason:compass yaw err large
30.179 : 1196019533 : 12999 [L-GPS](0)Lost. Reason:gps disable
42.379 : 1250919689 : 13609 [L-GPS](0)Lost. Reason:gps yaw err large
One final thought. An improper compass calibration is almost never the cause of an incident. In fact, I've never seen a case where there was data or some other compelling reason to believe that an improper compass calibration was the the cause of an incident.
I assume that you have sent, or will send, the P4 to DJI repair. I'd be interested to see what they say was the cause.
Wow! Thanks for the detailed analysis.
I have not actually sent out the P4 for repair yet. It is over a year old, so I ordered a new shell and set of props and was planning on doing the repair myself. Prior to this event, the drone hasn't even had as much as a bumpy landing - ever.
Dropbox - 20170613_211153.jpg
If I opt for sending it to DJI, is there a chance that the repair would be covered under warranty at this point, if the crash is determined to be the result of an electronic component failure?
Last edited:
Hard for me to say if DJI will repair it under warranty. Thankfully, I've not had any experience with DJI repair.Good luck.
Meta4
Premium Pilot
- Joined
- Jan 8, 2014
- Messages
- 15,301
- Reaction score
- 9,243
If you're interested we could perform an experiment. It's a modified compass dance. Turn on the P4, wait 10 secs, and hold the P4 in front of you. Turn through 2 full rotations at about 5 to 10 secs per rotation. I.e., you turn while holding the P4; don't rotate the P4 in your hands. This is so that the pitch and roll are relatively constant. Turn off and provide the .DAT. Depending on what we see we might be able to determine if there is a hardware issue with the compass or the gyro. Or, if it's a compass calibration problem. Don't do a compass or IMU calibration before you do the experiment.
Sorry. Thanks for the offer but I've already done a compass and IMU calibration since the crash. I wanted to see how much of a difference there would be on the bar graphs as I was doing my post-mortum.
Never the less there may be something to be learned with this experiment. If your interested could you modify the experiment by starting it with the P4 sitting absolutely still for about 30 secs. This will allow us to compare the gyroZ error before and after the IMU calibration.
Last edited:
@BudWalker, I re-downloaded the FLY logs for the two fly-aways and put them up on dropbox.
Dropbox - FLY112 (flyaway1).DAT
Dropbox - FLY114 (flyaway2).DAT (Crash flight)
Dropbox - FLY112 (flyaway1).DAT
Dropbox - FLY114 (flyaway2).DAT (Crash flight)
By way of comparison, this was the flight immediately before the first fly-away flight. All hand-flown.
That "flight" looks exactly like it's supposed to.
Yaw and magYaw are separated by a constant 11 degrees. BTW the geoDeclination is 11 degrees.
Looking at the totalGyroZ values for this flight and the crash flight it's apparent that gyroZ error hasn't changed much. That error would cause a 0.05 degrees/sec drift; very low.
The compass calibration has changed. The eventLog stream contains the bias and offset values for each axis and for both of the compasses. Through some arithmetic-ing and Excel spreadsheet wizardry it should be possible to convert these magnetometer values to what they would have looked like before the compass calibration you did.
But, let's assume the incident was caused by a bad compass calibration. I'm most interested to see how that happened. I know I asked this, but, have you had an external device (like a GPS tracker) attached? Could we have the .DAT for the last flight that didn't have a problem? Have you done any compass calibrations prior to this last one? If so, could we have the .DAT before and after the compass calibration?
The reason I'm interested in this is that I've done compass calibration experiments with my P3. I found it very difficult to obtain a bad calibration by performing it in a location that was geomagnetically distorted. The Go App would say that there was interference and that I needed to move. After a couple of attempts I managed to get just close enough, but not too close, to my pickup to get a marginal calibration. But, it wasn't bad enough to cause a problem.
A more effective method to obtain a bad calibration is to attach an allen wrench to the right front leg and then calibrate it. Removing the allen wrench gives you an AC with a bad compass calibration.
Very interesting. It looks as though it is still functioning to spec even after the crash. I wonder if the firmware gets its nickers in a twist when the compass calibration error exceeds some limit.
The P4 is absolutely stock in every respect with the exception of a PolarPro ND8 filter on the camera in place of the standard DJI clear filter. It is running the latest firmware and I am running the latest release of DJI GO 4 on my iPad Pro 9.7. I didn't event attach the GetterBack float I promised myself I'd use without fail on every over-water flight.
Here is the link to the FLY data from the earlier, uneventful flight depicted in the last video I posted. Just a little earlier on the same day - Dropbox - FLY110.DAT
This one looks just about as good as they get.
And I checked; the calibration hadn't been changed between this and the crash flight. One possible explanation I can think of is that the compass hardware changed for some reason between this flight and the crash flight and the calibration "fixed" that. Not exactly compelling but it's all I have. Lemme think about it some. I'm offline for the next day or two.
For your entertainment I looked at the path and noticed two toilet bowl events. I'm thinking this can't be in light of the plot above. But then I checked the control inputs and saw that you were flying those circles.
Ha! Yes. I like to hand-fly orbits around objects of interest. [emoji1]
The only thing that changed between the two flights was the battery. I will need to check my logs to see if the two fly-aways occurred with the same battery.
Thanks for all your help on this. It's been a real learning experience for me.
Update/Correction: Not the battery. First flight (the good one) used the same battery as the second (non-fatal fly-away).
Flight 1: B6 - 98% at takeoff, 68% at landing
Flight 2: B6 - 67% at takeoff, 35% at landing
Flight 3: B1 - 97% at takeoff, 93% at landing (crash, actually)
(data from HealthyDrones/Airdata)
Last edited:
I looked at this a little more. The P4 has two compasses and it occurred to me that the crash flight could be using a different compass than the good flights. But, all the flights were using compass #1. But, there is something interesting. Looking at FLY110, before the crash flight.
it can be seen that magZ values for the two compasses are very close; within 3%
But, in the crash flight the magZ values for the two compasses are further apart; > 6%
After the calibration the magZ values for the two compasses are within 1%
I'll speculate that there was a hardware change/failure that caused the separation seen in the crash flight. The signals have the same shape but the bias or offset is different. It would be interesting to measure these again if the P4 is ever flown again.
it can be seen that magZ values for the two compasses are very close; within 3%
But, in the crash flight the magZ values for the two compasses are further apart; > 6%
After the calibration the magZ values for the two compasses are within 1%
I'll speculate that there was a hardware change/failure that caused the separation seen in the crash flight. The signals have the same shape but the bias or offset is different. It would be interesting to measure these again if the P4 is ever flown again.
I have a new shell and a new set of props, and will be replacing them all later this week. Once the drone is rebuilt, I plan to treat the drone as if it is brand-new out of the box with a firmware refresh, do all the calibration again and then do some careful test flights in a large unobstructed area. I will post the results here once I'm done.
Thanks again for your interest and all your analysis. It was very much appreciated.
Similar threads
