Does DD care about autel or yuneek to do anything about it?
2 Likes
Hi Michael,
thank you for your detailed view.
But I have to correct your initial statement: my report being in meters means that 0.01 m is 1 cm accurate, not 10 cm.
So “RMSE of Camera GPS Location X 0.00m Y 0.00m Z 0.00m RMSE 0.00m” means that there is no measurable RMSE on a centimetre basis, what would mean by rounding standards that the error is even below 5 mm.
The same with "Average GPS Trust 0.03m” from my report. The GPS error is smaller than 3.5 cm (35 mm).
I completely agree with jmason702 by saying:
“If these values are true! BOOM EVO for everyone!
is DD on the forums?”
Unfortunately I cannot make my report public as the imagery and RTK/PPK data was sent to me for personal evaluation.
1 Like
Good catch. Then yours is in the same scenario as @jmason702… Too much weight on the image tags. Have you tried a map with and without GCP’s to see the cut/fill comparison? How did your checkpoints come out?
https://drive.google.com/drive/folders/1eRSFVnAYTivJuGYPdE_pqwHlpPuC17c2?usp=sharing
here is all the data from one of my flights
Ok,
Lots of info to post here. I did two flights, one manual camera setting, one in Shutter P.
both flights… 150ft AGL, 7MPH, 80/80 overlap, 120 photos all nadir for testing purpose.
-DD reports with no CPs or GCPs. ( not paying $50 a pop for these)
-Meta Shape error results
and a file set to prosses for yourself with one recorded point.
1 Like
https://drive.google.com/drive/folders/1mOc_BAti9VC8c0ggSGwn5y082bfaWMMe?usp=sharing
https://drive.google.com/drive/folders/1CML8d9dCKvx_cM37umN1SYvvk00-x4fd?usp=sharing
1 Like
Hi jmason702,
just to confirm: for your two above mentioned test flights you did not use a base station (relative positioning base/drone)? Both photo series were shot with RTK data feed directly from the remote controller to the drone (absolute positioning CORS/drone), right?
I just started to test your uploaded imagery. Will report later on…
I used base station, base was getting corrections from NTRIP and sending corrections to drone via NTRIP CASTER
it is the same as connecting to NTRP MT POINT
I downloaded Reality Capture Software, trying to learn the system now, I will post those results once I figure it out
So we just had a support session on a specific map that would not reconstruct properly. It was a corridor flight so it wasn’t unexpected as linear mapping has always been a little suspect. What we did figure out is that DroneDeploy was not applying the correct GPS trust level to the images just like we have talked about here. Our previous reports showed a 10m trust level which is the default for non-RTK but with images captured using RTK you need to be at the spec of the GNSS system which for most is 2-3cm. One their reprocessing of the map they applied a 4cm trust level and the map came out near perfect. Spot grades on the deteriorating roadway were +/- 0.08ft which was pretty eye opening considering the condition of the surfaces be modeled. I still think if you are seeing less than 1cm on your reports that something is wrong and they need to give their algorithms a once over. It’s an honest gap by them considering the none of the RTK drones are officially supported and on our Yuneec in particular the RTK and standard models both use the exact same camera and since I have been flying with that camera for a while it was calibrated as a non-RTK previously. I don’t know how they are going to tell the difference.
Normal Processing with no GCP’s and the incorrect image tag trust level. Note the errors shown on the image location section. Also, this map had doming which is also an issue sometimes with linear mapping.
Normal processing with GCP’s and incorrect trust level. Note the RMSE’s on the interface outside of the report. With GCP’s this should be 0’s or very near so. So instead of doming this one picked up a short side tilt. Also not surprising on linear maps because the GCP’s cannot be spread out on one of the axis.
DroneDeploy Re-Process with the correct trust level. This is more like it but there is still something wrong with the camera location RMSE’s in my opinion. No way the visual tie-points and the geotags match within 0.05ft as an average across all 200 images. I mean you can see the condition of the dots right?
That all said the re-processed map is accurately on the output so right now I don’t care what the report says but it does need to get fixed or we will inevitably end up with a project that requires backup.
1 Like
i will reprocess rite now
With DroneDeploy? Your reports already show that you have the correct or at least close to the correct trust levels so reprocessing yours there probably isn’t going to make much of a difference. I wonder if there’s something different about your RTK camera than the standard one that DroneDeploy already recognized…
1 Like
That is exactly what I was wondering about, but I sent jmason702’s published “manual shutter” flight data into PIX4Dcloud and they are “as excited” about the EVO2RTK’s EXIF data as DD:
I am currently only using a trial there, so I think it would be a little unfair to post screenshots of the reports. But here is some copy/paste data:
- Average Ground Sampling Distance (GSD) 0.95 cm / 0.37 in
- Camera Optimization 0.9% relative difference between initial and optimized internal camera parameters
- Absolute camera position and orientation uncertainties
X [m] Y [m] Z [m] Omega [degree] Phi [degree] Kappa [degree]
Mean 0.002 0.001 0.001 0.002 0.003 0.001
Sigma 0.000 0.000 0.000 0.000 0.000 0.000 - Mean Reprojection Error [pixels] 0.209
- Internal Camera Parameters
vvv Focal Length, Principal Point x, Principal Point y, R1, R2, R3, T1, T2
Initial Values 4221.410 [pixel] 10.131 [mm], 2744.005 [pixel] 6.586 [mm], 1848.880 [pixel] 4.437 [mm], 0.072, -0.231, 0.273, 0.001, 0.001
Optimized Values 4183.184 [pixel] 10.040 [mm], 2743.524 [pixel] 6.584 [mm], 1856.651 [pixel] 4.456 [mm], 0.071, -0.193, 0.220, 0.002, 0.001
Uncertainties (Sigma) 1.902 [pixel] 0.005 [mm], 0.076 [pixel] 0.000 [mm], 0.119 [pixel] 0.000 [mm], 0.000, 0.001, 0.001, 0.000, 0.000 - Relative camera position and orientation uncertainties
vvv X [m], Y [m], Z [m], Omega [degree], Phi [degree], Kappa [degree]
Mean 0.002, 0.002, 0.002, 0.006, 0.008, 0.001
Sigma 0.000, 0.000, 0.001, 0.003, 0.003, 0.000 - Absolute Geolocation Variance
Min Error [m], Max Error [m], Geolocation Error X [%], Geolocation Error Y [%], Geolocation Error Z [%]
-, -0.03, 0.00, 0.00, 5.00
-0.03, -0.03, 0.00, 0.00, 3.33
-0.03, -0.02, 0.00, 0.00, 8.33
-0.02, -0.01, 7.50, 1.67, 10.00
-0.01, -0.01, 25.00, 19.17, 10.00
-0.01, 0.00, 20.00, 26.67, 12.50
0.00, 0.01, 14.17, 31.67, 10.83
0.01, 0.01, 25.00, 19.17, 11.67
0.01, 0.02, 6.67, 0.83, 12.50
0.02, 0.03, 1.67, 0.83, 8.33
0.03, 0.03, 0.00, 0.00, 1.67
0.03, -, 0.00, 0.00, 5.83 - Relative Geolocation Variance
Relative Geolocation Error, Images X [%], Images Y [%], Images Z [%]
[-1.00, 1.00], 80.00, 89.17, 68.33
[-2.00, 2.00], 100.00, 100.00, 95.00
[-3.00, 3.00], 100.00, 100.00, 100.00
Mean of Geolocation Accuracy [m]: 0.011250, 0.011250, 0.019778
Sigma of Geolocation Accuracy [m]: 0.000466, 0.000466, 0.000495
They’re reporting geolocation error in %'s? Or is it the relative geolocation error of 1.1-2cm? I’m about done with the reporting that these companies do that are not even ASPRS standard measurements. It’s just like the hype marketing speak from DJI when the P4R came out. I want to see ground surveyed checkpoint results or in the field stakeout of the surface. That’s real accuracy… and a GSD of 0.37in/px is amazing but hardly practical unless you are flying a block. What size of sites are you guys reporting on? The larger they get the faster those numbers will go up especially if you are using a local base.
I don’t know, but it could certainly be from the EXIF info on the imagery. There is an “Accuracy” field in the EXIF that lists “0s” for a typical EVO2 6k camera, meters when using the precision gnss, and centimeters when used with a FIXed NTRIP connection.
Metashape uses that stated accuracy to apply weighting to the images.
3 Likes
I bet you’re right. I need to look at my EXIF’s for that.
I think you refer to this section of the report:
Relative Geolocation Error, Images X [%], Images Y [%], Images Z [%]
[-1.00, 1.00], 80.00, 89.17, 68.33
[-2.00, 2.00], 100.00, 100.00, 95.00
[-3.00, 3.00], 100.00, 100.00, 100.00
It should state the percentage of images whose geolocation is within a certain XYZ accuracy range:
X-wise: 80 % are within +/- 1 cm, 100 % are within +/- 2 cm and 100 % are within +/- 3 cm.
Y-wise: 89.17 % are within +/- 1 cm, 100 % are within +/- 2 cm and 100 % are within +/- 3 cm.
Z-wise: 68.33 % are within +/- 1 cm, 95 % are within +/- 2 cm and 100 % are within +/- 3 cm.
Well, jmason702’s field size (120 images, PIX4Dcloud) is:
Area Covered 0.017 km2 / 1.7431 ha / 0.01 sq. mi. / 4.3094 acres
Average Ground Sampling Distance (GSD) 0.95 cm / 0.37 in
RMS Error [m] 0.009169 0.007200 0.019462 (XYZ)
My evaluation dataset from a vendor in Italy (88 images, PIX4Dcloud) is:
Area Covered 0.016 km2 / 1.6412 ha / 0.01 sq. mi. / 4.0577 acres
Average Ground Sampling Distance (GSD) 0.96 cm / 0.38 in
RMS Error [m] 0.018248 0.012093 0.023426 (XYZ)
Maybe you are right with the relatively small area sizes.
BTW: jmason702’s camera was rated better than my evaluation data set:
jmason702:
Camera Optimization: 0.9% relative difference between initial and optimized internal camera parameters
my data set:
Camera Optimization: 2.03% relative difference between initial and optimized internal camera parameters
That could explain jmason702’s data being approx. 10% better than my test data. Probable cause here may be the 6K Pro Camera’s focal length EXIF data being 10 mm for jmason and 11 mm for my EXIF data.
PIX4D re-assumes 10.040 [mm] focal length after optimization for jmason702 (difference 0.040 mm to EXIF 10 mm). For my data set PIX4D re-assumes 9.744 [mm] focal length after optimization (difference 1.256 mm to EXIF11 mm).
2 Likes
Ok I get it now and those small of missions at extremely close GSD’s definitely explains why the numbers are so low. As the projects get larger you naturally fly higher and the longer the time you are out there the more the satellite tracks change which is extremely important for RTK. Typical GPS satellites are in optimum position for about 2-3 hours. I am guessing these missions took less than 10 minutes and we are usually in flight for 40-60 minutes including battery changes which break the fix and the receivers have to re-initialize. JM’s RMS shows less than a centimeter horizontally which is spec or just under for even survey grade GPS.