Hi

It was my chance to test Terrain Awareness Filght today.

Everything was good except resuming flight after changing battery. Each time I changed battery and wanted to continue flight mission, flight height became 40 meters lower from original flight height that I set during flight mission design.

Has anybody seen this problem?
What have I done wrongly?

sincerely,

yikes that sounds bad. have not tried but eager to hear what other folks have experienced around this...

patiam Posted at 7-2 20:21
yikes that sounds bad. have not tried but eager to hear what other folks have experienced around this...

I tested it another day and think that take off height is measured based on first waypoint.

If your height is 1500 meter and first waypoint height is 1400 meter and flight height is 130 meter above ground, drone goes to 30 meter height above ground and moves toward first waypoint at that elevation.

This procedure is dangerous because of possibility of striking obstacles.

What was your process for importing the DSM and where did you get the data to create the DSM?

barnumb2 Posted at 7-8 06:48
What was your process for importing the DSM and where did you get the data to create the DSM?

I use SRTM data in my works.

SRTM is readily available. There are other threads here on the forum discussing how to get DSM data into the app.

SRTM is readily available. There are other threads here on the forum discussing how to get DSM data into the app.
لعبة من سيربح المليون - لعبة جاتا - لعبة صب واي - لعبة زوما

SRTM is readily available.
http://www.winmilliongame.com
http://www.gtagame100.com
http://www.subway-game.com
http://www.zumagame100.com

jivago Posted at 7-5 22:38
I tested it another day and think that take off height is measured based on first waypoint.

If your height is 1500 meter and first waypoint height is 1400 meter and flight height is 130 meter above ground, drone goes to 30 meter height above ground and moves toward first waypoint at that elevation.

Eager to know more about the issue. I will be going to have a flight soon.

Hi
I prepared a complete document for review about big shift between ground elevation from GPS and Drone elevation.

Flight altitude was 50 to 70 m above ground.
GCP height was approximately 1600 m based on ellipsoid.
Therefore image absolute altitude that was written in the EXIF part should be 1650 to 1670 m, but they were about 1800 meter based on ellipsoid. This means Phantom 4 Pro Flight Controller assumption about altitude was wrong.

In this test I used Phantom 4 Pro but this problem is in Phantom 4 RTK and Inpire 2 either.

Attached Data:
1. Image Center Coordiante
2. Flight Log
3. GCP in that area

sam4498 Posted at 7-8 17:15
SRTM is readily available.
http://www.winmilliongame.com
http://www.gtagame100.com

All of above links is wrong.

Agreed, all of sam4498 posts should be deleted.

patiam Posted at 8-3 08:49
Agreed, all of sam4498 posts should be deleted.

Do you have any idea about shift that I saw in my test flight?

data is available for further investigation.

jivago Posted at 8-3 00:28
Hi
I prepared a complete document for review about big shift between ground elevation from GPS and Drone elevation.

@patiam

jivago Posted at 8-3 09:45
@patiam

love to help but haven't tried DSM Terrain Aware filight myself yet so I don't know what I can offer.
If you want to post data for me to look at I will but I don't see links that work yet.

patiam Posted at 8-3 16:04
love to help but haven't tried DSM Terrain Aware filight myself yet so I don't know what I can offer.
If you want to post data for me to look at I will but I don't see links that work yet.

I forgot it !

jivago Posted at 8-4 00:40
I forgot it !

@jivago-

Can't open your data. WinRar gives me a corrupted or missing archive error.

@patiam


Thank you for your interest. I upload it in new format.

Terrain awareness does not seem to  be in affect whenever the drone is returning to home or resuming missions. I find it safest to manually fly the drone back to the spot it stopped if I'm swapping batteries, and set my RTH altitude to a height that is well above any obstacles in my flight area. Haven't had any issues with the bird flying differently after battery swap.

