Optimal workflow for M3E with RTK

WebODM
#1

First of all, I want to say I appreciate this community as it has been an invaluable resource for me and my mapping journey! Thank you all.

On to the questions at hand: I have recently acquired a Mavic 3 Enterprise with Network RTK.
and I have begun the process of nailing down a correct workflow for producing the highest possible quality ortho’s and DEM’s. A report for a recent mission can be viewed here:

PDF: report.pdf - Google Drive
TXT: task_output.txt - Google Drive

This is the first RTK dataset I have processed. I use WebODM and Lightning for processing, and I am using DJI Pilot 2 for the flight planning which has some restrictions. I flew using the DJI pre-programmed “oblique” flight template which flies 5 different paths, with path 1 being nadir, and 2-5 being oblique. Oblique angle was 70 degrees. Front and side overlap 83%. All from 110 m altitude.

Looking at the report, I am happy to see the GPS errors are within expected tolerances. However, are the relative 3D errors a little higher than expected?

For verification I have overlayed a conventional topo survey over the DEM and compared elevations and the errors seem to agree with the 3D error in this report, in the area of 0.1 to 0.3 meters.

Am I just expecting too much for a dataset produced at 110 m with no GCP’s? Or is there something going on here? Would GCP’s improve this type of error?

Does anyone have any suggestions for how I might tighten this relative error to 0.05 m or better? Running on Ultra is not an option because I don’t have any other way to process than Lightning.

I appreciate any comments or suggestions. Additional data can be shared.

2 Likes
#2

If you can get RTK GCPs, then yes, this should really constrain the Z-errors.

#3

Thats what I was thinking to, and yes, I also have access to a survey grade GNSS rover, so for the latest map I ran 2 jobs through ODM, one with RTK+GCP and one with RTK only.

M3E Dataset: RTK+GCP:

M3E Dataset: RTK Only:

The orthometric elevations for the 5 GCP’s were used.

From my HT2-2010 geoid model in TIF format the difference between ellipsoid to orthometric at this location is 36.337m. On the GNSS rover it is 36.330m.

For reference, here is the geoid model we use converted to TIF:

Am I correct to interpret that in the RTK+GCP dataset ODM has reported an average difference ellipsoid-orthometric of 36.577m?

For additional reference here are a couple of reports from jobs with Mini 2 and RTK gcps:
Mini2 Dataset: GCP only

I guess I expected the M3E with mechanical shutter and RTK would noticeably outperform the Mini 2 in terms of Z error. I thought I would see closer to 2-3cm error in Z with RTK only. Thats why I am wondering if I have something set up incorrectly, or were my expectations are off.

One difference between the drones is the Flight planning software. For the Mini 2 I used Dronelink. For the M3E I am currently restricted to the DJI Pilot 2 app. With Dronelink, I typically flew a default grid pattern with the gimbal at 80 deg. with both overlaps somewhere between 80 and 90%. For Pilot 2, there is less choice. They have a “Mapping” mode which can be done with nadir-only, or a new mode called “smart-oblique” which changes gimble angle rapidy during flight to capture both nadir and oblique on a single flight path. They also have “Oblique” mode, which creates 5 seperate S-shape flight paths, with the 1st path being nadir, and paths 2-5 being an oblique angle of your choice.

For the above M3E datasets I chose the “Oblique” mode. You can select separate overlaps for nadir path 1 and oblique paths 2 to 5. For this small job I believe I just chose 90 for all of them. The gimbal for oblique paths I set to 75.

The flight path options are documented in the manual for M3E around pages 77 to 86

Dronelink does not support RTK data from M3E yet. I get the impression it may be coming, but not anytime soon.

1 Like
#4

3rd dataset with M3E RTK:

This job is much larger in area, so I chose a mapping flight path with s-shape, approx. 90m altitude, 83%overlap. No gcp’s were used but the data will be verified later with a GNSS rover. Gimbal was locked at nadir as per DJI limitations using this flight mode. Otherwise I probably would have selected 85 or 80 deg. as per ODM documentation.

However, within that nadir locked “mapping” mode, there is an option for “elevation optimisation” which takes a few oblique images while on a straight flight path from one of the corners of limit to center, and those images were included in the processing. I haven’t seen anyone doing this, I wonder what DJI is thinking here.

Finally, I did 2 run different processes with this set, one with automatic camera calibration, and one with the cameras.json from previous M3E dataset which had more oblique pictures.

Reported errors look much better this time:

With automatic camera calibration:

With cameras.json from previous job:

I wonder if the difference between these datasets has to do entirely with my use of nadir vs. oblique images. Perhaps this 3rd dataset which contains 99% nadir images, has lower error because everything captured by nadir had good effective overlap, whereas my oblique had worse effective overlap due to vegetation and other obstructions. Given that I primarily need this for Ortho’s and DEM’s, rather than full 3D, perhaps flying with nadir is ok. So, then the next thing I am thinking about is camera calibration. If I have to take nadir images, perhaps I should follow suggestions regarding special camera calibration flights.

1 Like
#5

Hi Luc, now that Pilot2 has terrain following via DEM download, I’ve also been trying to dial in an RTK workflow (M300 in my case). I use UGCS for complex flight planning, but would like to have a go-to RTK/Pilot2 process that I can use for things like construction progression without laying out GCPs every time I visit a site.

Your comments about the difference in z definitely sound like the geoid offset. And you’re probably onto something with the oblique photos introducing additional error, as now the obliques have a different/higher GSD than your nadir shots.

Is your RTK using a known point or are you connected to a VRS via NTRIP? I’ve been trying to get to the bottom of this question which might also inform your workflow goals:

NAD83 LLH in, NAD83 UTM out? (NTRIP/GIS question) - General Help - OpenDroneMap Community

Cheers.

b.

2 Likes
#6

We are using VRS via NTRIP. It was very easy to setup, just had to use the correct mountpoint for RTCM3.2. I have compared absolute horizontal georeferencing for this drone and RTK with GCP and RTK without GCP and the difference was barely noticeable. Absolute vertical I am still working to tighten. I will reply to you other thread that you linked.

I also want to get Terrain Following setup. Haven’t opened that can of worms yet. Dronelink was easier and automatically downloaded what seemed like a fairly accurate surface model for the drone to follow. Some of the DJI terminology seems atypical I still have to find a surface model for my region in Ontario, Canada.

2 Likes
#7

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