Virtual Litchi Mission

[namirda]

Mmmm I get what you saying -
ALSO iv noted that the drone gets AWFULLY confused when Out of Range from the RC - to do a Transition of gimbal Angle.
- So Then (at present) it would HAVE to be a Function of the WAYPOINT program (ie LITCHI) to calculate these better- and send the correct Math angles during the transition-

--- Please refer to the detail previously … ie
==============================

==============================

Thanks for your Explanation.

Litchi cannot really do any better given that they have to upload only simple WP data to the drone due to the limitations of DJI's API. Litchi "do not send any math angles" to the drone - they only send the very basic information which you have given them at each waypoint.

I think the only way Litchi could do better in this regard would be for them to generate one or more additional infill waypoints and correctly calculate the gimbal angles at these new WPs.

As you say, the drone has to stay in rc range during the mission for this to work properly.

This all might get a bit too confusing for the user ...

N

 

[OzoneVibe]

Thank you to both @Rockowe for raising this question and, as always, @namirda for the great explanation. Between the two of you I've at last understood something that always bugged me about Litchi missions.

Now to plan things pretending that the POIs I include don't really exist … Okaaaay!

 

[DaveN]

Hello Namirda: I've been flying autonomous Litchi missions for a while and just discovered & tried your simulator (V2.3.0) - well done! Now for a question.

When my current mission is exported as a csv file into GE, I get several warning messages in the sidebar stating 'Warning - Excessive Altitude Change for leg xx' while the simulation seems fine. What are the criteria which trigger this warning? Is this based on a performance limitation like rate of climb or total altitude change between waypoints for the drone? I've tried several dummy missions with various changes of speed & altitude and speed seems to be irrelevant. Altitude changes of >100 feet up between waypoints frequently trigger the warning. Is this a 'heads-up' warning about the possibility of terrain changes in between distant waypoint pairs? What am I overlooking?

TIA and kudos for a great program... Dave

Edit: I found the relevant values in the 'Setup' menu for VLM - I had not opened it previously - my goof.

 

[Rockowe]

 

[DaveN]

VLM is great and it has really improved my chances of getting the camera shots I want on the first flight. Now a question regarding a possible new feature:

I'm frequently in areas with significant altitude change requirements which result in warning messages: 'Warning - Excessive Altitude Change for leg xx'. Lowering the speed for that leg solves the problem but I have to iterate to an acceptable value which reloads GE each time. The speed calculation data needed (altitude change, max acceptable climb/descent rate, leg hypotenuse & speed) is already available within VLM - is it feasable to add a line below the warning which states the maximum speed which can be used for that leg (i.e. Max. Allowed Speed = xx MPH)? Otherwise no warning is good news.

Thanks!

 

[namirda]

VLM is great and it has really improved my chances of getting the camera shots I want on the first flight. Now a question regarding a possible new feature:

I'm frequently in areas with significant altitude change requirements which result in warning messages: 'Warning - Excessive Altitude Change for leg xx'. Lowering the speed for that leg solves the problem but I have to iterate to an acceptable value which reloads GE each time. The speed calculation data needed (altitude change, max acceptable climb/descent rate, leg hypotenuse & speed) is already available within VLM - is it feasable to add a line below the warning which states the maximum speed which can be used for that leg (i.e. Max. Allowed Speed = xx MPH)? Otherwise no warning is good news.

Thanks!

Hi Dave,

Yes - of course that is possible and I will add it in the next release - although I'm not sure when that will be.

VLM is a fairly mature product now - there are no bugs being reported and I don't have any ideas for significant new features so it may be a while before I have sufficient reason to make a new release.

Thanks

N

 

[DaveN]

A minor item I've noticed...

If the heading for a leg is set to 0 or 360 degrees (the heading slider limits), this later creates a 'Warning - No heading specified for WPxx' message when exporting to GE. A one degree change from these values clears the warning. Obviously this warning creates no risk but when I'm iterating the flight parameters, the orange color catches my eye every time. When evaluated for export, I'm guessing the heading limits are being tested as 'greater than 0' and 'less than 360'.

And a question - I'm planning an extended terrain-follow flight in a location in the mountains of northern Chihuahua State in Mexico. The mountain peaks there are rounded and not cliffs. Is there a way to find out what the spacing of the DEM used by VLM is there? The virtual terrain appears to be accurate. A topo map of the area shows 20 meter contours. Part of the time the drone will be out of comm range and I'm having to adjust altitudes downward to get the video I want when the gimbal angle cannot be changed.

TIA... Dave

 

[namirda]

A minor item I've noticed...