Tark Posted at 8-19 07:13
Terrain awareness does not seem to  be in affect whenever the drone is returning to home or resuming missions. I find it safest to manually fly the drone back to the spot it stopped if I'm swapping batteries, and set my RTH altitude to a height that is well above any obstacles in my flight area. Haven't had any issues with the bird flying differently after battery swap.

How much was roughness of your area?

If resuming point is lower than where you stay, drone doesn't reach your planned flight height because it gets height based on resuming point.

Hi All, I posted this in another section yesterday but realised it might be better if I ask the question here (as I've gotten no reply yet from my first post).

I'm very new to both this forum and to Drone Photogrammetry in general. My company has just recently invested in a Phantom 4 RTK Drone and base station and I'm in the process of learning how to use it.

So far I've flown two missions, the first at a local park and the second at one of our project areas both with great results and am looking forward to using it more.

I'm currently planning our 3rd mission, to be flown over an existing minesite (now closed) but where we are looking to recommence operations in the future.

I want to explore using the Terrain Awareness Mode on our P4 RTK however I have a question which I am hoping the DJI community can help with.

I have been able to import DSMs into the remote and create flight plans based off this. The DSMs I have however are in the AHD vertical Datum and not Height above GRS 1980 (which I believe is the "GPS" altitude that the drone uses). At this particular location, AHD sits approximately 24-25m above GRS 1980.

My question is, when I've set the flight height for the flight plan to 100m in the Terrain Awareness Mode, will the drone fly at a height of 100m above my DSM, or will it fly at an altitude of 100m above the GPS height but make a correction based on the take off location/base station information? The terrain at this site varies by ~100m and we want to have a constant GSD across the entire survey area. This is important to us as we want the best GSD possible with the time/batteries available (ie. I don't want to fly at 125m above the ground).

This flight is also planned so that it will need several battery changes.

jivago, have you managed to solve your issue regarding the flight height change after the battery swap?

Hey mate,

Be very very careful using terrain awareness mode if you do not have the ability to convert to the DSM to ellipsoidal heights.

It will take the height of the ground, according to the DSM, and calculate its flight altitude as DSM Ground height + 100m.  EG. DSM ground height of 40m would equal flight height of 120m.  

A 25m variance probably won't result in a terrain/tree collision, but your overlap settings could result in a model not being able to be generated.

Ideally, translate the whole DSM Z value by the geoid separation (24-25m in your case) and re-export.  

Good luck

Hi DJI4Survey,

Thanks very much for the tip. I had a feeling that was the case but being new to this wasn't sure.

I'll see how I go reconverting the DSM.

Cheers

dodger_rog Posted at 9-8 16:18
Hi DJI4Survey,

Thanks very much for the tip. I had a feeling that was the case but being new to this wasn't sure.

dodger_rog,

It really depends on the workflow you used to create the DSM. I use global mapper. which allows you to easily add or subtract a fixed number (geoid separation ) from elevation data. It works on SRTM data too. Not sure if there is an open source solution.
Dave

I am still collecting and analyzing data but thought I would share my preliminary thoughts.

Yesterday, we flew two terrain awareness missions over the same area from the same home point. The vertical offset was 100m above the DSM. The elevation data in the DSM was orthometric height.  No base station was used for either flight. For the first flight, we were not connected to an NTRIP server. The second flight we were, and all photos were RTK.

From the EXIF/XMP data from the non RTK flight the average relative altitude was  191 m above the ground, which is 91m higher than it should have been.  Due to experience with the P4P, I suspect this error is related to barometric pressure. When the barometric pressure is anything other then standard 29.92, the P4P EXIF encoded altitude is off 10ft for every 0.01 inHG.   However the P4P flies a relative altitude based on the pressure difference between 29.92 and ambient pressure, which leads to fairly consistent relative altitude, even with terrain following. 91 m is approximately 301 ft, which equates to .3013 inHG. Adding this to 29.92 equals 30.22. The local airport (about 10 miles away from the home point) reported altimeter reading of 30.22 for the time of flight. Stunning coincidence?

The second flight (with rtk)  EXIF/XMP data indicated average relative altitude was 127 m, 27 m higher than the offset.

