Litchi: New terrain-following workflow

Joined
Jan 2, 2017
Messages
610
Reaction score
303
Age
62
Before Litchi added ground-relative altitude for waypoints in the most recent update, we were using Google Earth to create constant Above-Ground-Level (AGL) paths then importing into Litchi through Mission Hub to achieve constant-height missions over varying terrain.

This workflow was EXCEEDINGLY awkward and time-consuming if you needed to add/move/remove waypoints when planning, which is true 100% of the time. There was no way to do it directly from Litchi, so you were always trying to approximate things from the Earth view to fit into the Litchi view. Also, as soon as you move a waypoint in Litchi, the ground-relative altitude information is no longer valid.

You get the idea.

Now, with ground-relative altitude available directly in Litchi, all planning and adjustment can be done directly in the app, and the resulting flight path can be exported and viewed in Google Earth in 3D, so that potential obstacles and other adjustments can be made -- back in Litchi!! -- then reviewed again in Earth.

With the workflow shown below, the only role Google Earth plays is simply as a 3D viewer with approximately accurate surface data.

Check this out, and please post feedback to improve it. This is the first raw edit of the tutorial, so it has a lot of rough edges. I'm looking for solid feedback to improve it.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

This tutorial including the editing was created entirely on an Nvidia Shield K1 using Litchi, Google Earth, and Kinemaster (editor).
 
Last edited:
Why does that last loop appear to not follow terrain?
 
It does, but the terrain data doesn't include surface features like trees and buildings. That's the purpose of this workflow -- to examine a terrain-following path to see if there are any tall above-ground obstacles that require adjust the altitude of waypoints to avoid.

The next step in the workflow would be to adjust troublesome waypoints upward, then repeat the visualization. It's this adjustment/re-visualize process that was nearly impossible before, when the "waypoints" were created in Google Earth itself as part of creating a path. There simply was no easy way to adjust some of the points, and then see the path again. All waypoints had to be at the same altitude above the ground.

This process could be made much easier if Litchi would just add a Google Earth Path Export feature to either the app or Mission Hub (or best, both). Ideally, the app (Android or iOS) could save a path directly to a user's Google Drive, so it could then be viewed immediately in Google Earth. I'm going to contact them about this -- it's a pretty small amount of engineering.
 
  • Like
Reactions: Loz
It does, but the terrain data doesn't include surface features like trees and buildings. That's the purpose of this workflow -- to examine a terrain-following path to see if there are any tall above-ground obstacles that require adjust the altitude of waypoints to avoid.

The next step in the workflow would be to adjust troublesome waypoints upward, then repeat the visualization. It's this adjustment/re-visualize process that was nearly impossible before, when the "waypoints" were created in Google Earth itself as part of creating a path. There simply was no easy way to adjust some of the points, and then see the path again. All waypoints had to be at the same altitude above the ground.

This process could be made much easier if Litchi would just add a Google Earth Path Export feature to either the app or Mission Hub (or best, both). Ideally, the app (Android or iOS) could save a path directly to a user's Google Drive, so it could then be viewed immediately in Google Earth. I'm going to contact them about this -- it's a pretty small amount of engineering.

I was aware that it doesn't figure trees. But it looked to me that the hill went up but the waypoints didn't.
 
I was aware that it doesn't figure trees. But it looked to me that the hill went up but the waypoints didn't.
I adjusted some of the waypoints to be higher to avoid trees.

That's the real value of this workflow -- you can set waypoints to any altitude and visualize it in GE. They don't have to be the same AGL.

You start with a constant AGL, visualize in GE, make adjustments to clear features that rise above the terrain (trees, buildings, etc.).
 
I just took a closer look. Yeah I guess there was an optical illusion there. I guess that leveling off at the top combined with the trees getting taller on than knoll fooled me. I presume GE isn't really accurate with tree heights so I'd still be looking to add plenty - like maybe 100'. Then fine tune later.

That's why I did after this mishap. :)

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
I wouldn't expect GE 3D imagery to be even remotely trustable with respect to tree heights.
You guys are missing the point.

In terms of planning the mission, it is extremely helpful to have a tree there even approximating the space it occupies for visualizing and adjusting the flight path, since the ground-relative waypoint does not account for this obstacle.

While not accurate enough to rely on blindly, my direct experience is that it is certainly more than sufficient to make rough planning decisions ahead of time, resulting in much less time on site making adjustments before the production flight of the mission.
 
You guys are missing the point.

In terms of planning the mission, it is extremely helpful to have a tree there even approximating the space it occupies for visualizing and adjusting the flight path, since the ground-relative waypoint does not account for this obstacle.

While not accurate enough to rely on blindly, my direct experience is that it is certainly more than sufficient to make rough planning decisions ahead of time, resulting in much less time on site making adjustments before the production flight of the mission.
Point not really missed. I guess I was being a little circumspect or deferential when I said that presumably GE doesn't accurately approximate tree heights. I was trying to point out that I thought your original post may not have been clear on that point and someone MIGHT be misled into thinking they can use the tree heights from GE to avoid them. You have clarified this for the reader in your latest post "While not accurate enough to rely on blindly, my direct experience is that it is certainly more than sufficient to make rough planning decisions ahead of time." Well done. :)
 
