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

Virtual Litchi Mission

namirda

Well-Known Member
Joined
Oct 22, 2017
Messages
344
Reactions
318
Location
New Zealand
Download latest version here :
Virtual Litchi Mission V2.8.4

---------------------------------------------------------------------------------------------------------------------

VLM Frequently Asked Questions

Problems Getting Started


Q) VLM does not start properly – startup sound and splash screen and then nothing!
A) Restart VLM while pressing CTRL and you will be given the option to reset VLM to initial conditions

Q) The Litchi Mission Hub panel in VLM is shifted from its expected location?
A) Try running in compatibility mode by right clicking on the VLM icon and choose

Compatibility tab -> Change High DPI Settings -> High DPI Scaling Override.

Q) VLM runs but Google Earth does not open?
A) Check that Google Earth Pro is properly installed and that kml files are properly associated with Google Earth. You can check this by double clicking on a kml file and confirming that Google Earth opens.

Q) VLM crashes on startup complaining about 'CefSharp.Core.dll' or one of its dependencies.
A) Check that the following are properly installed on your system:
Microsoft Visual C++ 2015 - 2022 Redistributable (x64)
Microsoft .NET Framework 4.6

Q) Can I run VLM on a Mac?
A) VLM is a windows only application. You have two options to run on a Mac or Linux machine

1) Apparently VLM runs well in a Virtual Machine such as Parallels​
2) User Bazuchan has implemented a version of VLM which runs as an extension to the browser. Yet another Virtual Litchi Mission (Google Chrome Extension)
Q) I get a message about my quota being exceeded - what's up?
A) VLM uses the Google Elevation API to get its elevation information using an API key which is shared between all users. If usage of this key exceeds a certain daily limit then you will need to either wait until the next day when the quota is reset - or else get your own key from Google. You can open an account with Google at https://console. cloud.google.coms. Google will require you to enter your credit card details but unless your usage of VLM exceeds 40,000 hits in a month you should not be charged anything. You can enter your own API key into VLM in the Google Tab of VLM Settings.

Problems with the Virtual Mission

Q) The elevations of my virtual mission look wrong
A) Check the following:
1) The exaggeration factor in Google Earth should be set to 1.0​
2) Check that the VLM Home Point Reference Altitude is appropriate for your mission. If you are unsure then use the default setting of WP1 and put the first WP of your mission directly above the Home Point (Take Off Point)​
3) If there are still small elevation differences then compare the elevation of the Home Point in both Google Earth and Google Maps (ie Litchi). If they are significantly different then set the VLM HP altitude to the elevation measured by Google Earth.​

Q) The VLM Mission is a poor match with the real mission
A) Check the following:
1) Check that you have specified a heading and gimbal angle for every waypoint of your mission. If any of these values are undefined you will see an orange warning in the VLM Activity Log.​
2) Check that your mission does not exceed the capabilities of your drone. Any such issues will be highlighted in orange in the VLM Activity Log and should be addressed.​
3) Check that the Google Earth viewing window is set to 16:9 to match your camera settings.​
4) Check that the drone type is set correctly in VLM and that the FOV setting is correct.​
5) If the VLM mission is jerky then try increasing the number of smoothing points.​

If you still have questions or problems then please ask in this thread.
---------------------------------------------------------------------------------------------------------------------------

Original post dated 26/12/2017:

In this thread started almost a year ago - https://mavicpilots.com/threads/how-hard-would-it-be-to-simulate-litchi-missions-in-google-earth.7864, user “torqum” introduced the intriguing idea ‘flying’ a Litchi mission virtually in Google Earth to see how it looks from the perspective specified in Litchi. It was a very appealing concept – to fly a mission anywhere in the world without getting out of your armchair!

In that thread, user "JTS" submitted a conversion program which apparently worked for some folks but not for others – and not for me so I decided to write my own.

The utility is called Virtual Litchi Mission (VLM) – it is a standalone executable and does not need any installation. It runs on my Win10 x64 machine but should run on x86 machines as well. On older versions of windows your mileage may vary…..

VLM sets a watch on a user specified Downloads folder and will automatically read any csv file created in this folder. When Litchi Mission Hub writes a csv file to this folder, VLM will convert it to a “Tour” in Google Earth including the complete camera orientation and gimbal settings which were specified in Litchi.

