RTK Format?

[Shelby Griggs]

Let me preface my questions with my background and experience. I have been working with high accuracy GNSS equipment as a land surveyor since 1990. I also have over 10 years of experience processing airborne trajectories on manned aerial mapping missions and my current business is an aerial mapping company with four Cessna aircraft and large format digital cameras along with LiDAR sensors.

We have decided to add to our fleet with an Autel EVO II with RTK module. I was able to get the RTK working on first try with our state Real Time Network (RTN), but was curious if anyone had more in-depth knowledge about technical details of using RTK on the Autel platform?

My sucess so far (or at least indicated fixed with solid tracking on four constellations) was using single baseline (nearest CORS). Is there any support for network solutions? It doesn't seem that there is any option to tell the onboard firmware what data type the RTN is broadcasting? Single baseline will be limited in usable accuracy to about 20 km, maybe the EVO II is geofenced to not provide RTK over 20 km from a CORS? I have a CORS just a few hundred meters from my house, so haven't had a chance to try and push the limit yet. Also I suppose I could try hooking to a network solution mount point (vs single baseline) and see what happens.

Also it appears that ONLY ellipsoidal heights are logged, no provision for a geoid model?

Documentation seems sparse to non existent.

Any discussion and input from experienced RTK users on the Autel implementation would be welcomed.

SHG

 

[Dave Pitman]

Hello Shelby,

I'm not a surveyor, but regarding your comments, this is what I know about the Evo2 RTK.

Documentation on the Evo2 RTK is indeed nonexistent. Autel has basically cloned what DJI is using with the P4RTK but has not provided any guidance or white paper on it's use.

I don't think that the Evo2 will discriminate or warn you if you attempt to use a CORS with a baseline longer than is appropriate, 15 to 20km, as you mentioned. When I first got the Evo2, I had a trial access to SmartNet and one of the options for a mountpoint was VRS. But at the time, there were lots of bugs with NTRIP in the Explorer app making a solid connection unobtainable. And by the time they were resolved, my access to that network had ended. If I'm not mistaken, the VRS calculations are done server-side and not on the local receivers, right? In that case, they should be usable. At any rate, there is no setting in Explorer to tell it that it is a VRS rather than a single baseline. If it doesn't work for you, you could set a base on site to receive NTRIP corrections from the VRS/CORS and then send corrections to the Evo2 from that base if your base supports that. The Emlid RS2 that we use with drones is capable of that.

The Evo references WGS84/Ellipsoidal period. No other options.

Dave

 

[Shelby Griggs]

Dave, thanks for the info. Yes I do use the Leica SmartNet sometimes and the state DOT in my state also runs a Spider network, so those are probably the two I would use the most. They are similar to a VRS, but different, VRS is what Trimble uses. Nonetheless, there are additional corrections done that minimize the distance dependant errors, so it would be good to use a network solution over a single baseline when out over 10 km.

I run Leica GNSS equipment and also use an Intuicom RTK Bridge, both of which can act as an NTRIP server, so I could set up my own base and broadcast corrections too after positioning my base as you suggest. The biggest obstacle will probably be the internet in some areas I work. I don't think I can broadcast corrections from a local base station over wifi, but actually haven't tried it, so maybe something to look at.

Appreciate the details, honestly if I didn't already know how this stuff is supposed to work, I think I wouldn't have been able to get it going given that there are zero manuals.

I know the choice in the EVO is WGS84, reality is it will be NAD83 if using a RTN in USA as they all broadcast that, fortunately the EVO won't care.

SHG

 

[jmason702]

ALL drones that I am aware of readout ellipsoid.

If I am reading you correctly I think you're talking about triangulating 2 to 3 different stations correct?

@elphtrooper

 

[Shelby Griggs]

ALL drones that I am aware of readout ellipsoid.

If I am reading you correctly I think you're talking about triangulating 2 to 3 different stations correct?

@elphtrooper

Sort of. There is not any triangulation, BUT there are correctors broadcast based on the surrounding CORS.

Basically, you can use single baseline and it is fine, BUT at longer distances some error is introduced. Generally recommended single baseline distances should be kept in the 10km-20km range maximum distance between the CORS and the rover (in this case the EVO II). Network solutions can easily doble that range and usually the CORS are spaced so that 50km is about maximum distance from any one CORS, so typically they are spaced at 70km-100km apart. Link to the State Of Washington network map as one example: Washington State Reference Network - Sensor Map

A network solution has these benefits:

1. Provides a network RTK correction based on most or all of the reference stations in the network.
2. The density of reference stations in an RTK Network is 3-6 times less than standalone CORS to cover same area.
3. RTK Network (software) largely mitigates distant-dependent variables such as the ionosphere, troposphere and orbit errors.

