Hi guys.
They’re appears to be a large amount of confusion in the community on how we deal with GPS coordinates.
From Mission items to surveying tools, people are complaining of >meter limitations on their data.
Confusion as to when we are using float, int32, or double throughout the chains…
Thanks
We need to start by establishing the GPS delay for the receiver. I’m curious to know if Edwin & Co have set the GPS delay for the Septentrio receiver.
@proficnc as you have raised the issue as a forum thread and I have already posted this reply from a surveying consultant I work with on GitHub, I feel it is worth repeating here.
I think this subject is worth some in depth discussion as RTK is being requested a lot more now.
Mike
I’m not sure about the equator but here in Australia 1 second is about 30 metres depending on where you are (could be 25 could be 34 could be 28 – also differs in distance between north-south and east-west from location to location)
In Central Queensland we use MGA94 projection which is a Transverse Mercator ™ projection of the (Geocentric) GDA94 datum (the geographic one). MGA94 zones are typically represented in metres. GDA94 uses the same spheroid as WGS84 and is ITRF compliant.
So using a seven parameter transformation between geographic coordinates (GDA94) to TM coordinates (MGA94 zone 56) on actual coordinates we get the following
Seven Decimal Places: 151.2943275E, -23.8655136S = 326317.031E, 7359616.631N
Above +0.000 000 1: 151.2943276E, -23.8655137S = 326317.083E, 7359616.631N
As you can see there is little difference in the Northing but about a 5cm diff in the easting when you use 7 decimal places and increment by 0.000 000 1. the differences obtained by 1/10 000 000 varies in the easting and northing values depending on where you are in Australia as longitudes converge at the poles and latitudes run parallel.
Also I’m not sure how the pixhawk/missionplanner handles decimal places (rounding or truncation) plus what is the precision of the EKF filters and does it change the value of the last decimal place (or last two decimal places.) should EKF be operating at 8 or 9 decimal places?
Fortunately, and that’s if the Pixhawk can actually talk to the Septentrio, we won’t be using the coordinates that the pixhawk/missionplanner stores as we will be logging direct to Septentrio using the coordinates of the survey grade L1/L2 GNSS module. That’s if the bloody Pixhawk will behave!
Hope this helps
Jason
i think what we really need to do I use the pps/time pulse pin to feed into the pixhawk, so the pulse can be used to calculate the delay.
as the gps measurement is tagged with the current time, the only part missing is the pps feedback which is ns accurate.
A further comment from Jason, I am just passing this along to assist in information gathering.
Using a seven parameter transformation from GDA94 to MGA94 Zone56 (for a location in CQ)
With eight decimal places:
151.29432705E, -23.86551306S, = 326316.985E, 7359616.740N
Above + 0.000 000 01 = 326316.980E, 7359616.740N
So 5mm diff in easting (rounded)
With nine decimal places
151.294327005E, -23.865513006S = 326316.980E, 7359616.740N
Above + 0.000 000 001 = 326316.980E, 7359616.740N
So accurate to less than 1mm (rounded)
Again this is only for this location in Central Queensland it will be different depending on the coordinate transformation (Lamberts compared to Transverse Mercator) and different for every location.
That said I would be happy with 9 decimal places and could be considered survey grade not GIS or mapping grade.
This has nothing to do with equipment (I know RTK is only accurate to between 15mm and 10mm depending on a lot of variables but PPK and PPP are accurate to 1mm and if we post process on 7 decimal places then not cm accurate!
Quite frankly anyone who uses the flight controller coordinates to process photogrammetry without GCPs is mad! I think using the Septentrio (or another survey grade GNSS to manage the coordinates and attitude for photogrammetry is a more sensible, accurate, reliable, truly survey grade solution without GCPs. We just need the pixhawk to communicate with it properly!
Hi Mike.
What I am looking for, is to improve the capabilities to the best we can provide. The discussion here is about finding the points in the code that are letting us down, and the additional requirements to calibrate this correctly
Quick question to the dev team and RTK users.
With the upcoming “cheap” RTK system (M8P : Here+ ou Drotek), more and more users will have access to better GPS position estimate.
As I understand that this post is about handling the GPS coordinate in the code (float, decimals and stuff), I am going a bit off road here and asking about the actual capabilities of a copter to keep a Cm level position in Loiter , Guided mode or even Precision landing ?
What do you guys think the best accuracy could be right now? How can we improve it ?
Is the control loop fast enough ? precise enough ?
Thanks for your answers 
In a discussion on this subject with the surveying consultant who asked me to post his thoughts, which you have in the posts above, while travelling to a job, as you do, I put the point forward as I put it here:
The logging needs to be to 9 decimal places but it is pointless and counter productive trying to make the flight controller sub cm accurate.
Between atmospheric conditions and aerodynamic affects, 10cm to 20cm is plenty accurate and what should be expected, as the flight envelope of the best designed and most accurately flying vehicles is not going to be more accurate than that.
We are battling with a Septentrio board at the moment (I personally think it is a faulty board) and it occurred to me that after getting the copter flying very nicely with a good old Ublox, that that is all it needs.
The Septentrio has its own logs, and all I have to do is feed it RTK.
So here is a thought:
To save having yet another radio on board just for the RTK, the current setup of feeding it over telemetry is great.
Is it possible to feed RTK through Mission Planner to GPS2 while the copter uses GPS1 for navigation (with or without RTK) ?
Nearly all pro grade multi frequency RTK GPS systems have their own on board logging, so if we had control over the destination of the RTK messages coming in from the GCS it would allow more flexibility in our on board GPS systems.
@mboland, you are looking at one application only, surveying is not the only use of RTK. The practical applications outside of surveying include, precision landing at charging stations, repeatable Cablecams, long term time lapse (like a building going up, same shot daily) precision landing on vehicles, RTK moving baseline compassing etc… I’m sure there are more. So please keep in mind that the applications for this technology are far broader than ont single use.
Regarding the loiter position, my understanding is that it loiters relative to EKF origin, and the int32 has more than enough precision to get the accuracy required for pinpoint loiter.
Yes, @mboland you can now use GPS1 for navigation, and inject to GPS2 (optionally merging/blending the two) when using 3.5.5
@proficnc will the new Here GPSs provide PPS signal connection to the new red cubes? Do you have any ideas how that could be done ?
I’m not sure if it’s a widely known fact, but for me it was news. Apparently M8P does NOT give you a 2cm absolute accuracy (or precision or whatever). This 2cm accuracy is in estimating Rover’s position vs Base. So, absolute accuracy would be this 2cm PLUS whatever comes from base, which, if it works in self-positioning mode, is usually 1-2m with any antenna. Of course, if the actual base position is known, this 1-2 meter does not count.
Just curious, how did you discover that it doesn’t give 2cm absolute accuracy (like did you measure it from from your own setup or did you read about it from another post)? And would you happen to know which board DOES give that level of accuracy?
Thanks,
Trixie
Actually, it’s in the manual 
There are many solutions that could help with getting absolute accuracy. You could set the base at known position for example, or use NTRIP to get RTCM from a known location over internet or use a DGPS as a base…
Also, out of my recent experience with both U-Blox and Navspark RTKs, there is a significant drift in altitude data during the day on rover for some reason. We were doing a ground survey not long ago and had lines crossing each other. The altitude difference for the exact same points was anywhere from 1 to 7 metres. Still trying to figure out why.
Ah, I see. Got it. Thanks for the swift response btw .
We were using Survey-In mode for our base station (which we always have to take down when we leave our flight area) and sending the corrections wirelessly with NTRIP already, but we were still getting some drifts on our drone. Our Survey-In takes a long time so we just had it set to 1m accuracy for it to finish in ~30min. So then this just means we need to do a survey down to sub-centimeter on the base to get the 2cm precision on our rover? I’m just worried about how long that will take.
Thanks,
Trixie
What I found strange, is that despite “locking” coordinates after survey-in completed, there is still drift in coordinates (mostly altitude). As I mentioned before, I tried both U-blox M8P AND Navspark S1216 RTKs. I wonder if ZED-F9P would be any better.
any suggestions how this can be done so pps/time pulse pin output can be obtained in ardupilot codebase ?