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

Virtual Litchi Mission

If you mean the gimbal pitch then it does! And of course it is used by VLM to produce the virtual mission. But perhaps you mean the gimbal azimuth which is not really relevant to the Mavic??

N
Wow! I didn't know that. I have a few missions in mind in which temporary loss of signal is probable. Now I'll be able to fly them. Thank you again your hard work!
 
Sorry - Not much I can do with the playback in GE. I could possibly post the speed as part of the label in the "WP Labels" but I don't think that would be very elegant or useful. Any ideas?
N

Even that would be a help as I sometimes forget to set the speed I want at a waypoint, at least when viewing the playback I can see the label speed..
 
I think the main reason for any inaccuracy in the virtual mission is the fact that the real mission is handled by the firmware onboard the drone and DJI do not tell us exactly how this is done. Litchi made a good guess by smoothing the path between the waypoints with a simple 5 point Bezier function and I have done the same in VLM. The heading, altitude and gimbal pitch are linearly interpolated between the Bezier nodes in VLM - DJI are probably doing something similar but they do not say anything about this anywhere in their API documentation.

I will keep your request in mind for the next release.

N

Hi Namirda,
Again thank you for this wonderful tool that I am using now to program all my mission.
About inaccuracies in the virtual missions, there is one that it might be hard to fix but in case this could be possible I tentatively expose the problem.

I use to fly in mountains, canyons etc. with very often huge and rather brutal changes in altitude. With the Mavic Pro (for example), the maximum vertical climbing velocity is 18 km/h and the max rate of descent is around 11 km/h. In a mission with a cruising speed set at, say, 36 km/h (10 m/s) and where two waypoints are distant horizontally by, say, 5m, these horizontal 5m will be achieved in 1/2 s. But if the same waypoints are separated by 100m vertically, the max speeds in the Y axis induce that it will take about 20s to cover these horizontal 5m if the Mavic climbs (at 5m/s max) and about 32s if it descents (at 3m/s max).
In the virtual mission, only the horizontal speed is taken into account and this produces strange results when the heading and/or the gimbal pitch are set to interpolate between widely different angles during what is supposed to be a long climb or descent at almost the vertical (in my example, a change of 90° heading executed in half a second instead of 20 s or 32 s).

I don't know if I am clear (English is not my native language) and, if so, whether it is possible or not to introduce these limitations in the virtual mission when two waypoints are superposed (or almost superposed) but located at altitudes largely different.
Best regards.
 
Hi Namirda,
Again thank you for this wonderful tool that I am using now to program all my mission.
About inaccuracies in the virtual missions, there is one that it might be hard to fix but in case this could be possible I tentatively expose the problem.

I use to fly in mountains, canyons etc. with very often huge and rather brutal changes in altitude. With the Mavic Pro (for example), the maximum vertical climbing velocity is 18 km/h and the max rate of descent is around 11 km/h. In a mission with a cruising speed set at, say, 36 km/h (10 m/s) and where two waypoints are distant horizontally by, say, 5m, these horizontal 5m will be achieved in 1/2 s. But if the same waypoints are separated by 100m vertically, the max speeds in the Y axis induce that it will take about 20s to cover these horizontal 5m if the Mavic climbs (at 5m/s max) and about 32s if it descents (at 3m/s max).
In the virtual mission, only the horizontal speed is taken into account and this produces strange results when the heading and/or the gimbal pitch are set to interpolate between widely different angles during what is supposed to be a long climb or descent at almost the vertical (in my example, a change of 90° heading executed in half a second instead of 20 s or 32 s).

I don't know if I am clear (English is not my native language) and, if so, whether it is possible or not to introduce these limitations in the virtual mission when two waypoints are superposed (or almost superposed) but located at altitudes largely different.
Best regards.

Hi,

Thanks for the kind words and interesting feedback.

Indeed, only the horizontal distance is taken into account when calculating times between waypoints in VLM - I had never considered the possibility of vertical legs in missions!

The Litchi app allows us to program missions which our drones are incapable of flying - either because they are too long, too high, too fast or in your case have altitude changes between waypoints which exceed the ascent/descent capabilities of the drone. It's a bummer when reality gets in the way! The question really is what, if anything, VLM should do when presented with an unrealistic mission.

It would not be too difficult to make changes to VLM such that it checks the altitude changes between successive waypoints and adjusts the speed if it exceeds the capabilities of the drone. However, in my view, a better approach would be for VLM to simply issue a warning in such cases and leave it to the pilot to make the required changes. What do you think?

For now, you can simply reduce the speed of the 'steep' legs in your mission - wouldn't that solve your problem?

