Virtual Litchi Mission

Deleted member 94047 · Apr 13, 2020

I would suggest contacting the Litchi development team, they are very responsive usually.

Prismatic · Apr 13, 2020

Your Field-of-View setting in VLM is probably wrong

Users of VLM may want to calculate the true field-of-view for their drone, so that simulated framing and composition more closely match the actual result.

For example, the Mavic Air camera is advertised with an 85° FoV, but when it's shooting video, the true FoV is only 74.5°. I expect other models suffer a similar mismatch between specification and video reality.

This post explains the problem and the (fairly simple) solution: Calculating the Video Field-of-View

Jeff A · Apr 13, 2020

Doppler said:
I would suggest contacting the Litchi development team, they are very responsive usually.

Would you mind sharing Contact information? I must have missed that.

Deleted member 94047 · Apr 13, 2020

Effects said:
Would you mind sharing Contact information? I must have missed that.

Dynochrome · Jun 4, 2020

I haven't used VLM for about a year. I have the latest versions of VLM and GE. It worked fine before now I get this message. I get the same error on two different computers. I always used CSV If I use KML, it goes to GE ok but shows a flightpath that looks like a roller coaster that won't play. Before when I used CSV, it showed a little camera Icon that let me play it.

namirda · Jun 5, 2020

Dynochrome said:
I haven't used VLM for about a year. I have the latest versions of VLM and GE. It worked fine before now I get this message. I get the same error on two different computers. I always used CSV If I use KML, it goes to GE ok but shows a flightpath that looks like a roller coaster that won't play. Before when I used CSV, it showed a little camera Icon that let me play it.

The issue appears to be that my initial 12 month free trial period on Google Cloud has now expired. Google did not give me any warning of this and have abruptly stopped access to their elevation data using the VLM default API key.

In the Google tab of the VLM setup options there is a place where you can input your own Google API Key. If you do not do so, then VLM will use my private key which has daily usage limits to ensure I do not get huge bills from Google. However now that my 12 month free trial period has expired, the key no longer works at all!!

I will try to find out if there is some way that we can continue to use this API key without me being at risk of receiving unwanted charges on my credit card - but in the meantime you will have to create your own billing account with Google Cloud Services (use the link provided in the error message) and use your own API Key in VLM.

Sorry for the hassle

Thanks

N

namirda · Jun 5, 2020

OK - Problem seems to be solved.

I have "upgraded" my account with Google Cloud Services from a free account to a normal paid account - so the old API key should now work.

I have set a quota on this key of 1000 hits per day which should keep the bills at zero - at least I hope so!

For your info, there are now more than 6000 VLM users and the number of daily hits on the API runs at between 600 and 1000. So at current usage levels, we should not hit the daily limit very often.

If you get an error message in the VLM Activity Log saying that the daily limit has been exceeded then you will either have to wait until the next day or else provide your own API key.

Thanks

N

JORGE SM · Jun 5, 2020

Good Morning. Yesterday I opened a topic about google APIs. Today is another day

and the counter will have been reset and we can now export to GOOGLE EARTH as usual.
As suggested by NAMIRDA, its creator, contact for the right place.
Today I already located the site to put the particular API key.
Thank you.

JORGE SM · Jun 5, 2020

And next, I dare to consult a couple of matters.
One corresponds to the attached image. It usually happens to me in some of the routes that I am creating but I don't know how to solve it, no matter how much I change heights, delete WP, the problem persists.
And the second, also attached image, is that they comment that they think the route created in relation to the height. Do not you think the drone would go too high? Perhaps it is an optical effect, since the image of the castle is not in 3D
Greetings and thank you very much

Facherty · Jun 5, 2020

@namirda
[I will post this here and in the other thread]

Firstly, thank-you again for all the work that you do on this extension - it has made my drone experience far more enjoyable.

I did not have the difficulty with GoogleEarth messages that others have described in joeruby Virtual Litchi Mission, Google Earth Pro error? or post #825 of this thread. The difficulty experienced concerned missions that bumped along the ground.

