DJI Mavic, Air and Mini Drones
Friendly, Helpful & Knowledgeable Community
Join Us Now

Virtual Litchi Mission

Yes, this is very long thread with information "sprinkled" in. And, yes I very much appreciate Namirda's help as I hope was clear from my posts. You know what would reduce this thread to a few posts- DOCUMENTATION.

44 pages to find out that "WP actions are ignored in curved mode"? Really? Litchi is an amazing product but there are many areas where the definitions and documentation is vague or non-existent.

Check the first paragraph under “Waypoint Actions” right next to the highlighted “important” notation where it says “Waypoint actions are ignored when the mission "Path Mode" is "Curved Turns" as the aircraft will not stop at waypoints”

I’ve actually rarely been unable to find what information I need by reading the “help” section on the Litchi online home.

Granted, it’s great to have this community available to ask fellow users about their experiences but that said, when I want to know something about a product I’ve found that it probably pays to check the product online documentation first and the associated enthusiast forums after that.

Regards
Ari
 
Last edited:

Check the first paragraph under “Waypoint Actions” right next to the highlighted “important” notation where it says “Waypoint actions are ignored when the mission "Path Mode" is "Curved Turns" as the aircraft will not stop at waypoints”

I’ve actually rarely been unable to find what information I need by reading the “help” section on the Litchi online home.

Granted, it’s great to have this community available to ask fellow users about their experiences but that said, when I want to know something about a product I’ve found that it probably pays to check the product online documentation first and the associated enthusiast forums after that.

Regards
Ari
Thank you. I see it now. My apologies.
 
  • Like
Reactions: Prismatic
Resolving VLM's "Excessive Altitude Change" warnings
without trial-and-error


TLDR: I made an Excel spreadsheet to model and optimize the change(s) required to a Litchi leg that's too steep for your bird. Works for the same DJI consumer drones as VLM. Available from DropBox on this link:
I'll note that you really do need a "real" Excel to get the most out of the Vertical Speed Analyzer (VSA). The "Goal Seek" feature is not currently part of "Excel for the Web", and "Google Sheets" doesn't do the VSA at all well.


What It's For

Every drone has two "vertical speed limits" regarding how fast it can climb or descend, and the two are often different. It's easy to accidentally create a Litchi mission leg that's too steep for your drone to climb (or descend), at least to do it at the speed you specified.

Users of VLM know the drill:

"Warning - Excessive Altitude Change for leg 3".​

1612579597783.png

To fix this, you must change one or more of the four parameters that define the vertical speed of the leg in question:
  • Flight speed
  • Starting elevation
  • Ending elevation
  • Leg length
Usually one of these has more flexibility than the others in the context of a particular mission; speed is often a good choice, but not always. The real stumper is figuring out how to resolve the problem without over-correcting. Finding the optimal solution--one that best works for your intent with the mission--can be a frustrating trial-and-error nightmare.

The Vertical Speed Analyzer spreadsheet lets you quickly zero in on exactly how much to change any of those four parameters to clear that warning with the least effect to your original plan.

The VSA works for many DJI consumer drones, including a couple that are, at this writing, not yet supported in Litchi or VLM:
In the example below, I'll use the Mavic Air (original), which is kind of a dog in its Z-axis performance. Maybe that's why I went to the effort to make the VSA? ?

How It Works​

Let's say we plan a mission with one leg that runs 600 ft at full speed (18 mph), dropping from 50 ft. down to -200 ft into a canyon. Oops! VLM throws the "Excessive Altitude Change" warning on it. That's when you turn to the VSA.

After setting the drone model and units, we enter the four leg parameters. The spreadsheet flags the Vertical Speed in red, agreeing with VLM that the leg is too steep to fly. And it's pretty bad, requiring a descent of -11 ft/s when the drone can only do -4.92 ft/s:

1612709579448.png

We need a flight speed that makes the drone descend as fast as it can, but not faster. Excel's "Goal Seek" function is the tool for that. "Goal Seek" is under "What-if Analysis" on the "Data" ribbon in Excel. The "Valid Sv Range" field in yellow provides your drone's limiting values.

