Virtual Litchi Mission

[causalloop]

Even if the drone is out of range of the controller, ie disconnected, it will still interpolate poi. It can not receive your "focus" command if it is disconnected but will still interpolate. Interpolate has nothing to do with the RC, it has to do with GPS and Litchi.

Yeah - I get that it won't take any commands after it goes out of range, that wasn't a question in and of itself.. Somewhere around post 613 I think, I guess I got the impression that in order for the gimbal to Focus POI, those commands aren't stored in the mission sent to the drone because of API limitations (someone said the drone's API doesn't understand POI's or something along those lines). I didn't mean to imply that I'd be sitting there fiddling during the mission, just that the portion of the mission that is stored on (my ipad?) has to send the gimbal commands as the drone reaches its waypoints etc. Which would effectively be the same as me doing it manually - which obviously doesn't work when its out of range.

If I'm wrong here, I'm wrong - but my mission plan calls for it to focus POI at waypoints out of radio range and take pictures and/or record video at the various POI's that are out of range, and my observation has been that the drone will physically turn to point at the POI, but the gimbal will stay in whatever the last position it was in, which says to me that its just storing the intended orientation of the drone at the various waypoints etc. Does that make more sense? Would it make more sense if I attached a mission?

 

[causalloop]

Just to add to that - I'm telling it to do *things* as 'actions' at the waypoints.

 

[Former Member]

Just to add to that - I'm telling it to do *things* as 'actions' at the waypoints.

Do you know how to set interpolate and what it can do?

 

[causalloop]

Do you know how to set interpolate and what it can do?

Let me rephrase - at the waypoints, I'm using the 'actions' to execute commands (take picture, record, etc.).

Yes - I know how to set interpolate and mostly know what it can do, but this isn't the point. Forget what I'm trying to do for the moment, create a mission with waypoints and POI's that are out of your radio's range and control - i.e. you can't do anything till it comes back into range. In the mission, set the recording to start - or picture taking - at the various waypoints that you've set up.

To be clear, to my knowledge "Focus POI" doesn't just 'focus' the camera, it puts the POI in focus by means of turning and adjusting the pitch of the gimbal and focus of the camera.

