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:
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
Outdoor test: CSG with Min SV elevation set to 5°
Results of the indoor test
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.
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
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.
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 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!