That should not happen if you create it in the Litchi Mission Hub and then open the flight in a (free) program Virtual Litchi Mission. Once opened, you output as csv and it will automatically open in Google Earth with the height data included.
1 Like
Are there any known issues with using a Litchi waypoint mission where the drone is moving backwards?
I was on site yesterday performing some tests of a simple 2x waypoint mission. The camera started by moving backwards from point A to point B, and at the same time climbing from 50m to 80m altitude. Also, during this movement, the drone rotated around 90 degrees clockwise, and the gimbal pitch changed from -3 to -12 degrees.
For some reason, as soon as the drone began moving from point A, the gimble seemed to jerk downwards quite erratically.
Any known issues?
Maybe it was just the wind it was fighting against.
Can you share the mission @phutureproof so someone can take a look at how itās set up?
1 Like
Not totally sure how to do that, but here is a theoretical mission path.
TheoreticalMission.zip (278 Bytes)
Also, on all my missions so far, Iāve wanted to smoothly accelerate from waypoint 1 and decelerate into the final waypoint. How do I do this on a simple, linear, straight mission such as this?
Any help hugely appreciated.
If you set each waypoint as interpolate the camera angle and speed should smoothly change from the values at waypoint x to the values at waypoint x+1
Hereās a link
Where do you set interpolate cam angle and speed? I can see interpolate gimbal pitch, but not speed/angle.
You might want to read about POI and adding something for the camera to aim at, as for speed changes , add more way points and specify the speed at each
Thanks milkmanchris.
Iām controlling the viewing direction by heading (which in turn has been set up in Google Earth Pro), so I donāt really have POIs.
I have wondered about adding more waypoints in between, but not really sure what to set their speeds to. For instance, the drone speed is set to cruising speed for this run, which is 20km/h. Where would you set intermediate points and what speed would you set them to?
Hereās a screengrab of this mission:-
If you want it to come to a stop at the end add one half way with half the starting speed
Thanks for sticking with me milkmanchris (and apologies for so many Qs).
I want to start smoothly (accelerate in).
I want to end smoothly (decelerate out).
Is this what I should do:-
Waypoint 1 (start) - speed = 0km/h (or as close to zero as possible)
Waypoint 2 (halfway) - speed = 20km/h
Waypoint 3 (end) - speed = 0km/h (or as close to zero as possible)
?
1 Like
Thats exactly right.
Thank you. Iāll give it a try.
I am āpre-visualisingā this using Virtual Litchi Mission and Google Earth. It seems that doing it this way does not respect the speed of the movements. At least I hope that is the case as the total camera movement takes absolutely ages with these values!
Hereās a screenshot of this mission. Iāve set the start and end point to be 1km/hr and the mid points to be 30km/h. Total journey time according to Litchi is 27 minutes!!!
Is that figure just wrong, or is it a bug?
Check you have no wait times in your waypoints
Just 20 seconds at first and last (as I need some locked-off video at the beginning and end of shot)
Share the plan again Iāll have a look.
In phone at mo so might be a while getting back to you
Iāve now carried out a few tests with litchi for this type of mission. Each and every time I use it I seem to find a new issue! Always quite tricky āin the fieldā to solve these things.
What I have ādiscoveredā is that with any waypoint mission, the first waypoint always screws up.
e.g.
I have a 5 waypoint mission. At each waypoint, I want a photo taken, either looking at a particular POI or just with a particular heading/gimbal rotation.
The mission begins and looks good, however, the first position isnāt pointing in the correct direction.
This seems to happen with photos and videos.
The solution (which is a bit crap) is to always create a second waypoint just after the first (and in a similar location to the first) and have that be the āfirstā waypoint instead. The first waypoint is then a āsacrificialā waypoint, and the second waypoint is the new first.
A quick google on this suggests others are having the same problem. Can anyone confirm this?
The other thing I learned is that the speed controls donāt really work. As you will see from my questions higher up, I wanted the M2P to smoothly speed up out of the first waypoint and gently slow down into the last. Setting the first and last waypoints to 1km/h and a middle waypoint at 30km/h created stupidly long total flight durations. I need to do some further testing and experimentation, but clearly Litchi needs to give speed curve controls.
I have never had any of the issues you mention. Litchi will always over-estimate the time taken to fly the mission and the one shown above will probably take in the region of 20-22 mins. If you use Virtual Litchi Mission and then output the flight to Google Earth, it will show you more or less exactly what you have set up (gimbal direction, height etc) and also show you a more accurate mission time. Looking at your first leg on the mission, 340m at 1km/h will take approximately 20 mins at that speed.
Most people who have issues with Litchi tend not to have set up everything properly (another reason to use VLM as a good visual check). With regard to speed, the speed change wont take effect until you reach a waypoint, when the drone receives itās next instruction. The only thing that will change smoothly between WPs is the gimbal direction, starting at the position set in one WP and gradually changing to the direction in the next.
With regard to āspeed curve controlsā, perhaps you should email Litchi with a change request? In the meantime, to slow down more gradually, add some more WPs, using gradually faster or slower speeds at each (depending if you want to speed up or slow down).
I hope all this helps.