Mavic Air 2 height accuracy for large changes from takeoff point?

[AZDave]

I live on the side of a mountain range and like to cruise my MA2 up the hillside. I recently did a roughly six minute run up a canyon in Pilot mode on a clear day with minimal wind. The total distance traveled up was about two thirds of a mile. I visually estimate from the video that I never got higher than 150 feet AGL and most of the time was probably half that, yet when I use DroneViewer to export the .srt path to .KML for Google Earth I get a completely different story.

Google Earth will display the path as a red line, and by right clicking on the line I can easily display the elevation profile of the path. When I compare the elevation of the path profile to the elevation of the ground (a simple mouse over in Google Earth), the difference (supposedly the height above ground) steadily increases to the point that about 1,000 feet above my takeoff point that difference is almost 800 feet. No way I was 800 feet above real ground, so I'm wondering where the error comes from. The hillside slope is not steep enough to explain the difference, such as my actual position being significantly different from my visually perceived position. Google Earth isn't perfect in its elevation accuracy, but no way is it off by 800 feet.

I also find it curious that the "error" increases steadily from my takeoff point. I can view the Google Earth path (the red line) from the side to compare against the land profile, and the red line simply has a steeper slope than the land for the entire path.

Does the MA2 barometer possibly have some sort of linear error (non-constant offset) for significant changes in altitude? I don't think that the error lies with Drone Viewer since it simply uses a Google Earth overlay based upon the lat/long coordinates from the drone's .srt file ... which seem to be accurate. Any thoughts?

One possibility might be that the barometer simply isn't that accurate for low pressures, since my starting point was at 5,150 feet ASL. That would be a bit disappointing since I had hoped to use an app like Litchi, DroneLink, or Maven to do some ridge running with appropriately programmed elevations for the various waypoints.

 

[Deleted member 103366]

What happens on the return flight?

 

[Rich QR]

I wonder if there's a software problem somewhere in the conversion to Google Earth? The drone measures altitude in height above takeoff point, but if the software is somehow interpreting that number as height above local ground level, it would produce an exaggerated altitude when flying over high ground.

Can you take off from a high point and fly out over a valley? If my theory is right, you could ascend to, say, 10 feet above takeoff point, and cruise out over a valley where you're 200 ft above the valley but still 10 ft above takeoff point. The Google Earth profile would show you descending and remaining 10 ft AGL, following the terrain.

If you descended to follow the terrain and went below your starting altitude, Google Earth would show you going underground!

My theory may be completely wrong, but it shouldn't be that hard to test. Fly level over changing terrain and see what happens.

 

[AZDave]

What happens on the return flight?

Same thing, except in reverse. By the time I get back to the takeoff point everything is accurate again.

 

[AZDave]

I wonder if there's a software problem somewhere in the conversion to Google Earth? The drone measures altitude in height above takeoff point, but if the software is somehow interpreting that number as height above local ground level, it would produce an exaggerated altitude when flying over high ground.

Can you take off from a high point and fly out over a valley? If my theory is right, you could ascend to, say, 10 feet above takeoff point, and cruise out over a valley where you're 200 ft above the valley but still 10 ft above takeoff point. The Google Earth profile would show you descending and remaining 10 ft AGL, following the terrain.

If you descended to follow the terrain and went below your starting altitude, Google Earth would show you going underground!

My theory may be completely wrong, but it shouldn't be that hard to test. Fly level over changing terrain and see what happens.

Your reply makes a lot of sense. I suspect Google Earth is doing precisely what you surmise. It's a bit too windy to fly today, but I will do your experiment as soon as I can ... both versions.

My original purpose for all of this was to be able to verify (in case of being challenged by anyone) that I was not exceeding the 400' limit when flying up the hillside since my flight logs would say otherwise. I just thought that exporting a .kml file would be an easily viewable proof that I wasn't. I guess not.

By the way, I have already posted a request to DroneViewer for them to add a feature to show height AGL for a recorded path based upon the .srt files, but I never heard anything back. I think I'll check around the internet. There must be an easy way to get ground elevation data from Google Earth based upon lat/long (besides mouse over on the map), and if so I might be able to write some code that couples that with the .srt data to plot height above ground for the path.

 

[AZDave]

Your reply makes a lot of sense. I suspect Google Earth is doing precisely what you surmise. It's a bit too windy to fly today, but I will do your experiment as soon as I can ... both versions.

My original purpose for all of this was to be able to verify (in case of being challenged by anyone) that I was not exceeding the 400' limit when flying up the hillside since my flight logs would say otherwise. I just thought that exporting a .kml file would be an easily viewable proof that I wasn't. I guess not.

By the way, I have already posted a request to DroneViewer for them to add a feature to show height AGL for a recorded path based upon the .srt files, but I never heard anything back. I think I'll check around the internet. There must be an easy way to get ground elevation data from Google Earth based upon lat/long (besides mouse over on the map), and if so I might be able to write some code that couples that with the .srt data to plot height above ground for the path.

It turns out that the Google Earth Elevation API requires setting up an API account with Google with a per-use fee, although the fee is small ($0.5 cents per request). I also saw a comment saying that the result must be displayed on a Google Map. So probably more hassle than I want to incur. I'll just have to pick points along the DroneViewer path and manually compare them to Google Earth via mouse over. Unless somebody has a better idea ...

 