The resulting Virtual Mission can then be flown in Google Earth and should show results very similar to that obtained when the mission is flown with your drone. I have tried it out on quite a few of the public missions available in Litchi Mission Hub and in areas where the satellite imagery is good, the results are impressive. Google Earth is so amazing!!

I have found VLM useful to check that there are no erroneous parameters in my Litchi Mission and to check that the camera ‘sees’ what I want it to see. It has saved me several wasted flights with my mavic.

A full User Guide is available in VLM under the Help Tab

Please give VLM a try and let me have any feedback, comments etc. I hope you find it useful.

Thanks

N
 
Last edited:
Thanks buddy! You write this in Visual Studio?
As par for the course the watcher is jumping the gun.
Litchi isn't fast enough on the export so opening fails.
I've had to use a delay before to make sure the system has it's hands off the file before trying to open it.
The fix is to save elsewhere and drag and drop to watched folder.

Example:



12/25/2017 5:38:16 PM - New CSV file detected G:\Media\Missions\National Quarry 1.csv

12/25/2017 5:38:16 PM - Error Opening File for read .. Aborting
12/25/2017 5:38:16 PM - Could not find file 'G:\Media\Missions\National Quarry 1.csv'.
12/25/2017 5:38:21 PM - File G:\Media\Missions\National Quarry 1.csv deleted

12/25/2017 5:38:21 PM - New CSV file detected G:\Media\Missions\National Quarry 1.csv

12/25/2017 5:38:21 PM - Error Opening File for read .. Aborting
12/25/2017 5:38:21 PM - Could not find file 'G:\Media\Missions\National Quarry 1.csv'.
12/25/2017 5:39:11 PM - Failed to delete File G:\Media\Missions\National Quarry 1.csv after 10 attempts


Save and drag/drop:


12/25/2017 5:29:53 PM - Watch Folder changed to G:\Media\Missions

12/25/2017 5:30:20 PM - New CSV file detected G:\Media\Missions\Bighouse1.csv
12/25/2017 5:30:20 PM - Altitudes in this csv file are in Feet
12/25/2017 5:30:20 PM - CSV File OK - 33 Waypoints Processed
12/25/2017 5:30:20 PM - Total Mission Distance = 2.366 miles
12/25/2017 5:30:20 PM - Mission sent to Google Earth
12/25/2017 5:30:20 PM - File G:\Media\Missions\Bighouse1.csv deleted

12/25/2017 5:35:37 PM - New CSV file detected G:\Media\Missions\National Quarry 1.csv
12/25/2017 5:35:37 PM - Altitudes in this csv file are in Feet
12/25/2017 5:35:37 PM - CSV File OK - 13 Waypoints Processed
12/25/2017 5:35:37 PM - Total Mission Distance = 2.570 miles
12/25/2017 5:35:37 PM - Mission sent to Google Earth
12/25/2017 5:35:37 PM - File G:\Media\Missions\National Quarry 1.csv deleted
 
Last edited:
Sorry Brojon - I never dreamed that anybody could possibly have slower download speed than I do!!

Try V1.0.1 - should be better.
lol - I dunno if that's the case as I have 60 mbps download. The new version functions perfectly - thanks.
I have a couple of questions on height.
I have a simple mission that I was playing with. All points have a height, orientation and gimbal angle specified.
I export as CSV and when it comes into Google Earth it's underground. I tried setting the home point in the app to the initial height to no avail.
I increased the height and it was still partially underground. It seems to require setting home point to 230 ft to get all points above ground!
The result is the entire mission is far far higher than it should be after the home point adjustment.
If I export the 3d KML and import it it looks fine.
Can you provide further explanation of the home point and how to set it properly - or what changes need to be made to the Litchi mission?
Also I noticed some weird yawing in the mission where it was a simple 180 turnaround with the craft orientation set to heading.
It did an opposite rotation where I would have expected a shortest point.
Not a show stopper and most likely some quirk of GE but if you have an explanation I'm all ears :) I'll have to actually fly it to see what really happens.
Thx! This rocks being able to do a simulated flight! I've attached the files for the mission I was discussing.
 

