PPK issue and/or Pix4D issue?

Did my first test mission with PPK yesterday… didn’t yield the results I was hoping for, so maybe you gurus can help a brother out here :wink:
I have a Matrice 600 with Sony A6000 camera, fitted with an Emlid hotshoe adapter and Reach M+ of course. I downloaded RINEX data from the national Dutch CORS network and used that in RTKPOST. PPK went fine, with just a few “orange dots” (I used the settings as described in the docs section)

I also placed 4 GCPs as checkpoints, which I measured with my Reach RS (also fed by CORS correction data of course). This is how the captures look like in Pix4D:

I tried a 10 degree camera angle for this run… maybe that was a mistake, as this is the quality report:

Not the accuracy I was looking for… thoughts?

Oh… also… there were 201 initial pictures, but 221 recorded trigger events. It should have recorded every odd-numbered second in this case (camera is self-triggering via the time lapse app, every 2 seconds), but there were 20 faulty records, on even-numbered seconds. I removed these before geotagging the pictures in Pix4D.

This is the quality report when I change the checkpoints to 3D GCPs:

Nobody? :frowning:

Can you post a picture of your drone antenna setup ?

Is your camera located vertically underneath under the antenna?
Was there a good bit of wind on the day?

Yes the camera’s lens is exactly below the antenna and I entered the Z offset in rtkpost before processing. I do realise that there will be a horizontal offset as well, when the drone tilts forward during flight.
Hardly any wind that day. I was wondering if my 10 degree camera angle was a bad idea… it was just a test. But I thought it shouldn’t make any difference for photogrammetry…

I have flown with a 70 degree angle (20 deg in your terminology) without any issues, so would be wierd if that was your issue.

When you processed your GCP positions and the camera positions, did you use the same base obs ?

Hmmm no I didn’t… I used realtime CORS data for the Reach RS to get a fix for measuring the GCPs… and downloaded the rinex file from the CORS network for the timeframe I was flying in for the PPK part

That’s probably where your problem is then. They might have a few offsets to each other, even though they shouldn’t.

Can you reprocess your gcp with the CORS files from your flying? If you have the log for that, of course.

If not, maybe just create an offset. If the theory above holds, you should see a general offset, that you can then correct.

Interesting. I’ll download a new rinex file from the CORS network then, as it needs to have an earlier start time as the one I have now (I measured the GCPs before I went flying). No time this evening, but I’ll sure give it a try tomorrow. Thanks for the tip!

1 Like

Before I waste money… :wink: Please take a look at the screenshot of my CORS provider’s RINEX data request form (tab 2):

I took a picture every 2 seconds, but I assume an interval of 1 sec is more on the safe side?

Next tab… what do I select for GLONASS bias class here?

And the next one, data format?

Hi @jantjj

I’d like to clarify that we couldn’t provide you with Pix4D support, so I can only help with Reach logs.
It seems that they are of good quality and the issue is on the Pix4D settings side.

As for this @wizprod quote, you don’t need to buy another CORS RINEX file as you placed your GCPs in RTK mode.

I can look through your log to check if the issue connected with raw data.

I did, but what I think @wizprod means, is that when I PPK the GCPs with the same RINEX file as I used for the pictures, then it might help…

Hi Jan,

I’ve just noticed the following text in your initial post:

This doesn’t sound right and should be addressed. Could you test your setup on the ground to see if this is a repeated issue?

The reason for such errors in your quality report may hide in a different number of images and trigger events. Particularly in that place where you remove faulty records. Are you sure your photos have the corresponding timestamps?

Perhaps, time lapse app is not functioning as it should.

The timelapse app is working just fine; it triggers every 2 seconds and I tested this thoroughly. Never a missed shot. However, the Reach M+ records more trigger events than are actually occuring… so my guess is that’s a faulty connection/wire, that short circuits sometimes or something like that…
Plus… when I remove the faulty logs, I have the right number of images, that match the number of logs remaining, so I’m pretty sure the photos have the corresponding timestamps.

I posted this issue on a Facebook Pix4D users group as well and one of the users said I needed to change the accuracy of the photos in the Images Properties Editor. By default, it’s set to 5m/10m (hor/ver)… and he said I should change it to 0.05m. Painful process, since I had to do that manually for every picture, but okay. And this is the quality report after re-running Step 1. Checkpoints only… NO GCPs!

I can’t really explain my feelings about this, but it feels like cheating or something. Besides that, the suggested 0.05 value for accuracy isn’t based on anything. The question here is:

What is a realistic value, so that the quality report is trustworthy and can be shown to customers?

And I also did another test, whereby I changed the checkpoints to 3D GCPs… take a look at the absolute vertical error. I just don’t understand how this works…

Nobody from @emlid have any thoughts on this? @TB_RTK you perhaps? :wink:

Setting the accuracy to 0.05 is standard procedure. Normally you would enter your RTK RMS here. It’s not cheating, it is giving a weight to your GCP’s. So if you have points with known high errors (like embedded exif gnss location from a Phantom 4) it can be set to 10 meters or similar. Then the program knows that these are unprecise, and cannot be relied upon as much as your GCP’s.
Remember this is not your absolute geo error, but a relative one. Your absolute error is how good you are at placing your base over a known point, and/or how long your baseline is.

Thanks @wizprod! So this quality report is fairly reliable then? (geolocation accuracy in Pix4D set to 0.05; checkpoints only; no GCPs)