Title

Post-flight Geo-tagging of
Still Imagery from
Yuneec™ Typhoon-Q500/Q500+/4K/G
to Support Mapping and Surveying

A workflow developed and prepared by North American Robotics (NAR),

and distributed through the Yuneec Typhoon Forum for the benefit of all
Typhoon owners/operators.

By Michael ‘Doc’ Vogt, PhD

Rev. 2017.2.26 Copyright © 2016 North American Robotics

Page 2
 ABSTRACT
Yuneec makes a decent semi-drone small Unmanned Aircraft System (sUAS) in the
Typhoon line of quad copters. These appear well-built and perform their functions with
little trouble. That said, their engineering staff made a huge and critical blunder by
choosing to not geo-tag images as they are taken. While in many cases there are work-
arounds or options to use aerial imagery without geo-tags, there are cases where that’s
just not practical.

We at North American innovative Robotics (NAiR or NAR) have developed a workflow

that semi-automates this process and does it with only modest extra effort on the part
of the pilot. We have used this workflow for more than a year refining it and have
completed over (30) mapping missions using this approach.

We have adopted several intermediate processing applications including Microsoft®

Excel, GPSVisualizer, GeoSetter™, and MapsMadeEasy™ as defacto mapping package.

This paper walks through a complete example mission, including a common error, and
explains all stages of the workflow. The process is MUCH simpler than a 40 page paper,
but the detailed explanations are valuable for the unfamiliar user.

Page 3
 INTRODUCTION
We will suggest several optional ways to use a Typhoon’s imagery to produced usable maps, surveys
(maps with elevation) and models. These do not all include geo-tagging the images. We will also
suggest a recipe for producing good results.

Out-of-the-box, using the Typhoon-Q500, Q500+, 4K, or G models, with stock lenses, plan your flights
considering the minimum and maximum relief you will observe in the terrain, as well as the regulations
that govern your flight. I have been involved in remote sensing since the mid-1980’s when we ortho-
rectified imagery with very expensive software and dedicated workstations (ERDAS Imagine™).
Understanding the algorithms involved, we know that to reasonably process stereo-type imagery you
need to take the photos as close to the nadir line as possible (looking straight down perpendicular to the
Earth’s surface) and that you need to be at an altitude more than 10x the maximum relief you wish to
model. None of these requirements is difficult to achieve from satellite or high-altitude manned
aircraft, but it’s a very different story with small unmanned systems. We have seen some authors note
that only 5x will suffice, but much of that depends upon the exact character of the terrain. Basically, you
can’t fly at 100 ft AGL (above ground level), over a 50 ft high hill, and expect to image it correctly – the
displacement of foreground objects and the distortion from the lens is just too great. Instead, plan to fly
at 500 ft AGL and you will have better results with a 50 ft hill. Adopt a standard operating altitude so
your flights are predictable, and the results will be equally predictable.

For this exercise we used a stock 2015 Typhoon-Q500 with CGO2+ gimbal and stock camera and lens,
looking straight down (nadir), flying at 150 ft AGL (in cold 32°F air and strong winds gusting from 12-16
mph) and produced a resulting Ground Sampling Distance (GSD or resolution) of 0.8 in/pixel.

Using MapsMadeEasy (MME) as an representative mapping application – this exercise will produce a 3D
model from understanding that if one wishes to use MME’s volume computing tools you need to achieve
final resolution GSDs of 2.00 in/pixel or less. That restricts the Typhoons with stock lens to flying below
300 ft AGL. In our experience, rising to 300 ft AGL [and descending] consume more battery than
desired, and we can extend the flight time significantly by staying at 200 ft or 150 ft AGL. This therefore
limits the relief we can accurately model to +/- 15 ft from ground level – something to consider as you
plan a mission.

If your still imagery is all along the nadir line (< 10 degrees off from vertical), with no view of the
surrounding horizon (blue sky) and you achieve approximately 60% over-lap side-to-side and above-and-
below each image, then you can expect the images to stitch together with little introduced error.

Once you have good imagery, you have at least (three) choices for ortho-rectifying and geo-referencing
the images during stitching.

1) Stitch it together and geo-reference against a base map, even one such as GoogleEarth, using
visible landmarks such as power poles, building foundation corners, sidewalks, street signage,
cracks in road materials, boulders, etc. This avoids the need for geo-tagging completely and
with only (7) such landmarks accurately geo-references the final map usefully. We use this

Page 4
 approach on half of our missions, shot in more urban areas and some rural ones. If you find
