Almost Consistent geolocation error

WebODM
#1

This is a puzzlement. I’m losing hair over this issue and at 70 I don’t have much to spare.

I’m doing a comparative processing exercise for a small drone company. Their drone uses RTK GPS with Trimble GPS and attitude equiment. The data is processed through PostPac and yields a SBET and geo.txt file in the appropriate UTM (WGS84) CRS.

This company has adapted a version of ODM 2.8 to accept the geo.txt file ( I think they have gotten their ODM 2.8 based processor to use the omega, phi, kappa values ???) and imagery and gets consistently excellent geolocation results. ( a little less than 2X the GSD size in X/Y error to ground truth). They are using the trianglulation process for SfM. I think this is wonderful for processing without GCP’s.

I’m using the same imagery and geo.txt files from three sites (TN, IL, and TX) and processing through the current WebODM S/W. I am using the incremental SfM. For the TN site, my geolocation error is comparably excellent to the drone company’s processor. On the IL and TX site, the geolocation error is consistently ~1 meter to the east-south-east.

Suggestions???

Konrad

1 Like
#2

How far is the basestation from the data in the IL and TX cases (assuming they’re linking into something like CORs and not using an on-site rover/base config)?

1 Like
#3

Also could the datum (NAD 83 or WGS 84) of the base and corrected positions require an additional translation to the appropriate datum? Or could the positions been double corrected? Just a thought.

1 Like
#4

Many apologies to all the thoughtful answers. The problem wasn’t with WebODM but QGIS. QGIS made a Cartesian transformation between UTM WGS and SPEC. The transformation needed to be geodetic as these two CRS use a different center of the earth.

3 Likes
#5

Glad to hear that you got it sorted out!

CRS issues always break my brain :rofl:

2 Likes
#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.