Can a faulty GPS module cause the drifting problem on Phantom 4 Pro? Drone is drifting east /or turning West in Autonomous missions

@BudWalker the only change I made was putting on the new "low noise" props. however, I am 99.9% sure that I put those on before I did any flights that I uploaded logs for. I do not know anything about reading logs and I am learning alot about how the P4P functions through this thread. Just to clarify, is the log in Post #8 for the manual flight,

I missed the question regarding strobes. There is nothing mounted on the P4P. Just the stock body with low noise props.

The only thing I can contribute
1. It would not seem to be a motor issue. Because the AC always veers off course to the east (regardless of direction) when manually flying the AC.
2. I have no idea why the AC is rotating to the west (instead of veering off course) in Autonomous flights but it does. I though it was to counter the East drift but that is obviously not the case.
3. The FC is not the problem. I switched out the controller from my other P4P (which flies fine) and the same problem occurred.

We have rain until Saturday evening so it will be Sunday until I can test further. I am going to do test flights East/West. Let me know if there are any specific test or configurations that you think would help. I will do them all and keep good records of the flight time, and what was done. I can also do screen recordings on my iPad 4 Mini if that would be helpful.

Do you think a bad compass could cause this? If not, what else could it be?
 
Because the AC always veers off course to the east (regardless of direction) when manually flying the AC.
Bud's post #8 I believe was from FLY 393....The latest is from FLY406....To re-iterate what @BudWalker stated, in this latest test, you manually turned the aircraft to the east before flying the route. Another view of the data.....

Direction2.png
 
Bud's post #8 I believe was from FLY 393....The latest is from FLY406....To re-iterate what @BudWalker stated, in this latest test, you manually turned the aircraft to the east before flying the route. Another view of the data.....
Flydawg the only thing I did was get the AC in perfect alignment to the end of the street. When I first flew it down to the south end of the street, I did not touch it. Just flew it there and let it hover for 120 seconds (I pretty sure that is correct). I then turned the AC around to face north, and it took me just a second it get it perfectly dead center over the road and then perfectly lined up with the north end of the street. After I had it dead center on the north end of the street, I then applied forward control on the right stick. Nothing else. But instead of flying to the end of the street it flew 75+ feet to the East of the destination point. I could have added manual correction along the flight to make it go where I intended but I used forward motion on the right stick only to demonstrate that this bird is veering off course to the east. It would have done the same thing if I was flying south.

So maybe it will be helpful on my next test run to
1. Screen record each flight from start to finish on my iPad to show the ipad view of what is taking place.
2. Setup a video camera to record the AC in the air so visibly see what it is doing from the ground.
Then fly. I can then upload a YT video that will show both views simultaneous and compare that to the log files. I can only tell you what I did. So having video to compare to the log files and see if they agree with each other may help run down the error that is happening.

I think there are many folks who are having this problem and just accept it and deal with it. For mapping this is problamatic because the images are being rotated when the camera is at 90° and it can cause stitching problems and other issues.

Thank you both for your help on this.
 
the only thing I did was get the AC in perfect alignment to the end of the street.
If that statement is correct, I am wondering if this may be a misalignment with the gimbal, since I presume you are using the video feed to line up with the street. If you can, upload your .txt file for this last test run. That file will have the gimbal angles. Just something else to check for. Upload that file to the link below, if possible and place a link back here to the upload.

Flight Log Viewer
 
If that statement is correct, I am wondering if this may be a misalignment with the gimbal, since I presume you are using the video feed to line up with the street. If you can, upload your .txt file for this last test run. That file will have the gimbal angles. Just something else to check for. Upload that file to the link below, if possible and place a link back here to the upload.

Flight Log Viewer
FlyDawg, here is the link to the two log files that I downloaded from AirData.

02-20-2019: Flown with DjiGo4 iOs. I flew the same path (south end of street to north end) and the same exact event occurred (veering to the east by 75+ feet) I also flew around alot more and observed the UAS behavior.
02-21-2019: Flown with Litchi iOs. I simply flew from one end of the street to the other (but 75+ feet off target to the east)

Holler if you need more details.

P4P Airdata Logs Veering Problem - Google Drive
 
Here is the link of where I uploaded the Litchi CSV file: However, I do not see any details regarding the Gimbal pitch/angle

