Hello all and thanks for any assistance, we are flying an M-300 RTK with Pilot 2 in a GPS denied environment with extreme geographical features.
During on-the-fly testing last week, I made a DSM using the data from a path drawn in google earth, by loading that data into QGIS, and exporting a Geotiff

Each time I did this, the M-300 controller would display color banding about 100 feet higher than what I gave it. Without being able to find out why, I thought perhaps that the drone wanted me to give it the ellipsoidal height, so I brought the DSM down to the ellipsoidal elevation.

It gave the error code (-2301) today, "Aircraft altitude too high". Do I need to reset a geofence or something?

Should I be giving the drone a DSM from Google Earth at all? If so, should it be at the Ellipsoidal Height or at the Orthographic Height?

The drone displays the Ellipsoidal.

I am a bit lost on this aspect, we are flying both P1 and L1 Missions.


Thank you all

You shouldn't be using TA w/o GNSS.  The M300 needs RTK fixed to calculate an accurate Z solution (which will be  in HAE). Barometric pressure is not accurate enough for reliable TA.

patiam Posted at 7-28 06:34
You shouldn't be using TA w/o GNSS.  The M300 needs RTK fixed to calculate an accurate Z solution (which will be  in HAE). Barometric pressure is not accurate enough for reliable TA.

Patiam, thanks for your answer. So far the pilots have had an RTK signal above the canopy on all flights.
The DSMs I created are all at Ellipsoidal height. I took data from Google Earth and added the negative geoid height to all data points,  then made a DSM in QGIS from that data set.

What I can't figure out is why that is incorrect

Sorry, you said "we are flying an M-300 RTK with Pilot 2 in a GPS denied environment with extreme geographical features."; I did not understand that you are able to get RTK fixed once you get above the canopy.

You're using the EGM96 Geoid height, correct (although the difference b/w that and say GEOID18 is likely sub-meter)? You're not off by 2N are you (due to a sign issue)?

Personally, I wouldn't use a DSM from GE for TA myself, and advise against it.

If the payload is L1, you can choose the suitable geoid before point cloud processing in Terra. For P1 you can also set a geoid, at least in Metashape, for other software i ignore.

LV_Forestry Posted at 7-28 11:49
If the payload is L1, you can choose the suitable geoid before point cloud processing in Terra. For P1 you can also set a geoid, at least in Metashape, for other software i ignore.

I think Candarco is talking about the vertical datum for his DSM to be used for terrain awareness during flight, not setting the datum in post-processing...

patiam Posted at 7-28 08:56
Sorry, you said "we are flying an M-300 RTK with Pilot 2 in a GPS denied environment with extreme geographical features."; I did not understand that you are able to get RTK fixed once you get above the canopy.

You're using the EGM96 Geoid height, correct (although the difference b/w that and say GEOID18 is likely sub-meter)? You're not off by 2N are you (due to a sign issue)?

Patiam, I am actually using the same Unavco Geoid height calculator you have posted in the past in select threads I've found while searching for answers. I have it set to EGM-2008 and set to perform interpolation.

What we did was this. The drone controller display has coordinates and an associated ellipsoid height. I took those coordinates, imported them into QGIS, and then evaluated each spot using the displayed ellipsoid height from the RTK drone, versus the DSM that had been created from GE.

I found one spot off by 26 feet, another by 54, yet another by 66.

Is that why you advise against it, or is there another reason?

You're using the HAE displayed on the drone's RC while it has an RTK fix, or on the ground where it doesn't?

If the former, I think the discrepancy you are seeing may be due to both the error of the GE-based DSM as well as that of the M300's poor Z solution.

I advise against using GE as a source of elvations for a DSM b/c while it is based on the same SRTM data that many built-in TA functionalities (from other vendors) use, Google has tweaked it according to their needs, and both they and many professionals who's experience and opinion I respect strongly counsel against doing so.

patiam Posted at 7-28 12:58
You're using the HAE displayed on the drone's RC while it has an RTK fix, or on the ground where it doesn't?

If the former, I think the discrepancy you are seeing may be due to both the error of the GE-based DSM as well as that of the M300's poor Z solution.

Patiam, does this display show the HAE height or the ellipsoid height?

How does the drone get this measurement?

Is here any other acceptable method?

