Litchi/P4P - Guaranteed altitude at waypoint?

[uke]

Hi folks

Apologies if this has been answered before. I searched "litchi altitude" and ended up traveling down the rabbit hole and into the tall grass. Amazing stuff out there.

Anyway. I am planning a mission that will climb about 140m in a track distance of approx 813m. The first waypoint is ~110m below the home point, and it will overfly the home point after traveling 813m. Basically It's flying up a steep hill and over the top.

I am wondering if the aircraft is guaranteed to be at the waypoint altitude when it hits the waypoint? I assume that the rate of climb is sufficient, and that the aircraft is not going to arrive at the waypoint lat/long below the target altitude.

Am I correct? Does the autopilot fly the geometric path to the 3D coordinates of the waypoint? Or will it fly to the lat/long, then ascend? Or ascend, then fly to the lat long? I assume that it will adjust horizontal speed to ensure meeting the target altitude, but I wanted to make sure before sending the bird up that scary hill.

All firmware/software is the most current version.

Thanks!

 

[SkyHog]

In my observations, the bird will fly to meet all parameters of the waypoint, to be fully satisfied at the point of arrival at the waypoint. It does not attempt to satisfy one parameter at a time, i.e., it will adjust both altitude and position in a 3D fashion progressively as it flies from one waypoint to another, as well as gimbal pitch, and bird speed/heading. Litchi does not wait until arrival to adjust altitude or any other parameter.

However, if you design waypoints that are too extreme, e.g., the bird is incapable of satisfying altitude changes before arrival, then there are no guarantees of satisfaction of all waypoint parameters on arrival.

 

[Rebelvis]

I concur that the drone will adjust position and height so as to arrive at the waypoint at the programmed position. One thing I would add based on my experience is, give yourself a lot of margin for error in terms of the altitude you set. IOW, in my experience, while the position coordinates are very precise, I would not count on great altitude precision. YMMV.

Hi folks

Apologies if this has been answered before. I searched "litchi altitude" and ended up traveling down the rabbit hole and into the tall grass. Amazing stuff out there.

Anyway. I am planning a mission that will climb about 140m in a track distance of approx 813m. The first waypoint is ~110m below the home point, and it will overfly the home point after traveling 813m. Basically It's flying up a steep hill and over the top.

I am wondering if the aircraft is guaranteed to be at the waypoint altitude when it hits the waypoint? I assume that the rate of climb is sufficient, and that the aircraft is not going to arrive at the waypoint lat/long below the target altitude.

Am I correct? Does the autopilot fly the geometric path to the 3D coordinates of the waypoint? Or will it fly to the lat/long, then ascend? Or ascend, then fly to the lat long? I assume that it will adjust horizontal speed to ensure meeting the target altitude, but I wanted to make sure before sending the bird up that scary hill.

All firmware/software is the most current version.

Thanks!

 

[Meta4]

Anyway. I am planning a mission that will climb about 140m in a track distance of approx 813m. The first waypoint is ~110m below the home point, and it will overfly the home point after traveling 813m. Basically It's flying up a steep hill and over the top.

Just make sure you allow a good safety margin to clear terrain and trees, buildings etc because the mission will put your Phantom exactly where you program it whether there are obstacles in the way or not.

 

[uke]

Thanks to all. That answers my question.

Yes, I plan to give it a big margin, at least for the first flight. Way higher (50m) than I want for the actual filming. I need to verify that the mapped elevations are accurate. No trees, just nasty rocks. Once I have a test flight or two under my belt, I will tighten it up and aim for a lower altitude over the top.

 

[Ed_2020]

Thanks to all. That answers my question.

Yes, I plan to give it a big margin, at least for the first flight. Way higher (50m) than I want for the actual filming. I need to verify that the mapped elevations are accurate. No trees, just nasty rocks. Once I have a test flight or two under my belt, I will tighten it up and aim for a lower altitude over the top.

I've experienced great precision for both position and altitude.

Checking logs after the mission, the barometer altitude (or height to be more precise) had a very good match regarding the planned height at the waypoints.

I suggest you create a small mission just to check it all, you will see 50 m is too big of a margin in my opinion.

Maybe the most important factor is that the take off point is really where it should be, regarding mission altitudes.

 

[Rebelvis]