[DanMan32]

I thought the Air2 had the telemetry caption embedded in the video.

I believe altitude there is AMSL rather than AGL. At least that's how it had been for M2 and MM1.

 

[AZDave]

I thought the Air2 had the telemetry caption embedded in the video.

I believe altitude there is AMSL rather than AGL. At least that's how it had been for M2 and MM1.

The latitude/longitude/elevation/etc data is embedded in a separate text file with the .srt nomenclature, and the altitude is referenced only to the takeoff point. For example, the elevation of the bedroom patio of my house is 5,150 feet AMSL, but when I takeoff and climb 20 feet above the patio the .srt data will show 20 feet elevation at that point.

 

[Dave Maine]

Google Earth has a number of settings used in determining the starting point for measuring altitude. Sea floor, sea level, absolute, above ground, etc. Looking at route and push pin locations can be non intuitive and confusing.

Looking straight down at the ground the height shown is the height above that particular land feature. The KML flight data will show height above the height above the takeoff point. You will need to adjust this number up or down to line it up with the height that Google references for that point.

 

[boblui]

You can check the flight log file in the phone to see if the height info is wrong there or after transferring to Google Earth

 

[Meta4]

You can check the flight log file in the phone to see if the height info is wrong there or after transferring to Google Earth

He said in post #4:

By the time I get back to the takeoff point everything is accurate again.​

That indicates there's no problem with the drone's height measuring.

 

[Ron Caballero CAP]

Your reply makes a lot of sense. I suspect Google Earth is doing precisely what you surmise. It's a bit too windy to fly today, but I will do your experiment as soon as I can ... both versions.

My original purpose for all of this was to be able to verify (in case of being challenged by anyone) that I was not exceeding the 400' limit when flying up the hillside since my flight logs would say otherwise. I just thought that exporting a .kml file would be an easily viewable proof that I wasn't. I guess not.

By the way, I have already posted a request to DroneViewer for them to add a feature to show height AGL for a recorded path based upon the .srt files, but I never heard anything back. I think I'll check around the internet. There must be an easy way to get ground elevation data from Google Earth based upon lat/long (besides mouse over on the map), and if so I might be able to write some code that couples that with the .srt data to plot height above ground for the path.

If you are using litchi, it has a feature (for each waypoint) to maintain a constant AGL...up and down.

 

[eaglesurfing]

If you are using litchi, it has a feature (for each waypoint) to maintain a constant AGL...up and down.

It doesn't work with MA2 yet.

 

[AZDave]

Google Earth has a number of settings used in determining the starting point for measuring altitude. Sea floor, sea level, absolute, above ground, etc. Looking at route and push pin locations can be non intuitive and confusing.

Looking straight down at the ground the height shown is the height above that particular land feature. The KML flight data will show height above the height above the takeoff point. You will need to adjust this number up or down to line it up with the height that Google references for that point.

Yes, there are lots of things I can do manually in Google Earth. I was looking for a way to simply, automatically, and visually show my actual height above ground, but there are various ways I can compute the height AGL manually. One thing I did recently was to use DroneViewer to export the path to a .KML file .... load that .KML file into GPS Visualizer ... and then re-export from GPS Visualizer to a different .KML file. GPS Visualizer ignores the elevation data so its output .KML file is purely the ground path, and I can then accurately compare those elevations point-by-point to the elevations in the .srt file. It's possible to translate all of these files to .CSV for use in Excel, do the subtraction there, and then plot the difference (i.e., AGL) in Excel, so I guess there is always that. It just won't be overlaid onto a pretty map.

 

[Ron Caballero CAP]

It doesn't work with MA2 yet.

The MSDK has been released...and I seem to recall someone here say they were using it. Sorry if I was premature. So, when Litchi makes it available that will be a solution. They should write to Litchi and ask about their plans.

 

[AZDave]

The MSDK has been released...and I seem to recall someone here say they were using it. Sorry if I was premature. So, when Litchi makes it available that will be a solution. They should write to Litchi and ask about their plans.

Maven has been able to properly use the new SDK but Maven only works with iOS hardware ... although the author is working on an Android version. Dronelink has a beta version out that uses the new SDK, but last I heard it still has a bug that requires a reinstallation when it crashes. Litchi of course also has the new SDK but thus far hasn't released a version that works with it.

 

[AZDave]

Rich QR was completely correct. I did a run downhill this afternoon (roughly 200 feet elevation change downhill), loaded the video and the .srt file into DroneViewer, exported the path to a .kml file, and then called Google Earth using that .KML file. Google Earth shows the path trace disappearing underground on the way out and surfacing again on the way back. So clearly my problem was simply that Google Earth adds or subtracts the elevation data from the .srt file to/from its own ground elevation data. It doesn't reference to a starting position when it plots the path ... although it theoretically could if it wanted to.

It looks like I'll have to do my own calculations to get what I want. I can do it in Excel using .csv files from both the Google Earth ground path (via the GPS Visualizer procedure I mentioned above) and the .csv file translated from the .srt file, but I'd have to translate the result from .csv back to .kml format to get a nice pretty display back in Google Earth. I'm pretty sure there are websites that will convert from .csv to .kml, but overall it's a messy process for something that on the surface seems like it should be simpler.

Anyway, thanks for all the replies and special thanks to Rich QR.