I would be very cautious about using Google Earth and VLM in areas of extreme and 'brutal' changes in elevation. In my area where there are also some steep cliffs and vertical pinnacles I have found that Google Earth rounds them all off - it does not see the pinnacles and vertical drop-offs at all but simply shows a smooth rounded profile. Do you not find the same?

N
 
Agreed. Warnings would suffice in my opinion and yes, when traversing dramatic terrain, I become very conservative in altitude and other aspects. I use more liberal flight parameters with flat or terrain I'm very familiar with.
One other thing... if you forget to enter a gimbal pitch on a waypoint then I think GE moves the pitch to 0 (but I may be wrong). If this is the case, a warning would be nice for any waypoints that don't have a gimbal pitch in them. I know the drone will use the last gimbal pitch during the flight but GE doesn't.
 
Hi,

(...)
It would not be too difficult to make changes to VLM such that it checks the altitude changes between successive waypoints and adjusts the speed if it exceeds the capabilities of the drone. However, in my view, a better approach would be for VLM to simply issue a warning in such cases and leave it to the pilot to make the required changes. What do you think?

For now, you can simply reduce the speed of the 'steep' legs in your mission - wouldn't that solve your problem?

I would be very cautious about using Google Earth and VLM in areas of extreme and 'brutal' changes in elevation. In my area where there are also some steep cliffs and vertical pinnacles I have found that Google Earth rounds them all off - it does not see the pinnacles and vertical drop-offs at all but simply shows a smooth rounded profile. Do you not find the same?

N

Thank you Namirda for this long and detailed answer.

Before to discuss these points, I intended to show an example of what I see in VLM and during corresponding actual flights but at my great disapointment, VLM 2.0.0 (X64) does not work anymore in my computer (MSI GT62VR 7RD, windows 10).
It opens (I get the sound of the drone and it looks working in the task manager) but I have no display anymore.
I tried to uninstall and re-install but no success.
The first time I tried to open the program today, I saw an "exception" warning windows but unfortunately, I forgot to pay attention on it. Now, this window is not displayed anymore and VLM simply does not appear in my screen. Attached is the developed info given by the task manager.
What can I do ?
 

Attachments

  • VLM-Capture.JPG
    VLM-Capture.JPG
    70.9 KB · Views: 26
Hi Namirda,

I've found some issue with when gimbal pitch mode in Litchi is set to disabled (mode 0). For example :
WP1 gimbal mode = interpolate -90
WP2 gimbal mode = interpolate -45
WP3 gimbal mode = disabled

VLM will interpret the WP3 disabled mode as 0 degrees instead of using back the last know gimbal pitch value which is -45.
In actual flight, the above scenario will have WP3 gimbal pitch at -45 instead of 0.

Another issue I noticed is in curved turns missions, if curve size is small at say 1m, even if the next WP is along the same trajectory, VLM tour will decelerate at each WP. In the actual flight, the speed is maintain if next WP is along the same direction, deceleration only occurs as the direction difference to the next WP increases. Would be great if VLM could take into account.

I've attached a sample Litchi mission csv with small curve size and along the same direction.
And here is how the actual flight looked like :
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Noticed how the speed of 22-23kmh is maintained while moving along the same trajectory, slowing only at sharp turns.

Hope you can look into this when you have the time.
 

Attachments

Hi Namirda,

I've found some issue with when gimbal pitch mode in Litchi is set to disabled (mode 0). For example :
WP1 gimbal mode = interpolate -90
WP2 gimbal mode = interpolate -45
WP3 gimbal mode = disabled

VLM will interpret the WP3 disabled mode as 0 degrees instead of using back the last know gimbal pitch value which is -45.
In actual flight, the above scenario will have WP3 gimbal pitch at -45 instead of 0.

Another issue I noticed is in curved turns missions, if curve size is small at say 1m, even if the next WP is along the same trajectory, VLM tour will decelerate at each WP. In the actual flight, the speed is maintain if next WP is along the same direction, deceleration only occurs as the direction difference to the next WP increases. Would be great if VLM could take into account.

I've attached a sample Litchi mission csv with small curve size and along the same direction.
And here is how the actual flight looked like :
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Noticed how the speed of 22-23kmh is maintained while moving along the same trajectory, slowing only at sharp turns.

Hope you can look into this when you have the time.

Hi Tajino,

Thanks for your comments and for investigating the issues.

1) VLM indeed interprets a WP gimbal mode ="disabled" as having zero tilt - and of course this is not ideal! I will fix it up in the next release. In future I will use the pitch from the previous waypoint - or zero if it is the first WP.

