I'm having some trouble with terrain following on our M350 with P1 camera, without RTK base station. Bottom line it flew at 155' AGL rather than 200' and I can't figure out why. This is new equipment for us.

I created a DTM from lidar that our local jurisdiction had flown. The data looks fine.

I understand that Pilot 2 wants elevation data relative to the ellipsoid.

Here are the steps I took to generate the raster dtm relative to the ellipsoid:

• I downloaded the lidar DTM
  
• Reprojected it to WGS84 in QGIS.
  
• Converted the Z values to meters.
  
• Adjusted the Z values to the ellipsoid. (-22.55 meters in this area)
  
• Imported the DTM into Pilot 2 and created my area mission.
  
  

Everything appeared fine to me in Pilot 2. I set the AGL elevation to 200'.

When I flew the mission it appeared to me that the aircraft was not 200' AGL but I'm not exactly sure what numbers Pilot 2 is reporting on the controller. I see values for elevation and elevation above sea level. The aircraft was well above the tree cover so I carried on even though I wasn't seeing elevation numbers that made sense to me.

After processing the project it appears that the mission was flown at approximately 155' AGL rather than the 200' specified. It worked fine but I don't like that it didn't perform as expected.

Below are what I believe to be the relevant numbers that I have. We use Aeropoints for GCPs so GCP-12873609 is referring to one of our Aeropoints. I provided the elevation for one of the photos. (520.76 NAVD88)

If any of you more experience with the M350 and terrain following can point out where I made a mistake I'll be very appreciative. I imagine I made some bonehead mistake or another but I haven't been able to figure it out yet.

In Pix4d NAVD88

GCP-12873609 ZUSFt: 365.561

Photo 20241130133535_0644: 520.76 (This photo was nearly directly above the GCP)

520.76 - 365.561 =155.199

Propeller Aeropoints Interface

GCP-12873609

NAVD88 height (geoid 12b) =365.561

Ellipsoid height =291.445

Adjustment 74.116

In QGIS

Lidar elevation near GCP prior to Adjustment: 365.54

Lidar elevation subsampled and converted to meters: 112.026115 (367.5386’)

Lidar elevation in meters adjusted to ellipsoid: 89.4708 (270.57’)

Expected camera elevation relative to elipsoid: 470’

Expected camera elevation NAVD88: 565

Observed camera elevation in Pix 4d (NAVD88): 520’

Observed camera elevation in Pix 4d (relative to ellipsoid): 520’ - 74’ =446’

Effective height AGL: 155’

AGL Specified in Pilot 2: 200’

The fact that the discrepancy between your desired and realized altitude AGL is 2X the correction you applied to shift your DTM to HAE might be of interest...
Whenever I see that I think sign error. Might not be relevant, but worth checking.

ETA: derp, didn't notice that the correction and altitude were in different units.

"I understand that Pilot 2 wants elevation data relative to the ellipsoid"

As per the manual you must use geoid raster as reference. Not Ellipsoidal

That’s what I thought initially as well.  The first flight I did I used NAVD88 and it was too high.  I don’t remember where I saw it but I read somewhere that pilot 2 expects elevations relative to the geoid.  I’ll try to find the source.  Thank you for taking a look.

patiam Posted at 11-25 22:00
The fact that the discrepancy between your desired and realized altitude AGL is 2X the correction you applied to shift your DTM to HAE might be of interest...
Whenever I see that I think sign error. Might not be relevant, but worth checking.

Maybe I’m not following you.  The discrepancy was approximately 44’ lower than expected.  The correction was -74’. (22.5 meters). Confusing when there are multiple coordinate systems and multiple units.  My understanding is that the DSM elevation units should be in meters even if I have the controller units set to imperial.  Maybe that isn’t correct.

brianpgreen Posted at 11-26 07:12
Maybe I’m not following you.  The discrepancy was approximately 44’ lower than expected.  The correction was -74’. (22.5 meters). Confusing when there are multiple coordinate systems and multiple units.  My understanding is that the DSM elevation units should be in meters even if I have the controller units set to imperial.  Maybe that isn’t correct.

Sorry I misread and didn't notice that the altitude and HAE correction were in different units. My mistake, apologies for confusing the issue.

