We have been using the L1 only Reach GPS from EMLID for about 2 months. We were first attracted to the fact that it claimed that it was going to be integrated to Pixhawk and would then, via a system of magic, give us centimeter accurate geotagged images, eliminating the need for ground control forever.
While we wait for that to become a reality, we have tried out the Reach as a replacement to our normal survey grade Leica GPS1200. We wanted to see just how accurate and robust the Reach is and whether it could be consider a tool for the budget aerial mapper to make more meaningful and accurate models. Despite our office being skeptical of L1 only GPS to give less than decimeter results, we were surprised at the robustness of post processed L1 data.
Our first major project using the Reach was in Zanibar, Tanzania early February 2016. The Reach was used to create a high accuracy GPS tracklog onboard a boat, to be coupled with sonar data, creating a medium accuracy bathymetric survey. Despite the antenna flopping over during the survey, some usable results were obtained. The full story can be read here: 3DroneMapping report
More recently, we attempted to create a workflow and benchmark test to adopt the Reach as our main surveying tool to place GCP. Having a Leica GPS1200 survey grade GPS has been great for all our projects, but lugging 30kg of additional hardware especially in remote places in Africa, as well the worry of transporting $60 000 worth of gear is a headache. As our workforce continues to grow, it is getting harder to afford such devices for all the teams to use. Placing GCP to a few centimeters is actually a simple process when you remove the RTK element and the Reach seems to do this just fine for us as well as having some other features baked into it for future use like IMU and Pixhawk integration.
The site chosen for the comparison is an active construction site near to Durban, South Africa. Points were surveyed by our office 3 months ago via a Leica GPS1200. The points have been semi permanently marked with road marking paint on tar, plastic bags arranged in "X" formation and other ways, making all points visible from the air for photogrammetric uses. The points were initially measured in RTK and then confirmed with a local NTRIP VRS server. The survey is based on the VRS coordinate system, Hartebeesthoek94 / Lo31 (EPSG:2054).
We wanted to test the Reach in 2 ways. The first being via RTK ways and then by post processing. A total of 3 Reach devices were used. It was decided to not use the Reach with an attached RFD900 radio. Previous tests have shown that the radio range, even at maximum power output, is not really useful for terrestrial work. We suspect that the polarization of the antennas is best suited for ground to air communications. It as then decided to send RTCM data via a TCP server, connected to an ADSL line(via a WIFI router)
The first Reach was installed at our office, 3km away from the site. This Reach, "BASE1" was to act as a reference base. The Reach was connected to the office WIFI and assigned a static IP. The antenna was installed on the roof of the office with a 300mm x300mm metal plate acting as a ground plane. The Reach was connected to our VRS and a coordinate was determined within 20 seconds. The point was averaged for over 30 seconds. This point occupation would form the basis of our control system making it easier to compare to the true system.
"BASE1" now had a coordinate, and was set to "Base" mode. The coordinate entered in the respective fields, the output set to "TCPServer", GPS and GLONASS data was sent at 1HZ. Before leaving the office, we tested that the data stream was accessible from outside of our local network via the Android app "Lefebure NTRIP Client"
On the site, "BASE2" was installed. This consisted of an antenna being installed on a 300mm x300mm metal plate acting as a ground plane, in an open area, elevated on a wooden fence post. The Reach was connected to a portable WIFI router, in turn connected to a public 3G service. The portable WIFI router was used as an access point to use Reachview as well as the internet. A Androind cellphone was also connected to the mobile WIFI network and Reachview accessed via Chrome browser. "BASE2" was initialized with the default Reach settings and configured to use "BASE1" via TCP client. After a 15 seconds, a solution was derived and stored. Reach was then placed in the default "Single" mode with GPS/GLONASS satellites being used at 1hz. The data being stored onboard.
Various points were then surveyed about the site. The 3rd Reach was setup on a 2m pole. The antenna placed on a 200mmx200mm sheet metal plate, and a plumbing bubble installed on the pole to ensure it was held vertically over every point. The point was located and then the pole/antenna positioned over the previously surveyed mark. The Reach was placed in the default RTK mode but "Static" was the operation of choice as the antenna would not be moving during the observation window. RTCM data was being received from "BASE1", all raw observations were being stored as well as the solution. The measurement windows lasted for 60 seconds per point, at 1hz. Most points had open clear view of the sky about them, but 2 locations had high tension power lines overhead, which made for some interesting results. The starting points were measured at the end of the survey again to ensure that the base had not moved and to test the integrity of the data.
After each point was measured, the base was retrieved and the data downloaded. Rinex files were determined for "BASE2" and for each of the measurements. The solutions calculated in the field were collected and tabulated ofr each point. The TCP measured data collected from BASE1 was also tested via RTKLIB v2.4.3 b8. The exact same result was created on a PC via post processing from BASE1 to what was determined in the field.
Post processing from BASE2 yielded much better results. These were tabulated and compared to the original values from the Leica GPS. The configuration used to calculate the positions was the default RTKLIB settings, using Static modes and a single solution derived.
In the table, the X,Y,Z,dX,dY,dZ columns are in meters, the coordinate system being Hartebeesthoek94 / Lo31 (EPSG:2054). These were calculated from the raw processed WGS84 coordinates in ArcGIS and the South Africa geoid model applied to obtain orthometric heights. The "Original" columns are the the Leica GPS1200 surveyed and adopted results as true sub 30mm accuracy.
As can be seen, there are a lot of inconsistencies with the TCP data stream corrected solutions from "BASE1". However, when compared to the PP solutions of "BASE2", the results really do appear favorable and perfectly suitable for placement of GCP.
This is a really accurate result from such affordable and simple hardware. Using proper survey techniques and understanding what is going on with processed GPS data helps a lot in getting the best from these devices.
We conclude that:
- Post processing is really robust and works well to getting good results, especially regarding heighting
- There are a few latency issues with using a TCP server. We think that in our case, having the data being streamed at 5hz from BASE1 > Router > ADSL > Internet > 3G > Mobile WIFI > Reach is a bit long winded causing data delays / loss.
- 1hz is perfectly fine for static observations. For post processing, good measurements come from long observation windows and not the amount of raw data used to process with.
- Having a good ground plane helps a lot to reduce multipath as well as having obstruction free view of the sky.
- L1 only is not that robust and the control point areas need to be carefully considered to reduce multipath and long baselines
- It would be really great if coming versions of Reach could also allow for raw observations to be recorded while in "Base" mode. These could be used as a back up if the communication goes down between units as well as offering a more more robust solution possibility.
- The RTKLIB method is a bit painful when it comes to multiple points as there is no way of assigning a name to an observation. One needs to alternatively log the time and name / details for compiling a coordinate list. Each point needs to be individually processed, taking time.
- A set of Emlid Reach GPS units (at less than $600 for a pair!) is perfectly fine to place sub 50mm accuracy control points for UAV photogrammetry.
Device Setup is as follows:
BASE1
Reach running Reach image V1.1, Reachview V0.1.0
Powered via 5v DF13 at 2ah
Tallysman TW-4721 placed on 300mmx300mm sheet metal, unobstructed
Conected via WIFI/4mbps internet ADSL connection
Static IP TCP Server
Broadcasting RTCM data at 5hz
BASE2
Reach running Reach image V1.2, Reachview V0.1.0
Powered via 5v USB at 2ah
Tallysman TW-2410 placed on 300mmx300mm sheet metal, unobstructed
No internet / WIFI connection
Recording raw data at 1hz
Rover
Reach running Reach image V1.2, Reachview V0.1.0
Powered via 5v USB at 2ah
Tallysman TW-4421 placed on 200mmx200mm sheet metal on 2m plumbing pole
Mobile WIFI connection via 3G for Reachview / TCP client
Recording raw data at 1hz
Comments
Hi @kiki boy . You are quite right that Reach is capable of recording data up to those speeds. For a moving rover, this would be well suited as we need as many measurements to accurately plot the rover position in a time span. But for static measurements that involve higher accuracy, we are more interested in the time elapsed than the number of measurements. What we are looking for is a longer time period as the satellite constellation moves, common to the rover. So having lots of measurements over the same time period does not help much in terms of accuracy.
FYI, for some VLB (very long baseline) post processing, 30 second interval data is often used, but this is L1L2.
Hi @Luke Wijnberg , I don't understand why you record only 1hz on rover. M8T is capable of 10hz with gps or glonass only Why you don't choose it ?
u-blox has released NEO-M8P RTK
The beauty of the concept is that the integration is basically only between camera and positioning device, thus keeping navigation and flight control completely ring-fenced from precise positioning. So the point actually is to make precise positioning ubiquitous at affordable levels. And that also makes the equipment universal and completely platform independent - never mind ground speeds - 20Hz for 6m/s is equivalent to 100Hz for 30m/s dynamics, all doable. The savings, when compared to land survey fees for ground control points, leave quiet a margin, so whether you pay $600 for a rudimentary L1 solution or $8K for a dual frequency solution - that is only a one-time cost easily recoverable in a soundly run mapping organization. And then consider how many people are still getting away with $100K plus lidar units when the SfM option will do just as well on exposed surfaces.
I was glad to see that you concur that post processing yields optimal results. One explanation for this is that RTK does not offer you the reverse processing solution. This facility is especially useful for L1 only setups which typically do take rather a long time to resolver ambiguities - i.e. to get to fixed positioning. Being able to process in chronologically reverse mode can significantly shorten the periods during which you have only float solutions.
What you have is great, Walter and we can wait to see how you integrate it further in to faster moving vehicles. Well done.
But the point is to show that for under $600, you can georeference to survey standards using a really simple and cheap tool.
Here's what you can get with 20Hz dual frequency on board quad-copter (6m/s) post processed camera exposure positions (NO GCPs!):
http://drone2gis.com/reporting-horizontal-errors-in-sfm-mapping/
Darius Jack, while it is very hard to was what the ping was during the survey, we can estimate that it was in the region of 400-450ms. Our exchange is very antiquated, over populated and 4.5km away on a dodgy copper wire.
Gary, no gazebo this time. We were doing real work for once that involved stretching legs.
Did you take the gazebo?
It looks a nice report. I will definitively look carefully at it.
i will see how much work to put a L1 receiver to work with a embedded platform to run librtk, to make another 'chinses clone' of this (like raspilot). any experience user in this please 'enlighten me'.
-
1
-
2
of 2 Next