2) Your second observation is a result of something that I think must be due to a recent change in the Litchi CSV output. It now seems to be the case that even when you specify "Path Mode=Straight Lines" in the Litchi settings, the CSV file still contains a non zero value for the curve size. I don't think that this used to be the case. The csv file you provided has a value of 0.2 for the curve size of each waypoint - I suspect those values are inserted by Litchi and not by you?? They should probably be zero.

The result of these small but non-zero values for curve size is that VLM inserts 5 smoothing waypoints very close to the original waypoint - you can see them in VLM if look carefully at the "Diagnostics/Smoothed Flight Path" - zoom in very close to one of your waypoints. These additional waypoints are only about 10cms apart in your case and I believe they are the reason for the slowdowns in the VLM mission at each waypoint.

In the next release I will ignore all small curve size values which are less than perhaps 5m and I think that will solve the problem. I will also ignore curve sizes if the change in direction from one waypoint to the next is below a certain value - it probably makes no sense to smooth course changes of only a few degrees.

In the meantime, you could try editting your csv file and set the curve size values to zero - I think that will help.

N
 
Thank you Namirda for this long and detailed answer.

Before to discuss these points, I intended to show an example of what I see in VLM and during corresponding actual flights but at my great disapointment, VLM 2.0.0 (X64) does not work anymore in my computer (MSI GT62VR 7RD, windows 10).
It opens (I get the sound of the drone and it looks working in the task manager) but I have no display anymore.
I tried to uninstall and re-install but no success.
The first time I tried to open the program today, I saw an "exception" warning windows but unfortunately, I forgot to pay attention on it. Now, this window is not displayed anymore and VLM simply does not appear in my screen. Attached is the developed info given by the task manager.
What can I do ?

Hi,

Please delete the VLM session files which are possibly corrupted. Delete both the following folders and their contents:

c:/users/<yourname>/appdata/local/temp/VLM

c:/users/<yourname>/appdata/Namirda

If you have this problem again in the future please let me know how to reproduce the problem so that I can fix it!

Thanks

N
 
  • Like
Reactions: Hauptmann
Hi,

Please delete the VLM session files which are possibly corrupted. Delete both the following folders and their contents:

c:/users/<yourname>/appdata/local/temp/VLM

c:/users/<yourname>/appdata/Namirda

If you have this problem again in the future please let me know how to reproduce the problem so that I can fix it!

Thanks

N

Thank you very much.
Before you anwered I tried an other way suggested by a fellow of the Litchi Users Facebook page (where I did advertise about your wonderful application some weeks ago). He suggested to install it elsewhere than in C:/program files. I have uninstalled from C:/ and re-installed in a new folder of D:/ which is my data drive and... VLM works again !
But tomorrow I will try to delete the two "appdata" folders and to install it again in C:/ and let you know if it was the problem.
Aftr what I think I will be able to discuss this vertical speed problem on the basis of examples :)

[Edit] It works but I get what is copied in the attached image in the "Activity log" :
 

Attachments

  • VLM_Capture4.JPG
    VLM_Capture4.JPG
    74.3 KB · Views: 20
Last edited:
2) Your second observation is a result of something that I think must be due to a recent change in the Litchi CSV output. It now seems to be the case that even when you specify "Path Mode=Straight Lines" in the Litchi settings, the CSV file still contains a non zero value for the curve size. I don't think that this used to be the case. The csv file you provided has a value of 0.2 for the curve size of each waypoint - I suspect those values are inserted by Litchi and not by you?? They should probably be zero.

Hi Namirda, thanks for looking into this.
The curvesize of 0.2 and 1.0 are entered by me to test out how the drone will behave in actual flight while moving along same direction and different direction in 'curved turns' mode.

The result of these small but non-zero values for curve size is that VLM inserts 5 smoothing waypoints very close to the original waypoint - you can see them in VLM if look carefully at the "Diagnostics/Smoothed Flight Path" - zoom in very close to one of your waypoints. These additional waypoints are only about 10cms apart in your case and I believe they are the reason for the slowdowns in the VLM mission at each waypoint.

I know this, initially I thought there were issues with <gx:duration> values in the tiny segments, however upon further investigation, the <gx:duration> for all segments looks to be correct with the given cruising speed and distance. The deceleration and even moving backwards at those tiny segments are due to Google Earth internal smooth spline interpolation between the <gx:FlyTo> keyframes which are apparent when the distance is small, so I guess there is nothing that can be done here. This would not have been an issue if there were a linear <gx:flyToMode>.

In the next release I will ignore all small curve size values which are less than perhaps 5m and I think that will solve the problem. I will also ignore curve sizes if the change in direction from one waypoint to the next is below a certain value - it probably makes no sense to smooth course changes of only a few degrees.