Initial thoughts:
1) The Phantom RTk doesn't consider home point pressure variation from 29.92
2) The Phantom RTK relative altitude doesn't account for non standard altimeters settings and flies high or low based on ambient barometric pressure.  On high pressure days the drone flies higher than desired , leading to higher GSD and much greater overlap. On low pressure days overlap is less than planned, which may be insufficient for photogrammetry. And significantly could lead to the drone crashing into the terrain.
3. When in RTK mode, the drone appears to offset or correct for barometric pressure. I am assuming the Phantom RTK still flies barometric altitudes and not GPS.
4, The GEOID separation in my area is 33 m, which is only 6m different from the average relative altitude with RTK data, which may be attributable to orthometric height in the DSM.

I know its not good science to draw conclusions from limited data. But that is all I have and I am eager to share with this community to hear their thoughts and other explanations.

We are headed back to the field today to do two more flight. One RTK one non RTK, both with ellipsoidal elevation data in the DSM.

I'd like to thank Phil Harvey for making ExifToolavailable to the public. Without it I could not have extracted relative altitute from the XMP data.

Skyveyor112 Posted at 11-6 09:29
I am still collecting and analyzing data but thought I would share my preliminary thoughts.

Yesterday, we flew two terrain awareness missions over the same area from the same home point. The vertical offset was 100m above the DSM. The elevation data in the DSM was orthometric height.  No base station was used for either flight. For the first flight, we were not connected to an NTRIP server. The second flight we were, and all photos were RTK.

I answered a few of my questions.

The reason the Phantom RTK is flying well above the offset altitude is an accumulation of two errors. The first is an incorrect vertical datum in the GeoTiff. I used orthometric height in the GeoTiff. It should be ellipsoidal. In the attached image, reference flight 2, 5, and 8 to see orthometric height and 10 for ellipsoidal height. It's not o m above the offset due to the granularity of the GeoTiff. The Geoid 12b and WGS 84 separation in my area is 33m.

The second error only manifest when using terrain awareness in GNSS (no RTK), reference 1, 3, 7, and 9. The drone fails to account for altimeters settings different from standard day, 29.92. With high pressure the drone flies higher (10ft/0.01inHg) than planned. With low pressure it flies lower. Both are significant safety of flight issues. When the altimeter setting is greater than 29.92 the drone my exceed FAA altitude restrictions as in flight 1, 3, 7, and 9. When the altimeter is lower than 29.92, the drone may impact a tree, building or the ground.

Bottom line: be care flying terrain with just GNSS.

Skyveyor112 Posted at 11-9 21:25
I answered a few of my questions.

The reason the Phantom RTK is flying well above the offset altitude is an accumulation of two errors. The first is an incorrect vertical datum in the GeoTiff. I used orthometric height in the GeoTiff. It should be ellipsoidal. In the attached image, reference flight 2, 5, and 8 to see orthometric height and 10 for ellipsoidal height. It's not o m above the offset due to the granularity of the GeoTiff. The Geoid 12b and WGS 84 separation in my area is 33m.

@Skyveyor112
Well done my friend.
That's what I was talking about but none of technicians in DJI accepted the defect in flight height calculation method.

I proposed them to use GNSS elevation when receiver gets enough satellites.
On the other hand if they insist on their method, in step one they could compare barometer elevation with DSM elevation and in step two add the amount of shift to final flight height.

regards,

jivago Posted at 11-10 07:42
@Skyveyor112
Well done my friend.
That's what I was talking about but none of technicians in DJI accepted the defect in flight height calculation method.

I don't know what the corrective action is. That's for DJI to figure out. I do know the P4P has the same problem with the exif data in the images, but the P4P flies the correct relative altitude. So the solution is straight forward, but don't really know what needs to happen.   

Skyveyor112 Posted at 11-10 09:59
I don't know what the corrective action is. That's for DJI to figure out. I do know the P4P has the same problem with the exif data in the images, but the P4P flies the correct relative altitude. So the solution is straight forward, but don't really know what needs to happen.

