Ratio Factor for AR Validation problem?

Hello everyone,

Recently my company bought M2 Emlid reach set. I have a problem with aerial photography. After post processing RTKPLOT said that 100% points in pos.event file were fixed. Report from pix4d mapper indicated few points with about 20-30 cm error and 2 with about 50 cm error. I think the problem is Ratio Factor for AR Validation. AR Validation graph show decrease of ratio factor for few minutes. What to do to solve this issue? Thanks

RTKPOST settings:

rtkpost_qt options (2021/03/13 11:34:26, v.2.4.3 Emlid b33)

pos1-posmode =kinematic # (0:single,1:dgps,2:kinematic,3:static,4:static-start,5:movingbase,6:fixed,7:ppp-kine,8:ppp-static,9:ppp-fixed)
pos1-frequency =l1+l2 # (1:l1,2:l1+l2,3:l1+l2+l5,4:l1+l5)
pos1-soltype =forward # (0:forward,1:backward,2:combined)
pos1-elmask =20 # (deg)
pos1-snrmask_r =on # (0:off,1:on)
pos1-snrmask_b =off # (0:off,1:on)
pos1-snrmask_L1 =40,40,40,40,40,40,40,40,40
pos1-snrmask_L2 =40,40,40,40,40,40,40,40,40
pos1-snrmask_L5 =4,40,40,40,40,40,40,40,40
pos1-dynamics =on # (0:off,1:on)
pos1-tidecorr =off # (0:off,1:on,2:otl)
pos1-ionoopt =brdc # (0:off,1:brdc,2:sbas,3:dual-freq,4:est-stec,5:ionex-tec,6:qzs-brdc,7:qzs-lex,8:stec)
pos1-tropopt =sbas # (0:off,1:saas,2:sbas,3:est-ztd,4:est-ztdgrad,5:ztd)
pos1-sateph =brdc # (0:brdc,1:precise,2:brdc+sbas,3:brdc+ssrapc,4:brdc+ssrcom)
pos1-posopt1 =off # (0:off,1:on)
pos1-posopt2 =off # (0:off,1:on)
pos1-posopt3 =off # (0:off,1:on,2:precise)
pos1-posopt4 =off # (0:off,1:on)
pos1-posopt5 =off # (0:off,1:on)
pos1-posopt6 =off # (0:off,1:on)
pos1-exclsats = # (prn …)
pos1-navsys =63 # (1:gps+2:sbas+4:glo+8:gal+16:qzs+32:comp)
pos2-armode =fix-and-hold # (0:off,1:continuous,2:instantaneous,3:fix-and-hold)
pos2-gloarmode =on # (0:off,1:on,2:autocal,3:fix-and-hold)
pos2-bdsarmode =on # (0:off,1:on)
pos2-arfilter =on # (0:off,1:on)
pos2-arthres =3
pos2-arthres1 =0.1
pos2-arthres2 =0.25
pos2-arthres3 =0.1
pos2-arthres4 =0.05
pos2-varholdamb =0.001 # (cyc^2)
pos2-gainholdamb =0.01
pos2-arlockcnt =0
pos2-minfixsats =4
pos2-minholdsats =5
pos2-mindropsats =20
pos2-rcvstds =off # (0:off,1:on)
pos2-arelmask =0 # (deg)
pos2-arminfix =100
pos2-armaxiter =1
pos2-elmaskhold =0 # (deg)
pos2-aroutcnt =100
pos2-maxage =60 # (s)
pos2-syncsol =off # (0:off,1:on)
pos2-slipthres =0.05 # (m)
pos2-rejionno =1000 # (m)
pos2-rejgdop =30
pos2-niter =1
pos2-baselen =0 # (m)
pos2-basesig =0 # (m)
smooth-mode =pos-domain # (0:off,1:meas-domain,2:pos-domain)
smooth-window =100 # (s)
smooth-varratio =0.2
base-multi_epoch =on # (0:off,1:on)
resid-mode =on # (0:off,1:on)
resid-maxiter =2
resid-reset_fix =0.3 # (m)
resid-reset_float =1 # (m)
resid-block_fix_sat =0.3 # (m)
out-solformat =llh # (0:llh,1:xyz,2:enu,3:nmea)
out-outhead =on # (0:off,1:on)
out-outopt =off # (0:off,1:on)
out-outvel =off # (0:off,1:on)
out-timesys =gpst # (0:gpst,1:utc,2:jst)
out-timeform =hms # (0:tow,1:hms)
out-timendec =3
out-degform =deg # (0:deg,1:dms)
out-fieldsep =
out-outsingle =on # (0:off,1:on)
out-maxsolstd =0 # (m)
out-height =geodetic # (0:ellipsoidal,1:geodetic)
out-geoid =egm96 # (0:internal,1:egm96,2:egm08_2.5,3:egm08_1,4:gsi2000)
out-solstatic =all # (0:all,1:single)
out-nmeaintv1 =0 # (s)
out-nmeaintv2 =0 # (s)
out-outstat =off # (0:off,1:state,2:residual)
out-addit_info =off # (0:off,1:on)
stats-eratio1 =300
stats-eratio2 =100
stats-errphase =0.003 # (m)
stats-errphaseel =0.003 # (m)
stats-errphasebl =0 # (m/10km)
stats-errdoppler =10 # (Hz)
stats-stdbias =30 # (m)
stats-stdiono =0.03 # (m)
stats-stdtrop =0.3 # (m)
stats-prnaccelh =1 # (m/s^2)
stats-prnaccelv =1 # (m/s^2)
stats-prnbias =0.0001 # (m)
stats-prniono =0.001 # (m)
stats-prntrop =0.0001 # (m)
stats-prnpos =0 # (m)
stats-clkstab =5e-012 # (s/s)
ant1-postype =llh # (0:llh,1:xyz,2:single,3:posfile,4:rinexhead,5:rtcm,6:raw)
ant1-pos1 =0 # (deg|m)
ant1-pos2 =0 # (deg|m)
ant1-pos3 =0 # (m|m)
ant1-anttype =
ant1-antdele =0 # (m)
ant1-antdeln =0 # (m)
ant1-antdelu =0 # (m)
ant2-postype =rinexhead # (0:llh,1:xyz,2:single,3:posfile,4:rinexhead,5:rtcm,6:raw)
ant2-pos1 =0 # (deg|m)
ant2-pos2 =0 # (deg|m)
ant2-pos3 =0 # (m|m)
ant2-anttype =
ant2-antdele =0 # (m)
ant2-antdeln =0 # (m)
ant2-antdelu =0 # (m)
ant2-maxaveep =0
ant2-initrst =off # (0:off,1:on)
misc-timeinterp =off # (0:off,1:on)
misc-sbasatsel =0 # (0:all)
misc-rnxopt1 =
misc-rnxopt2 =
misc-pppopt =
file-satantfile =
file-rcvantfile =
file-staposfile =
file-geoidfile =
file-ionofile =
file-dcbfile =
file-eopfile =
file-blqfile =
file-tempdir =
file-geexefile =
file-solstatfile =
file-tracefile =