I used earth explorer to download some SRTM files, but have not used them
https://drive.google.com/file/d/ ... U_/view?usp=sharing

Candarco HAE = Height Above Ellipsoid (Ellipsoid height). I don't have an M300 (I wish!) so I can't tell you for sure what the RC is displaying- I was just going by the fact that you stated it shows HAE.

The drone normally gets its altitude measurement from either a combination of GNSS and barometer, or when RTK is fixed, it just uses GNSS. Autonomous (non-RTK) GNSS has too much error in the Z for accurate measurements, so a pressure sensor is used to determine relative elevation/altitude between takeoff and current location.

I'd be interested to hear how the SRTM data compare to those you extracted from GE...

Candarco Posted at 7-28 13:52
Patiam, does this display show the HAE height or the ellipsoid height?

How does the drone get this measurement?

The RC shows your ASL (Above Sea Level) altitude which is based on the Geoid. The RC also shows your height which has the starting point as a reference and which also serves as a reference for the height you have selected.

If it's for terrain follow, you need a raster in WGS84 format that represents the bare ground or the canopy (it depends on what is the most interesting for you) with an ellipsoidal height. With this information the drone will constantly adjust its altitude to maintain the same height with respect to the ground, or the canopy if you have set a canopy height model.

Do not try to put a geoid like the EGM96 to do this, it will not result much because it is used to express the mean sea level, not that of the ground!

The GNSS receiver has the ability to give ASL altitude.

patiam Posted at 7-28 14:01
Candarco HAE = Height Above Ellipsoid (Ellipsoid height). I don't have an M300 (I wish!) so I can't tell you for sure what the RC is displaying- I was just going by the fact that you stated it shows HAE.

The drone normally gets its altitude measurement from either a combination of GNSS and barometer, or when RTK is fixed, it just uses GNSS. Autonomous (non-RTK) GNSS has too much error in the Z for accurate measurements, so a pressure sensor is used to determine relative elevation/altitude between takeoff and current location.

So HAE is the same thing as ellipsoid height? That seems counterintuitive.

Why would that be adopted as standard nomenclature. Is it the height OF the ellipsoid, or the height ABOVE the Ellipsoid?

Candarco Posted at 7-28 15:01
So HAE is the same thing as ellipsoid height? That seems counterintuitive.

Why would that be adopted as standard nomenclature. Is it the height OF the ellipsoid, or the height ABOVE the Ellipsoid?

https://www.researchgate.net/figure/Relationship-between-ellipsoidal-orthometric-and-geoid-heights_fig1_340030816/amp

Candarco Posted at 7-28 15:01
So HAE is the same thing as ellipsoid height? That seems counterintuitive.

Why would that be adopted as standard nomenclature. Is it the height OF the ellipsoid, or the height ABOVE the Ellipsoid?

the ellipsoid is a DATUM.  If Ellipsoid Height meant the height OF the ellipsoid, what would it's height be measured relative to?

Ellipsoid Height refers to the height of something relative to the Ellipsoid, as does "Height Above Ellipsoid (HAE).  They are the same thing.

LV_Forestry Posted at 7-28 14:37
The RC shows your ASL (Above Sea Level) altitude which is based on the Geoid. The RC also shows your height which has the starting point as a reference and which also serves as a reference for the height you have selected.
[view_image]
If it's for terrain follow, you need a raster in WGS84 format that represents the bare ground or the canopy (it depends on what is the most interesting for you) with an ellipsoidal height. With this information the drone will constantly adjust its altitude to maintain the same height with respect to the ground, or the canopy if you have set a canopy height model.

Thanks for the reply, does this mean the DSM I supply to the pilot should have the same values I see in Google earth, since I'm going for bare ground?

I was subtracting the Geoid height from those values, and reflecting those, lower value sin the dsm itself.

If we are using Google earth to get the data, should the DSM we load in reflect the height at the ground level then?

If so, why does the Pilot app bump it up so far upon import? We witnessed an extra 30 meters of flight height, so figured it was adding the geoid height on automatically, prompting me to reduce DSM elevation values by 30 meters.

Candarco Posted at 7-28 19:50
Thanks for the reply, does this mean the DSM I supply to the pilot should have the same values I see in Google earth, since I'm going for bare ground?

