Dealing with Cm level GPS input, how are we handling this in Ardupilot?

[proficnc]

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

Issue: Add parameter to select CAM data source.

[CraigElder]

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.

[mboland]

@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 (TM) 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

[Michael_Oborne]

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.

[mboland]

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!

[proficnc]

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

[Kiwa21]

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

[mboland]

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 copter does NOT need sub cm accuracy

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.

[proficnc]

@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.