FWIW, I would fully expect the logs to closely match the programmed waypoint altitude. That does NOT guarantee either were accurate. Again, best advice is leave some margin for error in terms of altitude.

I've experienced great precision for both position and altitude.

Checking logs after the mission, the barometer altitude (or height to be more precise) had a very good match regarding the planned height at the waypoints.

I suggest you create a small mission just to check it all, you will see 50 m is too big of a margin in my opinion.

Maybe the most important factor is that the take off point is really where it should be, regarding mission altitudes.

 

[Fester]

My testing with Litchi (limited to this point, but no problems yet) my last trial was 3 or so waypoints done from Home, up 200' AGL to a second waypoint also at 200' then descent to my final waypoint at round 30' to finish the mission and hover. Seem to hit waypoint altitudes on the money, and I must admit it was pretty gratifying to see it descend a nice linear slope from 200' to 30' and hover as I watched. I'm in a fairly steep, mostly forested valley so most any flight for me involves either an initial climb over home point to treetop clearance altitude (and plenty of margin), or "staged" waypoint altitudes to follow the slope contours. Before doing this in Litchi though I usually use the GO app to scout out the altitude required, then do some limited Litchi hub waypoints to make sure I'm "on the same page" with both apps.

 

[dolphindancer]

I am struggling with mission altitudes. I've no problem creating paths in Google Earth Pro and importing it as a KML to Litchi's Mission Hub to create a waypoint mission. Uploading to the P4P results in the drone flying the path's horizontal alignment and performing whatever is programmed to occur at each waypoint.

My Litchi problem is altitude... I can't seem to program the drone to refer it's altitude to anything other than the home point elev. I've tried importing GE paths "clamped to the ground" and "relative to the ground".

I tried batch editing the mission--once syncd to the ipad--
to reflect "ground" elev per Google at the waypoint. Saving the mission and then loading to the drone. Seems to refer right back to the home point for height reference.

Save for my struggle with altitude, the app seems ok.

What I'm trying to do is create a path that "flies" over variable ground elevations. I would like the drone to recognize the Google Earth surface elev beneath each of the path's waypoints and maintain the height I specify above it.

Sorry if I seem befuddled... I've flown 5 small test missions today and all refered the altitude to the home point.

Counsel Appreciated

Thanks
DD

 

[SkyHog]

I don't think you can expect the Phantom to do that. It would essentially require each bird to carry around a Google Earth representation of terrain elevation that can be correlated with drone position. Or, carry a radar altimeter to measure ground level wherever it goes. Both are impractical. The Phantom only has a very simple solid state chip barometer, with which it can easily reference altitude to some earlier point in the mission, e.g., the takeoff altitude. The bird has no way of knowing actual terrain elevation at any other point. (I'm ignoring the special sensors that only work within a few feet of the ground for landing).

So the most practical thing to do, is run your mission virtually in Google Earth, before you load it into the bird, just as you are doing now, while taking the extra step to make sure your waypoint altitudes account for the terrain elevation along the path. I do that by just running the cursor along the waypoint path in Google Earth while I watch the terrain elevation as reported in the lower right of the GE screen. If terrain varies too much, I adjust the waypoint altitudes to maintain approximate AGL altitude I want.

I understand why you'd like the capability you are asking for. It would be cool to fly the bird in a litchi mission with some nap-of-the-earth altitude that keeps the camera at a fixed altitude above ground, for example. But fundamentally, the only thing the bird can deal with is altitude above the takeoff point, because that is all it can see while in flight.

It's just like flying real airplanes. Your autopilot doesn't fly according to a programmed set of terrain elevations (AGL). It only flies according to programmed barometric altitudes (MSL).

 

[tevek]

I am struggling with mission altitudes. I've no problem creating paths in Google Earth Pro and importing it as a KML to Litchi's Mission Hub to create a waypoint mission. Uploading to the P4P results in the drone flying the path's horizontal alignment and performing whatever is programmed to occur at each waypoint.

My Litchi problem is altitude... I can't seem to program the drone to refer it's altitude to anything other than the home point elev. I've tried importing GE paths "clamped to the ground" and "relative to the ground".

I tried batch editing the mission--once syncd to the ipad--
to reflect "ground" elev per Google at the waypoint. Saving the mission and then loading to the drone. Seems to refer right back to the home point for height reference.

Save for my struggle with altitude, the app seems ok.

