Litchi - Google Earth Notes

[Avocet]

For those interested in refining the usage of Google Earth imports into Litchi, I just wanted to pass along something I've discovered with the hopes its useful to others. Perhaps some of you may have figured this out already, and I apologize for the redundancy.

There have been several posts and videos in most of the Phantom forums about using the Path tool in GE to take advantage of the GIS terrain data which will automatically provide altitude changes (AGL - above ground level - ready for 107?) over a given path - in our case a flight path for waypoint mission creation.

[We create a path in GE, save the path as a KML file and import into Mission Hub at flylitchi.com.]

Here's what I have discovered:

1. Let's say you create a path with a 10m buffer from the ground and your path is "relatIve to the ground" in GE. If your path STARTS (this will be Waypoint 1) at the lowest point and your next series of paths will realize INCREASES in altitude above the ground, the Litchi mission import will do a nice job of setting the waypoints with increases in altitude for each of the waypoints. Fine.

HOWEVER,

2. If your path STARTS (WP#1) at the HIGHEST point of your mission plan and places path points over terrain that is DECREASING, or terrain that is lower or falling away from the starting point altitude, then, after importing that KML file into Litchi Hub, all of the waypoints altitudes will be what you entered into the starting altitude in your GE path screen. Litchi will show the elevation from starting point as XXm BELOW starting point. The elevation at all Waypoints will remain constant/unchanged if the ground level elevations are less than the ground elevation at WP#1 (mission start).

This is difficult to convey in words - I suggest you try two short paths in GE. The first ascending over rising terrain and the second descending over the same path. Import both of them into the Litchi Hub and see how the hub sets up the waypoint elevations and the elevations from one waypoint to the next.

On the waypoint information screens in Litchi (select an existing waypoint), buried and sitting very quietly under "Altitude" is some dynamic text: "Ground Elevation: 1m (0m below first waypoint)". This string of text will be critical to study if your mission plan descends over lowering terrain.

Sorry to blab on ... this was a moment of important clarity for me. Thought I'd share for those who value their UAV experiences. Way too many folks overlook altitude in their missions and are crashing into terrain or terrain features. Litchi cannot account for anything that rises off the surface of the earth - trees, buildings, neighbors, neighbors friends, etc.

 

[matti]

Hmm. I tried it and the AGL vs ground elevation seemed to be correctly in sync both ways (I used Google Earth Pro and Safari in OS X 10.11, if that matters).

When going up, the AGL increased from 30m to 62m because ground elevation was 32m.

When going down, the AGL decreased from 30m to -2m because ground elevation was -32m.

This was very handy because those calculations were done automatically. With Litchi Mission Hub-only I must always do that error-prone AGL + ground elevation calculation myself to each waypoint (or am I missing something?).

 

[Avocet]

Hmmm ... what I have found has to do with the starting point of your path in GE. If you start your path and create it while ascending, the import into Litchi Hub shows altitude that ascends as you might expect.

If, however you start your path say on top of a hill and make the path down hill, the imported waypoints all stay at your WP#1 altitude which was set in the GE path interface.

Does that make sense?

 

[matti]

I tried this again and it didn't matter whether the path was ascending or descending. In both cases the altitude set in GE varied in the Litchi Mission Hub depending on the ground elevation so the AC was always in the same height from the ground. So it works as expected.

I wish Litchi Mission Hub worked like that, too, without a detour to GE.

I noticed that If I left GE altitude at its 0m default, then Litchi Mission Hub used its default altitude instead.

 

[STAINLESS]

OP's issue can be replicated by leaving altitude "Clamped to the Ground"

 

[GMack]

I made a GIF that shows the issue under the Drone rescue thread where a drone hit a mountain. See this post and item #6 and watch the red arrow: Drone rescue?

AutoPilot is also aware of this Google Earth import mission issue too. Their suggestion was to fly the route and use the "Use current location as a waypoint" marker. They may try and do a side view of the flight to show the proposed mission/flight path (If Google Earth will lie flat!), or show that altitude changing as seen from above in their little moving drone icon during planning to show if the craft is ascending or descending over the route soon enough to clear things under it.

Be careful in planning near tall items with GE. Flight could be risky!

 

[BigAl07]

Is there a video tutorial on how to incorporate GE into Litchi? I love the idea of using this along with Mission Hub but have no clue where to start.

 

[CRF319]

Is there a video tutorial on how to incorporate GE into Litchi? I love the idea of using this along with Mission Hub but have no clue where to start.

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

Accept third party cookies

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

Accept third party cookies

 

[matti]

Is there a video tutorial on how to incorporate GE into Litchi? I love the idea of using this along with Mission Hub but have no clue where to start.

Google Earth path to Litchi Mission Hub:

Google Earth > Add > Path > Left-click a path > Altitude tab > Relative to ground, set desired AGL Altitude for the AC (with 0m Litchi Mission Hub defaults to 30m AGL) > OK
> File > Save > Save Place As... > Kml

Litchi Mission Hub > MISSIONS > Import > Choose File > Import to new mission

Ground elevations are automatically added to the desired AGL.

Drawing paths and polygons - Earth Help

[edit: CRF319 ninja'd me by 2minutes so I deleted duplicate Youtube links]

...I've heard rumors that Litchi has a beta version which makes this detour to Google Earth unnecessary.

 

[GMack]

Is there a video tutorial on how to incorporate GE into Litchi? I love the idea of using this along with Mission Hub but have no clue where to start.

Heed the words at the end of the forest video where he says: "Use with caution!" Flight plan may not be what it appears to be in very tall surroundings, imhe.

Fwiw, AutoPilot's support used the word "Risky" with me due to variables like rate of climb, barometer, wind, bad GE output in planning stage (i.e GIF mission from GE mentioned above that shows clear sailing over the mountain, but obviously it isn't.), air density, faulty initial altitude when turned on, etc. I'm waiting to see how they handle this in an update as one could fly into a mountain side if not careful in planning.

 

[BigAl07]

Thanks gang. Now I'm armed with information and desire to push the limits

 

[matti]

Make sure that there are no unexpected ground elevations between waypoints. You can inspect the whole path in Google Earth by ctrl-clicking the path (in Places at center left) and choose "Show Elevation Profile". Or just move the cursor on the map and check the "elev" figure at lower right.

And do leave some margin for error because I guess Google's ground elevation info might not always be very reliable.

 

[Avocet]

Yes to all of the above. Here, again is the GRAY AREA. Published Phantom 3 Pro/Adv specs show the climb rate to be 5 meters per second climb and 3 m/s descent. This is corporate communication. There are many variables that will make that statement quite inaccurate - wind, heat, humidity, density air, aircraft performance, etc. As such, proceed with extra EXTRA caution and planning.

Some have designed Litchi missions that have sped into obstacles like trees or rising terrain because the craft could not ascend quickly enough to make the assigned altitude arriving at the waypoint. Use interim waypoints and step up your way to altitude in increments if you are unsure of the terrain changes of ascent.

 

[bsartist]

I tried this again and it didn't matter whether the path was ascending or descending. In both cases the altitude set in GE varied in the Litchi Mission Hub depending on the ground elevation so the AC was always in the same height from the ground. So it works as expected.

I wish Litchi Mission Hub worked like that, too, without a detour to GE.

I noticed that If I left GE altitude at its 0m default, then Litchi Mission Hub used its default altitude instead.

Hmm. I tried it and the AGL vs ground elevation seemed to be correctly in sync both ways (I used Google Earth Pro and Safari in OS X 10.11, if that matters).

When going up, the AGL increased from 30m to 62m because ground elevation was 32m.

When going down, the AGL decreased from 30m to -2m because ground elevation was -32m.

This was very handy because those calculations were done automatically. With Litchi Mission Hub-only I must always do that error-prone AGL + ground elevation calculation myself to each waypoint (or am I missing something?).

I am trying this out. All goes well in google earth. When I import the kml into mission hub, all elevations are fixed. They look ok and properly rising in GE. But mission hub doesn't seem to honor them. Any ideas? OSX and Safari.

 

[bsartist]

I am trying this out. All goes well in google earth. When I import the kml into mission hub, all elevations are fixed. They look ok and properly rising in GE. But mission hub doesn't seem to honor them. Any ideas? OSX and Safari.

I peeked into the kml file. Altitude mode says relativeToGround. All waypoints have 30 as their third value. And mission hub is putting them all at 30m high. If I edit the kml file to change one of the elevations and reimport, that waypoint takes the new value. Seems like mission hub is just ignoring the altitude mode. Or GE should be exporting with the elevations already taking into account ground level??

 

[bsartist]

Google Earth path to Litchi Mission Hub:

Google Earth > Add > Path > Left-click a path > Altitude tab > Relative to ground, set desired AGL Altitude for the AC (with 0m Litchi Mission Hub defaults to 30m AGL) > OK
> File > Save > Save Place As... > Kml

Litchi Mission Hub > MISSIONS > Import > Choose File > Import to new mission

Ground elevations are automatically added to the desired AGL.

Drawing paths and polygons - Earth Help

[edit: CRF319 ninja'd me by 2minutes so I deleted duplicate Youtube links]

...I've heard rumors that Litchi has a beta version which makes this detour to Google Earth unnecessary.

Does mission hub understand terrain elevations? Or does it expect each waypoint to already have the AGL in the kml file from Google earth already? I'm pulling my hair out. I do what I'm supposed to do in GE. The "curtain" looks good. It follows terrain. I export to kml. The kml has a relativeToGround altitude mode. Each waypoint is a tuple with the third param being the same value which is what I specified as altitude relative to ground (e.g. 30m). When I import it to mission hub it does NOT set different heights at each waypoint. They are all 30m. It's ignoring relative to ground. If I edit the kml file and change the elevation on one of the waypoints and reimport, mission hub reflects that new elevation for that waypoint. So it seems to be just reading them as waypoint altitudes and plugging them in. No relative to ground being honored. Any thoughts?

 

[The Springs]

I bookmarked this post earlier for future reference .I have now run 6 or 7 WP missions numerous times all planned on GE but haven't noticed anything amiss . .All were set to 33m above the ground and the imported GE path has set the WPs higher or lower to follow the ground .
One rises 70 odd meters over 2.5 km around one of our water tanks and back .Some days It seems to be a lot closer to the ground than 33 m at the hill.
bsartist I notice you had a RTH onto your roof .You should go for the chimney next time (see post where guy does this) Are you still using GE or does your problem persist ?

 

[bsartist]

I bookmarked this post earlier for future reference .I have now run 6 or 7 WP missions numerous times all planned on GE but haven't noticed anything amiss . .All were set to 33m above the ground and the imported GE path has set the WPs higher or lower to follow the ground .
One rises 70 odd meters over 2.5 km around one of our water tanks and back .Some days It seems to be a lot closer to the ground than 33 m at the hill.
bsartist I notice you had a RTH onto your roof .You should go for the chimney next time (see post where guy does this) Are you still using GE or does your problem persist ?

My initial problem of mission hub not honoring terrain input from my GE KML file was due to some browser problem with Safari in my case. I switched to chrome and all is good.

My roof landing was totally unrelated. The end of my mission was over the house with action set to hover at mission end. This was close enough to home point (only about 20 ft away) that the RTH caused it to land straight down and not move over to home point. I failed to take manual control due to faulty thought process. I thought it was disconnected and was trying to get reconnected. But the RC likely had connection.

Chimney land. LOL. I should try to fly it down the chimney. . May lose GPS though.

 

[smiller]

...I've heard rumors that Litchi has a beta version which makes this detour to Google Earth unnecessary.

It's not beta anymore, the 'relative to ground' feature has been released in both Android and iOS versions so you don't need to fuss with Google Earth anymore. But the usual cautions still apply, i.e. be sure to account for things not in the terrain database such as trees or man-made objects, have a sufficient number of waypoints to capture rapid changes in elevation, etc.

 

[bsartist]

It's not beta anymore, the 'relative to ground' feature has been released in both Android and iOS versions so you don't need to fuss with Google Earth anymore. But the usual cautions still apply, i.e. be sure to account for things not in the terrain database such as trees or man-made objects, have a sufficient number of waypoints to capture rapid changes in elevation, etc.

That last point about sufficient waypoints is something you can visualize for yourself when using the GE method and rotating up, down, and around.