I just tried ES for the first time with the Evo II Pro Enterprise (v2) RTK and received a 100% float. I am going to trial RedToolBox as @dpitman suggested. You can download the first battery’s data below.
RedToolBox reported pretty much the same thing on the dataset above so I moved on to the second dataset and got this from ES.
And this from RTB. So there must be something bad in the first dataset. This is interesting because the drone reported fixed for all the images taken. It did drop to float a few times but it was paused and no images were taken. Worries me a little on exactly how Autel defines the state of the solution.
Are you including glonass? If so, maybe give it a try without.
I cut all the way down to GPS on the second set that actually provided some results and got the same %'s. Is there a way to do this in the RTB trial.
For now I am going to submit raw, ES and RTB maps and we’ll see what we get.
Except that the ES tagged images don’t work with DroneDeploy. I know this was an issue previously but thought it got worked out. Guess not.
I believe the trial is the same as production software. On the CORS files I get, the glonass observations are in a seperate “*.21g” file. You just omit adding that one and move that file out of the folder where the other obs files are and RTB will not pick it up automatically.
The “secret sauce” in PPK processing of drone images is in the interpolation (in my opinion). The CORS observations are (typically) at 1hz. So, between each observation, the rover (drone) has moved a fair amount of distance. And the ppk software has to interpolate how far that distance is based upon known factors. But I don’t think it is a simple task.
PPK of relatively static positions is not comparable.
That’s been our experience as well. I am showing how the Emlid Studio version is missing the PPK/RTK accuracy values and all of the aircraft telemetry.
Sure. And how much those telem values play into the calculation of where the sensor on the drone actually is between 1hz observations is… the secret sauce in my view.
That makes sense now. It’s pretty stunning that we can even get within a foot when you think about the massive amounts of calculations it takes to account for every measurable component everywhere from the satellites, COR Station and two to three or even more electronic devices locally. Then add the drone which is an engineering feat in of itself.
So even though I wasn’t able to obtain a fixed solution just the mere fact that I retagged with PPK’d float values increased the accuracy of the map considerably. Here’s a link to processing reports between the native false (RTK) data and what I was able to get 40% fix and 60% float. Luckily this is just preconstruction and the site has only been hydro-axed. I’ve gotten my RS2 back so I know to run local NTRIP on that site next time. If that doesn’t work then i’ll have to look a little harder at the drone.
Couldn’t obtain anything better with the first dataset. The SNR is quite low overall and jumpy from the very beginning. So, maybe that’s the reason.
Not related to this case exactly, but different PPK and RTK results isn’t the reason to doubt RTK ones. As we always say, algorithms differ, and PPK sometimes is more picky about the data quality.
Yes, still investigating it with DroneDeploy.