Welcome, Commercial Drone Pilots!
Join our growing community today!
Sign up

Dronelink now offers terrain following

AMann

Well-Known Member
Joined
Sep 25, 2019
Messages
186
Reaction score
117
Dronelink now has terrain following for consistent AGL points along paths, rows and grids! This is a great development for doing orthophotos and maintaining more consistent pixel resolution for each image of a flight.
It will allow you to set a constant height AGL for each waypoint or photopoint in a grid or path.


The new functions include:
  • Import Of Litchi Missions
  • Import Of KML/KMZ Missions From Google Earth
  • AGL (Above Ground Level) Support for Destination Components, Paths, and Maps
  • AGL Support Overview
  • AGL Support Of Litchi/Google Earth
 
Last edited:
As an FYI, the Map component with AGL IS true terrain following as it adapts altitude based upon the terrain as it does an Ortho or Grid pattern.

Dronelink now has “terrain following” for consistent AGL of points along paths, rows and grids! This is a great development for doing orthophotos and maintaining more consistent pixel resolution for each image of a flight.
Note that It’s not true terrain following because it will run a straight line between two points, but it will allow you to set a constant height AGL for each waypoint or photopoint in a grid or path.


The new functions include:
  • Import Of Litchi Missions
  • Import Of KML/KMZ Missions From Google Earth
  • AGL (Above Ground Level) Support for Destination Components, Paths, and Maps
  • AGL Support Overview
  • AGL Support Of Litchi/Google Earth
 
  • Like
Reactions: AMann and BigAl07
I'm still trying to wrap my head around why the drone following terrain helps. I know it does, just don't really get why. I do this for a living (survey mapping) but it still seems to me that the drone consistently being X# of feet above the terrain throughout the shoot would defeat the photogrammetrical calculations in the SFM software that are designed to make the DSM and DTM based on the relative height in the terrain. This calculation is done by noticing the dips and rises based on reflectivity. I suppose with an RTK system the SFM software would make its calcs based on the altitude stated in the EXIF headers? I wouldn't want to rely on the DJI EXIF stamp without an RTK for instance, as they can be notoriously inaccurate. Anyone want to help me understand this one, please?
 
I'm still trying to wrap my head around why the drone following terrain helps. I know it does, just don't really get why. I do this for a living (survey mapping) but it still seems to me that the drone consistently being X# of feet above the terrain throughout the shoot would defeat the photogrammetrical calculations in the SFM software that are designed to make the DSM and DTM based on the relative height in the terrain. This calculation is done by noticing the dips and rises based on reflectivity. I suppose with an RTK system the SFM software would make its calcs based on the altitude stated in the EXIF headers? I wouldn't want to rely on the DJI EXIF stamp without an RTK for instance, as they can be notoriously inaccurate. Anyone want to help me understand this one, please?

My understanding of the way products like pix4d, drone deploy, agisoft, etc. work:

1. find key features in each image
2. for nearby pairs of images, find matching features between pairs.
3. make a giant jigsaw puzzle out of the whole set of camera poses and 3d feature locations. The puzzle can only fit together perfectly if all the features and all the camera poses are in their correct relative locations. There is a brilliant thing called an optimizer (bundle adjustment) that solves the puzzle. Engineers use optimizers for iteratively solving a lot of problems that are large or difficult. Terrain stitching is enormous because you can have millions of variables you need to simultaneously manipulate. But optimizers are magic and can deal with this.
4. generate all the output products (sparse & dense point meshes, orthophotos, dem, etc.)

Solving the puzzle doesn't depend on all the images being taken from the same altitude or orientation. It's ok if the camera poses are pretty much arbitrary. (However, if images are really close to each other, or one above another, or taken at a highly oblique angle ... showing the horizon then this can introduce big errors pretty quickly and mess up the fit.) Some of these software packages probably have ways to address this if your goal is to build a 3d model of some sort of monument or vertical structure.

The reason I would want to follow terrain is to get consistent pixel resolution in my images. I'm hunting for a needle in the haystack (things that shouldn't be there) like trash or invasive plants. For me, higher resolution is better, so flying lower is better ... but more dangerous if there is terrain or trees. I often have to cover larger areas with highly varying terrain. It is complicated to find the high point in the area you want to fly (it may be inaccessible) and/or estimate how much higher the surrounding terrain + trees are so I can safely fly.