The observed behavior of this outside of the simulator, is that wherever the gimbal was pointed when it went out of range, is where it will remain - regardless of the mission settings (it can't do it) - and while the drone itself will adjust its orientation to point at the POI (which would appear to really mean, turn this direction at this location - not really "pointing" at anything), what I'll end up with is pictures/video pointed in the direction that the drone is facing, but not pitched/focused on the actual POI.

With regards to Interpolate, to the best of my understanding, this just lets you set the gimbal's pitch and then figures out the changes in between the waypoints (if any) - correct me if I got that wrong.

I think what you're getting at is that Interpolate is really a fancier version of the 'set the camera angle' action because it sets the angle in between waypoints as well, not just at the waypoints. Yes? No? I haven't tried this yet, but seeing as how "focus POI" should be doing something very similar - the difference being (I think) that it figures out the angle to point for you(?) - in that its just sending the 'point here' data, I would expect a similar outcome.

To get to the meat of it - the drone doesn't appear to be doing much 'processing' on the fly. I don't have the coding background to know what to look for in the API, all I can do is test it - when I'm not trying to work too...

I'm not sure if I got too far off on a tangent, but I think what you're trying to say is that setting the camera angle *at* the waypoint via the actions should work because interpolate works (or visa versa I guess). But Focus POI doesn't because the drone doesn't have the ability to 'figure out' enough to say whether or not its set the pitch of the gimbal right or something (because of the API limitation - which seems kind of odd).

<breeeeeathe>

How am I doing so far there

 

[OzoneVibe]

Sorry to go back to something said earlier - if the drone is out of RC range (correct me if I'm understanding this wrong), it can NOT change the gimbal direction/pitch as part of your mission? I.E. why Focus POI or Interpolate don't work when out of range(?) Does this apply to the actions as well - i.e. 'Tilt Camera'?

There's some geography I want to get some imagery of before I head out to it (off road) and its just out of range (thanks trees... where's my blimp antenna when I need it). I could pre-set the angle on take off, but that means some pre-planned math (or just pointing it straight down I guess).

Since this (at least as of the last time this was brought up) is/was an API limitation, I assume this applies still to the DJI Go app (that now has waypoint missions - I haven't played with it yet)?

This would seem to be a question for a Litchi forum rather than Virtual Litchi Mission …. where Virtual Litchi Mission will show you what you get whether or not your are connected … once the mission is initiated.

 

[causalloop]

This would seem to be a question for a Litchi forum rather than Virtual Litchi Mission …. where Virtual Litchi Mission will show you what you get whether or not your are connected … once the mission is initiated.

You're probably right - it was brought up on this thread and I happened to be poking around as it was, but yeah, should probably go there. I don't often fly outside of radio range (makes me a tad nervous for obvious reasons), let alone VLOS, so the use case is not exactly huge, but you raise a good point.

 

[OzoneVibe]

You're probably right - it was brought up on this thread and I happened to be poking around as it was, but yeah, should probably go there. I don't often fly outside of radio range (makes me a tad nervous for obvious reasons), let alone VLOS, so the use case is not exactly huge, but you raise a good point.

It doesn't prevent you using VLM to see what will happen, even within VLOS.
You get an immediate visual representation of what your mission will actually do.

 

[causalloop]

It doesn't prevent you using VLM to see what will happen, even within VLOS.
You get an immediate visual representation of what your mission will actually do.

I know - but it won't tell me what it will do when it goes completely out of range, at least, not the full story; thats the problem. Or from what I gather, thats the problem that the API has (or hasn't been written into it yet).

Unfortunately I don't have a lot of places I can test this that aren't fairly far away - or rather I have a lot of places... but I don't fancy loosing contact with my drone over dense cities... (legalities, rules and ethics aside...)

 

[namirda]

I'd like to add my two cents worth to the discussion about Focus POI - there seems to be some misunderstanding here about a simple topic which is made confusing only by Litchi's choice of it's name!

When you choose Focus POI at a waypoint, Litchi will calculate the bearing and gimbal angle required to put your POI in the centre of the viewing window at that waypoint. You can achieve EXACTLY the same thing by using the INTERPOLATE option and calculating the two angles yourself but it's much easier to have Litchi do the arithmetic for you. Whether you use INTERPOLATE or FOCUS POI, the interpolation between waypoints works exactly the same way and in general WILL NOT keep your POI in the centre of your viewing window between waypoints. This is because the mission information transmitted to the drone does not contain POI information - it only contains the waypoint information Lat/Lon/Elevation/Speed and Bearing - notice that gimbal angle is not transmitted which is why there can be issues when the drone goes out of range.

Hope that helps.

N

 

[causalloop]

notice that gimbal angle is not transmitted which is why there can be issues when the drone goes out of range.

I think that sums up exactly what I was trying to say - I think. The gimbal angle is not transmitted - with the mission.. The mission is in both places - ipad and drone, and the gimbal part gets transmitted during the mission. Yes/No?

 

[namirda]

I think that sums up exactly what I was trying to say - I think. The gimbal angle is not transmitted - with the mission.. The mission is in both places - ipad and drone, and the gimbal part gets transmitted during the mission. Yes/No?

Correct!

 

[OzoneVibe]

Firstly, correct (quickly readiing somewhere above - terminology/translation issue with the use of focus) the camera focus (near<>infinity) can't be pre-set in the mission (in case of loss of connection) to change from POI to POI.
There's auto-focus, and manual focus. The former can hunt with poor detail (so I rarely use), the latter has to be a compromise for the duration of the mission … if you lose connection.
Litchi uses the other meaning of focus … as in to focus attention, rather than the photographic meaning.

I think that sums up exactly what I was trying to say - I think. The gimbal angle is not transmitted - with the mission.. The mission is in both places - ipad and drone, and the gimbal part gets transmitted during the mission. Yes/No?

Not in my experience. …. or, not in the way that I set up my mission?
I'll qualify this by saying that I use it for video, mainly, so (nearly) always use curves and not actions at waypoints. But, from my understanding/experience, this shouldn't change in either mode.

However, you might want to try what I tried when first building my understanding and trust in Litchi .... create a very small, very SLOW, low (about 10ft), mission in a small field - designed to test/understand the way it operates.
Initiate the mission and then switch off the RC … then walk along with your drone and watch exactly what it does.
You can place objects at the POI locations (jackets/bags/etc).
This way you will be able to examine your use of Litchi by effectively simulating "completely out of range".

 

[CdA Mavic]

Glad to hear that some of you have found VLM to be useful - thanks for the feedback.

Here is an updated version which solves a few issues present in earlier versions. There are no new features so nothing to get excited about.

However I am working on a more significant upgrade to VLM which I might get around to finishing one day. Any suggestions are welcome.

N

Hey Namirda. Thanks for a great tool. I just installed 2.3.0 on Win10. It worked until I closed it the 1st time. Now all I get is the opening tune but no user screen. It seems to work because GE will replay the mission, but why don't I get a VLM user interface?

 

[namirda]

Hey Namirda. Thanks for a great tool. I just installed 2.3.0 on Win10. It worked until I closed it the 1st time. Now all I get is the opening tune but no user screen. It seems to work because GE will replay the mission, but why don't I get a VLM user interface?

Hi,
For some reason, the cache can get messed up if VLM closes down incorrectly. You can clear the cache by pressing CTRL while starting VLM - that should fix it.

N

 

[Peio64270]

(...)
VLM gets its elevation information directly from Google's Elevation API. I have never seen a clear statement from Google on exactly how they calculate their DEM but I believe it is based on Shuttle Radar data (SRTM). If you search online you will find many discussions about the accuracy of this data but I have never seen a general way of estimating the accuracy in a particular area. If you come across anything which might be educational then please post a link....

Are you sure about this ? I ever build my missions with VLM (what a great app, thank you again for your work !) and recently I had a problem with the "above ground" setting at waypoints in some locations. After a quick check that this problem was not inherent in VLM and that I obtained the same error message in the Hub, I wrote to the Litchi support team what follows :

"My only concern is that I fly often in mountains and that I'd like to go downward steep slopes to a greater extent than -200m which is the limit in the Hub as well, indeed, as it is in VLM.
I know that I could set waypoints "relative to ground elevation" for bypassing this limitation but unfortunately, this setting does not work in some places. When I try to do this, both Hub and VLM display a message saying :

"Elevation Data Missing
Elevation Data is required to use this feature but could not be found. Import a Digital Elevation Model or enable Online Elevation in the settings."

In two different answers, the support team said, first that this -200m limit was due to the DJI SDK and could not be changed, second, that the Litchi Hub was not using anymore Google's elevation API. This is their answer on May 10 concerning the second point :

"We don’t use the Google Elevation data anymore due to their pricing change (*1000)
We now use Mapbox’s elevation api. Unfortunately it seems to have a bug currently where a lot of elevation data is missing. We reached out to them about this issue back in March this year. We hope they will fix it soon, but it could take a while…"
This is the data for example for the first mission you sent us (around WP1): Terrain (RGB-encoded dem)
Blank means no data, but it isn’t normal and happens randomly in a lot of places (not just spain).
If you want to see other locations, just change the lat/lng at the end of the URL"

Since this date, the Mapbox's bug has been corrected, at least for the two areas of my concern and I can use there "above ground" feature with VLM as well as with the Hub.
But I wonder whether resolution and accuracy are identical in Mapbox and in Google APIs. Differences between these two sources of elevations could explain some discrepancies that I and others observed when flying a mission over uneven terrains, virtually or really.

 

[Brojon]

Interesting - thanks!

 

[marklyn]

Does VLM work with the Mavic 2 Pro in the same way it does with the Mavic 1 Pro? I ask because I thought the FOV and something "else" was different (can't remember the else!)...
Additionally when I now export to GE the flight heading is most definitely not correct and doesn't correlate with the video, plus, if I use the HD player in Airdata, the flight (nose) direction is correct there. This is new to me since I've upgraded to the Mavic 2 Pro and I've verified all settings in VLM 2.3.0 so I'm not sure where the problem is. This worked well before so there must be something I goofed up somewhere.

 

[namirda]

Are you sure about this ? I ever build my missions with VLM (what a great app, thank you again for your work !) and recently I had a problem with the "above ground" setting at waypoints in some locations. After a quick check that this problem was not inherent in VLM and that I obtained the same error message in the Hub, I wrote to the Litchi support team what follows :
...........

Thanks for your thoughtful detailed post.

I am completely sure that VLM gets its elevation data from the Google API because I wrote it!

However I was not aware that Litchi have made a move away from Google due to their pricing changes. Fortunately, those pricing changes do not currently apply to VLM because it is not a commercial application and the number of API hits per day is below the minimum threshold. For now I can still get elevation data from Google for free - I hope that does not change.

I don't know anything about Mapbox or from where they get their elevation data but any differences between their data and Google's will certainly result in differences between your VLM flight and the subsequent real one.

Another source of elevation discrepancies which you may not be aware of is the strange fact that the elevation model used by Google Earth is not the same as the one used by Google Maps (and therefore by VLM). I have no idea why Google would do this! You can check the differences by comparing the elevation of your waypoints in Google Earth with those obtained from the Google Elevation API by VLM (use the Verbose option in VLM to see this). The differences vary from place to place but can be several tens of meters.

I also fly my Mavic in an area of rapidly changing elevation and had a few near misses due to unexplained elevation errors. I have since hiked to the top of all the local high points with a GPS receiver and an altimeter in order to make my own (very sparse!) elevation model. It may be sparse but at least I can trust it!

N

 

[namirda]

Does VLM work with the Mavic 2 Pro in the same way it does with the Mavic 1 Pro? I ask because I thought the FOV and something "else" was different (can't remember the else!)...
Additionally when I now export to GE the flight heading is most definitely not correct and doesn't correlate with the video, plus, if I use the HD player in Airdata, the flight (nose) direction is correct there. This is new to me since I've upgraded to the Mavic 2 Pro and I've verified all settings in VLM 2.3.0 so I'm not sure where the problem is. This worked well before so there must be something I goofed up somewhere.

Yes, VLM should work with any/all DJI drones which are supported by Litchi.

As you mentioned, VLM does not have an entry for the Mavic 2 in the config options and so you will have to manually enter the FOV and other parameters manually until I get around to releasing a new version.

Your description of the heading errors is new to me. The Litchi Mission Hub is agnostic as far as drone type is concerned - the Hub does not know what type of drone you will be using to fly the mission. VLM only uses the Drone Type in order to set the camera FOV and to do a sanity check on other flight settings and so I do not understand your problem. Can you give more details please.

N

 

[Peio64270]

Thanks for your thoughtful detailed post.

I am completely sure that VLM gets its elevation data from the Google API because I wrote it!

I see ! However I do not understand why I had the same error message ("Elevation Data Missing") at the same waypoints of the two same missions either with the Hub which is supposed to use Mapbox's API and with VLM that uses Google's API.
These two missions were distant by some 80km from each other and in the second one, only some waypoints located East from a very precise lgt were concerned. I copy hereunder what I wrote to Litchi support :

"The first image attached is an example of this issue. AGL works perfectly for the mission at the left in the image
(Mission Hub - Litchi) but not at all for the mission at the right side (Mission Hub - Litchi)..

Moreover, if I move waypoint 5 of the Westward (left) mission towards East (i.e. towards the mission at the right which does not accept AGL setting), AGL still works for this waypoint till a very precise location (longitude : -1.669928, see the second attached image) but it stops working after a tiny movement further East of this waypoint (longitude :
1.669918, see third image). However, at this moment AGL continues to work for the other (westward) waypoints of this mission."

(2 screenshots attached)

I verified that it was exactly the same behaviour in the Hub and in VLM. Thus, should I consider that it was a bug inherent in the Hub (fortunately fixed now) and not in this Mapbox API ? If it is the Hub, Litchi support is lying...

Another source of elevation discrepancies which you may not be aware of is the strange fact that the elevation model used by Google Earth is not the same as the one used by Google Maps (and therefore by VLM). I have no idea why Google would do this! You can check the differences by comparing the elevation of your waypoints in Google Earth with those obtained from the Google Elevation API by VLM (use the Verbose option in VLM to see this). The differences vary from place to place but can be several tens of meters.

I also fly my Mavic in an area of rapidly changing elevation and had a few near misses due to unexplained elevation errors. I have since hiked to the top of all the local high points with a GPS receiver and an altimeter in order to make my own (very sparse!) elevation model. It may be sparse but at least I can trust it!

N

I didn't know that Google could use two different sources for their DEM but this can enlight some unexplained discrepancies I observed sometimes in the past. Thank you for this info.
I don't hike my difficult missions because in most cases this is impossible (no trail or very rough terrain) but I use to compare Google's elevations at waypoints with those of good topo maps and I have sometimes big surprises. For example a canyon 120m deep is completely ignored by Google or an islet in the ocean is given for elevation zero while it is 90m high over the ocean surface...