In the meantime, you could try editting your csv file and set the curve size values to zero - I think that will help.

N

That could be a good workaround solution to the problem. However I would suggest to have this as an option, when checked, user will be able to set the small curve size threshold in which VLM will ignore.

Thanks again!
 
Thank you very much.
Before you anwered I tried an other way suggested by a fellow of the Litchi Users Facebook page (where I did advertise about your wonderful application some weeks ago). He suggested to install it elsewhere than in C:/program files. I have uninstalled from C:/ and re-installed in a new folder of D:/ which is my data drive and... VLM works again !
But tomorrow I will try to delete the two "appdata" folders and to install it again in C:/ and let you know if it was the problem.
Aftr what I think I will be able to discuss this vertical speed problem on the basis of examples :)

[Edit] It works but I get what is copied in the attached image in the "Activity log" :

Hi,

I have no idea what is going on there!! I am seeing calls to connect.facebook and that is not anything I know about. I am completely allergic to facebook and there are certainly no calls to it within VLM - so it must be something either you or Litchi are doing.

Sorry - can't help with that one..

N
 
Hi,

I have no idea what is going on there!! I am seeing calls to connect.facebook and that is not anything I know about. I am completely allergic to facebook and there are certainly no calls to it within VLM - so it must be something either you or Litchi are doing.

Sorry - can't help with that one..

N
I just had that same problem this evening where VLM stopped working. I used the suggestion to install it in a different directory, and that took care of it. By the way...love VLM!!!
 
I just had that same problem this evening where VLM stopped working. I used the suggestion to install it in a different directory, and that took care of it. By the way...love VLM!!!
Hi Bill,

I was in the middle of replying to a post of yours earlier today about ground referenced waypoints but by the time I was ready to post my reply your post had gone!!

If you find out what is causing VLM to behave badly then please let me know - I would like to fix it..

It shouldn't be necessary to install it in a different directory - just removing the temp folders as I described in post 249 should do the trick.

N
 
Hi,

I have no idea what is going on there!! I am seeing calls to connect.facebook and that is not anything I know about. I am completely allergic to facebook and there are certainly no calls to it within VLM - so it must be something either you or Litchi are doing.

Sorry - can't help with that one..

N

Anyway your program that became essential to me works again :-). Maybe these calls to Facebook have something to do with the browser (Firefox) that I use for connecting both to the Litchi hub and to Facebook ? Yesterday, I had the facebook page opened in firefox but not the hub page. An other thing at my first opening of my new installation of VLM is that I could open my missions but the yellow lines which join the waypoints were not drawn (in any mission).
I don't know what happened but apparently just changing drive and install folder is enough to fix the issue of VLM not displaying.At the second opening of VLM, I had not these calling errors and everything returned to normal.

Thanks for your help. I wish you an excellent day.
 
Hi Bill,

I was in the middle of replying to a post of yours earlier today about ground referenced waypoints but by the time I was ready to post my reply your post had gone!!

If you find out what is causing VLM to behave badly then please let me know - I would like to fix it..

It shouldn't be necessary to install it in a different directory - just removing the temp folders as I described in post 249 should do the trick.

N
Sorry for the confusion over my missing post. I installed version 2.0, and it solved the issue. I didn’t want to confuse anyone, so I just removed the post. I agree with others that you should either be charging for this program, or allow us to contribute somehow. I use it more than any other application out there!
 
  • Like
Reactions: Peio64270
Good morning, I'm new here and I have a Mavic Air, someone can tell me if there is a possibility and how to turn off the sound alarms for flights indor
 
Hi Namirda,

I did what you said (i.e. to delete the two folders in appdata) and I could re-install a working VLM in c:/. I will try not to forget this point for the next time.
Thinking about the error in the call of Facebook, yesterday, I realize that my login to Litchi is my facebook account. Maybe this explains that...
 
Hi Namirda,

Well, it happened again. VLM stopped working for no apparent reason. I deleted the Namirda_Inc folder from the appdata/local folder, re-installed, and all is well again. I'll continue to try and see what triggers this.

- Bill
 
I'm using VLM a bunch (Thanks Namirda!).

Would like to make GE Pro speed up the transit time from one WP to the next as I click along Viewng Waypoints in the Diagnostics folder, but I can't seem to find the magic words to get its attention. Any GE Pro sheriffs in here who can tell me how to speed up the fly-to speed from one WP to the next? I wouldn't even mind if it snapped to the next WP.

Much appreciated. Thanks............... R
 

DJI Drone Deals

New Threads

Members online

Forum statistics

Threads
134,568
Messages
1,596,335
Members
163,068
Latest member
Liger210
Want to Remove this Ad? Simply login or create a free account