Attachments

  • mission.zip
    2.4 KB · Views: 107
  • Like
Reactions: Hauptmann
Regarding your input parameters, I think of the "Altitude of the Home Point" as being zero. Everything from there is relative to that.
I don't think that's what you are looking for in the VLM.
Are you looking for the MSL or actual ground elevation of where you are taking off?
 
Regarding your input parameters, I think of the "Altitude of the Home Point" as being zero. Everything from there is relative to that.
I don't think that's what you are looking for in the VLM.
Are you looking for the MSL or actual ground elevation of where you are taking off?
As stated the exported KML shows correctly in GE. The converted CSV path is below the surface.
This is not the case with all the missions I tested - but quite a few.
In summation I would expect the converted CSV with associated virtual flight path should be exactly the same.
 
  • Like
Reactions: Hauptmann
@Brojon.

Sorry again. Indeed there is a problem with altitudes for you guys working in imperial units. I had not realised that Google Earth always requires altitudes to be input in metres even if you specify imperial units! Go figure!

I have made yet another update to VLM to handle this. You should use the same units in VLM as you do in Litchi. If you choose imperial units then VLM will convert the altitudes to metres to keep Google Earth happy!

In the case of your "School Tower Loop" mission, the area around waypoint 1 where I suppose you plan to take off (your Home Point) has an altitude of about 800 feet according to Google Earth. You should therefore put 800 into the Altitude Home Point box in VLM. Hopefully that will now match the Litchi 3DPath.

With regard to the 'weird yawing' that you see on your mission, I think this is because Litchi and Google handle the interpolation between waypoints differently. Between your waypoints 5-6, Litchi rotates the Heading clockwise because that is the shortest angular change between the two points. Google seems to prefer smoothness and says that since you are rotating anticlockwise between waypoints 2-3, waypoints 3-4 and also between 4-5, it should continue to do so between wayponts 5-6. I don't think it is possible to change this behaviour.

Google recommend a maximum heading difference of 30 degrees between waypoints for tours in Google Earth. ( see Placing views for a tour - KMLtouring) I have tried adding a couple of extra waypoints between 5 and 6 and it works much better.

Hope this helps.
 

Attachments

  • Virtual Litchi Mission V1.0.2.zip
    44.1 KB · Views: 324
Regarding your input parameters, I think of the "Altitude of the Home Point" as being zero. Everything from there is relative to that.
I don't think that's what you are looking for in the VLM.
Are you looking for the MSL or actual ground elevation of where you are taking off?

When you fly your drone, the altitudes are always relative to the altitude of the Home-Point (which is usually the Take-Off point). Similarly, the altitude of the waypoints in the Litchi Mission Hub are with respect to your Home Point.

However, if you plan your mission on Litchi Mission Hub before you go out to fly, the Home Point position is undefined and therefore so is its altitude. We need to tell Google Earth the reference altitude for the values coming from Litchi and that is what is meant by the Home Point Altitude.

The value that you need to provide to VLM is the absolute altitude of your proposed Home Point relative to MSL. This is easily found from Google Earth by moving the cursor over your proposed Home Point. The altitudes from GE may not always be precise but thankfully it doesn't matter if you crash your virtual drone!!.....

Hope this helps...
 
Last edited:
  • Like
Reactions: Steve Amerson
@Brojon.

Sorry again. Indeed there is a problem with altitudes for you guys working in imperial units. I had not realised that Google Earth always requires altitudes to be input in metres even if you specify imperial units! Go figure!

I have made yet another update to VLM to handle this. You should use the same units in VLM as you do in Litchi. If you choose imperial units then VLM will convert the altitudes to metres to keep Google Earth happy!

In the case of your "School Tower Loop" mission, the area around waypoint 1 where I suppose you plan to take off (your Home Point) has an altitude of about 800 feet according to Google Earth. You should therefore put 800 into the Altitude Home Point box in VLM. Hopefully that will now match the Litchi 3DPath.

With regard to the 'weird yawing' that you see on your mission, I think this is because Litchi and Google handle the interpolation between waypoints differently. Between your waypoints 5-6, Litchi rotates the Heading clockwise because that is the shortest angular change between the two points. Google seems to prefer smoothness and says that since you are rotating anticlockwise between waypoints 2-3, waypoints 3-4 and also between 4-5, it should continue to do so between wayponts 5-6. I don't think it is possible to change this behaviour.