While not accurate enough to rely on blindly, my direct experience is that it is certainly more than sufficient to make rough planning decisions ahead of time, resulting in much less time on site making adjustments before the production flight of the mission.
Well very rough decisions maybe, and there's also the possibility that one might be led into a false level of confidence. In my experience seeing trees in Google Earth means 'there are some tress there' and little else. I guess that's valuable to some extent, but again I wouldn't consider it wise to put much more faith in it than that.
 
Well very rough decisions maybe, and there's also the possibility that one might be led into a false level of confidence. In my experience seeing trees in Google Earth means 'there are some tress there' and little else. I guess that's valuable to some extent, but again I wouldn't consider it wise to put much more faith in it than that.
I think the OP agrees. Hopefully this follow on dialogue has made it just a little clearer to other readers. Don't use the "artist rendering" of trees to try to plan altitude with any precision. Just "know they are there" and add another 100 ft on your initial run to be safe (my opinion interjected from painful experience.)

The OP's workflow is very useful with these caveats in mind.
 
FWIW, here's a real-life example I flew yesterday, as part of my own experimentation with these tools.

I used the workflow described to create the initial mission, then loaded the KML file into GE on my PC. There, I "flew" it by running a "tour" on the path. This gave me an idea of what the flight -- including obstacles as GE data has them -- might look like, and where you should maybe bump up an altitude. Here's the simulation played back on GE on my Shield K1:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Now, here's that exact mission in actual flight. The only difference is I had some POIs in the real mission and focused some waypoints on them, so the camera heading changes to stay on these POIs for some waypoints, while in the simulation its the same as "Next Waypoint" set as the mission heading setting.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Features are pretty close, and 3D detail seems rather good too. I'm going to test this out with some progressive changes in altitude, with mission set to Next Waypoint for the heading so that it's like the simulation, and see what the actual error is. I don't plan to get too close -- just enough to get an idea of how good an approximation GE's data is.

Keep in mind that this is photogrammetry data. It's way better in some locations than in others. Most US locales have very good data from multiple high-resolution satellite imaging passes, different angles, TOD, etc. These private commercial imaging satellites are running 24x7, producing updated images and 3D data.

So, I don't know exactly how accurate this stuff is. What I can say is that in my immediate neighborhood it's near spot-on -- the tallest trees are the biggest in GE; the trees around my house are about right, within 30-40 feet or so.

The only way to know if this will work for your situation is to try it, with appropriate caution and safeties.
 
Oh, and that live video is a walking advertisement for ND filters... had a Polar Pro ND16 on when I filmed that. The colors just POP out... that green grass in particular!
 
FWIW, here's a real-life example I flew yesterday, as part of my own experimentation with these tools.

I used the workflow described to create the initial mission, then loaded the KML file into GE on my PC. There, I "flew" it by running a "tour" on the path. This gave me an idea of what the flight -- including obstacles as GE data has them -- might look like, and where you should maybe bump up an altitude. Here's the simulation played back on GE on my Shield K1:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Now, here's that exact mission in actual flight. The only difference is I had some POIs in the real mission and focused some waypoints on them, so the camera heading changes to stay on these POIs for some waypoints, while in the simulation its the same as "Next Waypoint" set as the mission heading setting.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Features are pretty close, and 3D detail seems rather good too. I'm going to test this out with some progressive changes in altitude, with mission set to Next Waypoint for the heading so that it's like the simulation, and see what the actual error is. I don't plan to get too close -- just enough to get an idea of how good an approximation GE's data is.

Keep in mind that this is photogrammetry data. It's way better in some locations than in others. Most US locales have very good data from multiple high-resolution satellite imaging passes, different angles, TOD, etc. These private commercial imaging satellites are running 24x7, producing updated images and 3D data.

So, I don't know exactly how accurate this stuff is. What I can say is that in my immediate neighborhood it's near spot-on -- the tallest trees are the biggest in GE; the trees around my house are about right, within 30-40 feet or so.

The only way to know if this will work for your situation is to try it, with appropriate caution and safeties.

The GE walkthru looks great. The other video, however, appears to be marked private. If you make it unlisted I'd love to view it.
 
Nice stuff dwallers!
This wil really help planning a mission. I also enjoyed watching the preview and the real mission. Maybe you can show them side by side to compare.
For a challenging mission I explore the flight manually and then add waypoints during the flight using the C1 button. Later I will chang the camera orientation. This way I am sure I won't hit for instance a tree like bsartist did. I also learned the hard way. In my case it was a building and I had to buy a new one :cry:
Its a pity that a lot of features of the mission hub (like batch editing) are not available on a PC.
 
Nice stuff dwallers!
This wil really help planning a mission. I also enjoyed watching the preview and the real mission. Maybe you can show them side by side to compare.
For a challenging mission I explore the flight manually and then add waypoints during the flight using the C1 button. Later I will chang the camera orientation. This way I am sure I won't hit for instance a tree like bsartist did. I also learned the hard way. In my case it was a building and I had to buy a new one :cry:
Its a pity that a lot of features of the mission hub (like batch editing) are not available on a PC.

I too would like to see batch editing on the mission hub, then I can plan on the laptop and then fly with the smartphone. iPhone screen too small to plan a mission.
 
  • Like
Reactions: rene van der meer

Recent Posts

Members online

Forum statistics

Threads
143,066
Messages
1,467,352
Members
104,933
Latest member
mactechnic