What accuracy with Reach on a UAV?

Hi all,

Greeting from Australia! I’m new to this forum but have been involved in UAV-based photogrammetry for about 4 years using Sensefly aircraft and multirotors. So far we’ve always used ground control points, as well as check points. We’re about to get a Reach for testing.

I read some posts by Steve Zeets that I found really informative.
Steve, if you read this, I’m wondering if you can tell me what accuracy you’re getting with the Reach on your UAVs? (How many centimeters error on check points.)

I saw the the test by Tuffwing (https://emlid.com/tuffwing-reach/) and while very impressive, they still had an RMS error of about 10 centimetres vertical. In contrast, we typically get about 5cm vertical RMS error with our ground control method. I couldn’t tell whether they were using a CORS network (VRS) or a single base, and whether they were using Real Time or Post Processed. 10 centimetres would be a problem for us.

For your multirotor, do you post-process using data downloaded from a CORS Network or from a single base?
Or do you log data from your own base on a point that you’ve surveyed?

For repeat jobs where comparisons are being made (beach sand levels etc), I’m thinking it would be good to create a permanent point to use every time for the base, always using the same coordinates. I assume that this would reduce survey-to-survey errors.

Interested in your thoughts Steve, or anyone else!

Thanks,
Richard

A couple of questions on this topic.

Does reach use it’s IMU to do data fusion with the GPS data ? If yes, then please add to the documentation how to orient the Reach boart relative to pixhawk.

Why does the documentation say that ECC correction needs to be turned off on 3DR radios for injection with mission planner ?

BTW I added a RTCM module to mavproxy, and the ardupilot team added a DGPS module to mavproxy as well. So now there are two Mavproxy modules that can be used to inject RTCM data. Mission planner is no longer the only ground station that can be used to inject RTCM data.

Hi Richard,

Greetings from Midwest U.S. (not nearly as cool scenery as Australia :smile:)

Yes, you can achieve 5cm on check points without GCPs with the Reach.
You can log the base data with any of the methods you mention. However, keep in mind that for the most accurate Z you want a short baseline. So it depends on where your CORS base is located compared to your flight. For accurate L1, I would keep you baselines under 10km.
Yes, you definitely want to use a permanent point for multiple surveys in the same location.

Best,
Steve

1 Like

Great info Steve, thanks.

This all makes sense. I assume that your concern about long baselines doesn’t apply when using a CORS network (as opposed to a single CORS base) since the whole point of the network is to interpolate between bases to create a very close Virtual Reference Station.

If it’s OK, I have “newbie” question:

People talk about needing to leave the Reach in position for a good amount of time for best results - the longer the better. If this is necessary, how can one get accurate results on a UAV that is continuously moving at say 10m/s? I think I must be missing something.

Thanks again, what a great forum this is,
Richard

Could it be OPUS you think of. This is a singel file uploaded to be postprocessed. Link
But CORS is correction data from one of many stations around, or even virtual refrence stations.
With this you dont need a base station but instead have to link up your rover to this system and you will have RTK.

Now, if you dont use RTK, you can postprocess by logging raw data from CORS and rover, with this you establish a position on the rover end which you then can use later as base and feed rover from your new known point.

There are many methods to gain data and a accurat coordinate.

-If you need accurat movement of your “rover” (which could be anything), you need RTK. Either correction sent from your base to rover or rover gets it from uplink to another refrence station.
-If you need accurat postition of your rover, but not in real time, you could use raw logging on rover and postprocess it later against logged raw data from your own base (a base with either absolute or relative position) or data from other refrence stations.

As @TB_RTK mentioned, the “Virtual Reference Station” only works when doing RTK. Which is only useful for accurate navigation.

As for your question: You need the reach in position for a long period of time when collecting a point on the ground. The L1 frequency is very susceptible to interference, especially on the ground. When on drone, flying in the air, there is minimal interference with the signal. This is why on a UAV it works great when moving. We use a fixed wing flying around 35m/s and get excellent accuracy with the Reach on it!

Best,
Steve

35m/s whaoh!
Which flying wing is ? Do you have picture ?

Thanks Steve and TB_RTK.

Regarding why the Reach works great on a UAV even when moving:
OK, I get it now - the difference is that the UAV is up in the air away from reflections and obstructions to the GPS signals.

Getting good data at 35m/s is amazing. Even a timing error of 1 millisecond would result in a 35mm error in camera position. So you must be getting less than a millisecond of error. I wonder if this is commonly achievable with the Reach when attached to the hot shoe of common cameras?

We’ve been using the excellent Ricoh GR for photogrammetry on multirotors, shooting at 1/1000.
I’ll let you guys know how it works with the Reach.

Richard

@Sylvain_POULAIN
It’s the Ritewing Drak from Ritewing RC.
Here is a pic of one we use on our projects. (This isn’t me in the pic).

2 Likes

@Vertiguy
We used a Sony A7 on the 35m/s flight.
It was setup to be flown at 20m/s, but a hard tail-wind increased the speed on every other flight line to 35m/s :smile:
I wouldn’t recommend that speed to be used all the time.
However, now that we know it works…

1 Like

Hi Steve (or any others),

If I may, I have a question about “matching” equipment.

There’s been some mention of the idea of “matching” the base and rover, including in this write-up:
https://rtklibexplorer.wordpress.com/category/cors-network/
I’ve not seen an explanation of the reason, but the suggestion is that it’s better to match a Reach rover with a Reach base, rather than say a Reach rover and Trimble base.

If one has a survey grade L1/L2 receiver (e,g, Trimble, or in my case Hemisphere), it would be nice to be able to set it up as an RTK rover using a VRS, get an accurate location, then switch it into base mode, and log raw data while the Reach on board the UAV also logs raw data, for later post processing.

However if this gives inferior results to a “Reach-base / Reach-rover” combo, then it means you have to do the additional step of accurately setting up a Reach base on the location where you took the RTK measurement.

Is this really an issue?
Or can PPK be done with a Reach rover and Trimble (etc) base?

Thanks!
Richard

Hi Richard,

You can mix receiver brand and obtain excellent accuracy.
What affects the vertical accuracy is when you do not pay attention to the antenna model used (vertical only).

Each geodetic antenna has it own parameters that allows to reduce the height measured to the antenna ARP (antenna reference point = bottom of the antenna).

When you use 2 antennas - same model , the error cancels out.
If you mixed different antenna models, you must specify the antenna model in you post-processing software to eliminate the vertical error.

Be aware that you will introduce a constante vertical error if you do not pay attention to antenna models (could be as much as 10cm). If you mix a Trimble & Emlid, the vertical error will always be the same (the constante error would be different if you mix a Leica & Emlid, and again different if it’s a Topcon & Emlid, etc).

You can find out what the constant error is (for a given antenna mixt) by doing a static session over 2 known geodetic points.

1 Like

Thanks Stephanie, that’s good to hear, and it makes sense that there would be no issue mixing brands.

And yes, I understand that we need to adjust for the base and rover ARPs if they are different.