It’s finally here. I posted on another thread to close it out, but let’s start talking about experiences whether they are good or more importantly bad.
Were you able to see a terrain awareness dialogue in your drone deploy app, I can see it to create the flight plan on the desktop but I don’t see anything in the app itself yet?
Yes, but this only works in iOS as of now.
OK thank you, I looked around the fact page to see if that was the case and didn’t see that tid bit.
@Andrew_Fraser, fyi in case this is supposed to work on Android. I am assuming not yet, but it may need to be documented for those that actually go look. It doesn’t appear to be on support.
@MichaelL You are correct - Terrain Awareness can only be flown with the iOS app at this time. Thanks for surfacing the support article - we will update to reflect.
The DroneDeploy Android app will get this and other upgrades this year.
I’m hurry for it to be on androïd
Buenas tardes, para consultar, como toma la altura de los puntos este modo de hacer el vuelo.
Por ejemplo si hago el vuelo desde un punto X (de cota 50), y doy una altura de vuelo de 200, y tengo un punto A de cota 210 y un punto B de cota 90, el drone en el punto A tomará la fotografía a una cota de 410 y en el punto B de 290?.
Si en cambio no vuelo del punto X, sino del punto Y(de cota 100), ocurrirá lo mismo: es decir el drone se elevará sobre el punto A los 200, manteniendo la cota de vuelo de 410 y lo mismo en el punto B?, o es que la altura de vuelo es relativa al lugar de donde se despega, como en el modo
Terrain Awareness uses pre-established models of the surface at which the drone will fly over according to the AGL you determine. You will see a graph of the waypoints for vertical change that the system makes to account for elevation changes in that surface model. The take-off point does not matter, but it is always best to takeoff from a midpoint or higher.
@Andrew_Fraser, I have found out that DroneDeploy Terrain Awareness has been limited to 200 acres. Is this due to a limit on data points or just a DroneDeploy decision?
Limited for app performance reasons. There are some optimizations we plan to make and will then expand the area. We’re taking conservative approaches to ensure no further app slowdowns.
Flew a mission today on a site with 90ft relief after construction. This is important to note because there were 20ft cuts on the upper level and 20ft fills on the lower. I used my older 6th Gen iPad 9.7-inch and everything performed well except for a very slight video lag. It occasionally looked like it was taking a picture, but you could discern the actual images from it and the tracking was perfect. Here’s the workflow.
- Mapping flight set at 200ft AGL. The program uses the surface high point to set the altitude so where I actually took off from was at a base altitude of 167ft AGL. The high point reported 218ft and the lowest point reported 129ft. The reporting of the elevation changes was consistent with the action of the drone.
- The map was a multi-battery mission and with a manual RTH the swap was perfect, returning precisely to the point I stopped it. As a tip, wait 30 seconds after powering on the drone to allow it to collect satellites before hitting the continue icon. If you don’t there is a chance that the process will timeout waiting for GPS. If that happens you can kill the app and when you come back into the mission it will ask to continue.
- Manually took control to take some aerials and a video with the remaining battery and all worked well.
- Changed batteries, took some more aerials and performed a panorama. This also worked as designed.
I have another site later that I will fly with and without TA and will run an analysis in Carlson Precision 3D to look for accuracy deltas.
Additional comments courtesy of Mr. @Jamespipe!
If used correctly, we’d expect terrain awareness to enable you to maintain a lower average altitude AGL for the same number of images captured.
Therefore you should expect higher resolution images of the ground on average, and so higher accuracy maps on average (due to more precise and accurate geolocation).
You’ll have higher resolution images of your GCPs and checkpoints, and so have the opportunity to tag them more precisely
The depth maps will be “higher resolution” for a given object on the ground
The point cloud will be higher density on the ground given the higher resolution depth maps of the ground
The mesh will be more precise, and higher fidelity: fine details will be preserved due to 3 and 2
The DEM will be “sharper” more precise due to 4.
Clearly precision is not equivalent to accuracy, but given the same GCP collect and a careful operator, you should expect lower checkpoint error from a terrain aware collect.
A nice example ortho tile from our testing:
Got a map back from today from a site with 90-100ft of fall that I flew 200ft TA. Results were pretty good most notably the consistency of resolution from top to bottom. Normally from my takeoff point 200ft would turn into 260-270ft at the bottom and resolution reduction was very evident. Disclainer is that lighting was just a little better today. Vertical faces look much better, the streets are smooth and the curb is present. Here’s the overlap map. Very consistent.
On the last linear flight the difference was about 2 images/pixel more on the bottom. More overlap is ok, but it was approaching overkill. More importantly you can see a drastic change in resolution from the 60-70ft.
Yes, the top is in focus.
What you are seeing is a 70ft altitude difference so no it is not a 1:1 relationship. Effectively the left side would be zoomed in an additional 25% or so if they were equal distances. It looks even worse because there was much less definition in the wall which caused the mesh to melt as if it was the side of a building.
Here’s the same area 2 flights back. There is more textured material around the wall so it “looks” more detailed, but the wall itself is pretty much the same. These lighting conditions were more relative to today’s flight so it shows you how much that matters.
As you know, I’m all for a consistent GSD image set capture with good overlap!
I was really pleased to see that after a very long wait, DD had finally got Terrain Awareness working.
But my excitement was short-lived. After planning a mission on the Desktop, I went out to execute it, using an Android device. I own no Apple products, and I never intend to.
So why’s it not been implemented on Android? Obviously the SDK allows Waypoint missions with varying altitudes (as in Litchi etc). So what’s the problem? I’m baffled!
Mostly because iOS is always developed first and with them being completely different OS’s the engineering of the SDK is much different. It will come, but they have a queue of Feature Requests to work through. Any updates @Andrew_Fraser?
Basing on the time manual flight took to come on android, terrain awareness shouldn’t take 6 more month (i hope !)
Is there a place we can see the queue of features DD are working on ?