DJI Flight Log Viewer - PhantomHelp.com

EDIT:
I used DatCon to convert FLY406.DAT to CSV. I have uploaded the CSV fiel to the above link. I'll be honest, I am not sure exactly which files ya'll need?? I opened the CSV file in CSVViewer but that is where my log file knowledge stops!
 
Last edited:
You need first to do a detailed analysis of your flight logs from the aircraft. That will help in determining if there is an issue. If you have not reviewed the aircraft logs before, see the link below to retrieve them. If you need assistance with the analysis you will need to upload the aircraft .dat file to a sharable location such as Dropbox or Google drive ( These are usually large files ) and place a link back here and many of us can assist you with an interpretation of the data. See this link to retrieve the log files.

Retriev Aircraft Dat File
Oh Lord, a Dawg from Watkinsville... Go You Ramblin’ Wrecks! That’s what I say.

LOL. Hello neighbor, from Rome, Ga.
 
I do not see any details regarding the Gimbal pitch/angle
They are in the CSV file.

This plot shows the exact same as the aircraft data. When you were adjusting for the street run, you rotated the aircraft approx 15 degrees off center. The gimbal followed the 15 degrees as you would expect. Then you began the straight line run, which was off center by that 15 degrees or so, thus resulting in the far off path at the end of the run. The aircraft flew perfectly straight and did not veer from the flight path. What do you think @BudWalker?

Gimbal Yaw2.png
 
They are in the CSV file.

This plot shows the exact same as the aircraft data. When you were adjusting for the street run, you rotated the aircraft approx 15 degrees off center. The gimbal followed the 15 degrees as you would expect. Then you began the straight line run, which was off center by that 15 degrees or so, thus resulting in the far off path at the end of the run. The aircraft flew perfectly straight and did not veer from the flight path. What do you think @BudWalker?
But that is just it. I did NOT adjust it 15° off center. I adjusted it to align perfectly with end of the road and the drone flew off center. I don't know how else to put that. My gimbal/camera is not off center. I can look at it and see that it points straight ahead. If the gimbal is not crooked then it would seem the likely culprit is the compass. When flying automously, the error worsens the further the drone flies. I have calibrated the compass more than once and there are no compass errors.

i am a thankful for the help and I have described in great detail exactly what happened. I will make a video of how this occurs on Sunday when the sun finally comes out ... and I am sure ready for it!!
 
If the gimbal is not crooked then it would seem the likely culprit is the compass.
No argument with your visual interpretation, but this is not what the data is indicating. Until you get another flight opportunity, let me see if @sar104 will take a look as well. Another set of eyes never hurts....
 
  • Like
Reactions: sar104
Hello neighbor, from Rome, Ga.
Greetings. I can deal with North Avenue Trade school folks. It's Bam's and Gators that get under my skin sometimes. ;)
 
No argument with your visual interpretation, but this is not what the data is indicating. Until you get another flight opportunity, let me see if @sar104 will take a look as well. Another set of eyes never hurts....
That dang data will get you every time :p It is frustrating to say the least but hopefully my next test (hopefully Sunday afternoon) with some video might help pinpoint what could be happening. Ya'll have a super duper weekend!
 
The problems in the two .DATs, FLY393.DAT and FLY406.DAT are different issues. In FLY393 the path appears to be an arc instead of a straight line because the heading is constantly changing. In FLY406 the issue is that the initial heading is wrong but the path is straight.

