I misunderstood your post. That's the mobile device txt log, not the mobile device DAT file. I need the mobile device DAT file:
Mobile device DAT file: How to retrieve a V3.DAT from the tablet
Phantom 4 Pro V2 Fell out of the sky...
- Thread starter russellk
- Start date
I misunderstood your post. That's the mobile device txt log, not the mobile device DAT file. I need the mobile device DAT file:
Mobile device DAT file: How to retrieve a V3.DAT from the tablet
Im a bit perplexed, as the file I sent you was the only one created today, same as my aircraft DAT file, but this one is DAT47, and the aircraft most recent was DAT48. Im pretty sure I sent the right file this time, but where is the difference coming from?
That's the correct file. The aircraft creates a DAT file every time it is powered up.
The rotation is clearly visible in the data. Somewhat curiously the compass and the z-axis gyro both see it, but the sensor fusion output shows indicates that the aircraft is not rotating at all. At the end of the flight the gyro is showing CCW rotation even though the compass and the FC show the aircraft as stationary. My first move would be an IMU calibration, but you mentioned previously that you have done that.
I suggest a simple test, which can be done either in flight or just holding the aircraft. Power it up and then slowly rotate it through more than 360° clockwise, and then counter-clockwise, and post the DAT file.
The uncommanded Yawing is normal in the sense that the FC sees an incorrect Yaw/magYaw separation that needs to be reconciled. It does this by holding the Yaw value fixed and then rotates the AC until it sees the correct Yaw/magYaw separation. This strategy first appeared when the mavic Pro was introduced and, I think, has since been incorporated in all the DJI platforms. Note, that at times 17 secs and 137 secs the Yaw/magYaw separation target was close to the geoDeclination which is the initial target.
But, the question remains what causes the Yaw/magYaw separation in the first place. I really don't know why this is. But, it appears that the FC is holding the Yaw value fixed when it shouldn't. E.g at time 132 secs the AC rotated as can be seen by the totalGyroZ and magYaw data, but the Yaw value is fixed.
The rotation wasn't actually commanded since there was no rudder input, just aileron, elevator and throttle inputs. Maybe the FC thinks the Yaw should be held fixed since there was no rudder input.
@DKG13CC there is a possible work around. Let the AC finish it's uncommanded Yawing and then set the gimbal orientation in the Go App.
@sar104
But, the question remains what causes the Yaw/magYaw separation in the first place. I really don't know why this is. But, it appears that the FC is holding the Yaw value fixed when it shouldn't. E.g at time 132 secs the AC rotated as can be seen by the totalGyroZ and magYaw data, but the Yaw value is fixed.
The rotation wasn't actually commanded since there was no rudder input, just aileron, elevator and throttle inputs. Maybe the FC thinks the Yaw should be held fixed since there was no rudder input.
@DKG13CC there is a possible work around. Let the AC finish it's uncommanded Yawing and then set the gimbal orientation in the Go App.
@sar104
If you do a IMU calibration it may work for part of a flight. But with my Vr 2.0 it will always eventually start the uncommanded yaw eventually.
Once it begins then it pretty much continues whenever a hover is done. Amount of yaw is very slight but enough to throw off multiple 5 shot brackets.
Paul C
Once it begins then it pretty much continues whenever a hover is done. Amount of yaw is very slight but enough to throw off multiple 5 shot brackets.
Paul C
Hey guys, thanks for all the info. The holiday season had me all over the country, but Im home now and im going to do a short flight with CW and then CCW rotation as Sar104 suggested.
Bud, Im not sure I understand what you mean by setting the gimbal orientation. Ive only ever been able to adjust roll
Ok, I attached what I believe is the correct .dat file.
I took the ac up maybe 20 or 30 feet and did a slow CW 360, and then went past a tad, and did a slow 360 CCW.
@sar104
@BudWalker
I took the ac up maybe 20 or 30 feet and did a slow CW 360, and then went past a tad, and did a slow 360 CCW.
@sar104
@BudWalker
I think that's not the right .DAT. It was from a flight 3 days ago - 2019-1-3 23:42:51 GMT. There wasn't a motorStart.
This is my P4Pv2
The slightest movement / vibration of the battery will disconnect the AC.
Apparently there's a sensor at the bottom of the battery compartment that will disable flight if the battery is not properly seated. If battery moves a bit, the AC will think the battery fell out
It's at DJI
And a DIFFERENT battery gave me even more movement.
The slightest movement / vibration of the battery will disconnect the AC.
Apparently there's a sensor at the bottom of the battery compartment that will disable flight if the battery is not properly seated. If battery moves a bit, the AC will think the battery fell out
It's at DJI
And a DIFFERENT battery gave me even more movement.
Interesting. Although it doesn’t look like a disconnect. Says can’t takeoff. I wonder what would happen in flight. Maybe their state machine would ignore it in flight. If it were a true disconnected state I presume it would initiate an RTH.
So it sounds like, as far as the AC is concerned, its operating properly. What recourse would I have to fix the uncommanded yaw?
I didn't see any evidence of uncommanded yaw in that last test. Is it still happening?
I'm not convinced. This flight (FLY055) doesn't duplicate the conditions under which the uncommanded yawing occurred in the first .DAT you posted (FLY047). In that flight there were just aileron and throttle inputs that caused the P4Pv2 to yaw a bit even though there was no rudder input. The result was magYaw changed but the FC held the Yaw value constant. This was then followed by the FC performing the uncommanded yawing to reconcile the magYaw/Yaw separation.
I suspect it's not possible to fix the uncommanded yawing. I don't actually know but I'll bet a trade-off has been made where the FC can reconcile some compass errors but at the cost of less than perfect Yaw stability.
BTW, the reason I was referring to the M2P with regards to setting the gimbal orientation was that the .DAT (FLY068) you mistakenly posted was from a M2P. Doesn't the P4Pv2 have the ability to Yaw the gimbal independent of the AC?
Last edited:
@DKG13CC There is another possible work around. If you can prevent the magYaw/Yaw separation from happening in the first place then the FC wouldn't try to reconcile it with the uncommanded yawing. The trick will be to get to the desired photo shoot location/orientation using minimum pitch and roll to get there. That means using small, smooth control inputs - especially upon arrival at the photo shoot location. Lowering both the attitude and brake sensitivity might help some. You could also try being in Tripod mode at launch and on the way to the photo shoot location.
There didn't seem to be any significant yaw/magyaw separation during the calibration procedure in that last DAT file, although that didn't include significant roll - only pitch. Are you thinking that it is primarily a roll problem? If so that could be an x-axis rate gyro issue rather than a compass issue.
Doesn't seem like a roll or pitch problem per se. In his flights there is a bit of yawing when an abrupt roll or pitch happens. I suppose that's normal. But, the FC holds the Yaw value constant even though it's clear from both the magYaw and totalGyro:Z that the AC has yawed.