What I'm trying to do is create a path that "flies" over variable ground elevations. I would like the drone to recognize the Google Earth surface elev beneath each of the path's waypoints and maintain the height I specify above it.

Sorry if I seem befuddled... I've flown 5 small test missions today and all refered the altitude to the home point.

Counsel Appreciated

Thanks
DD

FWIW, I only plan my missions on the device app as its more convenient in the event I stop somewhere and decide to fly. Once I've set my first WP height, I use the batch editing tool to make all subsequent WPs relative to ground and run the mission like that. The drone will climb and descend along the way and fly just fine.
Just need to make sure that you are well above the highest structure that is visible and that your RTH height will clear everything in the event that you want to cancel the trip or something untoward happens.

 

[dolphindancer]

I don't think you can expect the Phantom to do that. It would essentially require each bird to carry around a Google Earth representation of terrain elevation that can be correlated with drone position. Or, carry a radar altimeter to measure ground level wherever it goes. Both are impractical. The Phantom only has a very simple solid state chip barometer, with which it can easily reference altitude to some earlier point in the mission, e.g., the takeoff altitude. The bird has no way of knowing actual terrain elevation at any other point. (I'm ignoring the special sensors that only work within a few feet of the ground for landing).

So the most practical thing to do, is run your mission virtually in Google Earth, before you load it into the bird, just as you are doing now, while taking the extra step to make sure your waypoint altitudes account for the terrain elevation along the path. I do that by just running the cursor along the waypoint path in Google Earth while I watch the terrain elevation as reported in the lower right of the GE screen. If terrain varies too much, I adjust the waypoint altitudes to maintain approximate AGL altitude I want.

I understand why you'd like the capability you are asking for. It would be cool to fly the bird in a litchi mission with some nap-of-the-earth altitude that keeps the camera at a fixed altitude above ground, for example. But fundamentally, the only thing the bird can deal with is altitude above the takeoff point, because that is all it can see while in flight.

It's just like flying real airplanes. Your autopilot doesn't fly according to a programmed set of terrain elevations (AGL). It only flies according to programmed barometric altitudes (MSL).