But I think @LV_Forestry has pointed out something important (as usual).
My TF workflow is a bit different as I have only a P4 RTK.

patiam Posted at 11-26 08:44
Sorry I misread and didn't notice that the altitude and HAE correction were in different units. My mistake, apologies for confusing the issue.

But I think @LV_Forestry has pointed out something important (as usual).

Below from Chat GPT.  I know, it may  not necessarily be correct.  Everything I've been able to find suggests that my DTM imported into Pilot 2 should be in ellipsoid heights, which I believe I've done correctly by subtracting the 22.5m from the NAVD88 DTM.  I'm still stumped.

What vertical datum does the aster GDEM v3 geoid database use?
ChatGPT said:
ChatGPT
The ASTER GDEM v3 (Advanced Spaceborne Thermal Emission and Reflection Radiometer Global Digital Elevation Model) uses the WGS84 (World Geodetic System 1984) datum for its geoid database. This datum is the standard geodetic reference system used for positioning and navigation, including in most global datasets. The elevation values in ASTER GDEM v3 are referenced to the WGS84 ellipsoid, and the geoid model applied is consistent with this datum.

You said:
So are the elevations in the DEM ellipsoid elevations or geoid elevations?
ChatGPT said:
ChatGPT
The elevations in the ASTER GDEM v3 are referenced to the WGS84 ellipsoid, not to the geoid. This means that the elevation values in the DEM represent the height above the WGS84 ellipsoid, rather than the height above the geoid (which approximates mean sea level).

To convert ellipsoid heights to geoid heights (i.e., heights above mean sea level), you would need to apply a geoid model that provides the difference between the ellipsoid and the geoid at each location.

There is a question in all this data and units of measurement. What is the value of the raster that serves as a reference for Pilot2, at the location of the GCP?
Because the measurements in feet don't mean anything to me, in this case we're talking about 45 feet. But it's only 13 meters.

What method did you use to generate the DTM from the original LiDAR data?
What is the resolution of this raster?
Is the terrain perfectly flat or is it hilly?


I just did the test, it's quite disconcerting because the altitude displayed on the RC in the scalebar is ASL, with a WGS raster loaded... It's nonsense.

If it can reassure you I have a delta of 10m. where you have 13.

I think I know why, it's because it resamples the resolution to make the most smooth flight lines possible. Instead of really following the terrain.

To get this level of raster simplification I need to generate a resolution of at least 100m.


It's in the same line as DJI TERRA, the functions have names that sound professional, but in reality it's so cheap!

If you want to do real terrain following I recommend UGCS. Although I no longer agree with their pricing policy.

LV_Forestry Posted at 11-26 11:22
There is a question in all this data and units of measurement. What is the value of the raster that serves as a reference for Pilot2, at the location of the GCP?
Because the measurements in feet don't mean anything to me, in this case we're talking about 45 feet. But it's only 13 meters.

I should probably just do everything in meters to eliminate confusion.  

I downloaded the DTM directly from the state lidar portal.  https://lidarportal.dnr.wa.gov/download?ids=1487

The lidar has Aggregate Nominal Pulse Spacing (ft) 0.84

Once downloaded I imported it into QGIS, reprojected it, subsampled it to reduce the resolution.

The site is very hilly.  I would hope that I could at least expect the M350 to start out at the 200' AGL I specified, but it didn't.  I realize there's going to be some variance, but it seems reasonable to expect it to be +/- 10' from the DTM even if the variance to the actual ground surface is different.  It appeared to do a great job of following the DTM, just not at the AGL value I specified.

It seems like Pilot 2 is not actually referencing the ellipsoid as advertised.

brianpgreen Posted at 11-26 12:46
I should probably just do everything in meters to eliminate confusion.  

I downloaded the DTM directly from the state lidar portal.  https://lidarportal.dnr.wa.gov/download?ids=1487

My plan to convert Americans to the metric system is taking shape.

It's definitely Pilot 2 that's messing up. For my test I chose a relatively flat area with a river running through the center of the area. There's a 20m drop on either side.
Pilot 2 didn't care and simply ignored it.


It's a pity that it's not better implemented.

LV_Forestry Posted at 11-26 12:52
My plan to convert Americans to the metric system is taking shape.

