Hello Fellow Yuneec Pilot!
Join our free Yuneec community and remove this annoying banner!
Sign up

H520E RTK using PPK

Joined
Nov 24, 2020
Messages
13
Reaction score
1
Age
36
I really hope we can grow a good following for this drone and have some sort of influence on their customer support effort for it. Or I will just do it myself... :rolleyes:

What base are you using? What version of Rinex is it putting out?
I am using rinex 3.02
You found another method today.
it doesn't work a little long and healthy.
 

Attachments

  • YuneecPPK_Data_PostProcess_KUllanım Kılavuzu.pdf
    684.8 KB · Views: 8
Joined
Nov 28, 2019
Messages
406
Reaction score
238
Age
46
Location
Austin, Texas
I am using rinex 3.02
You found another method today.
it doesn't work a little long and healthy.
Holy Moley, it definitely shouldn't have to be that involved. The first roadblock I hit with a little testing of files I already had was getting the 20o file to convert to an OBS and to get the best track we are going to need the drone's NAV file as well so we'll see how that goes. The BAT file did not populate anything. I have some more flights to get through from today so I will see if I have time to play a little more tonight.
 
Joined
Nov 28, 2019
Messages
406
Reaction score
238
Age
46
Location
Austin, Texas
Good morning from Texas! I just ran the first set of logs through RTKLIB and it came out pretty well at 98.7% fix with my default settings. The 1.3% float was on the ground at startup so the actual flight is 100% fixed. This was with my normal configuration and I have not found the settings used by the Yuneec software to determine what it considers a fix. The full track is super easy to obtain but I found that the next step is acquiring the events file in order to retag the images in Geosetter. I'm guessing that's what the ppktimestamp file is in order to know the exact events times but I am not familiar with how to marry that to the POS file so on to the next phase. A POS events file was created but has virtually nothing in it. For this test though I have been able to verify that 96.2% of the RTK positions match the GPS track within a 2cm tolerance which means that in this dataset of 389 images that 15 of them resulted from a less than "fixed" solution. I don't have a way to know what the RTK track would look like but I know where RTK failed and the longest string of images was 3 so that means that RTK fix was out for about 6-8 seconds at one point. Once I figure out how to get the events I can retag the images and do a more thorough comparison and processing. By the number of events I can see that it is running at 5Hz.

1619269458694.png
 
Last edited:
Joined
Nov 28, 2019
Messages
406
Reaction score
238
Age
46
Location
Austin, Texas
So I haven't figured out some of the columns but the ones that are unknown aren't important to the relocation and tagging process. I think I need some uncorrected images to be able to finish the process.

1619306665605.png
 
Last edited:
Joined
Nov 28, 2019
Messages
406
Reaction score
238
Age
46
Location
Austin, Texas
I am posting this across the different forums independently to see what kind of insight I get and is primarily in DroneDeploy but I also included the Emlid GNSS forum. For here is is directly related to RTK/PPK use on the H20E RTK.

I still have not been able to buckle down on straight PPK and am continuing with the RTK verified via PPK as I am getting some pretty good results but at the end of the day it is not the workflow that I am comfortable with instilling in our company program so we'll get there.

I have started seeing some weird numbers with the H520E RTK imagery now. If I process the map without any ground control my camera GPS location RMSE’s are right around 1ft XY and 0.4ft Z but when I introduce GCP’s the number as all over the place and more up around the 1m range across the board with the vertical being slightly less for the most part. DroneDeploy has had to do some tweaking to their software in order to accomodate better image geotags similar to what you would do in Pix4D or Metashape with image accuracy so we will keep that in mind as a cause... We are testing with Phantom 4 RTK's and Yuneec H520E RTK's so if anyone is on DroneDeploy and using these or similar aircraft with RTK geotags and want to submit some data for the research let me know.

My rationality for this is that our drone and running on the same RTKNET via NTRIP which broadcasts NAD83(2011) coordinates. The rover has data collector software which use NAD83 natively and projects it to our local State Plane Coordinate System which the values in the GCP file are based on. The drone on the other hand works in WGS84 but I don’t know exactly how it negotiates the NAD83 corrections. WGS84 and NAD83 are very close in some areas and not so in others spread across the United States but we have to keep in mind that not only are there difference in the horizontal reference frame but they use different ellipsoids as well. WGS84 has its own and NAD83(2011) uses the GRS80(2010.00) ellipsoid. Factor on top of that which GEOID you are using and there is the additional split in vertical.

Because we are localized to the site benchmarks our checkpoints come out fine in DroneDeploy but the data always has to be given a final alignment in CAD.
 
  • Like
Reactions: vr-pilot
Joined
Nov 28, 2019
Messages
406
Reaction score
238
Age
46
Location
Austin, Texas
So I haven't figured out some of the columns but the ones that are unknown aren't important to the relocation and tagging process. I think I need some uncorrected images to be able to finish the process.

View attachment 25536
Not much of an update yet but I did find out that the three missing columns are the antenna phase center offset from the sensor in millimeters. YXZ (north,east,vertical) respectively.
 
  • Like
Reactions: vr-pilot
Joined
Sep 1, 2016
Messages
172
Reaction score
72
Age
52
Not much of an update yet but I did find out that the three missing columns are the antenna phase center offset from the sensor in millimeters. YXZ (north,east,vertical) respectively.
That might result in the (EDIT: slightly) varying and faulty values you get, depending i.e. on drone pitch/roll etc . Leaving values at ZERO (by the manufacturer...) in the table suggests that the camera target is located exactly in the middle of the GPS antenna. ;-)
 

New Threads

Members online

Forum statistics

Threads
19,769
Messages
228,863
Members
23,729
Latest member
DreDay