Thanks for your reply and reminding me of the barometric referencing in the P4P. The barometric sensor allows the onboard computer to relate the vertical position of the takeoff point to the atmospheric pressure at that position. If the drone is flown above the takeoff point, the sensor sends a reduced pressure reading to the computer which then calculates the vertical differential in meters or feet. (An approximation: 1" Hg change in barometric pressure = 1000' change in altitude.) One would hope that the P4P's barometer is really sensitive.


I understand the need to have the takeoff point's elevation accurately refer to the same datum as the variable elevations of the waypoints created by the path one plots on Google Earth.

Sort of like making sure the reading in Kollsman window reflects the pressure at the nearest airport.


I do confirm the waypoint elevs on the test missions so am still left with wondering why the drone does not descend or climb to that specified AGL above variable waypoint elev but remains at what appears to be the same elev throughout the mission.


This relates to your comment on nap-of-earth drone flight…


According to Litchi, that can be approximated by importing a Google Earth path KML to Litchi Mission Hub. The resulting mission is sync’d to the iPad. Opening the iPad Litchi app and loading the mission one can select the Block Edit dropdown. Select All, Edit, and the

Batch Waypoint Settings window is displayed. The first value displayed is Altitude: the desired height above the waypoint and what the height is relative to. Clicking on the box (I think HOME is the default) reveals three choices: HOME, CURRENT, and GROUND. So I read Litchi’s description of the GROUND choice as a way to cause the drone to approximate nap-of-the earth flight if the waypoints were frequent enough and accounted for break lines in the Google topography. Recall that GROUND is the Google Earth derived waypoint elev programmed into the mission. So the drone does know what the GROUND elev is at each waypoint.


I have tried to Batch Edit the altitude relative to read GROUND. I select it then save the mission. However, when I reload the saved mission and go to the Batch Waypoint Settings, I note the altitude reads HOME?


I always assume I’m missing some step or sequence so any comment or counsel is appreciated


Thanks to all for your help and suggestions

DD



I attached a link to Litchi Manual and a screen snap of Block Ed.


Litchi for iOS February 2017.pdf

 

[dolphindancer]

FWIW, I only plan my missions on the device app as its more convenient in the event I stop somewhere and decide to fly. Once I've set my first WP height, I use the batch editing tool to make all subsequent WPs relative to ground and run the mission like that. The drone will climb and descend along the way and fly just fine.
Just need to make sure that you are well above the highest structure that is visible and that your RTH height will clear everything in the event that you want to cancel the trip or something untoward happens.

tevek

Thanks for your suggestion. I do a lot of specific location reconaissance and therefore need to pre plan almost every
flight on Google Earth. I will try your method; perhaps the batch editing tool is for missions planned on the app only.

I find the drone (P4P) an amazing device. I look forward to drone technology and developement becoming a large part of today's
aerial imagery. We do GPS control surveys and I read recently that a drone is in developement that will allow RTK centimeter accuracy of the focal plane of the onboard camera!

Hard to keep up...

Cheers
DD

 

[SkyHog]

Clicking on the box (I think HOME is the default) reveals three choices: HOME, CURRENT, and GROUND. So I read Litchi’s description of the GROUND choice as a way to cause the drone to approximate nap-of-the earth flight if the waypoints were frequent enough and accounted for break lines in the Google topography. Recall that GROUND is the Google Earth derived waypoint elev programmed into the mission. So the drone does know what the GROUND elev is at each waypoint.
Litchi for iOS February 2017.pdf

I agree that the words in the manual actually say that the altitude can be referenced ground "at each waypoint". It sure sounds like it should work the way you are trying to make it work. I can imagine this is possible if the mission is created with Google Earth on the app, just as you discussed earlier. I'd guess the drone just gets the altitude that has been translated into the equivalent barometric altitude for the "ground reference" altitude that is presented to the user interface on the phone. In any case, it should work, according to the manual. I've not tried it that way, so I can't be sure.

By your observations, it sounds like they might just be referencing all waypoints to the ground level at home point instead, which would make the drone fly exactly as you observed. That isn't consistent with the wording in the manual.

 

[chucky lad]

Latest version of Litchi you can select all waypoints and give them a group , or individual heights relative to the ground level at the waypoint rather than relative to the home point. No need for the KML file. I assume the mission hub incorporated that data from google earth when it creates the mission you have coded. Seems to work well and if that is the case all you need to be aware of is height of obstacles above ground level eg trees power lines and towers. Also as mentioned previously, flying a to b, and allowing for high obstacles in the geometric ascent or descent is necessary
www.youtube.com/c/chuckylad

 

[SkyHog]

Latest version of Litchi you can select all waypoints and give them a group , or individual heights relative to the ground level at the waypoint rather than relative to the home point. No need for the KML file. I assume the mission hub incorporated that data from google earth when it creates the mission you have coded. Seems to work well and if that is the case all you need to be aware of is height of obstacles above ground level eg trees power lines and towers. Also as mentioned previously, flying a to b, and allowing for high obstacles in the geometric ascent or descent is necessary
www.youtube.com/c/chuckylad

Yes, I think the newest version does work exactly as you outlined. However, I have found that this feature still isn't a substitute for the KML file method using Google Earth, or at least a manual check and calculation of everything in the flight path in Google Earth anyway. It's true that Litchi will now let us set waypoints with reference to ground elevations, AT the waypoints, but not along the path between waypoints. In terrain like the rolling hills of Virginia, it's sometimes very difficult to visually see the peak of the hill in the imagery in Mission Hub, and an elevation rise might be in the path between waypoints. So I always end up opening Google Earth so I can cursor through the entire mission path, to be sure my altitudes are sufficient to clear nearby elevation rises. Often I have to change the mission plan to set waypoints at those tops, just to be sure I clear them. It's essentially the same work I had to do before the new feature was introduced in Litchi.

But I'm not complaining, I like the new feature for other reasons. It certainly makes waypoint planning easier and more intuitive over relatively flat terrain, where the only thing we need to worry about are the trees and/or cultural obstructions (buildings, wires, etc). It's easier to set altitudes above ground level for things like that, without having to do the math for conversion to home point reference altitude.

 

[chucky lad]

Absolutely. Have had a few experiences and much more conservative now. Nothing like seeing your drone drop out of the sky to sober ones views. Yes I check the "topography" etc anyway I can including physically but there comes a time in these sorts of flights where the sphincter does a few situps because you are down to "hope".