We have been using a Canon S100 running CHDK and KAP script for mapping and modelling using Pix4d for a while, and thought it might be useful to share the results of some testing of the possibility of GCP free mapping using the Canon and Emlid Reach system. The method outlined should be applicable to any Canon camera that can run CHDK.
The main issue with making use of the accuracy of precision GNSS systems for geotagging is the timestamp on the image. Flying at a fairly conservative 5 m/s getting the tags to within 5 cm of the actual position requires a precision of the timestamp of 10 milliseconds.
Experiments with the Reach and RTKPost have shown that positioning precision of the order of a few cm are fairly easily achieved. Fortunately, although the S100 exif time data is not much use, the KAP script creates a log file, which contains, among other information, a shutter release time to millisecond precision. The script creator I think claims 10ms precision for the information, but the actual precision seems better.
The Canon S100 clock can be synced using the built in GPS so in theory could provide a pretty much perfect clock sync. In practice it appears to sync to the latest second, so the offset between the camera clock and GPST has always so far been somewhat less than the 17 seconds you would expect.
The other issue is providing the geotag information to Pix4d. Our usual method for this would be to use the built in geotagging utility in Mission Planner, which experiments have shown to be slightly more accurate than tagging using the option in Pix4d to import the 3dr flight log.
In order to make use of the RTKPost output and the KAP log a simple spreadsheet was created to use the KAP timestamp information and the .pos file from RTKPost to interpolate precise positions for the image geotags, which is then output to a csv file which Pix4d can use.
The following is a proof of concept rather than fully developed workflow, but with a few of the rough edges knocked off could provide an extremely cheap option for those wanting to experiment with the effect of extremely precise geotags on mapping outputs.
The files can be found here for the moment:
https://www.dropbox.com/sh/x7h52i39b61bzmk/AAAQKCTwgCsn9roixM9ol308a?dl=0
Pix4d quality report here:
https://www.dropbox.com/s/dtbp31sjrzamf21/reach_demo_report.pdf?dl=0
The survey site is a local RC flying area. The flight was carried out at 70m agl and 5m/s, for approx. 16 minutes in the air. 355 images of the target area were collected, shutter triggered by 2 second intervalometer. The Reach flown on board was in single mode, set to GPS 10Hz, and was providing nav information to the Pixhawk, with a generic Ublox M8N based device as backup.
After the flight the images, KAP log file and Reach RINEX data were downloaded for processing.
Additionally, various intersections of white lines marking out the field and various football pitches were surveyed using a second Reach. This was carried out over 2 visits, the first with a 5 minute observation on each point (antenna on ground plane at ground level), the second with a 10 minute window on a tripod 1.52m off the ground.
In the UK historic RINEX data is provided free by the OSNet stations, there is one just over 10km away from the site at Teddington. Using the RINEX log from the Reach unit on the rover and the RINEX data from Teddington RTKPost can derive a fairly good solution with solid fixes for much of the flight. This can be further improved using precise clock and orbit data provided by the IGS products.
Figure 1: X8 dev rig
with 200mm ground plane. The primary GPS is located under the canopy to the
rear of the machine. The ground plane ahead and above the primary receiver
caused issues so the Reach was enabled as secondary GPS with autoswitch on, and
was used as primary nav throughout the flight.
Figure 2: Reach base
station antenna and ground plane, mounted on 1.52m tripod. Ground planes cut
from 1mm aluminium sheet.
Figure 3: Improvised
mapping ground control station :)
To process the data the KAP log and .pos file need to be imported into Excel:
open the files in Excel
Select 'delimited'
Click next
Check 'space'
Click next
Select the time stamp column (B) and select 'Text'
Click finish
Copy the position info from the .pos file to the positions tab on the geolocation spreadsheet
Then sort the KAP file by column D and copy all the date, time, shot number and filename data into the appropriate fields in the images and interpolation tab. Here you can also offset to account for the difference in time between GPST and UTC, and by height to account for the offset between GPS antenna and the camera sensor (-0.14m in this case).
Copy the information in the output tab to a new sheet, then export as a .prn file. Rename the file to csv and Pix4d will accept it as a geolocation file for the images.
To arrive at the exact time offset you need to run the initial processing in Pix4d. Use the difference between the initial and
calculated positions for the image to estimate the sub-second time offset, rerun and tweak, until no better accuracy can be reached. It is fairly easy to see when there is a consistent offset in the direction of flight. Increasing
the confidence in the geolocation data by lowering the horizontal and vertical accuracy values in the image properties can then help further improve the accuracy. Aiming for gaussian distribution of the errors given in the Absolute Geolocation Variance section of the Pix4d quality report helps zero in on the final offset. Other software may provide tools to extract this information more efficiently(!). It took 6 runs to derive the offset of 16.5925 seconds in this case, though the last two made very little difference to the end result.
Figure 4: We also
experimented with a 100mm ground plane, as recommended by Tallysman, both in
the air and on the ground, however the 200mm version seemed to give
consistently better results.
With the above steps carried out it is possible to get pretty accurate geotags – the limiting factor probably the resolution of the time stamps from the S100. In this case the majority of images were tagged to within 3cm of their calculated position. Slower flying might permit more accurate tags.
Canon S100 and Emlid Reach thus make a very low cost system allowing accurate mapping, potentially without the need for GCPs – in this case I would say the error of the GCPS is likely to be not much lower than that of the geotags for the images. With a bit more time and some further experimentation with antennae, RTKPost settings etc. highly accurate results should be possible.
A better method for syncing the camera and GPS clocks would increase confidence in the results – the self-referential method used above probably has the potential to introduce systemic errors so GCPS are still needed as a check against that possibility.
It should be fairly straightforward to use the RTKPost output to derive an accurate confidence interval for each of the geolocation entries. It ought to be possible to use the imu data from the Pixhawk flight logs to provide orientation information for the images, and then use the accurate geoloc and orientation calibration option in Pix4d, pending the
integration of the Reach IMU data.
All images used, along with the KAP log, rover and ground station RINEX logs, OSNet RINEX reference data, GCP coordinate file and Pix4d project and outputs are included to allow a full recreation of the results, comment and constructive advice very welcome :)
Useful links:
OSNet data:
https://www.ordnancesurvey.co.uk/gps/os-net-rinex-data/
IGS data:
ftp://cddis.gsfc.nasa.gov/gps/products/
CHDK wiki:
http://chdk.wikia.com/wiki/CHDKKAP script:
http://chdk.wikia.com/wiki/KAP_UAV_Exposure_Control_ScriptRTKPost tutorial:
http://blog.latitude51.ca/rtklib-part-2-rtk-processing/
![12 o'clock to 1 o'clock on a reciprocal track. Petr Adam Dohnálek [CC0] (Wikimedia)/Andreas 06 [PD] (Wikimedia)](https://hackadaycom.files.wordpress.com/2016/04/12-t0-1-path.png)
![The UK Houses of Parliament. Mike Gimelfarb [Public domain], Wikimedia](https://hackadaycom.files.wordpress.com/2016/04/parliament_at_sunset.jpg)
