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:
Pix4d quality report here:
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 the time stamp column (B) and select 'Text'
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 :)
Hey Rafaei, I believe the Reach Unit only need a shrot circuit between the ground and timestamp pins to log the camera events. Not sure what that precise geotag cable does, if what is does is no more than create a short circuit then it should work.
Hi, I´m running some test with CHDK, and tuffwing precise geotag cable.
The precise geotag cable is able to record CAM events when using it with pixhawk, so I can get the exact moment when the obturer of the camera moved to take the picture.
I attempted to do same instalation using timestamp pin on Reach GPS, but no record was made, any idea on how to make it work?
Otherwise i´ll have to follow OP method to geotag my images, as Ixus132 (camera I´m using) doesn´t have internal gps for logging
I'm not an electronics expert but it looks like a LED working as a light sensor, I guess that with a small amplifier to achieve sufficient voltage to trigger tagging (I do not know what is the minimum for pixhawk but it must be lower than 5V). I did some tests late at night replicating the video with a single LED (I was so excited with this discovery) and the flash pulse gave me a voltage of about 0,13V. I do not have any transistor at this time and I don't know very well how this simple circuit should be, although I hope to try it with a colleague with more experience in these electronic issues soon.
By the way, I have found more information about LEDs working as light sensor in the following links:
that does look a good solution - will be interested in the result of your investigations...
S100-s110 cameras have no option for hotshoe but I have found this very interesting alternative to precise geotagging: http://tuffwing.com/support/Install_a_canon_precision_geotag_cable....
I am going to investigate about it...
Thank you very much for your post.
Thanks Charlie. I did wonder whether using radio RTK would be just another thing to go wrong. I am happy post-processing so I will wait and see. I don't closely monitor the emlid forum but your point about antennae is interesting - I have a ground-based L1 M8T based system which has a better (and heavier) pair of antennae - I wonder how they compare?
Thanks also for the info on the S100 - I have one of these but tend to use sony a5100s now using a trigger but I have not yet found a solution for getting precise trigger timing (the a5100 does not have a hotshoe that others are getting control from). Like you my main aim is to get better camera location.
If I have anything interesting to report once I have done some testing I will report back.
Hi Darrel, will be very interested in how Smart RTK and Reach compare! London is pretty well supplied with base stations. I did try surveying a Reach base station point and then using that to provide the reference for post processing the rover, but the results were not better than those produced using the OSNet reference. I'm sure with a decent observation window that method should work for longer baselines though.
I have experimented with real time correction and RTK navigation using the Reach - quite odd to see the copter come straight down from 70m to within a few cm of the RTL point - but the real time solution is not as good as that which you can get from post process, and the possibility of losing fix or float makes it unwise to rely on the precision of the RTK system to maintain separation objects or land in very tight spots. You need to have better maps for planning missions to take advantage of it - ability to import DEM that the full version of UGcS has does look interesting in terms of making use of RTK enabled nav though.
On the ground plane front I'm pretty sure my solution is not optimal, but not sure what areas it needs to be improved. I flew with 3 DIY ground planes, a thin bit of clear plastic packaging laminated on both sides with copper tape, a 100mm aluminium disk and a 200mm, and the 200mm does seem to work best. Waiting to see the results of some people's expermimenting with higher quality antennae on the Emlid forum...
The GCPs in the project above were just observed on top of inner corners of intersections of lines marked at the field and on surrounding playing fields. Convenient but not always available...
Thanks for sharing, I am about to deploy both reach and smart rtk to see which works best with arduplane and copter. Are you planning to do real time correction via mavlink or always post-process? You are lucky to have such a short baseline for your base station - here in Northumberland the nearest one to my test location if 62km!
I currently have 10cm groundplanes but you suggest 20cm is better - I wonder how practical that would be on my fixed wings (Skywalker 1900)? What type of target do you use for your GCPs? I fly a little higher but have struggled to get accurate location of targets on the photos (I use photscan pro). I am also concerned about the accuracy of geotagging - I could not fly my fixed wings at 5m/s - nor could I do that for my multi-rotors given the size of the areas i need to map.!
Sorry for the questions - I look forward to seeing your later results.
Thanks very much - this was the first result after an initial trial which produced surprisingly good results, so hopefully can improve things with a bit more work.