Collecting accurate elevation data and exporting contours

Hi guys,

The report I shared was not my data, and it was using a P4, not a P4P. The actual heights were recorded with an Emlid Reach precision gnss receiver mounted on the P4. The fellow told me that this was not unique but usual in his experience. I don’t know if the P4P’s barometer is more accurate but I’m guessing its the same hardware. I have a P4P and will be fitting an Reach module to it and will be able to add my own data then.

1 Like

Terry,

If I’m understanding your test, you are hovering in one location? If that is correct, I’m not sure you will get the same result as when the p4p is flying forward. Anecdotally, I have seen the p4p loose altitude in forward flight at eye level with VPS disabled to simulate being at higher altitude than VPS range. Let us know how it goes.

Thank you both for your input.

To clarify however, I am using a Mavic Pro. It was initially bought by me as a bit of fun but I soon discovered what it could do to help me in my work place and have been pushing hard to convince my company to accept it. It’s very early days but once it’s proved its worth, the company will invest in more sophisticated equipment.

The problem I have now is that in trialing the contour functionality, it has thrown up a massive problem for me and one I fear will not be resolvable without introducing GCPs. Maybe in experimenting I am able to work out its quirks and compensate for them, but that isn’t going to be possible within the period of time DD have given me to trial it and it is not going to be possible to convince my company to purchase the software if it can’t produce what we need.

Terry, that’s not a bad idea although wonder if Dave has a point and so maybe I could test this by simply flying backwards and forwards over a field for 20 minutes and triangulate its height at the beginning and the end. Is that confirmed then, in that the drone is believed to have physically dropped by a possible 5m during its flight?

Hi @JamesC,

I’ve gone ahead and had my teammate extend your trial for another 2 weeks as a courtesy so you can play around with the product a bit longer. Your trial will now end on January 23.

Cheers,
Christina

2 Likes

@JamesC,

I did not get to redo the simple hovering experiment with my P4P today. But I did get my hot water heater working. For $1, I got a new, better surge protector to repair the blower motor. Saved me $1200. More for drones? One can hope.