Google recommend a maximum heading difference of 30 degrees between waypoints for tours in Google Earth. ( see Placing views for a tour - KMLtouring) I have tried adding a couple of extra waypoints between 5 and 6 and it works much better.

Hope this helps.
Me neither although it should have occurred to me since I knew the older convert Litchi CSV web app had that issue. The cure there is simply do the mission in Imperial, save, then change to metric before exporting. Likely the same could have been done here.
So you say that the home point needs to be set to your actual altitude? Then why - in that mission I uploaded - is 140 ft sufficient to get it above ground when the actual "height" relative to sea level is 750+ ft?
 
Just ran it - perfect!
Absolutely perfect!
Thanks so much for a tool that will *definitely* get a lot of use!
 
Me neither although it should have occurred to me since I knew the older convert Litchi CSV web app had that issue. The cure there is simply do the mission in Imperial, save, then change to metric before exporting. Likely the same could have been done here.
So you say that the home point needs to be set to your actual altitude? Then why - in that mission I uploaded - is 140 ft sufficient to get it above ground when the actual "height" relative to sea level is 750+ ft?

I think you must have been using the earlier version V1.0.1 - try V1.0.2 and I think you will find that a Home Point Altitude of 800 feet works well.
 
I think you must have been using the earlier version V1.0.1 - try V1.0.2 and I think you will find that a Home Point Altitude of 800 feet works well.
No - I did use 1.02 and it worked perfectly as stated. I was referring to a web based conversion script that converted to KML.
No need for it now that Litchi mission hub exports directly to KML 3D.
It is curious how it does not seem necessary to input the terrain height at the starting point with the KML exported by Litchi Mission hub.
Any way to use that as a basis for the virtual mission instead of the CSV?

Litchi CSV to KML tool
 
Interesting. The 3D KML file has the altitude set to relative to ground. The coordinates appear to have the normal long and lat along with a 3rd part which is specified waypoint altitude in meters.

<LineString>
<extrude>1</extrude>
<tessellate>1</tessellate>
<altitudeMode>relativeToGround</altitudeMode>
<coordinates>-97.71805107593536,30.419261564140832,6.096074128261392 -97.71766998851751,30.41964348345308,33.70150515641316 -97.71756985863107,30.419754317904147,40.99108766121435 -97.71748383195518,30.419871992130563,48.2327880859375 -97.7174119084898,30.419996506132332,48.09590148925781 -97.71735408823497,30.420127859909446,48.37754821777341 -97.7169855359715,30.421106228862012,51.718017578125 -97.71695735923674,30.42120831686107,51.5648498535156 -97.7169499101089,30.421309961928937,51.71185302734372 -97.71696318858801,30.421411164065603,52.12828063964841 -97.7169971946741,30.421511923271066,52.6195373535156 -97.71706981624925,30.42167647584874,52.48153686523432 -97.71712279720259,30.42175882554869,52.67294311523432 -97.71719097376945,30.42180020895342,52.9319152832031 -97.71727434594987,30.42180062606294,53.0426483154296 -97.71737291374382,30.42176007687724,53.1061248779296 -97.7175262217184,30.421671942997957,52.0460205078125 -97.7176248762043,30.42160918965204,51.900405883789006 -97.7177151683178,30.42153916674409,52.029296875 -97.7177970980589,30.4214618742741,51.4884338378906 -97.71787066542765,30.42137731224208,50.33480834960932 -97.72016523670266,30.418460567759436,42.56298828125 -97.7202031775663,30.41839619082884,42.9396057128906 -97.72021565627813,30.41833188826384,43.4654998779296 -97.72020267283824,30.418267660064426,43.89888000488281 -97.72016422724653,30.418203506230608,44.262741088867216 -97.720084619283,30.41810376916271,44.67147827148432 -97.7200286205848,30.418046637785555,44.682022094726506 -97.71996297734717,30.418003477098075,44.25265502929682 -97.7198876895701,30.417974287100254,44.92718505859372 -97.71980275725355,30.417959067792104,45.3096923828125 -97.71965954298236,30.417945929330134,45.72201538085932 -97.7195718994056,30.417945463941845,45.99119567871091 -97.71949050052643,30.41796072171934,45.588150024414006 -97.71941534634482,30.41799170266263,45.23895263671872 -97.71934643686075,30.418038406771707,45.253707885742216 -97.71793305873871,30.419210678446177,47.2521209716796</coordinates>
</LineString>


