Some tests on GPS, geotagging and stitching accuracy

Hi all,

I want to share some results of comparisons between different GPS modules as well as different approaches for geotagging and stitching images based on APM:Copter log files.


CAM_TRIGG_DIST (blue) vs. adjusted coordinates (green). Stitching is based on corrected coordinates.


The background is that we were aiming for a tool, which would allows us to check the image and geotagging quality immediately after completing a survey mission. So, in case of any camera triggering or geotagging errors (as well as image quality problems) one can repeat the mission again with different settings without having to wait for any complex and time consuming processing in the office. Additionally, I was interested in the positional accuracies one could expect from repeated survey missions and with different GPS modules. Hence, this post focuses on different aspects of positional accuracy. It provides a short summary of our experiments. It is not a scientific study and most of the tests were not repeated. So this is just intended to be a rough guide. Anyway, I hope it will be helpful to some of you.

1)        A comparison of the PDOP (Dilution of Precision) values between different common GPS modules for the Pixhawk autopilot

The crucial component for geotagging images as well as for geo-referencing in general is the GPS receiver. There are mainly 2 different u-blox systems currently in use together with the Pixhawk: the LEA 6H  and the NEO M8N.

For a test I mounted the following three GPS on my copter:

3689631252?profile=originalTest setup: 3DR LEA 6H, VR M8N and CSG M8N

The major difference between the two M8 modules is that the CSG M8 has a larger antenna (there is a „mini“ version with a smaller antenna available as well) whereas the VR M8 has an additional amplifier. VR M8 was connected to the Pixhawk as GPS1 and the 3DR 6H as GPS2. The CSG M8 was connected to my Laptop via USB directly. I used Mission Planner to monitor the VR and 3DR GPS modules and u-center to monitor the CSG one. Because AC3.2 is reporting is the PDOP and not the HDOP, we need to compare the AC3.2 HDOP with the PDOP reported in u-center. It is also important to set the "Min SV elevation" to the same values. To compare the performance I tested all three modules in parallel. In a first test I compared the performance outdoor and indoor (close to a window).

Results of the outdoor test

  • The LEA 6H always shows less satellites and a higher PDOP compared to the other two (~1.7 vs. 1.1)
  • The VR M8 is comparable to CSG M8 when the "Min SV elevation" of the latter is set 5deg. If "Min SV elevation“ of the CSG is set to 10deg the VR is slightly better. This is why I assume that "Min SV elevation" is set to 5deg on the VR M8.
  • The CSG M8 was the first that got a 3D Fix and it was better for quite a while. Interestingly, the position accuracy of both the VR and the 3DR increased significantly after re-booting the Pixhawk. This is a little strange to me but I experienced this more than once.


Outdoor test: CSG with Min SV elevation set to 5°

Results of the indoor test

  • After waiting 15 min the CSG had a 3D Fix.
  • After 20 min the 3DR came alive (gpsstatus2 = 3).
  • Even after 40 min the VR still showed gpsstatus2 = 1.
  • When setting the "Min SV elevation" to 5 on the CSG the results went a little worse and were more noisy.

The indoor results are reproducible. That's why I went outside - I thought the VR M8 was dead but luckily that is not the case. Roberto from VR reckons that the internal pre-amp could go in saturation if there is some interference.


  • always use an M8 instead of a 6H
  • the CSG M8 is the most sensitive
  • this must be due to the larger antenna even though the VR has an amp
  • the reason why the results went much better directly after rebooting should be investigated, since this is not the case for the CSG one (or at least I haven't realized before) and because it should result in better positional accuracies at least in the beginning of the flight. Since, the VR and the 3DR GPS were connected to the Pixhawk the problem might also be related to the autopilot. Can someone confirm this behavior?
  • the outdoor accuracy seems better and less noisy if "Min SV elevation“ is set to 5°. However, with this setting the receiver might be more affected by multipath errors as shown by the higher noise for this setting in the indoor test. Hence, for security reasons 10° might be the better choice.
  • There was no obvious difference if a GPS antenna was covered with the 3DR GPS cover or not.
  • I haven’t tested it with the VR M8 but the CSG M8 is very sensitive to interference from the bluetooth telemetry module - even if mounted >20 cm away from the GPS. The 3DR LEA is less sensitive.
  • All tests were conducted without an additional shielding of the GPS module. A first test with an additional shielding between the VR M8 and the Pixhawk et al. shows marginally higher number of satellites (20 instead of 18) and a little lower DOP values. But this has to be verified. I also have to test if there is a reduction regarding the bluetooth interference.

2)         Camera trigger delay and direct image stitching