DJI should really create a download surface on the fly solution for this to work correctly and easily.

They also need to add the ability to add in custom imagery.

The .tiff import is already set up, should not be that hard.

Skyveyor112 Posted at 2019-11-9 21:25
I answered a few of my questions.

The reason the Phantom RTK is flying well above the offset altitude is an accumulation of two errors. The first is an incorrect vertical datum in the GeoTiff. I used orthometric height in the GeoTiff. It should be ellipsoidal. In the attached image, reference flight 2, 5, and 8 to see orthometric height and 10 for ellipsoidal height. It's not o m above the offset due to the granularity of the GeoTiff. The Geoid 12b and WGS 84 separation in my area is 33m.

Thank you for the explanation. But do you have any idea how to avoid this situation? Last time after battery exchange P4R took off only 10m and went to the end/start point after mission breaking, it was quite risky.

flyaway2 Posted at 1-20 09:17
Thank you for the explanation. But do you have any idea how to avoid this situation? Last time after battery exchange P4R took off only 10m and went to the end/start point after mission breaking, it was quite risky.

The only way I know how to avoid it is to ensure you have an RTK fix prior to takeoff. That is the only time we are seeing correct flight altitudes.

Also, it's important to note after takeoff the PRTK climbs to the altitude of the first waypoint and fles this altitude to that location. If the first waypoint happens to be lower than your home point elevation, a crash is likely.

Pretty clumsy implementation.

First of all, thank you all for your successful sharing.

I am encountering a similar problem. Is there anyone who can find a solution?

fans75549d3e Posted at 4-29 01:35
First of all, thank you all for your successful sharing.

I am encountering a similar problem. Is there anyone who can find a solution?

This problem happens when start point of mission is far away from take off point and its height was less than take off point. Therefore mission planing software decides not to go high enough to reach flight height.

Maybe it's for saving power or mistake of programmers!

jivago Posted at 4-29 04:53
This problem happens when start point of mission is far away from take off point and its height was less than take off point. Therefore mission planing software decides not to go high enough to reach flight height.

Maybe it's for saving power or mistake of programmers!

But p4rtk sometimes flies higher than the terrain plan, sometimes it flies lower 30-40m.  Sometimes, its flies on the terrain.

fans75549d3e Posted at 4-29 05:28
But p4rtk sometimes flies higher than the terrain plan, sometimes it flies lower 30-40m.  Sometimes, its flies on the terrain.

According to your resume point elevation in multi-battery mission that is lower or higher than take-off point, mission planner software computed starting height at take-off point.

Skyveyor112 Posted at 2019-11-9 21:25
I answered a few of my questions.

The reason the Phantom RTK is flying well above the offset altitude is an accumulation of two errors. The first is an incorrect vertical datum in the GeoTiff. I used orthometric height in the GeoTiff. It should be ellipsoidal. In the attached image, reference flight 2, 5, and 8 to see orthometric height and 10 for ellipsoidal height. It's not o m above the offset due to the granularity of the GeoTiff. The Geoid 12b and WGS 84 separation in my area is 33m.

Hi Skyveyor112,

Thank you for this information. Do you know of an easy way to convert a DEM in Global Mapper from orthometric height to ellipsoidal height?

CCAM Posted at 6-11 09:44
Hi Skyveyor112,

Thank you for this information. Do you know of an easy way to convert a DEM in Global Mapper from orthometric height to ellipsoidal height?

You can use ellipsoid/geoid separation data from NGS. You can get geoid model data in raster grid format and just use raster math to calculate a new DEM wrt HAE.

jivago Posted at 4-29 20:08
According to your resume point elevation in multi-battery mission that is lower or higher than take-off point, mission planner software computed starting height at take-off point.

Can't you just manually fly at the target altitude then resume mission?

AntDX316 Posted at 6-11 22:45
Can't you just manually fly at the target altitude then resume mission?

It's a solution for that problem.
Thank you