Mapping with Reach and Canon S100: test flight results

Precision geotagging images using Emlid Reach, Canon S100, CHDK, KAP script
and RTKlib – Proof of concept

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 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 is always 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 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 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

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

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 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 :slight_smile:

Files here until dropbox bandwidth used up:

Useful links:

OSNet data:

IGS data:

CHDK wiki:

KAP script:

RTKPost tutorial:


Pix4d quality report here:

1 Like

Since noone commented yet, let me say: your work is awesome.
I was dreaming to do something similar, but since i have a Phantom3, i would also need to buy a new drone to test his setup. Luckily, you posted results with Reach.
I am not really into cameras, but maybe there is a camera out there to hack open, and grab a signal for e.g writing to flash? If the timing accuracy would be better, one could also interpolate coordinates for the photo.

Thank you for your awesome work and this detailed report!

It’s really nice to see Reach in action, especially in the mapping sphere. If you have any bug reports/suggestions/feature requests for Reach, don’t hesitate to write me a PM.

Emlid will be releasing an update to allow the pin on the hotshoe of an equipped camera to trigger fairly soon I believe, which should solve that problem. I think the next release of APM copter will include a similar function (alrady in Plane and Rover afaik). The nice thing about the above method is that anyone alrady using an S100 or similar camera can immediately begin to use a Reach to achieve these sorts of results.

A fairly simple hardware solution to discovering the exact offset would be an led array, say 3x10, drivern by an arduino or something, which could take the GPS time signal from eg a reach unit, and then pulse the leds to produce the 3 digits of the millisecond time in each second. Take a picture of the display at at least 1/1000 shutter speed before flying, then use the led counters and KAP log file to find the offset. Unfortunately I am no coder but it seems like someone with the skills could come up with plans for hardware and a bit of code pretty easily (?).

Thanks very much, will do!

Hey Charlie,

Fantastic write-up! Did you solve the radio range issue and the switching b/w two onboard GPSs? I thought I read somewhere that we could tell it to only use the secondary GPS (reach) - regardless of fix, float, or single. Is there truth to that?

Great work!
Austin M

I haven’t had a chance to try the Reach in RTK mode for navigation recently - in this case the Reach was plugged into serial 4/5 on the Pixhawk and was running in single mode at 10Hz, with auto switching enabled.

I have flown with just the Reach as primary gps, in RTK mode, and seen it switch between fix, float and single solutions without any apparent issues - the new nav dynamics option seems to help, but as it only works at 5Hz for the purposes of mapping if you just need the logs it seems preferable to use the Reach in single mode at a higher rate.

I still haven’t looked into the apm logs enough to work out how to tell which gps is actually being used for navigation at any given moment (hence flying with just the Reach, to ensure the primary was not being used). I’m sure the info is there. I feel that some of the problems I was seeing earlier were perhaps more caused by the ground plane (above and in front of the M8N antenna) - perhaps someone more knowledgeable on GPS could comment, but a short mulitipath error from reflections from the plane would seem to be harder for the system to filter out.

What might be good I think, would be a system with two GPS units sharing the same antenna. Don’t know how APM handles dual GPS, but the system could surely fuse the GPS results, which should be very similar if the GPS systems are the same. That seems like it might help with GPS switching if you are relying on RTK precision. Though separate antennas mean GPS compass is an option so perhaps not.

Anyway, will continue to experiment as time allows :slight_smile:

I’m just amazed of your achievements, congrats!
I was looking to get RAW phase carrier data from an airborne platform since 2 years or so, sincerely I was betting on more other horses than REACH. Now I’m your fan and looking for your RTKPost. When you think it will be available?
I’m just building a beautiful 2.4m wing and I would like to add it to it.

Unfortunately no phase observation in raw data file, the RINEX file probably it’s just a conversion of codes.

This should be the solution to the time stamp issue - should be able to log direct to the Reach, or to Pixhawk, or use to work out the offset for the KAP logs…

got an A6000 to get hotshoe timestamping going, but will pick one of those cables up at some point to see how accurate they are…

1 Like


I just ordered some phototransisitors to see if I can make one of these cables. $40 for a phototransistor, some hotgule, and a servo cable seems a bit excessive to me. It looks like a LTR-301, I ordered a batch and will report back if I have success…


That sounds great, will be very interested in your results :slight_smile:

I’ve been meaning to post back here actually, I did manage to get some more consistent results from the KAP script logs, I had not spotted the flag for outputting the times from RTKLib in UTC rather than GPST, so was manually offsetting 17 seconds plus a bit to account for the horizontal offset between the camera sensor and the Reach antenna. When I used the flag instead of my spreadsheet to switch to UTC I found a much better sync, I only needed to add an extra 3 ms offset to account for the ~15cm horizontal offset and 5 ms flight speed, and got some very good geotags. Have only had time to try this once so not 100% how repeatable the result is, but pix4d quality report is pretty ok:

woodberry_50m_09_06_16_-0.03,-13cm_report.pdf (1.3 MB)

Accuracy of the GCPS was a bit questionable here, time only permittefd very short observation windows. The base station GCP is a nice accurate fix though.

really need to move my gps antenna to directly above the camera and get imu data integrated. Anyway, the S100 does seem to work much better in this application than you might think, fingers crossed CHDK gets ported to some more recent canon cameras as the Sony is definitely less satisfactory in some regards.



Yes, CHDK is great, I don’t plan to ultilize Sony cameras if at all possible. I use A2300, SX260 and powershot N, all are great cameras for aerial imaging.

The only problem with CHDK is that the new image processors (greater that digic V) are not supported and IDK if they ever will be. There was some major changes in the way the newer processors are setup that would require a complete rewrite of CHDK I believe.

I’ll let you know how the diy geotag cable comes out…


Thanks a lot for sharing your results as well as the data!
I processed them sucessfully with Mavis ( Now, I have some questiones and would like to ask you if you could you contact me at

Thanks in advance and best regards,

Aquila How did the diy geotag cable come out?


Could you re-upload your quality reports? I would be very interested in checking them.


I have tested the sync with a 0,10 € photo resistor and it seems to work flawlessly.

Since there is a restriction to 2 kg take off weight in Germany now the Canon Powershot S100/110 seem to be a quit good start for low cost mapping with high precission, or what do the pros think?