There are different implementations of networks, Trimble uses something called VRS, Leica uses a MAX network sometimes called a Spider Network. There are a couple other methods, but largely the two mentioned have the predominate share of the market at least in North america.

SHG

 

[jmason702]

So would using your base (GNSS receiver) to collect corrections and then send them to the rover (drone) be the best option

 

[Shelby Griggs]

So would using your base (GNSS receiver) to collect corrections and then send them to the rover (drone) be the best option

Yes, almost always a better RTK solution is obtained the shorter the distance from base to rover. Assume you set up a base on site and then fly that will almost always work the best. This is especially true if the RTK system you use is NOT a network solution (i.e. single base) and also true if you have a multi constellation base station and the network is NOT. ALL early CORS were GPS only, some have added GLONASS, Galileo and BeiDou. The board on the EVO II is a multi constellation board, BUT if the CORS you use is say GPS only, then none of the extra constellations would be used in the solution. Summary is a multi constellation base station right next to the operator is going to provide best RTK corrections. Rember you will need to position the base station first before starting operations, otherwise you will just have an approximate location of your base station.

SHG

 

[Detritalgeo]

Do we know which multifrequency chip they are using? Trimble, Hemisphere/Unistrong, Tersus?... I assume it is a chinese spec. If the RTK module can be disassembled easily I would be interested, will see when mine arrives. I would almost prefer a few binary format log along with the Rinex conversion but I am likely the only one.

 

[jmason702]

here is how I use mine sir, a little long but I think all the info is in the video

 

[Shelby Griggs]

@jmason702 thanks, I had actually already seen your video someplace in last couple weeks, will watch again when I get a chance.

SHG

 

[Shelby Griggs]

@Detritalgeo I don't, BUT I might be able to tell looking at the RINEX data, I haven't flown with RTK yet, just got the airframe recently.

SHG

 

[elphtrooper]

Let me preface my questions with my background and experience. I have been working with high accuracy GNSS equipment as a land surveyor since 1990. I also have over 10 years of experience processing airborne trajectories on manned aerial mapping missions and my current business is an aerial mapping company with four Cessna aircraft and large format digital cameras along with LiDAR sensors.

We have decided to add to our fleet with an Autel EVO II with RTK module. I was able to get the RTK working on first try with our state Real Time Network (RTN), but was curious if anyone had more in-depth knowledge about technical details of using RTK on the Autel platform?

My sucess so far (or at least indicated fixed with solid tracking on four constellations) was using single baseline (nearest CORS). Is there any support for network solutions? It doesn't seem that there is any option to tell the onboard firmware what data type the RTN is broadcasting? Single baseline will be limited in usable accuracy to about 20 km, maybe the EVO II is geofenced to not provide RTK over 20 km from a CORS? I have a CORS just a few hundred meters from my house, so haven't had a chance to try and push the limit yet. Also I suppose I could try hooking to a network solution mount point (vs single baseline) and see what happens.

Also it appears that ONLY ellipsoidal heights are logged, no provision for a geoid model?

Documentation seems sparse to non existent.

Any discussion and input from experienced RTK users on the Autel implementation would be welcomed.

SHG

All CORS record WGS84 and ellipsoid heights. You would need a point on the ground to adjust the elevations to orthometric. Some network services offer VRS which is what we use. It's especially important in Texas because everything is so far apart. My home is almost exactly 10mi away from the 3 closest stations in my area so I am as far from them as I can get but the VRS creates a virtual base 100ft from me. You have to use a custom network and I have had to manually enter the mountpoint but besides that it works just like any other NTRIP configuration.

 

[Shelby Griggs]

@elphtrooper correct on the native format being ellipsoidal height. All my field survey gear allows a geoid model on the gear to display orthometric height, and from the answers here that needs to be done in office processing, this is exact same workflow as with manned aerial aircraft and large format cameras. With our setups those are always post processed is only difference.

Slight point of correction, If you are receiving RTK corrections from a network, then the recorded positions will actually be in what datum the RTK is being broadcast in, in the USA that in most cases will be NAD83(2011)(2010.0) currently. Of course it could be something else, especially if you are getting corrections form your base station.

If you collect autonomous GNSS data then it is always in the native WGS84.

SHG

 

[elphtrooper]

then the recorded positions will actually be in what datum the RTK is being broadcast in, in the USA that in most cases will be NAD83(2011)