yourself focusing on a small plot of land devoid of such landmarks, simply look around and plan
to extend your flight specifically to include extra coverage that does include landmarks. We
regularly fly farm fields, but when done, fly out of the field, along the county roads to include
power poles, driveways, signage, buildings etc. just to introduce landmarks for later use. This is
the planning portion of the mission and produces much better results than just flying by the seat
of your pants and hoping for good results.
2) Instrument the ground before you shoot. If the area we need to map is devoid of natural
landmarks, we drop 1 m x 1 m square tile targets made of heavy vinyl material on the ground.
These are divided into 4 quadrants and painted checker-board fashion to make them easy to
spot.

1m

If we are flying a 50 acre field we will place four (4) of these targets down in roughly a triangle,
spaced through the field. The fourth target being placed in roughly the center of the triangle.
These four landmarks are surveyed using a hand-held GPS receiver in its most accurate mode.
Use RTK-capable GPS if you have it, but a good Garmin or Trimble hand-held (or smart phone
using Mobile Topographer app) seeing more than (10) satellites will produce < 1m error in most
cases and for many applications this is suffice. This “instrumenting” of the field serves the same
purpose as locating real landmarks on a base map. When preparing to stitch (or after the
stitching if you prefer) one locates the marker tiles in the imagery and provides the software
with the lat/lon/alt information. This approach generates very accurate results and does not
require any base map.
3) Geo-tag the images in post-flight production using the flight log on-board the Typhoon.
Sometimes, you just cannot instrument the field, and the ground cover is such that no natural
landmarks are practical, and you have to rely upon the accuracy of the GPS on-board the copter,
and rely upon the ability of the copter to hold a vertical position above the ground, and you
have to rely upon the altimeter (barometer+GPS) and other instruments to report the copters
tilt. We chose such a case for the example, where the entire 500 acres surrounding the work
area was under significant construction – GoogleEarth was two years old and did not reflect
these changes and so was useless as a base map, the landscaping being performed prevented us
from dropping targets for instrumenting the field, and trusting geo-tagging was the only
alternative that was practical. The final results were still impressive, and illustrate the
usefulness of this technique.

Page 5
The workflow process in a nutshell… (all because YUNEEC wont upgrade the Typhoon firmware to
&^^%$-ing geo-tag images automatically… ^$$*&^@#.)

Step 1 Step 2 Step 3 Step 4 Step 5

ST10/+  MSExcel  GPSVisualizer  GeoSetter  MapsMadeEasy

.csv  .xlsx  .gpx  .jpg’s  .kmz

Here are some caveats and recommendations before you begin.

1) READ these instructions completely before you begin following along.

2) Gather the needed files first, place them all in one folder together. It is all too easy to try and
process several missions at the same time and mix up parts… please people, this is
engineering/surveying – take your time, and be careful with the organization of your data. Get
the ST10 FlightLog, and all Typhoon still imagery in one folder.
3) Always, always, always, during the mission, use a separate camera (or smart phone) to take a
panorama of the entire skyline from where you fly, from the ground. Take stills with your
mobile phone pointing North, East, South, West – take other angles too and use these stills to
help answer questions you will have about the location of objects later, when you are post-
processing the imagery. Days after a flight, your memory will be near-useless and this extra
information will show its value and save you a return trip to the site.
4) If using a Typhoon-G model, just before you launch the copter, synchronize the clocks on the
CGO2 camera and the ST10. I have used GoPros, SJCams, and GitUp cams (Git1 and Git2 are the
BEST of the bunch) and can easily sync these to within 1 second of each other. Start by using
your mobile phone as a time reference (the GPS on-board is the most trusted time source) and
setting the ST10 against it. Then, get in to your camera clock setting menu and set it to be just
ahead of the ST10’s reported time. The ST10 reports time ending in Minutes… but if you set
your camera clock to be the minute ahead of the ST10… then hold back from
entering/accepting that time and watch your ST10… just as it ticks over to the next minute you
now know the ST10 just passed the MM:00Sec mark – then enter/accept the new clock value in
the camera and voila’ – you have synced the camera clock to the ST10 to within 1 sec. Now your
camera time-stamp and the ST10 flightlog will align with reasonable accuracy.

Note – the author has adopted a print layout from Microsoft. In their 1990’s line of reference manuals
they began to break all complicated topics up into two-page layouts, always starting on the left side. We
found this very agreeable when learning a new procedure and have used it in this manual. Each Step
will begin on a left page and proceed to completion.

Page 6
 Step 1 – ST10/+ Getting the FlightLog
