Litchi: New terrain-following workflow

[rene van der meer]

Here is another Mavipilots thread working on this topic.

 

[NorthcountySD]

Am I missing something here or did your first waypoint in the mission register a height that was lower then what you indicated in the google Earth bottom left cornor... or is that height in relation to your take off? I watched it a couple times and seems that the elevation where you started the "mission" was 180 ft... but the waypoint at that same point was 131 ft... or is that 131 ft above your starting point assuming you start in the middle of the road... right??? I'm considering using this to go up and over a hill that is 700 - 800 ft high and going to the other side of it that drops back down to about 200 ft elevation... if I keep a constant above the ground level (assuming google earth has the elevation at the top of this hill) it should put my waypoints higher and then back down and it will all be from my starting point... right....?? just confriming.. Thanks.. great video and a great tool to be aware of... thanks for posting

 

[dwallersv]

Yeah, it gets confusing because Litchi references altitudes relative to the takeoff altitude.

What @Member 's converter does is take the difference between the subject waypoint elevation and that of the first waypoint, then adds this to the desired AGL. So, you want to fly 100' AGL, first WP at 1200' (according to the Google Earth database); down-mission, the GE reported elevation at WP4 is 1345'. Litchi would set that WP to 100+145=245' above the ground at WP1, which would be 100' AGL at WP4. Later, at WP15 the elevation is 950'. Litchi would set this to 950-1200+100= -150'.

A path is loaded into GE as a KML file, which is a particular XML formatted file, human readable. A point in this format is expressed as the lat/long and elevation ground-relative. So, to translate an exported Litchi mission in CSV, the process is reversed, with lookups for the ground elevations at the waypoints to add it back, then the elevation at WP1 is subtracted, giving a ground-relative height that GE understands.

 

[dwallersv]

I'm considering using this to go up and over a hill that is 700 - 800 ft high and going to the other side of it that drops back down to about 200 ft elevation... if I keep a constant above the ground level (assuming google earth has the elevation at the top of this hill) it should put my waypoints higher and then back down and it will all be from my starting point... right....?? just confriming.. Thanks.. great video and a great tool to be aware of... thanks for posting

Yeah, that should work. Make sure you put a WP at the top of the hill. Also, you should testrun the mission first to make sure there aren't any anomalies in the GE data that set a bad waypoint altitude. It's one of the reasons exporting and visualizing the path in GE is so helpful.

 

[IzzyP4]

Great info... works well flying around uneven terrain. I hope you can still visually see your SUAS at all times (I doubt it). Please be safe and thanks!

 

[jivago]

We want to design a flight path in 100m AGL and do calculation for all waypoints according to altitude of first waypoint(for example first wp at 1000m AMSL), it's very clear and can do without any doubt.

Assume that when we go to field and ready to take off, place drone on land with 1500m AMSL . In this situation drone will go to 100m based on take off land. Therefore when we reach to first waypoint the drone is at 1600m AMSL that mean 600m AGL and it's not suitable for Ariel Photogrammetry.

Is there any way to solve this problem?

AMSL : above mean sea level
AGL : above ground level

 

[bsartist]

We want to design a flight path in 100m AGL and do calculation for all waypoints according to altitude of first waypoint(for example first wp at 1000m AMSL), it's very clear and can do without any doubt.

Assume that when we go to field and ready to take off, place drone on land with 1500m AMSL . In this situation drone will go to 100m based on take off land. Therefore when we reach to first waypoint the drone is at 1600m AMSL that mean 600m AGL and it's not suitable for Ariel Photogrammetry.

Is there any way to solve this problem?

AMSL : above mean sea level
AGL : above ground level

Are you saying that the terrain drops DOWN by 500m at the first waypoint such that the land is 500m below your takeoff point?

 

[jivago]

Are you saying that the terrain drops DOWN by 500m at the first waypoint such that the land is 500m below your takeoff point?

This is an example to exaggerating situation. In real situation the maximum difference is about 100m.
The point in my question is that Litchi can update waypoints elevation base on new altitude of take off point?
Or I have to calculate difference between design altitude and actual altitude of take off point and add it to all waypoints in batch mode?

 

[bsartist]

Ok. Yes. You can do this with Litchi. But only in the smartphone/tablet app. Not on the browser based mission hub. Here is how ...

You can tell Litchi to calculate the altitude of each waypoint AGL. Open the mission in the smart phone or tablet app. You can then do a batch edit (I’ll leave this as an exercise to the reader) and select all waypoints. Then set the altitude to how ever many meters you want above ground level. Then specify RELATIVE TO GROUND. All the waypoint elevations will recalculate relative to ground. But will display as relative to takeoff point? Understood? That’s an important point.

Most importantly: drop many waypoints so Litchi has many opportunities to calculate following the terrain. If you put them too far apart it will doa straight line between the two (horizontally AND vertically) which means a hill can pop up in between and Litchi will not program in the rise.

Also obviously know that above ground does NOT mean above trees or other obstructions.