I was subtracting the Geoid height from those values, and reflecting those, lower value sin the dsm itself.

I now understand where is your issue. You want to know from which reference, geoid or ellipsoidal, your DSM should be.

It does not matter !

What matters is GSD, Ground sample distance. This is the flight height relative to the point where the drone initializes.

And that the DSM has the shape of the terrain / obstacles. You have to be careful because a collision is quickly arrived in a steep terrain. M300 has colission avoidance, but...

I read the thread on the forest you want to monitor. I do a bit the same thing, with much smaller trees. I did not answer on the thread because you received a mass of information, no need to add too quickly.

What I will do in this case with the L1:
-make a first flight to map the canopy. Flying approx 50m height of the highest point with a 50% overlap
-Extract the canopy height model as DSM and feed DJI pilot with
-Fly in terrain following with a height of 100m (Which is still calculated from the drone initialization point) and 50% overlap. The drone will follow the shape of the DSM, so you will always have the same GSD on the canopy which will greatly increase the accuracy.

If the canopy is not too dense you should have a good image of the ground. You can generate a DTM (not sure if that's the right term for the US) of bare ground, then use it to do follow terrain. This time the GSD will be focused on the ground.

These are the outlines of how I proceed with the L1 to do this kind of work.

If you need clarification don't hesitate to ask.

If Pilot asks you to change the elevation of your DSM to 30m, you open it in QGIS and with the raster calculator you do DSM-30But by generating DSM with Terra in WGS84 format I don't have this problem. forget google earth. Also try to rise up the maximum altitude of your drone. Maybe you reach the max Alt over 30m.

Sorry, non native english here.
I disagree with LV_Forestry when he said "It does not matter ! What matters is GSD, Ground sample distance. ".
From what i understand, Candarco need a DSM suitable for terrain avoidance, is it right?
From my experience, for the terrain avoidance function the Matrice 300 need a DSM in EPSG 4326 (wgs 84) with ellipsoidical height.
Google earth give you geoidical height (A.M.S.L.),
The Ellipsoid is a simple geometrical shape (a sphere stretched at the poles) to approximate the earth.
The Geoid is an irregular surface, affected by gravity irregularity (heavy rocky masses under the terrain, for example, can "deviate" the gravity vector).
Every traditional topographic gear give you height on the geoid surface, because is leveled with a toric or spheric liquid level; the gps system can't; he can only give you an eight above a geometric reference, the ellipsoid (or datum).
The height difference depend in what part of the world you are; here, in north western Italy is about 45 meters
When i need a terrain avoidance, i follow two paths:
When i need the maximum accuracy, i fly a preliminary mission with a constant height that guarantees safety, generate a DSM (WGS84 with default elevation reference in DJI Terra for example), next i put this DSM in the controller and subsequently i can fly the "real" mission at reduced elevation, with the Matrice following the DSM elevation (plus, obviously, the elevation i set for the mission).
When the main mission isn't so low on terrain (for example when i must map rolling hills or mountains territory at least at 50 meters elevation), normally i download from italian local administrations a portion of DSM (generally more accurate than GE), then i convert in EPSG 4326 and geoid elevation to ellipsoidical elevation using Terrascan or similar capable softwares; next i put this DSM in the controller, in the field i check if the elevation delta is acceptable and finally i fly my mission.

Probably, when you need to fly not so high in difficult terrain, the "double mission" approach is the safest. First an highest mission to obtain a reliable DSM in correct coordinate/elevation system, and then the main mission above the DSM.

Sorry for the long post and for my english.

aebrilievi Posted at 7-29 02:21
Sorry, non native english here.
I disagree with LV_Forestry when he said "It does not matter ! What matters is GSD, Ground sample distance. ".
From what i understand, Candarco need a DSM suitable for terrain avoidance, is it right?

LV. thanks very much and everyone else as well.

I can certainly accept that GE is not an acceptable data source, but I need to understand in practice why the process itself we tried did not work.

I read from your post that you "Convert in EPSG and geoid elevation to ellipsoidal elevation"

Although I utilized a data source (Google Earth) that was not optimum, but still cannot determine why the flight controller would not accept those DSMs at all

Perhaps it was this. I erroneously believed, due to inattentive research, that the Ellipsoid height would be below the Geoid height. However, Patiam has said, and Schematics show, that the ellipsoid height is not the height of the ellipsoid itself, but is the height of the ground at that point.

How then does this HAE height differ from AMSL.

https://drive.google.com/drive/f ... YMEQK60?usp=sharing

I just tried. I took a DSM that I usually use from the national database, these are rasters based on a geoidal height, so AMSL. flight height 100m here is the result:

It perfectly follow the terrain

After that i add 30m to simulate an ellipsoidal height transformation, here is the results :

The same trend with 30m more everywhere

So, it doesn't matter yes and no, i agree. For me it doesn't matter because i adjust my flight altitude to get the right value over my location. the idea is only to have the tendency of what is below to respect the GSD.
I tried with your TiFF whose resolution I changed to be able to have them read by Pilot, no problem. With those at 0ft it seems consistent with the ground heights of google earth. Watch out for the trees!

Candarco Posted at 7-29 05:23
LV. thanks very much and everyone else as well.

I can certainly accept that GE is not an acceptable data source, but I need to understand in practice why the process itself we tried did not work.

Ellipsoid and geoid are references. Then you measure the distance between your point of interest and these references. This gives you the orthometric height (AMSL) and the ellipsoidal height (HAE).Geoid height is the difference between geoid and ellipsoid renference. It is this data you will find in so call Geoid rasters. picture source : community.emlid.com

mmm....
I don't know in the US, but for example here in Italy the ellipsoid is about 45 meters below mean sea level.
The ellipsoid is a simplyfication of the earth shape, so somewhere there are obviously some discrepancies.

So, the Ellipsoid height is a reference elevation. In particular an elevation expressed as a distance from a reference ellipsoid, in our case the WGS84 ellipsoid because there are many of those.
(imagine the ellipsoid as a geometric figure that approximates the shape of the earth; a sphere stretched at the poles)
The geoidical (or above mean sea level) height is another reference elevation, expressed as a distance from the Geoid.
(imagine the geoid as an extremely irregular shape, "sculpted" by the graviti force).
The difference between ellipsoid and geoid is explained here:

https://www.propelleraero.com/bl ... ats-the-difference/

Ellipsoid height is the height above the WGS84 ellipsoid.
Geodetic AMSL level is the eight above the geoid; above the mean water level when the earth is full covered with water.

They are different, because the water don't set itself on a regular geometric shape (like the ellipsoid), but she set itself by the gravity irregularity.
GPS system can use natively ellipsoidical height only; engineering in the earth is better use geoid instead: water flown follow gravity rules (geoid), not a geometric hypotetical stretched sphere (ellipsoid).
There are many ellipsoids, but the most used is actually the WGS84, and it's valid worldwide; the gps systems work with wgs84 ellipsoid.
When you read projected coordinates (not lat/long degrees, but meters or feets), your GPS controller has traslated with some algoritm; for elevation is the same; gps read normal distances from the reference ellipsoid, and eventually correct them using a geoid model (or other tecniques); so WGS84 lat/lon coordinates are normally associated with ellipsoidical height.
In conclusion i think DJI use WGS84 and ellipsoidical height because those are valid worldwide; probably is too difficult (and risky) to implement the moltitude of projection system and elevation geoidic reference  existant in the world.

Sorry, the language barrier is a problem for me in "normal" conversation; in this case is more difficult to explain myself...

I'm out....

patiam Posted at 7-29 07:48
I'm out....

Hi Patiam,

did I write something wrong?

aebrilievi Posted at 7-29 07:37
mmm....
I don't know in the US, but for example here in Italy the ellipsoid is about 45 meters above mean sea level.
The ellipsoid is a simplyfication of the earth shape, so somewhere there are obviously some discrepancies.

M300 R/C screenshot :

Maybe you're right, but from the "M300 RTK Known Issue List" document from DJI Download center:

"The DSM imported should be in .tif format, needs to be 20MB
or smaller, with spatial resolution less than 10m. Utilize WGS
84 / EPSG: 4326 for coordinate reference system. Vertical
datum for elevation data should be ellipsoidal. Otherwise
the .tif document cannot be processed by Pilot App."

You posted a controller screenshot with "ASL"; perhaps the ellipsoidal elevation is only required for the DSM?

aebrilievi Posted at 7-29 07:58
Hi Patiam,

did I write something wrong?

Ciao aebrilievi-

Absolutely not! Your contribution here is very helpful and appreciated! I'm sorry if my statement that I'm leaving the conversation seemed as if it was directed at anyone in particular, or anything that was posted.

I think there are two basic concepts/quandaries here:

• Basic geodesy, especially with respect to vertical datums and coordinates- what are the ellipsoid, geoid, orthometric height, etc., and how are they related
• Pilot 2/M300-specific requirements for DSMs to be used in TA, and best-practices for preparing those DSMs (sources, GSD, spatial reference, vertical datum, etc.)
  

I've tried to help the OP with the first. Based on the exchange I'm not sure it has all registered, but at this point I'll just be repeating myself if I continue.


You and LV_Forestry are much more able to address #2, as you have the M300 & Pilot 2. I can only contribute what I know about TA best practices for other similar systems (DJI and non-DJI), which may just obfuscate rather than help.

So I'll leave the thread in your capable hands (and anyone else that can chime in)

ciao!

patiam Posted at 7-29 09:03
Ciao aebrilievi-

Absolutely not! Your contribution here is very helpful and appreciated! I'm sorry if my statement that I'm leaving the conversation seemed as if it was directed at anyone in particular, or anything that was posted.

Ah ok, but i'm not an expert, and i think the real problem here can be... geodesy.
Anyway, thanks for your kind words.

Ciao!

aebrilievi Posted at 7-29 09:14
Ah ok, but i'm not an expert, and i think the real problem here can be... geodesy.
Anyway, thanks for your kind words.

Everything is fine, it is with this kind of debate that we learn and discover how DJI machines work. If there is something to blame DJI for, it's the lack of documentation.
Look at my post #23, I did the experiment, it's geoidal, finally orthometric, it all depends on the language used.

patiam Posted at 7-29 07:48
I'm out....

Well thank you much for the time you've spent, I'm greatly appreciative your input and understand this much better on that account.

patiam Posted at 7-29 09:03
Ciao aebrilievi-

Absolutely not! Your contribution here is very helpful and appreciated! I'm sorry if my statement that I'm leaving the conversation seemed as if it was directed at anyone in particular, or anything that was posted.

Patiam, quandry 1 you have addressed, and that is now quite clear.

Quandry 2 is an ongoing mystery to me, and I need to know why the DSMs I created, found in the folder below, would not work for the M-300 in the field.

My central process was simple.
     1.  I drew a path object in Google Earth, and extracted from that kmz the latitude, longitude, and
          elevation data from  GE itself.

     2.  I took that data and adjusted the elevation values DOWN by the geoid height for the site, which is
          30.6 meters or so.

     3.  The resulting data set was added to QGIS as a delimited text layer, which was then used to create
          a DSM using the "Natural Neighbor" Saga Algorithm.

     4.  That raster was then exported to Geotiff, the sizes of those files were kept smaller than 20 mb for
          import into the Pilot 2 App.
     
     5. Failure - error code (-2301) Aircraft Altitude too high!

I need to be able to explain this result, and determine a best practice moving forward.

We do a hundred or more surveys per year here, but this is the first time we have needed to utilize terrain following. Our pix 4d output is always good, without any complication from TA functions, but this is not normal at all and requires us to expand our toolbox by a large amount.

LV, did you say you successfully imported one of the tifs I created?
Should I instead have moved the Tif Files UP by 30 meters?

Thanks everyone
https://drive.google.com/drive/f ... YMEQK60?usp=sharing

Candarco Posted at 7-29 09:45
Patiam, quandry 1 you have addressed, and that is now quite clear.

Quandry 2 is an ongoing mystery to me, and I need to know why the DSMs I created, found in the folder below, would not work for the M-300 in the field.

Yes it works fine for me. I just redo it with the file +100, its working! post #23 Doesn't matter what is the altitude output. just stick to your project GSD !

All good, that's what we do here- users helping users, backfilling for DJI's stellar documentation and customer support!

LV_Forestry Posted at 7-29 10:19
Yes it works fine for me. I just redo it with the file +100, its working! post #23 Doesn't matter what is the altitude output. just stick to your project GSD !

Thanks a million everyone for helping fill in these blanks. I have a misunderstanding here still, and a more direct question about a DSM I'm making now.

LV_Forestry, I don't actually have the m-300 here, but am making the DSMs for the filed crews, so perhaps that is causing me to not quite get a part of this. You say to stick to the Project GSD, but then you also moved my DSM up by 100 to get it to work. Why did you move it up, if the elevation input doesn't matter?

Patiam solved the misunderstanding about Ellipsoid height and HAE height being the same thing.

Patiam, I recall you asking about the differences between Google Earth and A DSM from a n actual flight. Here are two images of DSMs, one is from an actual flat flight, produced from Terra, and the other is one I created from Google Earth. These look close enough when I am using a P1 camera though.





I have several of these to produce for tomorrow, and the client is adamant that if GE is possible, thats where the data should originate, likely so he can replicate the functionality easily.

Candarco Posted at 8-1 21:28
Thanks a million everyone for helping fill in these blanks. I have a misunderstanding here still, and a more direct question about a DSM I'm making now.

LV_Forestry, I don't actually have the m-300 here, but am making the DSMs for the filed crews, so perhaps that is causing me to not quite get a part of this. You say to stick to the Project GSD, but then you also moved my DSM up by 100 to get it to work. Why did you move it up, if the elevation input doesn't matter?

I used one of the files you sent, in this case the +100. I tried zero too. It works. Terrain following appears to be consistent with the AMSL ground height given on GE. It's up to you to change your altitude offset to fall in the right place depending on what's on the ground.
I recommend you to go there and experience it, be prepared to press the pause button to cancel the flight if the altitude does not suit you. Then set the offset to your liking.

LV_Forestry Posted at 8-2 09:22
I used one of the files you sent, in this case the +100. I tried zero too. It works. Terrain following appears to be consistent with the AMSL ground height given on GE. It's up to you to change your altitude offset to fall in the right place depending on what's on the ground.[view_image]
I recommend you to go there and experience it, be prepared to press the pause button to cancel the flight if the altitude does not suit you. Then set the offset to your liking.

LV, thanks alot, the test flights are being done today, the current lot is actually a 40 acre stretch of desert mountainside.

I made them 2 sets of DSMs. One at the AMSL height, and another at the Elllipsoidal.

Each set contains a DSM at the actual values, another at plus 50 feet, another at plus 100 feet, and yet another at  plus 150 feet, hoping to allow for some flexibility for those guys in the field. I will not be with them.

I will let you know how that one turns out.

I notice that when the L1 is in use, terra shows the point cloud populating in real time. Would there be any issue with using that output immediately as a dsm for a P1 flight using Terrain awareness?

Can I use the Terra L1 Lidar point cloud as a DSM so that two trips are not required?
I would expect a laptop being required to convert the point cloud to dsm format

  

Candarco Posted at 8-2 09:29
LV, thanks alot, the test flights are being done today, the current lot is actually a 40 acre stretch of desert mountainside.

I made them 2 sets of DSMs. One at the AMSL height, and another at the Elllipsoidal.

What I do, after the LiDAR flight, I generate a DSM with Terra then CloudCompare. For 40acre it should take about ten minutes depending on the computer. Then the DSM/DTM can be used in Pilot or UGCS.
I don't use Terra for flight preparation. Only for reconstruction of point clouds in LAS format. What I know of the live view (that of the remote control) is only a rough overview, not a DSM.

Candarco Posted at 8-1 21:28
Thanks a million everyone for helping fill in these blanks. I have a misunderstanding here still, and a more direct question about a DSM I'm making now.

LV_Forestry, I don't actually have the m-300 here, but am making the DSMs for the filed crews, so perhaps that is causing me to not quite get a part of this. You say to stick to the Project GSD, but then you also moved my DSM up by 100 to get it to work. Why did you move it up, if the elevation input doesn't matter?

I don't know what level of precision you want to obtain but 1269 photos for 24acre seems extreme to me. Especially if you're using a P1. Increase altitude to reduce resolution or reduce overlap. The risk is to end up with rasters that have a huge number of Gb, very complicated to process in GIS.
it's just a common remark, if you have no choice (resolution / overlap imposed) then there is no problem.

Just noticed you're in Esri's backyard, lol.