Virtual Litchi Mission

[namirda]

Hi
Yes that's clear thanks. Unfortunately, any mission I run, whether my own or a discover mission, flies at an incorrect altitude (approx halfway down the 'curtain'), sometimes below ground. It doesn't matter whether the waypoints are defined as above ground or not. Using either WP1 or user seems to make no difference. I am probably missing something obvious, but I have tried everything I can think of. I will stick to using the older version for now.
Thanks

I wonder what's going wrong here- sounds very odd. Would you mind making your mission public in Litchi Discover so that I can take a look at it? Let me know the location/name so I can find it.

It's late here now but I will try to look at it tomorrow...

N

 

[Dude]

Wondering if anyone else has this small issue:
when I run the virtual mission, the Litchi Hub shows the flight duration of 16 minutes, yet the log shows the Mission Duration is 18.43 minutes. And the mission runs seemingly slower (my cruise is 20.1mph).
Just for testing purposes, I decreased the cruise speed to 10mph and the Litchi Hub shows the mission with an increased mission time of 30 minutes, yet on the log, after saving and re-uploading, it still shows 18.43 minutes.

Otherwise, this is an awesome tool!

Joe

 

[namirda]

Wondering if anyone else has this small issue:
when I run the virtual mission, the Litchi Hub shows the flight duration of 16 minutes, yet the log shows the Mission Duration is 18.43 minutes. And the mission runs seemingly slower (my cruise is 20.1mph).
Just for testing purposes, I decreased the cruise speed to 10mph and the Litchi Hub shows the mission with an increased mission time of 30 minutes, yet on the log, after saving and re-uploading, it still shows 18.43 minutes.

Otherwise, this is an awesome tool!

Joe

Hi Joe,

I have also noticed a discrepancy between the missions times reported by Litchi Mission Hub and VLM - I think the problem is in Litchi rather than VLM. Here's a little test you can do...

1) Remove the complication of curves from your mission (ie set Curve Size to zero for all waypoints).

2) Make sure all waypoints are using the cruising speed.

3) Set the Cruising Speed to 20mph in BOTH Litchi and VLM

4) Export your mission.

5) I think you will see that the mission length as reported by Litchi and VLM are the same to within a meter or so. There are different ways of calculating the distance between two points on a spherical earth - I took the rhumb line distance and perhaps Litchi used a different method. Anyway, for all the missions I have looked at, they are very close.

6) You will also note that VLM reports the mission distance after smoothing as being the same - because there is no smoothing in this case. With smoothing applied then the mission distance will be reduced because the drone will 'cut the corners'

7) Compare the mission times reported by Litchi and VLM - they are often different.

8) Calculate your own mission time by taking your mission distance and dividing it by your cruising speed and then multiplying it by 60 to get the answer in minutes. Does your answer agree with Litchi or VLM?


One important point to note is that Litchi does not export the cruising speed in its csv file. That means that you have to set the cruising speed in VLM to match the value set in the mission hub. I suspect that when you repeated your mission using 10mph, you did not change the cruising speed in VLM??

Please let me know your conclusion..

N

 

[Dude]

I'll try it again later and post my results.

Thanks for your support!

 

[Dude]

Namirda, that was it. I forgot I had the ability to adjust my cruising speed in VLM, so once I adjusted to a slower mph, the log showed a relatively slower mission time. I have adjusted the cruising speed equally in both. My default in VLM was 12.4mph.
When I removed the curves for my mission in the hub, the Litchi mission duration did not change: 16min in Litchi/11.56 in VLM. I'm okay with that "window" for planning purposes. Mission lengths between the 2 programs are near identical as you mentioned.

For reference, I added one of my Cabo missions and video to the Litchi Hub. Litchi shows the mission duration is 10minutes, VLM shows 7:32 and I calculated via the video at 8minutes.

Again, no problem with the slight duration differences.

Joe

 

[namirda]