I have tried my VLM following your re-subscription to Google, and the results are the same - the virtual drone stays at ground level whilst attempting to become a mole (or a submarine) as it moves around the flight path.

The sole difference in the .kml document generated is as reported in #4 of https://mavicpilots.com/threads/vir...stopped-working-correctly.89773/#post-1017346 - the setting of altitude for each waypoint is changed:
from a gradually varying <altitude>315.6561584472656</altitude> to a continuous <altitude>40.0</altitude> (since I have set all my waypoints at 40m AGL).

I can see how the GoogleEarth subscription has fixed the problem for others, but when I generate a .kml file today I am experiencing:
View attachment 103739

whereas the same mission exported last week, and rendered by GoogleEarth today, gave:
View attachment 103737

Most importantly: thank you.

namirda · Jun 5, 2020

Facherty said:
@namirda
[I will post this here and in the other thread]

Firstly, thank-you again for all the work that you do on this extension - it has made my drone experience far more enjoyable.

I did not have the difficulty with GoogleEarth messages that others have described in joeruby Virtual Litchi Mission, Google Earth Pro error? or post #825 of this thread. The difficulty experienced concerned missions that bumped along the ground.

I have tried my VLM following your re-subscription to Google, and the results are the same - the virtual drone stays at ground level whilst attempting to become a mole (or a submarine) as it moves around the flight path.

The sole difference in the .kml document generated is as reported in #4 of Virtual Mission in Google Earth Pro has stopped working correctly - the setting of altitude for each waypoint is changed:
from a gradually varying <altitude>315.6561584472656</altitude> to a continuous <altitude>40.0</altitude> (since I have set all my waypoints at 40m AGL).

I can see how the GoogleEarth subscription has fixed the problem for others, but when I generate a .kml file today I am experiencing:
View attachment 103739

whereas the same mission exported last week, and rendered by GoogleEarth today, gave:
View attachment 103737

Most importantly: thank you.

Hi,

Please provide a link to your mission in the Mission Hub (remember to set it to public viewing) and I will take a look at it.

N

Facherty · Jun 5, 2020

namirda said:
Hi,
Please provide a link to your mission in the Mission Hub (remember to set it to public viewing) and I will take a look at it.
N

Thank you:

Mission Hub - Litchi

Litchi's Mission Hub lets you plan waypoint flights and later execute them using the mobile Litchi app.

flylitchi.com

Dynochrome · Jun 5, 2020

namirda said:
OK - Problem seems to be solved.

I have "upgraded" my account with Google Cloud Services from a free account to a normal paid account - so the old API key should now work.

I have set a quota on this key of 1000 hits per day which should keep the bills at zero - at least I hope so!

For your info, there are now more than 6000 VLM users and the number of daily hits on the API runs at between 600 and 1000. So at current usage levels, we should not hit the daily limit very often.

View attachment 103727

If you get an error message in the VLM Activity Log saying that the daily limit has been exceeded then you will either have to wait until the next day or else provide your own API key.

Thanks

N

It works now! Thank you! Does a "hit" mean every time I export a file into GE? If so I would limit how much I use it to not hog hits. This is something I never knew about (the google cloud thing). If I have my own account, is it free up untill 1,000 hits ?

Jack747 · Jun 5, 2020

Hello , i discover this thread and i get same problem : after export of VLM ( with Chrome and VLM plugin ) the flight in GE stay at ground level.
in a weird manner , olds Kml files created at end 2019 gave a fly at good height.
the GE is not fautly.
actually the problem is in generating Kml files with the " save as VLM " option
saving cvs files gave absolutely anything.
Thanks to the creator of this plugin for all the work done
edit : kml not klm

J.S.

D2M2P · Jun 5, 2020

Prismatic said:
Your Field-of-View setting in VLM is probably wrong

Users of VLM may want to calculate the true field-of-view for their drone, so that simulated framing and composition more closely match the actual result.

For example, the Mavic Air camera is advertised with an 85° FoV, but when it's shooting video, the true FoV is only 74.5°. I expect other models suffer a similar mismatch between specification and video reality.

This post explains the problem and the (fairly simple) solution: Calculating the Video Field-of-View