I took a closer look at FLY393. In summary, the P4P isn't drifting - it's doing exactly what the mapping software is telling it to do. The mapping software that I've used doesn't fly a straight path. Rather it flies from point to point, taking an image at each point. The fact that the path appears to be straight is just because a straight line is the most efficient way to get from one point to the next. Looking closer at the 3rd traversal in FLY393 we can see the points that were calculated by the mapping software. This from the eventLog stream. (I've edited out a bunch of stuff to make it readable.)
134.485 : 13193 [L-MIS]|#SiF%|20190220 21:07:54 0 34.91793238 -89.94046213 156.10 155.99 -0.01 0
138.805 : 13409 [L-CAMERA]<0> ack_type 1 send 1 p 004e1971
138.805 : 13409 [L-MIS][WP] camera action send simple shot
138.825 : 13410 [L-CAMERA]SIMPLE_SHOT, get camera mode, wait step 1 ack
138.860 : 13411 [L-CAMERA]!!!!!!!!!!!!get mode camera acked len 2 buf 0, cb_type=0
138.860 : 13411 [L-CAMERA]I receive camera reply result 0, mode 0
138.860 : 13411 [L-CAMERA]cmd success
138.866 : 13412 [L-CAMERA]recv step 1 ack, mode ready
138.885 : 13413 [L-CAMERA]let camera shot, wait step 2 ack
139.040 : 13420 [L-CAMERA]!!!!!!!!!!!!shot camera acked len 1 buf 0, cb_type=0
139.040 : 13420 [L-CAMERA]I receive camera reply result is 0
139.040 : 13420 [L-CAMERA]cmd success
139.046 : 13421 [L-CAMERA]recv step 2 ack
139.065 : 13422 [L-CAMERA]SUCCESSED SIMPLE_SHOT
139.065 : 13422 [L-MIS]|#SiF%|20190220 21:07:59 0 34.91801567 -89.94046174 157.44 156.00 0.00 0
:
:
175.065 : 15222 [L-MIS]|#SiF%|20190220 21:08:35 0 34.91866010 -89.94046019 155.43 155.89 0.02 0
:
206.825 : 16810 [L-MIS]|#SiF%|20190220 21:09:07 0 34.91923252 -89.94042416 156.79 155.93 0.05 0

Using Google Earth I was able to determine that
1) The actual flight path matches exactly the points calculated by the mapping software
2) The path is bent (maybe curved - I only looked at 3 points) In the interval [134.485, 175.065] the heading is 0.10°. In the next interval [175.065, 206.825] the heading is 2°. It's a little hard to see but it kind of looks to my old eyes like the the two paths are actually arcs. But, it doesn't matter the end points match exactly the points determined by the mapping software.
1550935962587.png


@timmydjr I'm not sure I understand what the problem is. If the images are taken at the right locations then the mapping software should give the correct results. It would be interesting to see your other P4P flown with the same mission.
 
The problems in the two .DATs, FLY393.DAT and FLY406.DAT are different issues.
That's another issue with the testing as well. FLY406 was flown with Litchi. To be consistant, the testing needs to be done with the same app in either manual or autonomous as opposed to adding another variable in to the equation.
 
@timmydjr Below is a short mission you can try with Litchi. Make sure you set the aircraft heading to 0 degrees in both Waypoint 2 and Waypoint 3. Also, at Waypoint 2, set a 10-15 second "Stay" action before the street run begins. With both Waypoint 2 and 3 set to 0 degrees, this should fly perfectly straight between the two waypoints ( +/- a degree or two) but most certainly not 15 degrees. This most certainly should not have any drift to any great extent and should eliminate an aircraft issue if successful.

MISSION1.png
 
Last edited:
You aren’t using a POI in the automated litchi mission are you?
 
You aren’t using a POI in the automated litchi mission are you?
The original files were Map Pilot. The manual mission was in Litchi. You have to read the full thread and the descriptions to get the "drift" ( No pun intended )....
 
The original files were Map Pilot. The manual mission was in Litchi. You have to read the full thread and the descriptions to get the "drift" ( No pun intended )....
I did read the whole thread. Pardon me if I missed a detail. The details were “all over the map.” (No pun intended) ;-)
 
Last edited:
I did read the whole thread. Pardon me if I missed a detail.
No worries there. The only thing you missed was that nothing in the primary data was an automated Litchi mission. It was flown through Map Pilot, then a manual flight with Litchi. Which is one reason the discussion and tests are on-going. Unless the OP decides otherwise...;)
 
I've managed to figure out, at least partially, the cause of the magnetometer spikes in FLY363.DAT. They occur about 100 milisecs before the camera has taken an image in the mapping mission. E.g.
170.806 : 15009 [L-CAMERA]SUCCESSED SIMPLE_SHOT
170.806 : 15009 [L-MIS]|#SiF%|20190220 21:08:31 0 34.91858344 -89.94046191 156.72 155.96 0.01 0
and the mag data
1551024515032.png

@sar104
 

Members online

Forum statistics

Threads
143,066
Messages
1,467,355
Members
104,934
Latest member
jody.paugh@fullerandsons.