Good point of clarification. If you are in the States and are doing site work you would use your State plane but the other types of Surveying like parcels, land titles and geodesy care nothing about grid. It is starting to be used more and more because the GNSS is so easy and now that drones are in the mix it will eventually be every project. That said, with survey-grade drone mapping it really doesn't matter which one it is being there are calibration routines that need to be done in order to verify that all sources of data are on the same page. Taking into account the actual GNSS track, verifying the real float/fix values from PPK, the transformation needed for the output and the configuration of the CAD there are a lot of moving parts. Some of which are not in our control by the time it hits us. It's even worse when there are scale factors and shifts.

 

[jmason702]

Yes, almost always a better RTK solution is obtained the shorter the distance from base to rover. Assume you set up a base on site and then fly that will almost always work the best. This is especially true if the RTK system you use is NOT a network solution (i.e. single base) and also true if you have a multi constellation base station and the network is NOT. ALL early CORS were GPS only, some have added GLONASS, Galileo and BeiDou. The board on the EVO II is a multi constellation board, BUT if the CORS you use is say GPS only, then none of the extra constellations would be used in the solution. Summary is a multi constellation base station right next to the operator is going to provide best RTK corrections. Rember you will need to position the base station first before starting operations, otherwise you will just have an approximate location of your base station.

SHG

My NTRIP network connection is through Leica, MAX network sometimes called a Spider Network. My GNSS receiver collects corrections from 4 constellations. and then sends them to the rover (drone)
So would this be considered a single baseline, VRS, or other? Just looking to know how good and solid my corrections are...

Thanks

 

[Shelby Griggs]

I think two different scenarios if I understand your question.. If you connect to the Spider network and select a MAX or iMAX mountpoint, then you will be getting a network solution.

If you set your own base up and use that, then single baseline solution, although if on site, then obviously very short baseline to the aircraft and that is fine for short distances under 10 km.

Where the network solution is an advantage is from a CORS say 20 km from your project, the distance dependent and ionospheric errors are reduced so that a longer network solution provides roughly the same accuracy as a shorter single baseline solution.

 

[jmason702]

My base is receiving NTRIP corrections and after 10 mins sets its point. The the drone will get a fix from the base.

Is this in your mind better than connecting drone directly to the NTRIP service?

 

[elphtrooper]

My base is receiving NTRIP corrections and after 10 mins sets its point. The the drone will get a fix from the base.

Is this in your mind better than connecting drone directly to the NTRIP service?

It depends on what the coordinate system is of your subject. We run straight NTRIP to the drone and rover and only locally cast if we don't have service. You'd have to ask them if they are providing VRS or not.

 

[Shelby Griggs]

It is a toss up rather you run off the network or individual base station, especially if relatively close to the CORS station. Running a base then makes everything relative to that off the UAV, errors in positioning your base relative to the CORS are propagated into your work. Generally though it is better to run your own base with a short baseline to the UAV and especially so if the network isn't full constellation as more satellites is generally better.

I have NOT used my own base (NTRIP Caster) with the EVO II yet, it does seem to work fine running straight on a spider RTN with single baseline solution. My original question in this thread revolved around format expected by the Autel firmware, rather it was a network solution or a single base solution. As far as I know, zero documentation on that. I have only used the single baseline solution so far, maybe I will connect to a network mountpoint next time I fly with RTK and see if a Spider iMax solution works too.

Proper term for a real time network is RTN, Virtual Reference Station (VRS) is a Trimble implementation and Leica Spider software uses a different implementation of Master-Auxiliary, thus terms like MAX or iMAX which are similar.

With the VRS implementation, a virtual base station is created at your location and then treated as if it were a real base station on your site.

The Master-Auxiliary concept is your are tied to a real CORS (closest one to you usually) and then get additional corrections from surrounding CORS in the network.

I think at end of day, similar results, but as a long time Leica user I like their implementation better. Every point is tied back to a real CORS, not the virtual CORS, which you can't ever delete out of your project without losing all the points tied to it.

Link to a brief discussion of various types of real time network implementations: Concept and Comparison Of VRS , MAX , iMAX , FKP , NEAREST in GPS Networks - Hi-Target

 

[jahalnon]

So Shelby,
Recently getting into the drone game with the Evo ii Pro RTK and found this discussion. I am a PLS in MA and RI for 30 years and follow your excellent discussions on the surveyor forum.
I am deep into the learning curve with the drone and use the Carlson software packages for processing and cad. I am using the Smartnet RTN directly into the Evo and only issue I am having is the wait time for fix. Once I get it, everything is great but I am finding the wait times up to 10 minutes which does have an impact on the battery life and drone mission time.

Question: is the use of a base on site speeding up the fix time for you? I assume you have had a few months to get a handle on it. We have Leica and Javad, but they are used by the field crew so don't want to use up those bases. I was thinking of a cheap add on in the Emlid RS2+ but want to get a feel if that actually speeds up the fix.
Thanks,
John