It's definitely Pilot 2 that's messing up. For my test I chose a relatively flat area with a river running through the center of the area. There's a 20m drop on either side.

  I may convert for the purposes of not running this thing into a tree but as soon as I've got my photos  it's M X 3.2808333

I'm new to this forum.  Any chance to get the attention of the experts at DJI here?  It's pretty disappointing to spend $23K to get terrain following then have it not work correctly.  There's got to be a solution.

brianpgreen Posted at 11-26 13:00
I may convert for the purposes of not running this thing into a tree but as soon as I've got my photos  it's M X 3.2808333

I'm new to this forum.  Any chance to get the attention of the experts at DJI here?  It's pretty disappointing to spend $23K to get terrain following then have it not work correctly.  There's got to be a solution.

Don't worry, at best an admin will come and write:
"Sorry for the inconvenience this has caused, we will forward it to the relevant team"

Otherwise it will be as usual, you can go take a look at the threads in the pro section, very often there is not a shadow of a DJI employee.


But somehow the information seems to come back to the engineer because sometimes there are small improvements that respond to problems raised on the forum.



Well I'm postponing my plans for America.

LV_Forestry Posted at 11-26 13:12
Don't worry, at best an admin will come and write:
"Sorry for the inconvenience this has caused, we will forward it to the relevant team"

I've just finished up a chat with DJI support.  They asked me to send flight logs, DSM, and a KMZ of my flight plan.  She seemed very helpful and said that it was being forwarded on to RD.  I'm hopeful that they will help me get it resolved.

She did confirm that elevations should be relative to the ellipsoid as opposed to the geoid.

brianpgreen Posted at 11-26 16:31
I've just finished up a chat with DJI support.  They asked me to send flight logs, DSM, and a KMZ of my flight plan.  She seemed very helpful and said that it was being forwarded on to RD.  I'm hopeful that they will help me get it resolved.

She did confirm that elevations should be relative to the ellipsoid as opposed to the geoid.

Passed to R&D, that's exactly it. They can't do much more anyway. It's a software modification that's needed. Not so simple.

brianpgreen Posted at 11-26 13:00
I may convert for the purposes of not running this thing into a tree but as soon as I've got my photos  it's M X 3.2808333

I'm new to this forum.  Any chance to get the attention of the experts at DJI here?  It's pretty disappointing to spend $23K to get terrain following then have it not work correctly.  There's got to be a solution.

Welcome to our world.

99% of the time it's users helping users. As @LV_Forestry noted, DJI moderator responses are rare and botlike, often misinterpret the issue or even offer incorrect information, but every now and then some value is added.

It's refreshing to have someone post an issue that actually understands geodesy, we do a lot of helping folks that have never heard of an ellipsoid or geoid...

patiam Posted at 11-26 21:55
Welcome to our world.

99% of the time it's users helping users. As @LV_Forestry noted, DJI moderator responses are rare and botlike, often misinterpret the issue or even offer incorrect information, but every now and then some value is added.

Pat, what do you think about the so called "WGS84 geoid"?

In my language its a nonsense. There are two way to proceed, using WGS84, GRS80... ellipsoid, or EGM96, local,... geoid. That's how GNSS are supposed to work no?

Iam confused with DJI documentation. Because its not clear, and obviously what needs to be taken is the WGS84 ellipsoid, to generate reference raster.

To avoid frustration : use UGCS, they have a pretty good terrain following feature...but if it's a one time mission, it may be over expensive.

AR_AirPrecision Posted at 11-27 00:41
To avoid frustration : use UGCS, they have a pretty good terrain following feature...but if it's a one time mission, it may be over expensive.

Looks worth a try.  Seems reasonably priced.

patiam Posted at 11-26 21:55
Welcome to our world.

99% of the time it's users helping users. As @LV_Forestry noted, DJI moderator responses are rare and botlike, often misinterpret the issue or even offer incorrect information, but every now and then some value is added.

I'll take that as a compliment.  I can't claim to understand it but I'm aware of it.

LV_Forestry Posted at 11-26 23:04
Pat, what do you think about the so called "WGS84 geoid"?

In my language its a nonsense. There are two way to proceed, using WGS84, GRS80... ellipsoid, or EGM96, local,... geoid. That's how GNSS are supposed to work no?

