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


  • T3

    Yes, I am also happy with the VR GPS. There are also other similar GPS on the market like the DroTek. It seems to have the another antenna with a size comparable to the one used on VR M8. But I am not sure about the preamp. Anyone made a comparison between those?

    Another one is the zubax which uses the u-blox MAX-M8C(Q). From the specs it should perform similar to the NEO M8N. But it has a big antenna and a good shielding and thus seems to produce the best results of all: 



    Not sure if it works out of the box with Pixhawk/Ardupilot or the native PX4 stack only. Can someone provide some details?

    One disadvantage is that it weighs more. 

  • Thanks for the article. I do use the VR GPS with great results. Very precise and smooth auto flight, good landing precision

  • T3

    Chase, yes true. I like your service! But unfortunately the 4G connectivity is rather poor here. 

  • Another option if you would like immediate feedback on image quality and the resulting stitched images is to look into dronedeploy. You can view and interact with a stitched orthomosaic map right after the drone has flown over that area and is still flying.
  • T3



    Yes the trigger delays are not constant (see my reply on drones discuss). Hence, an additional parameter might not be the best solution. What is required is the EKF estimates at 5 or 10Hz. Currently only the DCM estimates (if you fly with EKF enabled) and the raw GPS coordinates are reported.

    Thanks for pointing me to TC_XY. I'll make some tests!

  • That's a very interesting post, congrats!

    About GPS sensitivity: the bigest is the antenna volume, the best it is. I have the big CGS one, I confirm that is far superior to Ublox 6 series.

    +1 for lidar alt correction, that should be the most accurate way to do it. There are some solutions to limit the disturbances on the GPS unit in the thread you linked.

    Some ideas, not sure I'm right:

    - To limit the estimate errors on the GPS position, as the estimate is based on the Acc,  maybe check the Acc disturbances are as low as possible and constant between your different flights.

    - You can try to tune the TC_XY param to give more or less weight to the GPS or Acc to estimate position.

    - Maybe the "trigger_delay" is too long and brings those position errors,  maybe the trigger delays are not constant?

    - If the issue it the trigger delay, a param to tune it could be worth maybe, get the CAM position only at the end of the trigger, which correspond the the exact position when the shot is done.

  • T3

    I just had a closer look and it seems that currently the best way is to take the GPS coordinates and to interpolate those. 

  • T3

    There is another open question regarding georeferencing accuracy: which coordinates reported in the log file should be used.

    Coordinates are reported in AHR2, CAM and GPS entires. Since the coordinates come from the GPS it is the reference. It is reported at 5Hz. Then there is an EKF estimate which is - as far as I know - reported in the CAM entries and the AHR2. The latter is reported reported at 10Hz. 

    With 5Hz at 5m/s nav speed the accuracy is 1m. For planes even 10Hz might cause large inaccuracies. 

    Hence interpolation is required especially if RTK GPS will be used. 

  • T3

    Hi Hugues,

    yes, the exif time is an option for sure. The problem is to determine the offset especially if you have different cameras. Apart from other shortcomings there is also some timing jitter (even between the Pixhawk and the directly connected GPS). Moreover, if you need a good estimate directly in the field (for example if you have limited access) you need a quick and reliable solution. Hence, we were aiming at a "global" option. 

    But maybe at the end the result would be the same.

  • MR60

    Hi Thorsten,

    Thank you for this analysis.

    I have a question about your method to find the "real position of each picture". You correct the logged positions with various error & offset corrections due to camera triggering delay, pixhawk cam_trigger delay, etc...

    It seems to me that to get the most exact position for each picture is to use the exif picture time data and simply add/substract the GPS time offset versus the camera time. This method will indeed "include" all of the corrections for delays in the triggering chain. And it is also much more simple to do. So why don't you use that method instead ? I would be curious how it could improve your results.

This reply was deleted.