Namirda, that was it. I forgot I had the ability to adjust my cruising speed in VLM, so once I adjusted to a slower mph, the log showed a relatively slower mission time. I have adjusted the cruising speed equally in both. My default in VLM was 12.4mph.
When I removed the curves for my mission in the hub, the Litchi mission duration did not change: 16min in Litchi/11.56 in VLM. I'm okay with that "window" for planning purposes. Mission lengths between the 2 programs are near identical as you mentioned.

For reference, I added one of my Cabo missions and video to the Litchi Hub. Litchi shows the mission duration is 10minutes, VLM shows 7:32 and I calculated via the video at 8minutes.

Again, no problem with the slight duration differences.

Joe

Thanks for the feedback Joe.

I wonder how Litchi come up with 16 minutes to fly a mission of 4.1km at 20km/h (12.4mph) !! If you ever get to understand their arithmetic then please let me know!

I 'flew' your 'cabo around the horn' mission - looks a really nice area!

N

 

[Radagast]

Would you mind making your mission public in Litchi Discover

Sorry I am not sure how to do this.
Mission Hub - Litchi is a link to one of my missions if that helps.
But my issue is viewing ANY mission, eg 'cabo around the horn' flies halfway down the 'curtain' for me

 

[namirda]

Sorry I am not sure how to do this.
Mission Hub - Litchi is a link to one of my missions if that helps.
But my issue is viewing ANY mission, eg 'cabo around the horn' flies halfway down the 'curtain' for me

Hi,

Your Pendennis Castle mission looks just fine from here. When I display the 'Smooth Flight Path' in the diagnostics folder of your mission in Google Earth I see the 'curtain' as I expect - ie the top of the curtain should be in the middle of the screen.

In the case of your mission it looks a bit strange because all your waypoints are in a straight line with the elevation increasing towards the end of the mission and with the camera facing forward. If you switch on the 'waypoint labels' it might be more clear what's going on.

As you fly your mission, Google Earth shows the elevation at the bottom right of the screen (eye at xxx m) - do the displayed camera elevations jive with what you expect? Do you think the camera is at the wrong height or is the curtain wrong? You can look at the elevations of each waypoint by right clicking on the relevant 'waypoint label' and selecting properties then altitude.

It's a bit hard to help when it all looks fine from here! However it should be possible to see where the problem is by digging into the mission in Google Earth.

The Google Earth resolution looks great round there - reminds me of childhood holidays..!

N

 

[Radagast]

Hi,

Your Pendennis Castle mission looks just fine from here. When I display the 'Smooth Flight Path' in the diagnostics folder of your mission in Google Earth I see the 'curtain' as I expect - ie the top of the curtain should be in the middle of the screen.

In the case of your mission it looks a bit strange because all your waypoints are in a straight line with the elevation increasing towards the end of the mission and with the camera facing forward. If you switch on the 'waypoint labels' it might be more clear what's going on.

As you fly your mission, Google Earth shows the elevation at the bottom right of the screen (eye at xxx m) - do the displayed camera elevations jive with what you expect? Do you think the camera is at the wrong height or is the curtain wrong? You can look at the elevations of each waypoint by right clicking on the relevant 'waypoint label' and selecting properties then altitude.

It's a bit hard to help when it all looks fine from here! However it should be possible to see where the problem is by digging into the mission in Google Earth.

The Google Earth resolution looks great round there - reminds me of childhood holidays..!

N

Hi,

Your Pendennis Castle mission looks just fine from here. When I display the 'Smooth Flight Path' in the diagnostics folder of your mission in Google Earth I see the 'curtain' as I expect - ie the top of the curtain should be in the middle of the screen.

In the case of your mission it looks a bit strange because all your waypoints are in a straight line with the elevation increasing towards the end of the mission and with the camera facing forward. If you switch on the 'waypoint labels' it might be more clear what's going on.

As you fly your mission, Google Earth shows the elevation at the bottom right of the screen (eye at xxx m) - do the displayed camera elevations jive with what you expect? Do you think the camera is at the wrong height or is the curtain wrong? You can look at the elevations of each waypoint by right clicking on the relevant 'waypoint label' and selecting properties then altitude.