I concur. It wouldn't be the first time their documentation is confusing or misleading. There is no "WGS84 geoid". WGS84 either uses the GRS80 ellipsoid or an EGM geoid, but raw GNSS is always HAE so unless the DJI software is converting on the fly, the reference raster for TF needs to be relative to the ellipsoid, not geoid. That's the way TF works on other DJI platforms such as GS-RTK.

brianpgreen Posted at 11-27 09:21
I'll take that as a compliment.  I can't claim to understand it but I'm aware of it.

By "our world", I meant this DJI-hosted forum where DJI sometimes kinda sorta helps us with tech issues.

The compliment part was actually later in my response

patiam Posted at 11-27 15:30
I concur. It wouldn't be the first time their documentation is confusing or misleading. There is no "WGS84 geoid". WGS84 either uses the GRS80 ellipsoid or an EGM geoid, but raw GNSS is always HAE so unless the DJI software is converting on the fly, the reference raster for TF needs to be relative to the ellipsoid, not geoid. That's the way TF works on other DJI platforms such as GS-RTK.

I am reassured. The Enterprise series integrates the EGM 96, the altitude is indicated ASL on the RC. Which further increases the confusion.

LV_Forestry Posted at 11-27 22:05
I am reassured. The Enterprise series integrates the EGM 96, the altitude is indicated ASL on the RC. Which further increases the confusion.

Any idea why if they are reporting EGM96 in Pilot 2 they want us to use DTM with HAE?  Seems like it'd be handy to have everything operating on the same system.

brianpgreen Posted at 12-2 09:35
Any idea why if they are reporting EGM96 in Pilot 2 they want us to use DTM with HAE?  Seems like it'd be handy to have everything operating on the same system.

This is the eternal problem with DJI. They are not geographers, for them the use of one system or another means absolutely nothing.

It is difficult to get the message across, even if our complaints reach the relevant team. I have already proposed to DJI to meet one of their engineers, in the field, and to discuss seriously. To date... Nothing.

I've continued to go back and for the with DJI on this.  They appear to be trying hard but it's taken some time for me to explain the issue clearly.  I think we are getting close.  I'm going to paste my latest response to them below.  If any of you could take a look to see if I've made any errors in my explanation or if there's a way that I could clarify it for them that would be a big help.  I'm a little bit over my head on some of this stuff but I think I have a reasonable understanding.
(Sorry about the formatting.  The copy/paste from my email made a mess)

Thank you for the offer of the discount but that’s not necessary.  I appreciate your continued support and that is more than enough.  I look forward to understanding how to properly use terrain following or identifying that there is a problem with the software or hardware.

  

  

• GCP
  

  

I have uploaded the GCP file.  It’s name is North East, WA(2).csv

  

                There are 4 GCP’s used in the project.  The GCP I used for my example is labeled 12873609  (Coordinate System NAD83(2011)/Washington South (ftUS) EPSG 6599  Vertical Datum NAVD88 height (geoid 12b) EPSG5703)

  

The position of this GCP is as follows:

  

Northing 723474.332 ft (US)

  

Easting 1164107.385 ft (US)

  

NAVD88 height (geoid12b) 365.561 ft (US)

  

The ellipsoid height of this GCP is 291.445 ft (US)

  

  

• Photograph      DJI_20241120133534_0644.JPG   
  

  

I have uploaded photograph DJI_20241120133534_0644.JPG   (It appears we had an error in one of our emails.  You list it as 064 when it is actually 0644, that may have come from me)

  
  

The recorded GPS information from the drone prior to PPK correction is as follows:  

  

DJI_20241120133535_0644.JPG,

  

Latitude 47.3013933888889,   

  

Longitude -122.419966416667,

  

132.896 (Meters) (This would be 436 Feet)   

  

(Note that adding 74.116 feet to this results in 510.111’.  Add to that the approximate 45 discrepancy and the result is 555.111’  This is within 10’ of the expected value of the photograph elevation below and closer to an acceptable level of error when not using RTK.  Further note that this 10’ error is within the recorded vertical error of 3.7 meters as recorded in the image tags prior to PPK adjustment)

  
  