Further to this discussion... a tutorial through LITCHI.... indicates at 2:47 to select FOV through type of Mavic flown in "Navigation" settings. However, the tutorial is from 2018...so things have changed. Is there any where with current Mission Hub/GEPro to specify the FOV?
thanks

Jeff A · Jun 5, 2020

I was so excited to see that there was an answer to this problem of VLM's, but alas, mine still does not work, even using the same KML file that used to work.

DragonFly Aerials LLC · Jun 5, 2020

Effects said:
I was so excited to see that there was an answer to this problem of VLM's, but alas, mine still does not work, even using the same KML file that used to work.

Neither does mine.

namirda · Jun 5, 2020

Facherty said:
Thank you:

Mission Hub - Litchi

Litchi's Mission Hub lets you plan waypoint flights and later execute them using the mobile Litchi app.

flylitchi.com

I have taken a look at your mission and I really can't see much wrong with it. When I open it in VLM I see the following:

which looks just fine. There are two elevation numbers provided at each waypoint - the first is the desired elevation above ground and the second is the elevation above WP1.

When I export that mission to GE I see the following :

The mission 'flies' OK - I cannot duplicate the problem you describe.

***************
EDIT !!!

I have just looked at your original post and see that you are not using VLM at all! I didn't notice that!

You are using a similar utility written by @bazuchan which works as a chrome extension. You should ask him to look into the problem - he quite likely has the same problem with his Google account as I did with mine!.

Thanks

N

namirda · Jun 5, 2020

JORGE SM said:
And next, I dare to consult a couple of matters.
One corresponds to the attached image. It usually happens to me in some of the routes that I am creating but I don't know how to solve it, no matter how much I change heights, delete WP, the problem persists.
And the second, also attached image, is that they comment that they think the route created in relation to the height. Do not you think the drone would go too high? Perhaps it is an optical effect, since the image of the castle is not in 3D
Greetings and thank you very much

Hi,

1) The messages about curve size are not an error - just a warning to inform you that no smoothing of your mission will occur at Waypoints 6, 7 and 8. If you want to remove the message then simply increase the curve size at those waypoints.

2) I don't completely understand your question here - but from your screenshot it does indeed look like the elevations in GE are rather higher than your intended 20m or so. You can check this by clicking on the WP lollipops in GE and check that the elevation values displayed in the tooltip are as you expect.

Hope this helps

N

JORGE SM · Jun 6, 2020

namirda said:
Hi,

1) The messages about curve size are not an error - just a warning to inform you that no smoothing of your mission will occur at Waypoints 6, 7 and 8. If you want to remove the message then simply increase the curve size at those waypoints.

2) I don't completely understand your question here - but from your screenshot it does indeed look like the elevations in GE are rather higher than your intended 20m or so. You can check this by clicking on the WP lollipops in GE and check that the elevation values displayed in the tooltip are as you expect.

Hope this helps

N

Thank you very much for answering and sharing with others who may have similar doubts.
The first question is already resolved, I have increased the size of the curve and the warnings no longer appear.
As for the second, what I mean is that giving the desired height 20 meters above the ground, when you see it on google earth, it gives the impression that the drone is going VERY HIGH. As I also commented, it may be an "optical illusion", since the castle that I intend to visualize and record is FLAT, it is not in 3D format in GE.
I have searched in GE the heights that the WP have and the following appears, I only expose the first 3 WP.
WP 1: MSL 451 RTG 10
WP2: MSL 461 RTG 20
WP3: MSL 462 RTG 20
The rest of the WPs, continue to mark as RTG 20 and the MSL between 463 and 460.
The RTG equals the DESIRED elevation and the MSL is assumed to be the REAL height.
It is right ??
I leave the file with the path created in case you can import it and see that everything can be correct.
And I end with another simpler question: what POIs does he recommend? I suppose it will depend on where it is placed, but a brief idea of how it would be better to give one height or another?
Once again thank you for your work and attention.

P.D. By the way, like sharing a route. In the options there is a way that is to share on FACEBOOK, another opens a new window with the route and the one I have used, download the route.