Can you upload your raw-data for repro?

Yes, sure

raw_202103111004.pos (5.0 MB) raw_202103111004_events.pos (233.7 KB)

So the data you have is from the m2 on the drone, including triggers?
How are the Checkpoint positions calculated?
Are you using any Control points?

Having processed the data in both RTKpost and EzSurv, I don’t see anything obviously wrong with the data, as such.

From looking at your settings above you probably want to drop the SnR to at least 35. We have never had any luck using a Geoid for PP height and then expecting it to match with my orthometric heights shot on our checkpoints and GCPs. Of course we always use GCPs so we haven’t had a need. What satellites did you use and did you check their status throughout the mission? Being a UAV flight it is really odd that there seems to be a pattern… Interference in one direction vs the other?

As for the Pix4D results… It looks like you didn’t use GCPs? Photogrammetry processing is not a perfect science and the algorithms misinterpret data all the time. Run the same mission twice and see what you get. The answers will be different. The algorithms also give more weight to the visual matching than it does to any control points, more importantly GCP’s. In order to really nail down the accuracy you need to spend the time to verify with you own eyes that tie point matching is consistent and if you use GCP’s that they are tagged near perfectly. Especially if any auto-tagging is performed. Never trust the machine. Next time you do use GCPs go check the elevation values on the model/point cloud where you tagged them and observe how they don’t match. It’s all interpretation and interpolation. What were you camera position RMSE’s?

1 Like

According to the obs-file, then G+R+E, but the base-obs file only has G+R, so the Gal-constellation isn’t used.

When processed with EzSurv each “camera” has a stdev xy of ~0.2 meter and vertical around ~0.36 m.


This is what the report looks like

28_report.pdf (1.3 MB)

I’m no photogrammetrist, but it appears to me the GCP’s are pretty sloppy in location. Usually when we contract out any Photogrammetry, we provide the horizontal/ vertical control and placement of the GCP’s per the photogrammetrist locations.

We have accuracies of GCP’s of less than 2cm horizontal and vertical depending on site size and referenced to the NSRS.

1 Like

I think we have to look at it from another perspective: where do the Checkpoints come from? How are they derived?

The RTK-position data seems sound, from reading the Report.

1 Like

I agree, but the OP has yet to tell us whether or not they used GCP’s and or checkpoints. I assume so since they are worried about values, but who knows… Depending on the scenario the values posted by @wizprod are either really bad or too good to be true.

Hi Michal,

The AR ratio changing doesn’t affect the accuracy while the solution status remains Fix.

The orthomosaic quality indeed depends on many factors.

In the report you’ve shared, I noticed the “no 3D GCP” error message. Do your GCPs coordinates contained z-coordinate? Have you collected GCPs using the Reach device?


As I read the report and this sentence, it means that all markes are used for Check Points, and none of the markers as Control Points.

1 Like

The stdevs of the flight you mean?
I am guessing they are acceptable for a fixed-wing mission, the speed being higher than a multi rotor…

I’m just not sure what values they are. Are they the deviation between the drones image location vs the PPK’d events or the camera location residuals from photogrammetry. From my perspective those would be amazingly good values of the PPK shift and pretty good values for the PG processing camera relocations.

The stdev values I posted above are theoretical uncertainties, I would think stem from the interpolation process coupled with the postprocessing results of each postprocessed epoch.

1 Like

Sorry, I should have introduced you to the topic. We are doing ppk test flights using the emlid device. I have been working with post processing for a short time and I am just learning. Checking the accuracy and placement of checkpoints were handled by other surveying company. Measurement of checkpoints was made by Trimble R6 receiver, but I am not sure about that. The coordinates of the points are recorded in the state reference system 2000(7) (EPSG: 2178). Z coords are in EVRF2007. We make UAV’s missions and determine image’s geolocations. The missions were performed using a fixed-wing drone. Recently, on similar terrain, we obtained an accuracy of less than 10 cm on check points by performing the mission using a hybrid drone and with the same emlid module. Thanks for engaging in the discussion and sorry for my English.

1 Like

Hi Svetlana,

Is age of Differential can affect on the accuracy?

Would it be possible to get the images and GCP-locations for processing in Metashape?

Would be interesting to see if I would get the same error, when setting up the project in the same way, but in a different piece of software.

Yes, but I still waiting for GCP-locations file.
Images here