I am writing some software to help with PPK processing of Phantom 4 RTK data and have a question about how to apply the antenna-camera lever arm correction. I use RTKLIB to come up with a PPK trajectory and then my software performs the following steps:

1. Interpolate the position of the drone with the PPK trajectory and the times in the Timestamp.MRK file.


2. Next I need to apply a lever arm correction to each position for the antenna phase center to camera offset. I see the north, east, and vertical offsets in the Timestamp.MRK file but I haven't found anywhere in the P4 RTK documentation that talks about what north, east, and vertical actually mean.


Right now I calculate tangent vectors to a sphere at a given (lat, lon) that point north and east then take the cross product to get vertical. I have no idea if this is the right thing to do though. Wondering if I need to project the coordinates to UTM or something like it and then apply the north, east, vertical correction that way?

3. Next I have some code that takes the corrected positions and writes them to the EXIF and XMP data in the photos.


Has anybody figured this out or gotten info from DJI about it?

Also - once this is sorted out would people be interested in software like this? I'd be happy to put it up on github if people would find it useful.

Hi, i have tried and compared RTKLIB and other software that make a PPK between drone rinex and a base station (public and my own).... The main problem i see is basically the interpolation to calculate the position of the drone... if you process a 1 sec raw data capture, in the worst scenario you will have 1/2 sec of uncertainty... if the drone is moving at 13m/s you will have 6.5m error (in the worst scenario).

Please correct me if i am wrong

Posibles solutions:
1) move slower (higher battery cost)
2) try to store at higher frequencies (at least 1/300 which is impossible i think with the drone and any other commercial gps)
3) try to synchronize the time of data capture of the drone with the base station AND maintain it. There is an option in the controller where you can select between "timed shooting" and "distance shooting".
    Selecting "time shooting" you can maintain that "time shift" in a constant

Guille_Meinero Posted at 7-3 07:45
Hi, i have tried and compared RTKLIB and other software that make a PPK between drone rinex and a base station (public and my own).... The main problem i see is basically the interpolation to calculate the position of the drone... if you process a 1 sec raw data capture, in the worst scenario you will have 1/2 sec of uncertainty... if the drone is moving at 13m/s you will have 6.5m error (in the worst scenario).

Please correct me if i am wrong

um. if done right there is a mark (time) that occurs when you take the picture. This will not ever be at the actual GNSS epoch that is processed. so you interpolate between. usually using linear. You assume a constant velocity or whatever. But the actual GNSS epoch is solved by processing, PPK, or RTK. And that has its own time stamp. So the mark is used to compute the in between. Now if your epochs are far apart then it gets more of a guess when you extrapolate the position of he mark. but … it is NOT the error you seem to mention. At time T = 0, 1, 2, 3, you get GNSS positions at the those times (epoch). The camera fired off at T = 0.005, T= 2.652 etc. You draw a line between the time at 0 to 1, and at 0.005 that is the position you assign that mark, and it will be what you assign the image taken. But you also want to account for the offset from the GNSS sensor on the drone to the actual camera. That info is in the manual.

Decent PPK software will do this. The on board RTk does this, and also accounts for the offset. However if you PPK, you need to do the offset still.

So fly at whatever speed you need to.  now, if you are using 1 second GNSS data from a public base, it will work, but you probably will get better results from a 0.2 second logging, if you use your own base. Again this only matters if you are doing PPK. If you do RTK it is different, and it is a matter of how often updated RTK corrections arrive. I don't think those need to be as frequent though, because an rtk correction is not going to change drastically in a short time.

the clock on a GNSS is very good.

the manual says what the offsets are physically from the GNSS sensor to the camera. But … as you say, I think you have to also consider the direction of flight … maybe. by the way, this is one thing that worries me about if you plan a mission where you fly forward and then fly backwards. To get various angles for like 3D. Because if not accounted for, it will affects the results. I suspect it is ok when doing RTK as the on board IMU handles it. I am not so sure for PPK.

Geomaticist Posted at 8-27 14:53
um. if done right there is a mark (time) that occurs when you take the picture. This will not ever be at the actual GNSS epoch that is processed. so you interpolate between. usually using linear. You assume a constant velocity or whatever. But the actual GNSS epoch is solved by processing, PPK, or RTK. And that has its own time stamp. So the mark is used to compute the in between. Now if your epochs are far apart then it gets more of a guess when you extrapolate the position of he mark. but … it is NOT the error you seem to mention. At time T = 0, 1, 2, 3, you get GNSS positions at the those times (epoch). The camera fired off at T = 0.005, T= 2.652 etc. You draw a line between the time at 0 to 1, and at 0.005 that is the position you assign that mark, and it will be what you assign the image taken. But you also want to account for the offset from the GNSS sensor on the drone to the actual camera. That info is in the manual.

Decent PPK software will do this. The on board RTk does this, and also accounts for the offset. However if you PPK, you need to do the offset still.

I'll try to make some comparisons. Thanks for your reply