Hey guys, thought I’d give a bit of a run down on a workflow I’ve been using with our M300 and Emlid RS2 units. I won’t go over placing control as there’s good guides found here Placing GCPs in RTK mode | Reach RS2/RS2+ or, if RTK by LoRa/NTRIP/Serial Radio isn’t an option, then stop and go works well on all accounts (although I have never used this due to my work flow).
(Sorry in advance for all text and no pics, I’ll endeavour to get relevant pics in a little while)
For context, I’m in Australia, we use AHD Geoid heights for all surveys conducted in our company. We tie in all our control to SSMs (Standard Survey Marks) and use their local grid coordinates and AHD heights. We use these local grids provided by Main Roads as the scale factors generally range between 0.999999 and 1.00004 which makes working with a total station and GPS quite hassle free given we are combining total station work less than 1km square in size (TS only comes out for intricate pickup around buildings on these sorts of jobs). As the whole workflow from the traditional side of things is in these grids and in geoid height, it can complicate the setup as mentioned further in this post. If you’re happy to collect your GCPs and checks in WGS84 and Ellipsoidal height, then convert to a different coord system during the photogrammetry processing stage then you’ll be up and running even quicker. It’s a bit of a juggling act for our workflow but since everyone is working in some sort of local grid with geoid heights, be it the surveyors or clients, I’d rather not introduce a heap more work on their end to save me a couple of minutes in the field by wanting a specific data upload in WGS84.
Due to the size and number of images captured for the jobs we do (250-300 gigapixels worth), PPK capture isn’t really a viable option for us. We’ve tried and the time spent waiting for thousands of photos to be adjusted is just not working for us. In addition to the more efficient image ingest to our software, DJI Pilot 2’s terrain following only works with an RTK connection as opposed to some of the paid programs like UGCS/Drone Harmony/Hammer that don’t require an RTK connection.
Flights and image tagging by RTK is therefore our go to, although with 99% of our work in areas with poor to no phone reception, Caster NTRIP and other internet based NTRIP services are not an option to stream RTK corrections and thankfully Emlid came up with a solution – Local NTRIP.
Local NTRIP function streams the corrections by wifi, be it directly between the base and m300 controller or using an outdoor wireless repeater/ap/router like this wavlink unit https://www.mwave.com.au/product/wavlink-ac1200-high-power-outdoor-dual-band-wireless-poe-repeateraprouter-ac24084 By using this unit you can extend the range you can operate from the base if site access is an issue. I have found that you can reliably have the wifi unit up to 40m away from the base, while the M300 can maintain connection (and importantly, the rtk correction stream) up to 250m away (Distances are LOS with no vegetation in the way, your use case might be different).
If your project and GCPs are in Ellipsoidal heights, you can skip this next part. If you have a surveyor providing you with GCPs and control, ensure you know the coordinate system they are working in so that your project in RV3 matches.
There is one important thing to note with this workflow, DJI expects to see ellipsoidal heights in the base coordinate and subsequently tags the images of the P1 with ellipsoidal height. If your RV3 project/supplied GCPs are in a local grid with Geoid height, your elevation value is going to confuse the M300 and your altitudes will be off. It will not look at the local grid coords & geoid height of the base point, it instead looks at the converted geographic coordinates that RV3 calculates. This caught me out a few times at the start, our horizontal checks to GCPs would be within expected tolerance but our z values would be way off. If utilising a base from a project conducted with geoid heights, you will need to create a point in that project to use specifically while flying the M300. You will duplicate the known base point’s X & Y values, however you will need to add or subtract “N” (geoid undulation) to get an ellipsoidal height that is equal to your geoid height of the control point.
For example, if I were to setup my base over a known point (#9000) and my Geoid height was 167.818m, and from RV3 we know the Ellipsoidal height is 137.326m, I need to create another control point whose Ellipsoidal height is the equivalent to the Geoid height of the known base point. In this instance I add 30.492m (Geoid – Ellipsoidal) to the height of known point and call it “(#9000) DJI Base” and its new Geoid height would be 198.31. Check the computed geographic coordinates at the bottom of the point info page and the Ellipsoidal height now reads 167.818m (there may be a couple of millimetres in it with the conversions occurring so tweak it as required). Now that DJI has been fooled in to using the geoid elevation value as the perceived Ellipsoidal elevation, terrain following will match the DSM heights (Imported DSMs only work in WGS84 & Ellipsoidal heights) and image tags are within expected z value tolerance when checked against GCPs provided with geoid heights.
With a known base point at the correct elevation in your working RV3 project, setup and power up your M300 drone, controller and RS2 unit. After you setup your Reach over a known point, take advantage of the new update that allows you to use points stored within projects and select the correct base point. After setting the base coords, tap correction output and select Local NTRIP. Click on the information icon and take note of the credentials. Your M300 controller should be powered on at this stage and connected to the wifi network listed in point 1 of the local NTRIP information page; if you are running the additional wifi unit then the Reach and M300 should be connected to that network before commencing this step.
With the M300 controller connected to the correct wifi network, open DJI Pilot 2 and navigate to the RTK settings menu. You will need to toggle on RTK, and then select Custom network RTK as the service type. From here you enter the details from RV3 Local NTRIP information under point 2 of the local NTRIP information page. You have the option to let the M300 continue when it loses RTK corrections, but I have that turned off. It is handy to ensure the connection between your controller and the Emlid is solid and reliable by stopping the flight immediately, you’ll only have this happen once or twice before you get a feel for your working environment and the wifi strength either directly between the Reach and the controller, or if your wifi unit is perhaps too far from the base or the antenna aren’t correctly aligned.
The drone should converge reasonably quickly (2 minutes or less), however if it’s not converging you may need to try a quick work around. This was only present a handful of times in the early days of local NTRIP but I did see it pop up in the forum & FB pages a bit. You’ll need to change the update rate in the GNSS settings of the base, I would change this to 5hz, apply the change and then revert back to 1hz and it would be fixed almost instantly. For the past couple of months I have not seen this issue and I assume that with the app and firmware updates this has become a thing of the past.
You’re now ready to fly with RTK, you can perform terrain following missions and have accurately tagged images without shelling out for the one trick pony dji base.
A little bonus for the aussie users that haven’t found it yet but you can get DEMs from https://elevation.fsdf.org.au/ to assist with terrain following missions. Some areas have DEMs created by 5m Lidar grids compared to the 30m SRTM DEMs. Pick the smoothed options and ensure it’s a WGS84 Coord system Geotiff.
If you’re in any state except for WA, check out the Benchmrk App to help search for SSMs and Benchmarks while you’re out and about as well.