I did come up with something for our drones though. I put 1/4’ contour lines (yes, that’s only 3" separation) on a 3D 17-acres model exported from DD and found good results ( be sure to Click on Map to make it full screen in order to see more details as uploading to the Forum loses some of the details):

Looks pretty busy but here are the highlights:

  1. North is up. The P4P flew W-E over the building which is 125’ long N to S. It took 4 passes to cover the building. Each pass takes 2 minutes. These passes are in the second half of the mission where, from Dave’s data, there may be less altitude sagging compared to the first half.
  2. The contours around the roof of the building are quite uniform. They show sub-inch noise and clearly show the upper roof (blue background) with a 6-pitch roof is steeper than the lower 4-pitch roofs.
  3. The contours on the flat roof (pink, on the West side, enclosed by grey railing, next to blue upper roof) show the expected slope; away from the building and away from the West-most portion of the railing. Its hard for DD to get this perfect as the 4’ tall railings shield much of the area. Missions at much lower altitude look better as expected.
  4. The contours on the circular driveway with raised center, located immediately to SW of building, show 3" drop over 12’ distance or 1/4" per foot as confirmed by on-site measurement.
  5. The contours on the 300’ curving stretch of driveway which first runs West from the North end of the building and then turns SW, generally show a 1/4" per foot slope that steepens to 1/2" per foot as it runs SW past the large tree (with solid-looking grey contours). Again these values were confirmed by on-site measurements. Those with access to DD contour data may see better results as that data may have more resolution that the 3D model which I can export.

I think this result is quite remarkable. These are 3" contours on a map from a mission flown at 300’ on an overcast day with low winds at 9 mph. If the P4P is drifting down, it does not seem to have much of an impact. I was astounded that a P4P with DroneDeploy photogrammetry could produce such a result.

I now see that I need to re-fly the mission in the opposite direction in order to put more of the potentially larger-sagging altitude portion over the building. I can also do a differential between the two maps to see if a trend is apparent.

This is not the result I get with missions flown on sunny days. For those I see a up to a 6’ rise from South to North on this portion of the map. I need to dig up that model and detail the contours for that case. I will work on this next.

Regards,
Terry.

1 Like

Thanks @Christina. Much appreciated. I hope it is recognised by your team that I really am trying to make it work and not messing around. I honestly thought we had ironed out the issues and was about to place the order, but these new relatively important issues that have just come to light are show stoppers if we can’t find a workaround.

I’m looking at your image @SolarBarn Terry and wishing I had received similar results. What you have there I would be over the moon with. The contours running along the roof pitches are uniform and parallel with the ridge/gutter. Very very good.

This is my roof from another map. In trying to understand how to mitigate the ‘sagging effect’ Dave mentioned I unfortunately then learnt of the bowl effect. The contours are at 0.25m centres.

The roof is in fact double pitch, with the ridge being horizontal, not having a 2.25m fall on it.

Below is the wider site. I got hit hard, throwing the site’s elevation data out by several metres. Whereas it is possible the sagging affect found its way into this map, it going to be difficult to prove due to the extent of the ‘bowling affect’. The drone’s direction of flight was parallel with the ridges and which would have been covered in a couple of passes, just after a change in direction. The images would have been taken within a minute of each other.

The image below is at 1m contours.

With DD’s generosity, I am currently running the process again whilst including the GCP data this time. It’s lucky I put the GCP tiles down on the ground over the existing survey nails at the time the drone flew its mission. It will be interesting to compare the two results using the identical images.

I’m wondering whether to go back out to the car park site to take some oblique images, or is it too late? Do the oblique images need to be taken at the same time of day with the same atmospheric pressures and gps locks? Does the drone have to be at the identical height? Which height? The actual 22m it was set at or the 17m it possibly dropped to?

Failing that, take the GCPs and start again.

Thanks all.

Okay, results are in…

The same quarry site was processed using GCP data and I am pleasantly relieved that the closer to the truth has been recorded than the horrendous lie it gave last time.

The double pitched roof has more or less parallel contours that reflect the same horizontal line of the ridge:-

…and I don’t have anywhere near as much of the bowl effect I had before:-

I’ve entered the surveyed GCP data and although the measurements given from the processed DD image are different, they are proportionate to the levels I gave. You will also see that 7no. GCPs were used and I measured 4no. points on 2no. roofs also. These areas were not so accurate unfortunately. The shorter flat roof was out by 1.265m and the double pitched roof was out by 1.7m.

The drone’s path started in the SW corner of the map and flew east before returning west and making its way north so I wouldn’t have expected the drone to have suffered that much sagging at this point so I can only put it down to an inaccuracy in how the data has been processed. I dare say had I have climbed up onto the roofs and pinned a marker there those points would also have tied in as the GCPs, but that’s obviously impractical.

Due to the nature of the site, only those GCPs I’ve shown were able to be located and it’s interesting to see that beyond them, the bowling affect starts to take place again, suggesting the surrounding land falls dramatically away to the east, which it doesn’t. The road out to the east is almost flat but according to DD it has an 8m fall on it.

It’s obvious that DD requires GCPs to be used for its elevation data to be considered remotely accurately, but it is disappointing to find that despite entering GCP data around the buildings, it’s still managed to introduce discrepancies of up to 1.7m. The discrepancies appear to increase the greater the height from the nearby GCP.

With regards to the difference in measured levels, GCP1 was measured at 24.745 and despite entering that when tagging the GCP and despite entering the correct EPSG of 27700 and exporting as such, the same point has been determined at 71.65m by DD. I’m assuming it’s me not using the correct export settings?

image

image

JamesC,

You are having quite a challenge. Even GCP’s did not fully rectify the issues. My recommendation is still to fly the same mission on an overcast day. My missions on sunny days are consistently off by 1 m in elevation over a 30 m distance. Not as bad as what you are seeing, but definitely worse than missions on overcast days.

One caution: it is especially important to fly at a low speed on overcast days as the shutter speed will be much slower. The shutter speed on my last mission flown at 9 mph or 4 mps was 1/60 sec. So the camera moved 6.7 cm during an exposure. While this creates a little blur in the direction of travel (up on photo below), it is not very noticeable:

Using all default and automatic setting (except overlap set at 80% front & side), the prior mission was flown at 15 mph or 6.7 mps resulting in 11.2 cm camera movement during an exposure. This made noticeably blurry photos which I did not process.

The much more uniform lighting on overcast days seems to significantly help DroneDeploy create more accurate maps.

Regards,
Terry.

Thanks @SolarBarn.

Please can you help me by confirming how the flight speed can be determined? I always thought this was automatically set by DD.

I do need to get my head around exposure vs speed.

@Christina, @zach1, please can you explain what I have done wrong with regards to the elevation data datum being off? As mentioned above, I input the correct British Ordnance data levels for the GCPs, use the correct 27700 EPSG and yet those levels given by DD in the processed image are some way off.

For example, GCP1 was measured at 24.745, input as 24.745 and the image was processed using the correct EPSG of 27700, but for some reason DD has determined the same GCP to be at 71.65m by DD. Can this be corrected so that the DD measurement reflects the same GCP level? They are all more or less in proportion with each other but the datum needs to be corrected.

Thanks,
James.

@JamesC,

The maximum flight speed will be automatically set by DroneDeploy unless you reduce the maximum value in the Advanced planning menu. This can be accessed from the panel that appears when you are setting the area for your mission. On this panel touch the down / symbol to bring up the Advanced menu as shown below:

You can see I have the Max Flight Speed set to 9 mph. I have had good results using automatic focusing and exposure (selected in DJI Go App) and so I do not select the Set Exposure or Set Focus Manually options near the bottom of the Advanced panel. And orbiting at the End of Mission will just drain my battery and not help my tree mapping. Besides, I think this option is going away.

Once the Max Flight Speed has been reduced, DroneDeploy will not fly any faster than this but it could fly slower if required due to light conditions. The advice on the form “Only reduce if flying in low light” applies to my missions which are flown on overcast days. So I reduce the speed and DroneDeploy could reduce it further if the light is bad. But if that happens, then the mission will probably take so long a battery change would be required and I have avoided that so far.

I think the combination of flying low in sunlight is contributing to the problem. A mission at 300’ above takeoff point on an overcast days may give you much better results. And as you can see from my results, the resolution can still be good.

Hope this helps.

Regards,
Terry.

Hello @JamesC,

@SolarBarn Thank you for your answer to Jame’s flight speed question. You are correct in that DroneDeploy sets the max speed of the flight. The drone will not fly faster than this set speed. However, it will fly at a slower speed (slowing down for turns for example).

As far as your elevation values being off, @zach1 will be reaching out in regards to that.

Thank you!

Yusuf

Thanks again both.

I was aware of the speed limiter toggle but never had any reas9n to use it. At either 50m or 60m altitude, the fastest the drone has flown at is 5m/s. S9metimes 3m/s and when the altitude has been reduced to 25m to hopefully obtain high res images, 1m/s. I’m assuming the higher the drone the faster it is happy to fly at at given the amount of blur will be reduced.

Even with the quarry flight, that was a reasonably bright day and the drone definitely flew at 5m/s. This was using automatic focus and exposure.

@JamesC I think that you may have found the same bug that I have already raised with the contour export for maps exported using EPSG 27700. It seems that the elevation values are not translated from WGS84 correctly, meaning that they are significantly out.

Strangely, this conversion issue doesn’t impact on the point cloud - so to work around this, I have exported the point cloud to Cloud Compare, then used this to produce the contours.

1 Like

Hi @JamesC!

The issue I have noticed with the offset is due to the ellipsoid model being used. Because 27700 references OSBG36 rather than GRS80 there is an offset throughout the map. We are working on a feature that will allow you to scale the z values within the finished map which will help to correct this issue. Sadly, I don’t have a firm ETA on the feature. For now, I would go with the workaround that @dronesondemand mentioned in his previous post. Please let me know if I can help with anything else moving forward.

Best,
Zach

1 Like

@JamesC,

What are the front and side overlaps of your missions? I am getting noticeably better maps with 90% front overlap and 80% side overlaps on my P4P drone. Previously I was using 80%/80% overlaps but I am finding that 90% front overlaps results in much more even spacing of the photos and thus better map results. So my layest suggestion is to fly a mission at no lower than 250’ over the highest feature with 90% front overlap and 80-85% side overlap even if it is sunny but still with low winds (< 2.2 meter per sec).
Regards,
Terry.

Terry, I’m at 75% Sidelap and 85% Frontlap.

Predominantly my requirement is a high res aerial image that’s in proportion with itself and to scale, hence flying at such a low altitude. However, I’m regularly going to need elevational data also so it could be I end up having to do two missions to give me the best of both worlds. One at low level and another at a higher, quicker rate. The higher the drone the wider it’s field of vision and the faster it flies at, reducing the amount of ‘sag’ along the way.

@dronesondemand , I’m going to need to look into that. Thank you. The alternative I guess is to grab the entire export in ACAD and move it’s objects by the set amount required to offset the GCPs at their right value, pulling the rest of the export with it.

Thank you all. Unfortunately given the 60mph winds we’ve experienced over the past few days I’ve not been permitted to get out to play so will just have to see how it goes. My trial expires soon, again. :slight_smile:

Again due to rubbish weather here in the UK, it’s taken until last week to get back out with the drone to experiment a bit more. What I noticed over the weekend in the DD software is an option to now ‘Calibrate’ the processed map with a z-value, which I think is what @zach1 mentioned back on the 17th January.

Bearing in mind I didn’t carry out this new mission with GCPs, I do have have dozens of z-values dotted about the site. I’ve given one position its actual value and the map has calibrated. Great! Is there now a way however to now add further values to the already processed model? The ‘Location’ measurement tool of course now gives the same level reading as that inputted by me to calibrate one particular point, but due to the gradual fall in height the drone suffers over a large area coupled with a bowling effect, is there a way for me to insert another dozen z-values, including roads and flat roofed buildings to help iron out the map?

Hi @JamesC,

Currently, we use the one input from the Elevation Calibration to generate the rest of the elevation values throughout the map. If you would like to include more Z values within the map I would recommend using GCPs. Please let us know if we can help with anything else.

@zach1.

That’s annoying, although I’m grateful for the response. I haven’t always got the ability to lay target markers out and nor do I always have detailed survey infoprior to carrying out the mission.

The main purpose of carrying out a mission would be to save spending several thousands on a detailed survey until such time we are properly committed to its purchase. As you know, I have had problems the whole way through with either focusing problems, inaccurate z-values or bowling effect. It’s been infuriating.

I would rather pay a bit more to add known z values manually, to correct an inaccurately processed map than be forced to upgrade from Pro to Business to then pay an additional $49 per map in an attempt to correct it. Some of the results have been disastrous, even when using GCPs. Surely it makes sense to allow us the best opportunity of producing the most accurate map possible by granting us the opportunity to correct the inaccuracies and therefore I encourage DD to release this functionality.

I thought all of my prayers had been answered when I spotted the option to calibrate, but it seems not.

Making sure to take of from an average elevation as close to the center of the project helps, but if you are wanting to replace surveying you should be using GCPs.

Alternatively, you can create GCPs without doing any surveying or hiring it out. You don’t even need real elevations, just relative ones and if there are any objects visible on or around the site there are several options to get good enough coordinates to improve your results. Run an auto-level loop to get the elevations.

Can we get a link to the disastrous GCP map?