It's a bit hard to help when it all looks fine from here! However it should be possible to see where the problem is by digging into the mission in Google Earth.

The Google Earth resolution looks great round there - reminds me of childhood holidays..!

N

Yes sorry that was not a good example, but when I run that one, the camera goes straight through the castle!
Here is a better example (different parameters), and what I see when I 'fly' it. The camera does change elevation, but always stays below the waypoint pins



This was my hometown when I was growing up, beautiful area!
Thanks for taking the time to try to help me with this, I appreciate it

 

[wywh]

An Intel "Mac" running Windows should be the same as an Intel "PC" but maybe there are driver or GPU issues or other "gremlins" that produce these errors. Anyone?

But Virtual Litchi Mission 1.0.5 runs OK on my MacBook Pro and when I now installed and used it, I didn't even have to manually open a .csv file to get it going (I very seldom boot the MacBook Pro to Windows and lately Windows 10 was updated).

Attached are four image pairs:

a) Virtual Litchi Mission 1.0.5 & GE

b) the actual P3P mission at about the same spots. Google Maps images are a few years old summer scenery without some new buildings.

In this mission the final image area is slightly wider and slightly taller than planned via VLM 1.0.5 & GE.

Google Earth flattens the buildings but Virtual Litchi Mission is a GREAT help when pre-planning the mission. Now I'm more on the right ballpark just how wide and tall the captured image area is from the desired altitude!! Thanks.

 

[namirda]

View attachment 33785

Yes sorry that was not a good example, but when I run that one, the camera goes straight through the castle!
Here is a better example (different parameters), and what I see when I 'fly' it. The camera does change elevation, but always stays below the waypoint pins

View attachment 33786View attachment 33787View attachment 33788

This was my hometown when I was growing up, beautiful area!
Thanks for taking the time to try to help me with this, I appreciate it

Yes - that certainly looks wrong.

It looks as if you might have a strange value for 'Elevation Exaggeration' set in Google Earth. Go to Google Earth/Tools/Options and make sure that 'Elevation Exaggeration' is set to 1. Does that help?

Also your screen shots do not show the camera elevation on the bottom right - select the checkbox View/Status Bar and check that the eye elevation is what you expect.

N

 

[namirda]

When I try to launch VLM 2.0.0 I get an error message:

System.IO.FileNotFoundException: Could not load file or assembly 'CefSharp.Core.dll' or one of its dependencies. The specified module could not be found.
File name: 'CefSharp.Core.dll'

AFAIK VLM installed the prerequisites (I tried to separately install .NET4.6.2 but it was already installed).

If I ignore the error, then in VLM 2 the Mission Hub panel is grayed out (should it be the Google Chrome window?). I can open the "real" Google Chrome and Mission Hub, export .csv, go to VLM 2 and manually open .csv and from there to GE. I have to open VLM as an administrator because otherwise there is an error message in its log:

Access to the path 'C:\Program Files (x86)\Namirda\Virtual Litchi Mission\missionname.kml' is denied.

VLM 1.0.5 worked, but with each session I first had to manually open a .csv file to get it going and automatically open the .csv, make the GE icon active and feed the info to GE.

(MacBook Pro running Windows 10 Pro 1709 16299.15 via BootCamp)

I have been doing a little reading about PC emulation on Macs and learned that Macs are allergic to 32bit applications. I wonder if that is the problem when you try to run VLM in BootCamp.

The previous version of VLM V2 was compiled with the standard 'any CPU' options which means that it contains some 32 bit code and I wonder if this is the cause of your problems.

I have compiled a pure 64 bit version which may solve the problem - it doesn't hurt to try! Here's the link Dropbox - VLM 2.0.0 (x64) Setup.zip

No guarantees because I don't have a Mac to try it on - this is just a shot in the dark.

This version will of course also run on a 64bit PC but will NOT run on a 32bit PC

Please let me know if it helps.

N

 

[Radagast]

Go to Google Earth/Tools/Options and make sure that 'Elevation Exaggeration' is set to 1. Does that help?

