Emlid with a Autel Evo RTK UAV

The exif data has a specific line item that tells the software to hold the geotag value instead of relying on movement from the “visual” stitching which will modify the location of the image. DroneDeploy had to add that tag name specifically for the system to recognize it was high precision data.

Having two different manufacturers and vastly different sensors running through a 3rd party software is not comparable IMO. Obviously Pix4D would have spent a lot of time tweaking for the M300 and I doubt they even looked at the Evo much at all. Just let people struggle until it becomes enough of an issue. Kind of sums up why we don’t use them. You can’t be on the edge of tech like this and have mediocre to poor support.

1 Like

I did find this in the image data

That’s it. Now look at one of your m300 images and see if it’s in the same category and named the same.

The m300 doesn’t call it out.
xmp:ModifyDate=“2022-12-07 09:36:18”
xmp:CreateDate=“2022-12-07 09:36:18”
tiff:Make=“DJI”
tiff:Model=“ZenmuseP1”
dc:format=“image/jpg”
drone-dji:Version=“1.4”
drone-dji:GpsStatus=“RTK”
drone-dji:AltitudeType=“RtkAlt”
drone-dji:GpsLatitude=“+30.562872469”
drone-dji:GpsLongitude=“-97.882620203”
drone-dji:AbsoluteAltitude=“+360.192”
drone-dji:RelativeAltitude=“+60.003”
drone-dji:GimbalRollDegree=“+0.00”
drone-dji:GimbalYawDegree=“+160.30”
drone-dji:GimbalPitchDegree=“-89.90”
drone-dji:FlightRollDegree=“+0.70”
drone-dji:FlightYawDegree=“+162.00”
drone-dji:FlightPitchDegree=“-8.30”
drone-dji:FlightXSpeed=“-6.3”
drone-dji:FlightYSpeed=“2.0”
drone-dji:FlightZSpeed=“0.0”
drone-dji:CamReverse=“0”
drone-dji:GimbalReverse=“0”
drone-dji:SelfData=“”
drone-dji:RtkFlag=“50”
drone-dji:RtkStdLon=“0.00827”
drone-dji:RtkStdLat=“0.00987”
drone-dji:RtkStdHgt=“0.02682”
drone-dji:RtkDiffAge=“2.60000”
drone-dji:SurveyingMode=“1”
drone-dji:UTCAtExposure=“2022-12-07T15:36:36.274881”
drone-dji:ShutterType=“Mechanical”
drone-dji:ShutterCount=“92984”
drone-dji:CameraSerialNumber="
drone-dji:LensSerialNumber=
drone-dji:DroneModel=“Matrice 300 RTK”
drone-dji:DroneSerialNumber=
crs:Version=“7.0”
crs:HasSettings=“False”
crs:HasCrop=“False”
crs:AlreadyApplied=“False”>

Autel’s Camera:GPSXYAccuracy=“” tag seems to be equivalent to DJI’s drone-dji:RtkStdLon/Lat=“”.

When you import the images in Pix4D, check the Accuracy Horz/Vert fields. I’m thinking maybe Pix4D doesn’t read the tag correctly and enters wild values by default? You can change them automatically for all images by right clicking the field in the first image’s line and selecting Edit All Horz. Accuracies. It does change how Pix4D does its reconstruction.

Just enter a value that’s close to what you see in the image tags, 5-10cm.


image

Looks like they import it correctly, they just round up.
Camera:GPSXYAccuracy=“0.009600”
Camera:GPSZAccuracy=“0.026563”

This is one of the reasons why they don’t process the same. I am surprised though because pick 4D has a specific setting to tell the software what the precision of the images is. Did you go into settings and set it to a 10th?

GPS trust values should be 2 to 3 cm.

I am kinda curious why neither of those numbers were what I used for the geoid -83.58 and the difference between them is about what I’m off by. I’m gonna fly another test at a different site and see if I get the same thing. Right now pix is telling me my data is off…either GCP or VCS which is not true at least from everything I’ve been looking at.

Survey ground control vary rarely matches network obtained values and localizations don’t help. Just one of the checkboxes we always have to go through. We basically do our own localization and rectify that to the survey. I hit a tenth occasionally when staking out a CAD (ground) point with the network but it’s not uncommon to see 2-3ths invertical. Not saying that’s what’s going on but that how I process.

Yeah, I noticed that when I was using Aeropoints for ground control, would maybe be within a 1/10 2 out of 10 flights…if that.

Flew another test flight with the EVO. Still not right. Elevation wasn’t off by 6 feet though this time, only about 8/10th horizontal .2 to .6. No idea what’s going on. Opened a ticket with Autel again. Seems like horizontal and vertical CS are not right but from what I can tell looks correct according to the data in the images.
I also took a picture with the drone sitting close to my base after I flew the site.
Ellipsoid height from the pic is 239.83221m 786.851083ft then added what the geoid offset is 84.222ft and get 871.073 and I get a difference of .1731 ft about 2 in which is basically the height of the drone.
To be continued.

Joe, can you try doing a test mission and leave everything in WGS 84 ellipsoidal height with both control and the drone, and see how it comes out

I think you have too many variables in play to try and pinpoint where the error is coming from.

Hey Dave, Sure I’ll give that a shot as soon as we get a break from the rain. I was able to sneak a flight in this morning just before a down pour…weather in Texas, wait an hour and it will change.

Good! keep it simple and I’ll run the project through Metashape for comparison as well.

1 Like

Does this work for Reach RS+ model?

Waaait a second. I don’t know if it’s been mentioned earlier in the thread, it’s been a while, but is the antenna/camera offset taken into account?

I think the DJI and Autel drones require a multi-band gnss. The RS+ is single-band.

2 Likes

This is correct. It will connect but it will never get past a float.

1 Like

Comparing the reported position of the drone on the ground next to a known point, there will be some expected small offset from the center of sensor to the ground.

That offset isn’t a factor in processing. It’s just a quick check to see if the readout is reasonable.

1 Like