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
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:
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.
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…
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
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!
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’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…
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.