Fetch the FlightLog folder from the ST10. Power up the ST10 or ST10+, after a couple minutes touch the
screen so it will stop looking for the copter. It should be ready to behave like a USB storage device, so
get a data cable with USB-Micro-B connector and while still powered ON, plug cable between your
computer and the ST10. ST10 should so up under Windows Explorer as a storage device (drive). You
should be able to find a FlightLog folder, and inside that should be three (3) other folders – Remote,
RemoteGPS, and Telemetry. The Telemetry folder will have one or many .csv files, one for each time the
ST10 was powered up. When I have the ST10 mounted as a drive it does NOT report creation dates for
these .csv files so I have to drag/copy the entire folder to my local computer hard drive and then the
creation date shows for each .csv file. Find the one closest to the time of your copter flight. Note, the
date/time of the files will be when it closed, not when it opened. With the correct .csv file located to
match the date/time of your set of flight photos, open it up in Microsoft Excel.

Page 7
Page 8
 Step 2 – Cleaning up the FlightLog in MS Excel
Inspect the ST10 FlightLog .csv file in MS Excel… it should look like this –

I have not seen any that vary from this format – columns A through X, containing pretty much
everything about the aircraft GPS/accelerometers as you would care to know, but, the date/time in ColA
is formatted to be as-is pretty much useless to any other software applications.. we need to standardize
the format for Date and Time. I have coded up two columns of Excel formulas that parse and extract
the needed Date and Time format and cast them into useable standardized formats. Column B contains
copies of =DATE((LEFT(A2,4)), (MID(A2,5,2)), (MID(A2,7,2)) ) while Column C contains copies of
=RIGHT(A2,12). Introduce these formulas into your spreadsheet by inserting three (3) new columns
before the B column. Then, copy the two columns of formulas from my template spreadsheet and paste
into the new ColB and ColC. Leave ColD blank for near future development. You should end up with a
spreadsheet that looks like this, but with your data in it.

Page 9
Next, paste in my two columns in B and C…

Examine the parsing formula in the cells so you understand that all the do is cleanly dissect the Yuneec
non-standard timestamp and cast it into something ore standardized and readable by later stages of this
workflow.

Page
10
Repeat the formula blocks for any extra rows that need it, trim off any extra rows to match the number
of rows in your FlightLog (for tidiness). Save in .xlsx format.

It has been wise at this time to chart the Altitude column to inspect how level and uniform the Typhoon
was during its flight. Doing this for the template sample data shows that the Typhoon then climbed up
to working altitude (in meters) in steps, which agrees with the mission notes. It held a constant altitude
for the bulk of its mission where the example images were taken.

Page
11
The altitude data from the new working project is also charted.

Note the constant altitude (in meters) reflecting a working altitude of 150 ft AGL.

Page
12
 Step 3 – Creating a GPX file in GPSVisualizer
Now… go to GPSVisualizer.com website.

Select .xlsx file and set output format for GPX, <Convert it>

Page
13
Click to download 20170226015130-17097-data.gpx this file is now in a standardized GPS route
format that can be inspected, dissected, and used to automatically time-sync to image files to provide
lat/lon/alt geo-tag data.

20170226015130-17097-data.gpx

Rename for practical handling.

Site2 ST10 route.gpx

It is practical to open and inspect this file in a GIS or viewer like GoogleEarth to validate its location and
general shape against mission notes.

Page
14
This mission was flown over a new construction site on the SMSC Native American Indian Reservation
near Shakopee, MN.

Page
15
Page
16
The GoogleEarth Playback slider can be used to replay the route from launch to recovery. Here the
route launched from a construction road, headed south about 1000 ft to pass over some new
construction, came back slightly to the west to provide some over-lap of imagery, then caught some
extra excavation near the launch point and a bit west. Note the lack of any features in the base map
that could have been used to geo-reference the imagery – this illustrates the purpose and functionality
of geo-tagging the images based upon the on-board GPS data.

Note – changing the viewing settings for this .gpx track to Relative to Ground and Extend to Ground
helps visualize the path, and verify its uniformity and area coverage.

Page
17
Moving along.

Option A – Option for Time Syncing Camera and Ground Control Station
We need to introduce an option step here depending upon which Typhoon you have, the Q500/500+/4K
or the G. If you have one of the Typhoons with a CGO2 gimbal-mounted camera then your images are
already time-stamped in sync with the on-board Ground Control Station clock. But, if you have a
separate camera such as a GoPro or GitUp or SJcam or any others then you need to gather information
to provide a time sync between the ST10 clock which time-stamps the FlightLog data and the camera
which time-stamps the images. I do this by using the camera (for examples will be a GitUp Git1 cam) to
take a photo of the ST10 display screen. That image will be time-stamped by the camera but the image
content will be of the ST10 – voila, perfect reference numbers for software to calculate an offset.
Remember, if you did not take care to sync the ST10 to a reference clock ahead of time (I use my mobile
phone clock as a reference) and to sync the camera also to the reference clock then there can be
considerable difference here, and when multiplied by the rate of movement of the copter during flight
can lead to very serious positional error.

