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
"
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."
What are your pings ?
"
having the data being streamed at 5hz"
stays for what ?
@Igor. I understand AC 3.3 has the ability to log the hot shoe flash trigger pulse (as long as you get the correct Universal Hot Shoe adapter, as least for a Sony Nex in my case). Am I not correct in assuming that? Just planning to try this in the next week. Or have you had to add some other code? (Sorry I purchased a Drotek L1 unit, I did not know you were this close!).
Pascal, actually having an L1/L2 base station could be a great idea for remote areas. Reach onboard still promises significant cost savings.
Igor, I agree of course, 20 km is fine from base to rover. I just worried about base to closest known geodetic point distance. Where I am it is much more than 20 km, so for me L1/L2 is still needed at least to create base point. After that, your system is just perfect for what we are doing.
Luke, thanks for the warm review! It's a pleasure to know our product is appreciated by professional surveyors.
We are working hard on enhancements for the Base mode providing features like automatic single position and multiple destination corrections. Your feedback is highly appreciated.
Contributing to RTKLIB is also one of our major goals. After we are done with mapping features and APM integration, we will continue our work to enhance this amazing piece of software.
Pascal, but you rarely would fly that far. 20km is perfectly fine for virtually any mapping mission.
We definitely will make a study, actually I have performed one in the past but can't disclose it. The bottom line is - the model can be precise to <20cm without any ground control. An I am talking absolute. Reach is perfect fort that. And at $235 you can have one in every aircraft.
Luke, yes L1 only GPS will never offer more than 20km baseline with few centimeter accuracy.
Igor : getting camera time from flash sync pulse is great. I wish you can publish accuracy study soon for no CGP aerial survey.
Luke, incredible work! Your in-depth analysis is highly appreciated.
We are doing our best to deliver Reach RTK integration to Pixhawk. We already have it working, pull-request to APM is pending, just polishing some details to release it.
The tricky part is that integration with Pixhawk is not enough to get precisely tagged pictures, because camera delay plays a very big role in precision degradation. We will be using flash sync pulse from the camera, connected to Reach to capture the exact time when the shutter actually opened. These events will be accurate to tens of nanoseconds and could be used to calculate picture coordinates from the post-processed solution.
We are really close to making precision mapping easy and affordable!
Pascal P., if only OPUS or Centerpoint RTX could use single frequency data. But I dont think it is possible to calculate on such long baselines.
So if you do not tie into an established geodetic control system, locally, your measurements will be in the same accuracy range (it makes no difference) but relatively or compared to real world coordinates, you will be shifted by a few meters.
As always, there is no magic bullet for all project requirements. But the Reach right now is a very good, affordable and future-proof setup.
Thanks Luke, very interesting study ! I am sure Reach is a good solution for CGP relatively localised from a short distance known base station.Getting this known location is really the issue for remote location (I am in Cameroon, few geodetic points here). So at least a dual frequency GPS is still necessary in my case for PPP.
The other issue is CGP/No CGP. I hope you can do also a study with RTK only on your aerial rover. Ebee claims that CGPs are no more needed when RTK is onboard. What a gain in time it could be !
-
1
-
2
of 2 Next