We'll ask Excel to figure out how to make Cell J16 (the "Vertical Speed (Sv)") to the drone's maximum descent of -4.96 ft/s by twiddling with the
"Speed" (Cell C16, or $C$16, doesn't matter), as shown here:

1612709715510.png

When we click "OK" on the Goal Seek ... hey presto! ... turns out that if we fly that leg at 8mph instead of 18mph, the MA can manage it. Note that the "Vertical Speed (Sv)" field is green when the Sv is within the drone's range; it's green now because the drone can fly the leg at the new speed:

1612709776221.png

But that's too dang slow, and takes too dang long! Instead, let's find an End Altitude that we could reach at 12mph, which is as slow as we decide we want to go here. We'll set up Goal Seek the same as before, only this time we ask Excel to change End Altitude (E16) instead of Speed (C16):

1612710442100.png

And below is our answer: instead of the original--and impossible--plan to fly18mph and drop 250 ft on this leg, we'll do it at 12mph (taking an extra 11 seconds), and drop only 168 ft:

1612710562478.png

As you see, the VSA lets you fiddle with any of the parameters to find the optimal alternative without blind trial-and-error!

Bits and Bobs of Information​

  • Use the drop-down lists to select your drone and the units you want to use: 1612714426004.png
  • The analyzer works for both ascending and descending legs (where the Sv is negative). The associated speed limits are often different, as expressed in the "Valid Sv Range" field. (Tip: when using "Goal Seek", don't forget the minus-sign on a descending target value, say -9.84, because if you do forget it Excel will just run away madly down the street.)
  • You can change the drone-model or the measurement-standard any time.
    • All labels, Sv ranges, internal computations and color-flag criteria reflect your choices.
    • Existing input values are not converted: what was, say, 25 mph is now considered 25 km/h. You have to manually change the input parameters.
  • Rarely, you'll see a valid Sv flagged red; this happens when the actual value is very slightly out-of-bounds, but gets rounded for display to a "valid" value. You should take the cue from the flag color : Red is Never Good.
  • If you set waypoint elevations "Above Ground" in Litchi, you may find that the spreadsheet gives results that still trigger an "Excessive Altitude Change" warning. That's because of differences in the digital elevation models between Litchi and VLM. The solution is to push the term you optimized on (say, "Speed") a bit farther in the "greener" direction. The spreadsheet gets you very close, so you won't need to push it very far.
  • You'll be flagged if the basic "Speed" value is set too fast for your drone. This is unusual, and only happens if you maximize your Sv by using goal-seeking to max-out your "Speed" on a leg that's already well within the capability of your drone.
  • You'll be dope-slapped if the "Rise/Fall" value exceeds the "Length" of the leg. The reason for that is left as a mental exercise. ?
  • I hope you like the Vertical Speed Analyzer, I really do, but I'm offering it as-is : no guarantees or warranties or attestations of suiti-freakin-bility, OK? It works for me, I expect it will work for you, but with all the potential variables, YMMV.
  • Also, I'm not an Excel tutor, so keep that in mind, and I'm not planning to offer upgrades or support.
  • That said, most of the background drone parameters were taken from VLM. They should be correct, but if not, let me know in a PM; I can change the spreadsheet, or tell you how to.
This tool definitely makes my Litchi life easier, as I often plot Mavic Air missions in steep terrain where a failure to climb as planned could have a bad ending. The trial-and-error was killing me!
 
Last edited:
  • Like
Reactions: wywh and Facherty
I have a very simple waypoint mission I created in VLM, however I seem to have a major discrepancy with the elevations compared to Google Earth. To simplify the problem there is an start point WP1 and an endpoint WP2. My settings are set to USE ONLINE ELEVATION. Both WP's are set to 60m above ground. When I click on WP 1 it says the ground elevation is 1053, however the Google Earth elevation is 1037. Clicking on WP2 it shows a ground elevation of 1263, 210m above WP1. The Google Earth elevation is 1275. When I export the mission to Google Earth everything looks great, however when I flew the mission the drone almost flew into the tops of 30m. trees at WP2. I reviewed the flight data and the drone flew to an elevation of 1306, should have been 1335 according to Google Earth.
I thought it was a problem with the API so loaded my own and it was the same.
Could someone import the attached kml file into Google Earth and check the ground elevations vs. VLM (clicking on the Waypoints to confirm?
 

Attachments

  • Coffeys Climb High Point.zip
    2.5 KB · Views: 3
It all looks very sensible to me:
1613687088171.png
You're at 60m relative to the ground, in some hills that are about a kilometre above mean sea level. Seems about right when you're in the Rockies...

Theoretically, it would take 2m43s to fly this mission, but remember that GoogleEarth doesn't know what speeds (especially vertically) your aircraft is capable of.

Personally, I would also program the return journey...
 
Thanks Facherty for looking into this. This flight was not my normal routine as I almost always end the mission close to where I started.
I get the same results in Google Earth as you have shown. I wonder if you could do me a favor and import the .kml file into VLM or Mission Hub and click on WP1 with ONLINE ELEVATION on in the Settings. See what you get for a ground elevation in the WP info box. It should be 1037, however I get 1053 in VLM.
 
I imported the .kml file into mission hub, and it produced poor data - the number of waypoints had increased, and the heights were wrong.
screenshot-2021-02-18-at-23-09-47-jpg.124052


However, the .KML file is only VLM's way of communicating with GoogleEarth. If you want me to look at your actual mission, the way to do that is to untick the "private" box:

1613690813914.png

and post a reference to the mission.
 

Attachments

  • Screenshot 2021-02-18 at 23.09.47.jpg
    Screenshot 2021-02-18 at 23.09.47.jpg
    104.3 KB · Views: 121
Thanks Facherty for your great help.
As you have suggested I have unchecked the private box.
Here is the reference:
WP 1 ground in Mission Hub = 1053.2 in WP info box. Google Earth = 1037 (1097-60)
WP 2 ground in Mission Hub = 1263.9 in WP info box. Google Earth = 1273 (1333-60)
When I export it from VLM to Google Earth everything looks good and I should be flying to WP 2 to an altitude of 1333, however during the actual flight it flew to 1308 so it seems VLM or Mission Hub isn't extracting the Google Map API elevations correctly.
 
I looked at the mission again, and have to agree that it is difficult to resolve the discrepancy.

GoogleEarth suggests the mission will start at 60m in the air, from a point that is itself 1037m above sea level:
1613693312639.png
Yet Litchi Mission Hub suggests that it will start at 60m above a ground elevation of 1053.2m:
1613693486811.png

It may be a real discrepancy between two sources of data (one used by LItchi, one by Google), and I don't have enough knowledge about how any of these databases are developed.

I can only add that I use Litchi nearly all the time, and in four countries, and have never come across this discrepancy before.

Sorry I can't help.
 
Thanks again Facherty.
Maybe the developer of VLM can chime in on this problem. It seems like VLM is not using the Google Map Elevation API.
I tried it with and without my Google Map API key and come up with the same WP1 ground elevation of 1053.2 In Mission Hub and VLM. Google Earth is correct at 1037 so I think it is defaulting to some world wide dem model.
 
Thanks again Facherty.
Maybe the developer of VLM can chime in on this problem. It seems like VLM is not using the Google Map Elevation API.
I tried it with and without my Google Map API key and come up with the same WP1 ground elevation of 1053.2 In Mission Hub and VLM. Google Earth is correct at 1037 so I think it is defaulting to some world wide dem model.
This may be of interest, from personal correspondence with the VLM developer:
VLM gets ground elevations for all WPs and POIs from Google - I believe that Litchi has a different source for their data because I have noticed that they are often different by a few metres.

... <snip some stuff specific to the reason we were conversing> ...

You could check if this is the case by switching on the verbose output in the VLM Activity Log and comparing the Abs Alt for your two waypoints as calculated by VLM with those shown in the Mission Hub.
 
This may be of interest, from personal correspondence with the VLM developer:
Thanks Prismatic on that tip to turn Verbose On. I checked it out and sure enough VLM is correctly using the Google Elevation API as the elevations of WP1 and WP2 are correct. The problem seems to be in Mission Hub as the elevations of the WP's don't match. From the log, the difference in elevation between WP2-WP1 = (1333-1097) = 236M. From the WP dialog boxes in Mission Hub (VLM) the difference in elevation between WP2-WP1 = (1263.9-1053.2) = 210.7. When I flew the mission it used the latter change in elevation and I almost flew into the tops of some 30m. trees. I was expecting to be 60m. above the ground at WP2.
I am not too familiar with the programming going on in VLM but from what I understand Litchi Mission Hub is in an insert in Virtual Litchi Mission so maybe that is why there are discrepancies??

Here is a portion of the log file when I Export as CSV

8:22:53 AM Parameters for Raw WayPoints
WP Distance(m) Speed(km/h) Abs Alt(m) Alt Ref Heading GTilt
01 2152.4 47.5 01097 RTG 333 00
02 0000.0 23.0 01333 RTG 339 00

From the dialog boxes in Mission Hub (VLM)
WP1 Ground Elevation: 1053.2m (0m below first waypoint)
WP2 Ground Elevation: 1263.9m (210.7m above first waypoint)

WP1 is at the takeoff (Home) point.


A huge thank you to everyone contributing to this forum. The shared knowledge here is incredible!
 
  • Like
Reactions: Prismatic
Thanks Prismatic on that tip to turn Verbose On. I checked it out and sure enough VLM is correctly using the Google Elevation API as the elevations of WP1 and WP2 are correct. The problem seems to be in Mission Hub as the elevations of the WP's don't match. From the log, the difference in elevation between WP2-WP1 = (1333-1097) = 236M. From the WP dialog boxes in Mission Hub (VLM) the difference in elevation between WP2-WP1 = (1263.9-1053.2) = 210.7. When I flew the mission it used the latter change in elevation and I almost flew into the tops of some 30m. trees. I was expecting to be 60m. above the ground at WP2.
I am not too familiar with the programming going on in VLM but from what I understand Litchi Mission Hub is in an insert in Virtual Litchi Mission so maybe that is why there are discrepancies??

Here is a portion of the log file when I Export as CSV

8:22:53 AM Parameters for Raw WayPoints
WP Distance(m) Speed(km/h) Abs Alt(m) Alt Ref Heading GTilt
01 2152.4 47.5 01097 RTG 333 00
02 0000.0 23.0 01333 RTG 339 00

From the dialog boxes in Mission Hub (VLM)
WP1 Ground Elevation: 1053.2m (0m below first waypoint)
WP2 Ground Elevation: 1263.9m (210.7m above first waypoint)

WP1 is at the takeoff (Home) point.


A huge thank you to everyone contributing to this forum. The shared knowledge here is incredible!
 
Just to clarify my last post. The Google Earth elevations in the log file for WP1 and WP2 both 60m. above ground.

I see you haven't posted much. FYI, you can edit or delete your entries for a day or so. Can help reduce clutter. ?
 
Thanks Prismatic on that tip to turn Verbose On. I checked it out and sure enough VLM is correctly using the Google Elevation API as the elevations of WP1 and WP2 are correct. The problem seems to be in Mission Hub as the elevations of the WP's don't match. From the log, the difference in elevation between WP2-WP1 = (1333-1097) = 236M. From the WP dialog boxes in Mission Hub (VLM) the difference in elevation between WP2-WP1 = (1263.9-1053.2) = 210.7. When I flew the mission it used the latter change in elevation and I almost flew into the tops of some 30m. trees. I was expecting to be 60m. above the ground at WP2.
I am not too familiar with the programming going on in VLM but from what I understand Litchi Mission Hub is in an insert in Virtual Litchi Mission so maybe that is why there are discrepancies??

Here is a portion of the log file when I Export as CSV

8:22:53 AM Parameters for Raw WayPoints
WP Distance(m) Speed(km/h) Abs Alt(m) Alt Ref Heading GTilt
01 2152.4 47.5 01097 RTG 333 00
02 0000.0 23.0 01333 RTG 339 00

From the dialog boxes in Mission Hub (VLM)
WP1 Ground Elevation: 1053.2m (0m below first waypoint)
WP2 Ground Elevation: 1263.9m (210.7m above first waypoint)

WP1 is at the takeoff (Home) point.


A huge thank you to everyone contributing to this forum. The shared knowledge here is incredible!
Really, you know, the suite of boggling amazing technologies that get you this ? close ultimately do have their limits. As the VLM author noted, "I believe that Litchi has a different source for their data ...".

Like VLM, I'm sure Litchi is also using its elevation data correctly, too. It's just that the data in the two models is not identical. It's to be expected. As no two clocks agree, no two geographical data models agree.

I'm sure Litchi has good reasons for using their data source, and I know @namirda has good reasons to tap into Google Earth. The models collide a little bit when you use VLM, because its knowledge of the world differs slightly from Litchi's.

As a rule, it's best to treat your Virtual Mission as an idealized version of the actual flight. In practice the bird will rarely perfectly track that ideal. There are so many variables at play! If you try that same flight tomorrow, you may well hit those trees.

I wrote a bit about this up the thread a ways. Until you fly a slow test mission, you'd best give yourself a good cushion of clearance. I've been lucky sometimes, but I wouldn't do it again!
 
Last edited:
Just come across this thread and its a mine of information. Forgive me if I've missed the answer to this question amongst the 45 pages of info this thread holds:
What is the latest version of VLM? Is there a website link that holds the latest version for download and is there a sticky I might have missed that already gives this information. Thanks for reading and thanks to the developer and all contributors.
 

DJI Drone Deals

New Threads

Forum statistics

Threads
130,994
Messages
1,558,710
Members
159,982
Latest member
PetefromNZ