Now, criticism for Yuneec. These guys appear to have designed and engineered a decent series of
copters, but whoever hired their nephew to tackle the software engineering should be taken out and
beaten. Severely. That doorknob should have already taken care of geo-tagging our images for us, it
would have taken perhaps a dozen lines of code and he’s responsible for costing this industry thousands
of extra hours of work doing it for him… and cost Yuneec a huge loss by literally handing over the
mapping/surveying drone industry to DJI – what a fool. But it gets worse. This same fool requires the
user to set the date and time on their ST10 to some arbitrary values… when they have immediate access
to the GNSS (GPS) date time location data right from the on-board GPS – no better, no more accurate

Page
18
time reference available, but instead he asks the user to set the time??!?!?!? I can’t criticize this clown
enough.

Moving right along… however you want to do it, once you have computed your time-offset between
the ST10 and your camera, you can move to the final step – GeoSetter.

Page
19
Page
20
 Step 4 – Geo-tag Imagery Using GeoSetter
Download the GeoSetter Windows application from your favorite safe web source and install it. If you
haven’t launched it for a while, expect instructions to update it as shown here.

Page
21
I have been using GeoSetter for a couple of years, and it works well. Kudos to Herr Schmidt for a decent
piece of software, including regular updates.

It is because of his effort and his assistants’ that I am making the time to draft this primer for using his
tool (and others) to geo-tag specifically Yuneec Typhoon imagery.

For simplicity and convenience, copy the earlier generated .gpx file into the same directory as the
images to be geo-tagged.

Page
22
From inside GeoSetter, open the folder with the desired images.

Inspect some of the images to become familiar with the EXIF data available, and check the time stamp to
make sure it agrees with the mission notes. The images are all between minutes :59 and :06 which
agrees with mission notes and pilot’s log entries.

Because we copied the .gpx track into the same directory as the images, the default <Synchronize>
button can be selected.

Page
23
The CGO2+ camera gets its time stamp from the ST10, so they share a clock and no adjustments should
need to be made – can proceed with defaults.

Note –
<?xml version="1.0"?>

<gpx version="1.1" creator="GPS Visualizer http://www.gpsvisualizer.com/"

xmlns="http://www.topografix.com/GPX/1/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1
http://www.topografix.com/GPX/1/1/gpx.xsd">

<trk>

<name>Site2 St10 data with corrected Alts Date Time</name>

<trkseg>

<trkpt lat="44.761173" lon="-93.46603">

<ele>-0.29</ele>

<time>2017-02-23T12:56:33Z</time>

</trkpt>

<trkpt lat="44.761173" lon="-93.466034">

<ele>-0.28</ele>

<time>2017-02-23T12:56:33Z</time>

</trkpt>

Page
24
 <trkpt lat="44.76117" lon="-93.466034">

<ele>-0.27</ele>

<time>2017-02-23T12:56:33Z</time>

</trkpt>

<trkpt lat="44.76117" lon="-93.46603">

A sample from the .gpx file indicates that the time is Z for Zulu Time, which is typical of GPS time stamps,
but the times shown – T12:56:33Z are actually local times, the mission notes report this flight was
completed from about 12:57PM to about 1:10PM local time (right after lunch).

We introduced a correction of -6 hours. We could have gone back and introduced a time correction in
GPSVisualizer as instead and generated a correctly Zulu time-stamped .gpx file.

And got the following confirmation…

Page
25
Press <Yes>

A few seconds later…

This placement of markers agrees with the .gpx track as displayed earlier in GoogleEarth. Note the geo-
tag now in red associated with each of the images along with its original Taken date/time.

Page
26
Save the Changes to Images…

This saving step can take several minutes… be patient.

Page
27
Note! - This process OVERWRITEs the original images. Make sure to always work on a COPY of the
original images for this reason. We recommend .zipping/compressing the original folder before work
begins so the user can return to this archive if problems occur during processing.

site2 @150 ft AGL.zip

Page
28
When done, no real errors only warnings about overwriting files. In this case, one file did appear to be
corrupted and was corrected – this was not confirmed.

The new headers with updated EXIF GPS data can be inspected…

and moving through the flight…

and

