Ok so after digging into your logs, It does appear as though the craft developed a mind of its own for one reason or another in terms of the altitude. The barometer height and GPS height seemed to skew around the 100 second mark. It also seems as though the drone realized this as this was in the log:
106.061 : 846153654 : 9009 [L-FDI][FDI][CTRL]: fault on , height_ctrl_fail
Thanks for looking at those for me.
I plotted the data that was in the csv file that resulted on the phantomhelp page and came up with plots similar, but less detail, to what you got. Of course I can’t see the gpsAlt or one of the two Yaws in that file.
After seeing the GPS alt data to me it looks like at some point the recorded baroAlt started lagging the real world badly. The Barometric alt data should respond as fast or faster than the GPS alt data, and does so until after the 77 second mark. But from that time on the GPS alt data seems to be responding before the baro alt data, with the same general trends after about 110 seconds or so but with several seconds of time delta.
Note that the GPS alt data ends at about the right altitude on top of the truck, while the baro alt data is still coming down at that point (when I turned the P4 off), with a 35+ meter delta between the two.
To me it really looks like the system was responding to baro data that was not keeping up with the pace of the real world. Probably after the height_ctrl_fail all bets were off on its ability to keep itself up in the air with no elevation inputs from me. If I had been looking at the thing instead of head down I probably would have been able to control it to the ground.
I can’t think of any way a failed barometric sensor could cause this kind of lag. Errors yes, no input yes, but several seconds lagging input seems more of a processing system error than a barometric sensor error. At least to me, but what do I know, I am an RF guy, not a software guy
What really concerns me, I mean besides it happened at all, is that the obstacle avoidance with its Vision Positioning sensors, with the ultrasonic altitude detection, apparently never attempted to slow the fall of the aircraft, and I was in P mode according to the data.
As for the yaw, the yaw appears to have been commanded correctly by you with your stick. The yaw from your RC is the green line on the 2nd graph, and you can see it matches the yaw direction that occurred in the first graph which is the craft yaw (also green).
That said, there was definitely some kind of issue that occurred with the barometer and height control of the craft. I don't know if it was caused by the environment or hardware. You could either send it back to DJI for diagnostic/warranty, or you could wait and see if it happens again.
I don’t remember me commanding the start of the yaw, in fact I thought I responded trying to counter the yaw, however the RcRudder vs Yaw seems to support that yaw was under control until impact.
At this point I will watch the thing closely for the next few hops. If it shows any future issue with alt control I will contact DJI, but until it shows an issue again I will treat this as an isolated glitch. The next two flights after that were essentially flawless.
I am somewhat surprised and pseudo pleased that the P4 wacked the truck hard enough to dent the roof, and made a heck of a thump sound, with the only detectable damage on the P4 as a broken prop that probably impacted an antenna just before smack down.
By the way, is there any data out there on the format of the .DAT file or maybe does a converter exist? I would love to be able to look in detail at the information in there.
Thanks,
T!