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