For many applications a simple image overlay is sufficient. The advantage compared to the generation of orthophotos is that the mosaic can be generated quickly in the field. However, even stitching can be relatively time consuming - especially with large image sets and if image registration is performed using automated image-matching techniques. Hence, we were aiming for an approach that provides georeferenced image mosaics that rely on the GPS coordinates only.

To achieve this aim, we

Hence, the CAM entries in the log file can be used for geotagging the images. The GPS used in all following test was the Virtual Robotics NEO M8N. To achieve optimal image quality the camera settings have to be adjusted for every single image. This results in some delay between triggering the camera and shooting the image.


Direct stitching results

The following two figures (I moved the first one to the top of the post) shows the coordinates when the camera is triggered (blue) vs. automatically corrected coordinates (green) where individual velocities and shooing delays have been factored in. The stitched image based on the corrected coordinates is shown in the background.

The mosaic based on CAM_TRIGG_DIST is corrupted. This is due to the fact that CAM_TRIGG_DIST was set too small in this test in relation to speed and camera trigger delay. Hence, some images were not taken. Normally, there is only some offset. Synchronizing the image time stamp with CAM_TRIGG_DIST time will also help to reduce this effect in case images are missing.


CAM_TRIGG_DIST (blue) vs. adjusted coordinates (green). Stitching is based on CAM_TRIGG_DIST.


The comparison between the stitched images shows that

  • Geotagging has to be performed carefully to reduce artifacts
  • NADIR gimbals provide an easy way to reduce perspective distortions and guarantee the best viewpoint for many applications (e.g. SAR, Precision Agg)

Processing takes only a fraction of time compared to generating an orthophoto. Stitching is completed within minutes on normal laptops.

3)         Positional GPS accuracy of repeated surveys

What is most interesting is the positional accuracy between directly stitched mosaics of repeated surveys. Therefore, we repeated missions over the same area at two consecutive days. Georeferencing is performed independently for each image and only based on the GPS coordinates provided by the VR M8. Additional ground control points and image matching routines were not used.

We also tested different cameras so the results show a mixture of potential errors.


Direct stitching results

The red points in the following image mark same position of different flights.


RGB mosaic, day 1, flight 2

The following screenshots show the potential geo-referencing accuracy without any ground control points and after applying a linear shift (no scaling or rotation) to the images based on Google Earth data. The orthoimage as well as the DSM are perfect. The simple overlay and the mosaic show a small offset/distortion (Some more precise measuring/shifting should result in even better positioning.). Yet, this should be ok for many applications. Because it was snowing during parts of the flight the image quality is rather poor.





Stitched mosaic


The results show that in average the PDOP reported by ArduCopter is a quite good estimator of the offset between single images within one mission (although it is called HDOP for unknown reasons). Positional errors can be seen within each mosaic but most obvious in the RGB mosaic.

The offset between the different flights/cameras in the IR/RGB example is up to 4 m and not linear over the entire mosaic. But, as expected, the offset is smaller at the end of the mission indicating that a longer warm up period (and/or reboot?) should reduce the offset in the beginning of a mission. This is why in many cases the directly stitched mosaic fits the true orthophoto quite well and the overall offset is mostly consistent during a mission. The offset can easily be determined using Google Earth and thus corrected. If this is possible and sufficient, ground control points are not necessarily required to provide positional accuracies < 1.5m for a directly stitched mosaic. Yet, orthophotos should be preferred. However, processing takes much longer.

Apart from some small pitch and roll offset from NADIR (calibration error) there is often some small misalignment of the camera so the images might be rotated which needs to be determined and then yaw needs to be adjusted before stitching.


4)         AC3.2 „issues“

Regarding AC3.2 there are some things that need to be tackled. These are rather minor „bugs“ but might sum up to some significant offsets of single images and/or the entire mosaic or other inconsistencies:

  • For consistent stitching the exact flight altitude must be known for each image. However, the „altitude“ currently used in AC3.2 is based on baro measurements. The problem is that there can/will be a drift in atmospheric pressure during the flight which can sum up to several meters over longer flights. See link for an example from a 40 min survey.
  • I am not sure if this has a real influence. There is some timing jitter (missing samples) which occurs at least with both M8N (not sure about the 6H) GPS modules. Yet, an measurement offset of only 200ms might produce a considerable spatial offset especially at higher speeds. This jitter also results in some twitching.
  • In addition there is some clock drift or communication latencybetween the GPS module and the Pixhawk. This can also lead to spatial offsets depending on the log file entry one relies on for geotagging.