It certainly does!
It was set to 1.5, reset to 1 and now everything runs perfectly.
Thank you again namirda for the help. This is an extremely useful tool, which will get a lot of use from me

 

[wywh]

I have compiled a pure 64 bit version which may solve the problem - it doesn't hurt to try! Here's the link Dropbox - VLM 2.0.0 (x64) Setup.zip

Thank you!! VLM 2.0.0 (x64) works OK on a MacBook Pro 15,4” (i7 2.2GHz, 16 GB RAM, 256 GB SD) running Windows 10 Pro via Boot Camp.

AFAIK unlike emulation software like VMware Fusion, Parallels and Virtual Box that run while booted into OS X or macOS, Boot Camp runs Windows on bare metal with no emulation (as far as I know, "Boot Camp" software might not really even needed -- it just provides end users the workflow to prepare the correct Windows partition format + some drivers to make the mouse pad, volume/brightness keys, startup disk selection etc to work in Windows).

So it seems the reason for the initial errors was that my MacBook Pro is 64-bit only.

...

My old memo:

"Traditionally, "Boot Camp" has been a conglomeration of two separate things:

1) A compatibility module residing in the system firmware (an EFI module) that provided the ability to boot legacy MBR-based operating systems
2) A set of drivers packaged by Apple that was more or less guaranteed to install all required drivers for your system

The CSM (compatibility module) was depreciated and removed from the 2013 Mac Pro, and now several of their laptops as well. That is because Windows 8 (or newer) is capable of booting directly from EFI without the compatibility layer in-between (and therefore an MBR partition).

As far as I know, Apple isn't really even providing driver packages anymore since these operating systems generally support the Macintosh hardware OOTB. This had happened before as well, certain systems like the MacPro1,1 were capable of running Windows 7 or newer (even though Apple didn't list support for those)- you just had to go out and find the drivers yourself, which was fairly easy since nothing in that machine was really proprietary.

So really, the story should be that Boot Camp has been removed from these Macintosh systems, because it no longer exists. There's no more CSM for booting legacy operating systems and the drivers mostly work OOTB. The recent versions of Windows are capable of booting directly on the machine WITHOUT "Boot Camp".

 

[namirda]

Now I'm more on the right ballpark just how wide and tall the captured image area is from the desired altitude!! Thanks.

Good that the x64 version worked for you!

One comment on your statement above about using VLM to judge how wide and tall the final captured image would be:

I have found it important to view the VLM Mission in Google Earth using the same aspect ratio as you intend to use in your recording. Maybe that's obvious but it took me a while to understand why I was chopping off stuff at the top and bottom of my recording.

Assuming you intend to record at 16:9 then you need to make sure that your Google Earth viewing window is also 16:9. If your PC screen is also 16:9 as most are these days, this means that you have to close the Google Earth sidebar to allow the viewing window to take up the entire 16:9 screen. Alternatively, you can specify a 16:9 viewing window in Google Earth using the menu View/View Size.

If you omit to do this then Google Earth will show you more at the top and bottom of the screen than you will record and fool you into thinking your recording will be 'taller' than it actually will be.

Just my two pence worth...

N

 

[sowega]

namirda,

have downloaded and installed your 64 bit version on my MacBook Pro running Parallel vice bootcamp and it works perfectly....THANKS!...your program is really amazing and will be very helpful in planning missions and tweaking them to meet expectations thereby saving time and effort for each mission...great work!!!

 

[wombat]

Just trying out VLM v2 and have a problem, see pic

 

[Wapiti16]

This is incredibly useful!! I can't imagine how much work this would have taken. You ought to charge for this or Litchi should buy your work. Nice work!

 

[namirda]

Just trying out VLM v2 and have a problem, see pic
View attachment 34426

Hi,

Click on the VLM menu "Show/Activity Log" - I think this is probably what you are missing.

Try looking at the "Show/Profiles" as well - it's quite useful

N

 

[wombat]

This is incredibly useful!! I can't imagine how much work this would have taken. You ought to charge for this or Litchi should buy your work. Nice work!

ditto

thank you namirda, will try that today