After PPK Correction the location information is as follows:  (Coordinate System NAD83(2011)/Washington South (ftUS) EPSG 6599  Vertical Datum NAVD88 height (geoid 12b)EPSG5703)

  

DJI_20241120133535_0644.JPG

  

Northing 723505.595

  

Easting 1164087.919

  

Elevation 520.858 (US Feet)

  
  

After Processing in Pix4d Photogrammetry software the location information is as follows: (Coordinate System NAD83(2011)/Washington South (ftUS) EPSG 6599  Vertical Datum NAVD88 height (geoid 12b)EPSG5703)

  

DJI_20241120133535_0644.JPG

  

Northing 723505.64,

  

Easting 1164087.94,

  

Elevation 520.76 (US Feet)

  
  

A very small difference (520.858 vs 520.75) between the PPK corrected image tag and the calculated image position in the photogrammetry software is to be expected.  

  

If terrain following was working property this photo should have an elevation after PPK correction that is something close to 200’ above the elevation of GCP 12873609.  (365.561+200=565.561  The results of this photogrammetry project are extremely accurate.  The data variance  of the GCPs is less than 5 millimeters vertically.  There error in the terrain following as performed by Pilot 2 is approximately 45’  This large terrain following error is not acceptable, will affect the photograph overlap percentage and could be unsafe in some situations.)

  

  

I also uploaded the image location file for all images both before and after PPK correction.  These files are labeled as follows:

  

Itin.txt – These are the image location tags for all images after PPK correction

  

Itout.txt – These are the image location tags for all images as captured by the M350/P1 prior to PPK correction and reprojection to EPSG 6599 and Vertical Data EPSG5703)

  
  

• DSM
  

  

It should be noted that I rechecked the elevation of the DSM in the location of the GCP.  The elevation after reprojection to WGS84, adjustment to the ellipsoid and conversion to meters is as follows:

  

Elevation 88.5101 meters relative to the ellipsoid.

  

If I convert this to US Feet it is 290.386 feet

  

If I add the adjustment to from the ellipsoid to Geoid 12b which is 74.116 feet the result is 290.386 + 74.116 = 364.502 feet

  

If I add to the 364.502 feet the 200’ above ground level that I programmed into my terrain following flight plan I get 564.502 feet

  

This result matches what I expected for the height of the photograph as highlighted above to within about a foot.  This suggests that the DSM file was properly prepared and that there is an error somewhere in the conversions performed by Pilot 2.

  
  

• Units       Another      thing to note that I’m curious about.  I have my units in Pilot 2 set      to Imperial (feet) but I prepared the DSM in meters because that’s what      the instructions provided by DJI say to do.  Is it possible that this      could be the source of the error?  If Pilot 2 is set to Imperial does      it expect the DSM to also be imperial?  I expect this it not the      problem since it seems it would result in the error being much worse but I      would like to know what DJI has to say on the subject.
  

  

  

I hope this explanation helps .  It’s possible that I made an error in the preparation of the DSM used for the terrain following but I don’t believe that is the case.  It appears to me that somewhere in Pilot 2 there is a conversion error of some kind.  In the M350 DJI has produced an amazing piece of hardware.  I’m confident that you will be able to help me identify where the error has occurred here.  

  

  

Thanks again for your support.

  

Brian

LV_Forestry Posted at 11-25 22:06
"I understand that Pilot 2 wants elevation data relative to the ellipsoid"

As per the manual you must use geoid raster as reference. Not Ellipsoidal[view_image]

which manual is this? i don't see it in the M350 User Manual...
and I couldn't easily find a Pilot 2 manual.

patiam Posted at 12-7 14:50
which manual is this? i don't see it in the M350 User Manual...
and I couldn't easily find a Pilot 2 manual.

It is in the L2 manual. Page 16

Don't you find it logical to put the instructions of the drone's flight planner in a manual of one of the compatible payloads?

LV_Forestry Posted at 12-7 16:10
It is in the L2 manual. Page 16

Don't you find it logical to put the instructions of the drone's flight planner in a manual of one of the compatible payloads?

LMAO. How DJI!!!

It would make waaaaay too much sense to put it in the M350 or Pilot2 manual, for sure.

Thanks, as always.