For surveys where the highest precision is required orthophotos and ground control points are the way to go. This is also true in areas with stronger relief. However, in many cases directly stitches images georeferenced using common GPS modules are sufficient. What is required is proper geotagging and a stabilized NADIR gimbal. This involves good GPS modules as well as specific CHDK scripts, log file analysis and stitching routines. The advantage is that stitching can be processed in field within minutes, which makes it suitable for SAR missions as well as quick overviews for agricultural purposes.

To overcome some positional inaccuracies, image-matching techniques might be applied. However, there is a trade-off regarding processing time. A real boost in accuracy can be expected if RTK DGPS systems (read Piksi) are fully integrated and operational.

Any comments are welcome!

Best regards and a Happy New Year,


PS: A big thank-you goes to all the Ardupilot devs for all of their help and suggestions!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Yet another GPS module, claims to be more accurate, resistant to noise.




  • T3


    UBX-RXM-RAWX support is now in master. Not sure if it will end up in AC3.3.

  • Marc Cretten - If you want to process the images before the drone lands, you should look into DroneDeploy. You can also use any tablet, phone, or laptop you want once you go that route.

  • Marc Cretten - Еvеry surface pro can work with usb hub also the surface 2 can use usb hubs. Sensefly drones can't process images when flying. If you wan you can allign/stich images on site to check for holes with some software like autopano giga but this wont be a orthophoto or produce DSM. To use autopano giga or similar for stiching images and check for holes on site you need the i7 surface with 8gigs of ram. I think the tablet in couple of their videos is surface pro. A frend works with getac rugged tablet wich has two usb ports but costs around 5000$. Sensefly ebee is using RTK but they use Topcon Hiper SR for base station wich is quiete expensive. Don't now what is the GNSS unit on the plane and don't want to buy it for thousands when the same is posible for hundrets and is enough for my use.
    Thorsten are you sure that the next RC of Ardupilot wil use M8T. Can someone tell my if this in the link is now posible with pixhawk https://github.com/diydrones/ardupilot/issues/1966 and will this work with rtklib

  • T3

    Hi Sobido,

    great track analysis! (Somehow, I only get notifications randomly when someone is replying to this post. Hence, my delayed reply.)

    I am looking forward to the M8T since the next RC of Ardupilot will include the option to record RXM raw data, which can be treated in post-processing. It should work in single GPS setups.

  • which MS Surface? i3, i5, i7? Does anyone know what sensefly is using as their tablet? That seems to process images before the drone lands?

  • with rdf900

  • Or you can try windows tablet like the MS Surface with usb hub.

  • @ Arga

    I assume that you are talking of RTK solution. I worked more on Post treatment option but I did also some test in RTK.

    For tablet and RTKGps+ , as there is only one usb port that I keep for the rover gps , I used a Ntrip ( Euref or Igs ) as base . If you have the chance to leave not to far of a Ntrip server the result is not too bad ( I did around 30 cm with a server at 140 km ) . I personnaly note a bug in RTKGps+ when I need to give the lat/lon of the Ntrip position . I can't use a West longitude position or a south Latitude because I can't introduce a negative figure.

    So far, I think that the use of RTKGPS+ in RTK solution is only possible with a Ntrip positionned in Lat>0 and Lon>0 . Very frustating!

    If you use a computer and Rtklib , as the computer as more than 2 Usb port, I can use a personal RTK option or a Ntrip option as Base Gps.

    I build a M8N Gps with datalogger module , where I plug also a 3DR radio on it,  in parallel on the COM Port ( used here as Base GPS ,somewhere around 150m of your computer)  . You can program the Radio wiith Mission planner to work with.

    After I use the associated radio on my computer to receive the Gps signal from the base. 

    it is working quite well but I am not satisfy with the range of the radio of hardly 150m . Need to be improve.

  • Hi SObido, i'm very interested on your work.

    I was wondering how did you connect the second gps to the computer or tablet. I have my telemetry ready and a tablet with rtkgps+ app, but how do you connect the gps to the computer/tablet? can you post the wiring diagram?


This reply was deleted.