The virtual flight appears to specify each segment as a flyto directive giving the camera coordinates plus a height in metric which appears to be the ground height plus the waypoint height.
I wonder if this could be set to the relativeToGround altitude mode and eliminate the ground offset.


<gx:Tour>
<name>VirtualMission</name>
<gx:playlist>
<gx:FlyTo>
<gx:flyToMode>smooth</gx:flyToMode>
<Camera>
<gx:horizFov>78</gx:horizFov>
<longitude>-97.71805000000001</longitude>
<latitude>30.4192619</latitude>
<altitude>249.936081</altitude>
<heading>40</heading>
<tilt>90</tilt>
<roll>0</roll>
<altitudeMode>absolute</altitudeMode>
</Camera>
</gx:FlyTo>
 
In Litchi Hub, if you place a POI or Waypoint where your anticipate your Home Point to be, that will provide you the same ground elevation as if you placed your cursor in the same spot in Google Earth. I used that value as the elevation parameter in the latest VLM and the resulting flight path looked accurate in GE and the same as if I imported the 3D .klm file.
Thanks for the fix!
 
Interesting. The 3D KML file has the altitude set to relative to ground. The coordinates appear to have the normal long and lat along with a 3rd part which is specified waypoint altitude in meters.

<LineString>
<extrude>1</extrude>
<tessellate>1</tessellate>
<altitudeMode>relativeToGround</altitudeMode>
<coordinates>-97.71805107593536,30.419261564140832,6.096074128261392 -97.71766998851751,30.41964348345308,33.70150515641316 -97.71756985863107,30.419754317904147,40.99108766121435 -97.71748383195518,30.419871992130563,48.2327880859375 -97.7174119084898,30.419996506132332,48.09590148925781 -97.71735408823497,30.420127859909446,48.37754821777341 -97.7169855359715,30.421106228862012,51.718017578125 -97.71695735923674,30.42120831686107,51.5648498535156 -97.7169499101089,30.421309961928937,51.71185302734372 -97.71696318858801,30.421411164065603,52.12828063964841 -97.7169971946741,30.421511923271066,52.6195373535156 -97.71706981624925,30.42167647584874,52.48153686523432 -97.71712279720259,30.42175882554869,52.67294311523432 -97.71719097376945,30.42180020895342,52.9319152832031 -97.71727434594987,30.42180062606294,53.0426483154296 -97.71737291374382,30.42176007687724,53.1061248779296 -97.7175262217184,30.421671942997957,52.0460205078125 -97.7176248762043,30.42160918965204,51.900405883789006 -97.7177151683178,30.42153916674409,52.029296875 -97.7177970980589,30.4214618742741,51.4884338378906 -97.71787066542765,30.42137731224208,50.33480834960932 -97.72016523670266,30.418460567759436,42.56298828125 -97.7202031775663,30.41839619082884,42.9396057128906 -97.72021565627813,30.41833188826384,43.4654998779296 -97.72020267283824,30.418267660064426,43.89888000488281 -97.72016422724653,30.418203506230608,44.262741088867216 -97.720084619283,30.41810376916271,44.67147827148432 -97.7200286205848,30.418046637785555,44.682022094726506 -97.71996297734717,30.418003477098075,44.25265502929682 -97.7198876895701,30.417974287100254,44.92718505859372 -97.71980275725355,30.417959067792104,45.3096923828125 -97.71965954298236,30.417945929330134,45.72201538085932 -97.7195718994056,30.417945463941845,45.99119567871091 -97.71949050052643,30.41796072171934,45.588150024414006 -97.71941534634482,30.41799170266263,45.23895263671872 -97.71934643686075,30.418038406771707,45.253707885742216 -97.71793305873871,30.419210678446177,47.2521209716796</coordinates>
</LineString>