Page
29
Now… it is important to scroll through the entire entire collection of image thumbnails and look for any
with bad location lat/lon values. This seems to happen regularly with 0.0000000, 0.000000 showing up
for no explainable reason whatsoever. These need to be removed. Reprocessing doesn’t seem to help.
The presence of these images with bad position data will not be detected by mapping software until it
causes an entire project to fail. I have experienced this odd event in almost every batch of images I have
processed using this workflow. I have examined the failed images carefully and can find no pattern,
nothing unusual, nothing to cause the lat/lon error. I am assuming it is somehow related to the actual
time values stamped on these images, and how the interpolation of new lat/lon values is computed
using the neighbor .gpx points. If someone notices something I have overlooked please contact me and
we can work around it (likely by adjusting the timestamp on that image by some minute amount).

These images can now be processed in MapsMadeEasy or other stitching geo-referencing software
(Pix4D, etc.).

Page
30
One last note – when you shoot a set of aerial surveying/mapping images… always take a couple photos
on the ground at Ground Level. MapsMadeEasy and other applications ask for this in order to establish
the actual Ground Level for processing. Not having such an example image introduces elevation error
that makes the produced DEMs and .KMZ files less friendly to later import into GISs.

Page
31
Page
32
 Step 5 – Confirm Geo-tags by Making Map/Model in MapsMadeEasy
MapsMadeEasy (MME) is a very practical, very useful on-line application and mapping service. We have
developed this workflow to be universal in that it can geo-tag images for any 3D mapping software, but
we used MME as a model because of its excellent documentation and uncluttered nature.

The home screen is simple, and shows the user clear menus.

Once the user sets up an account they can continue to <Create a new Map> from several different
locations in the menu system.

Page
33
Several options are presented for working with imagery and generating stitched and geo-referenced
maps. These align with the options for processing described earlier in this paper. By no means is the
user restricted to only using geo-tagged images, and in fact, more accurate maps can be produced using
[accurately] gathered GPS Ground Control Points than in trusting the geo-tagged imagery.

Page
34
The steps are pretty self-explanatory so the commentary will be minimal.

Select the images, all in the single folder together.

Page
35
Page
36
Note – MME does not charge a fee if the processing is below a minimum threshold. For the Typhoon
CGO camera (including the new Typhoon-H CGO3 camera) this translates into projects of 150 images or
less. Press the Normal Processing Urgency and you will not be charged at all.

Page
37
Page
38
Now…. Wait for MME processing….. I have timed this for the past 50 projects and about 1 hour is my
typical wait time – not bad for a free exercise project. Kudos to MME!!!!!!!!!!

Failure!!!!!!… MME failed with this!!!!!!!!!!!!!! Let’s go see why…

Page
39
It turns out that three (3) images geo-tagged by GeoSetter had the unexplained 0.00000,0.000000
lat/lon location. There was nothing unusual about the images themselves, GeoSetter offers no
explanation. We removed these, leaving only 58 images… and then reprocessed. There was more than
sufficient over-lap between images for this to have no negative impact on the final map quality.

Page
40
Page
41
Page
42
About 1 more hour later…

Done, and looking good!!!!

Page
43
MME provides a very useful report describing the process, results, and characteristics of the generated
map. Study this report – you will learn a lot, and understand the strengths and limitations of your map
as well.

Page
44
Learn how to interpret the following Over-Lap Report portion, and understand how to use it to guide
your next flight/mission planning. You can download the entire set of digital results with a single
button, or, download only certain items.

Page
45
Page
46
Examine the DEM or Elevation model that is also generate by MME along with the geotiff mosaic image.

One of the other generated files is a .kml or .kmz file which all by itself is courser than the actual geotiff,
but imports directly into GoogleEarth for easy display and navigation. This is how we (NAiR) deliver
many of our products to sponsors – they appreciate the utility of this model and its speed in playback.

Page
47
Viewed from the position from where the flight was executed… (that is the author in yellow-green safety
vest and his Jeep chase vehicle in the foreground).

NAiR has plans to condense all of this workflow into a simple Windows application that will read the
ST10 FlightLog and extract the GPX data and geo-tag images all in one step. The lifespan of the typical
quad copter model is limited, but we have gotten two good years out of ours and looking to get two
more from each of our six. If we get enough prompting and positive feedback from Yuneec pilots we will

Page
48
pursue coding and engineering this application, till then, this workflow has been satisfying the problem
and we hope it will serve you well.

Please feel free to share comments, advice, catch and report errors and corrections to use at
info@NARobotics.US.

Cheers

DocV

finis

Page
49