That said, I haven't tried this new product, and I'm not sure I'd trust something that blindly flies altitudes from an offline database ... you would still want to build in very large margins. Also, it really matters what direction you fly the survey pattern in terrain. You could easily end up wasting a lot of energy climbing and descending if you aren't careful.

Interesting stuff, but my recommendation is to use with caution and validate everything first with your human brain.
 
  • Like
Reactions: John Githens
I'm still trying to wrap my head around why the drone following terrain helps. I know it does, just don't really get why. I do this for a living (survey mapping) but it still seems to me that the drone consistently being X# of feet above the terrain throughout the shoot would defeat the photogrammetrical calculations in the SFM software that are designed to make the DSM and DTM based on the relative height in the terrain. This calculation is done by noticing the dips and rises based on reflectivity. I suppose with an RTK system the SFM software would make its calcs based on the altitude stated in the EXIF headers? I wouldn't want to rely on the DJI EXIF stamp without an RTK for instance, as they can be notoriously inaccurate. Anyone want to help me understand this one, please?
The main benefit is that pixel resolution remains more constant throughout all of the shot, because the landscape remains at a more similar distance from the camera. This makes for flat orthophotos that have more constant resolution throughout the image. The image processing software can find common points of objects in the image to correct and stitch the images, including roads, bushes, buildings and GCP’s. RTK makes it even easier for the software to create a more accurate image.
 
Pix states they can handle differentials in GSD up to one half of the original GSD calculation, IE: if you have a 0.5 initial GSD you can fly to the relative altitude that gives you 0.75 GSD and it will still integrate correctly. That's a pretty big change. Oregon can and does have terrain that can change by 100 feet vertical in 30 feet of lateral space, so I still have to plan my shots around such extremes. Not sure terrain following could accurately account for that, or not. I appreciate both of you taking the time to unpack that for me. I'm still not seeing how it accounts for the Z if it is consistently at a fixed point above the ground other than the EXIF stamp. My GCP's can be spread out up to 500 feet or so apart on a large project (250+ acres for instance), but the terrain variables wouldn't be accurately calculated if the camera is always at the fixed AGL setting.
 
I find with my DJI mavic pro and phantom 4 pro that the exif stamp is actually quite accurate (and this is without rtk). I usually see that the fitted solution is within 1-2 meters of the original exif position estimate and this includes the vertical movement. I don't have an absolute truth reference though so I am looking at consensus of all the exif tags.

I don't know specifically how the commercial black box tools handle this, but my stitching software uses the exif position and orientation as an initial guess. When the optimizer finishes fitting everything together, I use an affine transformation (rotation, translation, scale) to best fit the optimized solution over the original exif locations. In the end, everything is best fit relative to each other, and the that is rigidly best fit to the original exif stamps. I haven't used GCP's in my own work.
 
I find with my DJI mavic pro and phantom 4 pro that the exif stamp is actually quite accurate (and this is without rtk). I usually see that the fitted solution is within 1-2 meters of the original exif position estimate and this includes the vertical movement. I don't have an absolute truth reference though so I am looking at consensus of all the exif tags.

I don't know specifically how the commercial black box tools handle this, but my stitching software uses the exif position and orientation as an initial guess. When the optimizer finishes fitting everything together, I use an affine transformation (rotation, translation, scale) to best fit the optimized solution over the original exif locations. In the end, everything is best fit relative to each other, and the that is rigidly best fit to the original exif stamps. I haven't used GCP's in my own work.
That's pretty accurate for a drone position stamp. Mine are always off between 2m-30m in XY, and the Z can be all over the map (no pun intended). I flew a project at 115 feet (35m) and 17 different flights. The Altitude stamps were anywhere between 41m and 116m. All the same drone, same day, same 35m setting. Phantom 4, no RTK.
 
Oh, oh, oh, I forgot the major caveate!!! The phantom 4 pro v2 (at least mine) stamps altitude with barometric pressure, not gps. The mavic 2 uses gps which makes way more sense. I can only speculate that dji thought it was a good idea to use baro altitude for better flight control, but it does screw everything up with the exif altitude tags. I forgot that I take an extra step to calculate my the gps altitude of my phantom 4 images. My phantom 4 has a sentera camera which takes it's own pictures and geotags them with the gps including altitude, so I can do some fancy footwork to estimate the gps altitude of my dji shots. Sorry I completely forgot about that because I've been working with our mavic more recently.