The virtual flight appears to specify each segment as a flyto directive giving the camera coordinates plus a height in metric which appears to be the ground height plus the waypoint height.
I wonder if this could be set to the relativeToGround altitude mode and eliminate the ground offset.


<gx:Tour>
<name>VirtualMission</name>
<gx:playlist>
<gx:FlyTo>
<gx:flyToMode>smooth</gx:flyToMode>
<Camera>
<gx:horizFov>78</gx:horizFov>
<longitude>-97.71805000000001</longitude>
<latitude>30.4192619</latitude>
<altitude>249.936081</altitude>
<heading>40</heading>
<tilt>90</tilt>
<roll>0</roll>
<altitudeMode>absolute</altitudeMode>
</Camera>
</gx:FlyTo>

The altitudes in the Litchi csv file are all relative to the Home Point and Google Earth does not know anything about this - so somehow we have to tell GE the reference height.

One way of doing this is to assume that the first waypoint in the mission is the Home Point - GE can then estimate the altitude of this location and use it as the reference. I believe this is the approach taken by the Litchi export kml 3d Path.

The other approach is to specify the reference altitude explicitly - this is the approach taken in VLM.

The first approach is simpler for the user because he does not need to input any altitude information but it does require that you always take off from your first waypoint - I usually do not. The second approach requires a bit more user input, allows full flexibility.

One possible compromise could be that I get the altitude of the first waypoint from GE and use that as the initial value for the Home Point Altitude in VLM. It could still be changed by the user if required. That might work well. The only trouble I can see is that Google no longer support the COM API for Google Earth - I will investigate further.
 
All I can say is WOW. This is so cool. I have been hunting for something like this!!!! Amazing job and you can bet I'll be watching this thread for any updates.
I love the fact that you can basically test fly your mission to get the best camera angles first. I'm so impressed. I hope you continue to build on this.
You made my day!!!! THANK YOU!
 
All I can say is WOW. This is so cool. I have been hunting for something like this!!!! Amazing job and you can bet I'll be watching this thread for any updates.
I love the fact that you can basically test fly your mission to get the best camera angles first. I'm so impressed. I hope you continue to build on this.
You made my day!!!! THANK YOU!
Ditto to all of this! Just what I wanted for Christmas.
 
  • Like
Reactions: namirda
I got this error: 12/26/2017 11:27:11 PM - Warning - Google Earth Pro does not appear to be installed. Please Check.

What does it mean?

My Google Earth is in this directory: "C:\Program Files (x86)\Google\Google Earth Pro\client\googleearth.exe"

Solution: Reinstall Google Earth
 
Last edited:
I got this error: 12/26/2017 11:27:11 PM - Warning - Google Earth Pro does not appear to be installed. Please Check.

What does it mean?

My Google Earth is in this directory: "C:\Program Files (x86)\Google\Google Earth Pro\client\googleearth.exe"
Don't pretend to know why this would happen, but aside from rebooting, I would try having Google Earth already running.
 
The altitudes in the Litchi csv file are all relative to the Home Point and Google Earth does not know anything about this - so somehow we have to tell GE the reference height.

One way of doing this is to assume that the first waypoint in the mission is the Home Point - GE can then estimate the altitude of this location and use it as the reference. I believe this is the approach taken by the Litchi export kml 3d Path.

The other approach is to specify the reference altitude explicitly - this is the approach taken in VLM.
What I was pointing out is that the KML file works fine in GE (aside from no virtual flight of course ;) ). The altitude is set to relative and I would assume applies to all points in the list of coordinates since it's specified once in the group containing all the coordinates. <altitudeMode>relativeToGround</altitudeMode>
The same tag is used in the virtual flight generated by VLM you just set it to <altitudeMode>absolute</altitudeMode>
It's not that big an imposition to set the actual height in VLM and reload - I'm just curious if it'd work to set relative to ground for EACH point since the altitude mode is specified inside each flight segment. Hope I'm being clear.
If I remember correctly GE wasn't all that good with COM or something changed - I have some Garmin products that used the COM API and they don't work properly.
 

DJI Drone Deals

New Threads

Forum statistics

Threads
130,599
Messages
1,554,251
Members
159,603
Latest member
refrigasketscanada