If the heading for a leg is set to 0 or 360 degrees (the heading slider limits), this later creates a 'Warning - No heading specified for WPxx' message when exporting to GE. A one degree change from these values clears the warning. Obviously this warning creates no risk but when I'm iterating the flight parameters, the orange color catches my eye every time. When evaluated for export, I'm guessing the heading limits are being tested as 'greater than 0' and 'less than 360'.

And a question - I'm planning an extended terrain-follow flight in a location in the mountains of northern Chihuahua State in Mexico. The mountain peaks there are rounded and not cliffs. Is there a way to find out what the spacing of the DEM used by VLM is there? The virtual terrain appears to be accurate. A topo map of the area shows 20 meter contours. Part of the time the drone will be out of comm range and I'm having to adjust altitudes downward to get the video I want when the gimbal angle cannot be changed.

TIA... Dave

The warning is generated when the csv file contains a heading is zero. I introduced this warning because I found it all too easy to create a mission using either Litchi's Manual (UC) or Custom (WD) mode and then forget to correct the heading..

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....

 

[DaveN]

I looked up info on the SRTM data and found the current DEMs now resolve to 1 arc-second (30 meter increments) globally. Some time ago this was only within the US and 3 arc-seconds everywhere else. I suspect this is what Google's API taps into if you pass coordinates to it. The 2nd link states "...data points posted every 1 arc-second ". I checked my location of interest in Mexico and the metadata for the image stated 1 arc-second resolution - yay! Now if it could only tell me the height of the trees I need to stay above...

Meanwhile there's a familiar site near me which has tall (~200 ft) vertical cliffs in a narrow canyon - I'm curious (and optimistic) what a virtual mission there will show - time to get busy!

Dave

Public Announcement re DEM Data
USGS SRTM Overview
USGS Earth Explorer - SRTM Images

 

[EyeFlightDrone]

Thank you very much and many blessings. I can't believe what we can do now. It's like a dream.

 

[AcesHigh]

Sorry for the stupid question but i am confused. What do i need VLM for when i can "Export as KLM 3D Path" in Litchi's Mission Hub and open that file in Google Earth?

 

[Tajino]

Sorry for the stupid question but i am confused. What do i need VLM for when i can "Export as KLM 3D Path" in Litchi's Mission Hub and open that file in Google Earth?

VLM gives you a simulated FPV view of the mission, timing, etc, while export KML path only shows the flight path without knowing how the FPV would look like and other useful info needed to fine tune the mission. Not to mention the automation that saves you multiple redundant clicks to import and export.

edit : should read KML path not KLM

 

[AcesHigh]

Thank you Tajino
Now I understand. I thought with the KLM file i can already make a virtual fly in Google Earth.

 

[OzoneVibe]

Thank you Tajino
Now I understand. I thought with the KLM file i can already make a virtual fly in Google Earth.

You could - but you wouldn't automatically get all the correct camera tilt/heading info to simulate the actual mission correctly.

 

[DaveN]

Sorry for the stupid question but i am confused. What do i need VLM for when i can "Export as KLM 3D Path" in Litchi's Mission Hub and open that file in Google Earth?

VLM also flags mission legs which exceed the drone's rate-of-climb/descent capabilities. This and the ability to see my camera angles before flying have made a big improvement in saving time for me, especially when the flight plan goes out of comm range due to obstacles.

 

[causalloop]

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)?

 

[Brojon]

You specify the camera angle as part of your missions. You can choose the specific angle or have it point at a POI and it will adjust automatically to stay pointed at that object. You can change your angle for each waypoint. It will work regardless of being in range IOW connected.
If you are referring to FPV flight then no - out of range is out of range.

 

[causalloop]

Sorry, not FPV flight - that one is as expected. Some earlier posts indicated that if you have the mission hitting waypoints and pointing at some POI, and its out of range, then the aircraft will orient to point at the POI, but not do anything with the gimbal - which is consistent with what I've observed thus far.

What I'm curious about is if instead of telling it to either Focus POI or Interpolate, at each waypoint I add an action that sets the camera angle, will that work or is it constrained by the same problem as Focus POI - i.e. can the gimbal do "stuff" automatically when out of range etc.

 

[Former Member]

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)?

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.

 

[Former Member]

Sorry, not FPV flight - that one is as expected. Some earlier posts indicated that if you have the mission hitting waypoints and pointing at some POI, and its out of range, then the aircraft will orient to point at the POI, but not do anything with the gimbal - which is consistent with what I've observed thus far.

What I'm curious about is if instead of telling it to either Focus POI or Interpolate, at each waypoint I add an action that sets the camera angle, will that work or is it constrained by the same problem as Focus POI - i.e. can the gimbal do "stuff" automatically when out of range etc.

It can. But if you are out of range, and are looking to shoot stills or video, it's self defeating if you cant see what your shooting at.