I have also been playing around with SRTM (shuttle radar topography mission) which is a world-wide earth surface data set with elevation posts every 30m (approx) for the USA. The elevations are in egm96 and I haven't found a good (python) way to convert to wgs84 altitudes in my own code yet, but the elevation differences are roughly 10m in my area.

So you are right, the dji phantom 4 pro v2 elevation tags will be all over the map and need to be corrected manually some how. Super annoying for this sort of work. :-(
 
It's an easy fix with Pix. Load the photos, when the screen comes on that has the photo Exif tags you right click under Altitude and select Edit all altitudes, correct one, and enter. The software will change all the others.
1577725850248.png
 
Pix states they can handle differentials in GSD up to one half of the original GSD calculation, IE: if you have a 0.5 initial GSD you can fly to the relative altitude that gives you 0.75 GSD and it will still integrate correctly. That's a pretty big change. Oregon can and does have terrain that can change by 100 feet vertical in 30 feet of lateral space, so I still have to plan my shots around such extremes. Not sure terrain following could accurately account for that, or not. I appreciate both of you taking the time to unpack that for me. I'm still not seeing how it accounts for the Z if it is consistently at a fixed point above the ground other than the EXIF stamp. My GCP's can be spread out up to 500 feet or so apart on a large project (250+ acres for instance), but the terrain variables wouldn't be accurately calculated if the camera is always at the fixed AGL setting.

With drastic changes in elevation like you described it is prudent to adjust your flight altitude so as not to collide with terrain manually instead of relying on the software to do it for you. MY aircraft has a terrain following capability based upon one of the space shuttle SRTM radar mapping missions. It does an excellent job under normal conditions but they also caution that abrupt changes in elevation could lead to a impact with terrain and to plan the mission flight altitude accordingly. They also suggest breaking the flight up into two phases to more accurately map the area with a high and a low segment.
 
  • Like
Reactions: AMann and clolsonus
They also suggest breaking the flight up into two phases to more accurately map the area with a high and a low segment.
You are correct, and I do it too. If it isn't a breach of site protocol, which bird do you fly? I have the capability on three of my birds to use the SRTM, but I always end up with "segment not available in one quadrant" when mountains are part of the site.
 
Question for this group:
True or False:
  1. "Terrain-following" is a software-side feature that calls upon some USGS file for known terrains in North America (once a mapping mission is designed/saved)?
  2. Software that uses this "GEO file on the product-side, not client side" may have variability/accuracy +/- 30 feet?
  3. The Terrain data does NOT include many man-made obstructions like RF antennas, guy wires, etc.?
My experience with productized "terrain-following" is limited to DroneDeploy right now (and multi-rotor scans).
Thanks in advance
 
Question for this group:
True or False:
  1. "Terrain-following" is a software-side feature that calls upon some USGS file for known terrains in North America (once a mapping mission is designed/saved)?
  2. Software that uses this "GEO file on the product-side, not client side" may have variability/accuracy +/- 30 feet?
  3. The Terrain data does NOT include many man-made obstructions like RF antennas, guy wires, etc.?
My experience with productized "terrain-following" is limited to DroneDeploy right now (and multi-rotor scans).
Thanks in advance
1) My software uses terrain data from (STS-91? don't remember) space shuttle radar mapping data gathered a few years back.
2) Any GPS reading will have variability in it based upon the natural world effects, the accuracy of the particular unit you are using to gather the points, the software package processing the data and the operators skill at using the unit.
3) Affirmative. That is why there should always be a human in the decision chain. Rapid terrain elevation changes are also not covered. Cliffs, mountains, etc. always have to be taken into account when planning and executing a terrain following mission.

I've been using terrain following for a couple of years now on my FireFly 6 Pro and have had excellent results with it. Our current job site 'had' (since been leveled out) a 140 foot elevation difference and I am able to maintain a constant GSD over the course of the mission.
 
  • Like
Reactions: KLAX

Members online

No members online now.

Forum statistics

Threads
4,277
Messages
37,605
Members
5,969
Latest member
KC5JIM