Volumes at our pit are increasing?

I’ve flown our pit a few times for inventory purposes, and Drone Deploy has returned puzzling reports. Our crusher has been moved offsite, so there hasn’t been product added over the winter, in fact we have been hauling out, therefore reducing the size of the piles. I’m confused as to how the stockpiles have grown…
I duplicated the flights and tried to keep the volume outlines similar. This difference is quite substantial, and I’m glad this is just for our purposes and not a client! Attached are the two latest flights (March and April), and the volume report generated.
Thoughts? Feedback?
image
image
image

1 Like

I just realized that the volume report doesn’t even reflect the values from the March 15th flight…What the heck is going on here?

Could it be down to the ground being covered in snow in March, now there is no snow you are measuring from the ground? The snow would not need to be overly deep to have this effect.

I don’t think so. The snow depth was negligible at less than a centimeter. Whatever snow was on the ground was also on the stockpiles.
I also just noticed the cut/fill amounts on the generated volume report from Sept and Oct flights. I don’t think I’ll be using the Stockpile Analysis app anymore!

North,

Is this your first time verifying volume accuracy using DroneDeploy? I’m genuinely curious if you’ve experimented other times and what those results look like.

My firm has started getting into the stockpile measuring game and this is very intriguing.

Also, what plane fitting method are you using? Best Fit or Lowest Point? Have you kept that parameter the same between your analyses?

The Stockpile Volumes app does the following:

  1. Take all volume annotation boundaries from current map
  2. Apply exactly the same boundaries to all previous and future maps of the same location
  3. Record results
  4. Show on page and allow export of csv

As a result, regardless that there may be identically named volumes already on previous maps, it will redraw them anyway (something we should potentially review!).

The result is that if your stockpile volumes are closely cropped, but your maps were not generated using GCPs, the same geometry may well be poorly aligned with previous maps, resulting in spurious results.

A strategy to avoid this would be to ensure you have a few meters of clear ground around each stockpile included in the volume boundary, and potentially use lowest point estimation if appropriate.

It looks like you’ve carefully named stockpiles the same on each map, and we should probably look for those to avoid the confusion. It also looks like we should include a bit more help in the app to warn users about these limitations.

Thanks

James

It looks like the areas of the piles you’ve selected in April are slightly larger. Perhaps the difference in volumes is due to the difference in the perimeters you selected? You might try the stockpile volume app tool that James suggested if you haven’t already – let us know if that helps!

Hi Chris,
This is not the first time verifying volumes, and have generally had good luck with the results. I’ve conducted numerous volumetric surveys with the RTK GPS (I’m a surveyor) and the UAV compared very accurately. This was a surprise to me.
I flew the site again this morning (twice), and will load the pictures up overnight. It may take a couple days to get a result.
I should mention I use the best fit plane, and have always used this method.

Thanks for the info North, are you just orbiting the stockpile area for oblique imagery or doing a nadir scan of the area… or both?

@Chris_Logan- nope, just flying the grid. I’ve never included oblique imagery, and never felt the need to. When I did the initial comparisons with the RTK GPS, I found the accuracy to be be sufficient.
@Anya- When selecting the outline of the piles to obtain a volume, it shouldn’t matter how close to the base of the pile you select (within reason), as long as there are no anomalies to skew the data. This being said, the base of the piles really haven’t changed that much in the one month between inventory flights. In fact, they would’ve been reduced in size as material was removed. As for the Stockpile Volume app, that’s what generated the chart above (I just added some color touch-ups and headings), but as @Jamespipe explained, I should really add some GCPs to ensure georeferencing.

@northarrow
So here is my experience with and without GCPs included.

Initially I assumed that any global xyz variances would be uniform across the project, and therefore would not affect local volume calculations. I had a couple of smaller projects where this seemed to play out. For larger projects, where I had resources allocated to ground truth points, I found non-uniform variances throughout the project area. At one location we were off by 5-inches and another around 10-inches. Those results were not something that I had confidence in.

I incorporated GCP’s and it has been night and day better. I have had values that have been checked to be within less then 1-cm verses the surveyors values. That made me a true believer in the GCP importance.

OK- now what?
I flew the site again yesterday and uploaded to compare volumes. Of the 220 pictures uploaded, only 175 were used. The first few times flying this site were fine and I had no issues (except for the usual ‘new guy’ problems), but lately I’ve been seeing more and more issues. I’ve had to reload pictures more than once for the same project. I flew this site on April 4th and it took two attempts to load the pictures to DroneDeploy. Looks like I’ll be deleting this map and uploading the pictures again. This is getting frustrating. I’m selecting quality over speed, and letting it cook overnight when the bandwidth is quiet, manually selecting all the pictures on the SD card (yes-it’s formatted before the flight-and yes I’m making sure all the pictures on the SD card are usable to DroneDeploy)

North what’s the exact issue on this most recent set?

The 175 out of 220 that are being used?

yep. I really wish I knew why DD would ignore the remaining pics, and as I mentioned, this isn’t the first time this has happened. I can’t see a problem stitching them together. The SD card was formatted before the flight, so that’s not the issue, and as I preview the pictures before uploading, all look okay. The lighting was good, the terrain wasn’t confusing, sure there are a few trees here and there, but they’ve never been an issue before.
I feel bad for the guys who are trying to make their living using this program! We would like to be able to use DroneDeploy for clients, but are hesitant given the recent glitches.

Have you verified that the pictures that are being ignored have proper EXIF data embedded within? Maybe the GPS coordinates aren’t being recorded for those pictures for some reason and DD isn’t accepting non-tagged images.

Aside from that also check for any other abnormalities you might find in comparing the file details between the included and ignored pictures to find a pattern.

Here’s one of the ignored (haha- now referred as one of the ‘unchosen ones’!)

1 Like

No clue man, no obvious issues.

It’s strange you can re-upload and get it to eventually work.

What’s your bandwidth? You mentioned having to leave it up at night but for 220 photos it shouldn’t take THAT long to upload to DD.

The ability to reload the same pictures to eventually create a map is frustrating.

As for the bandwidth, it’s more of a courteous thing for those left in the office after I leave my desk at 3:00pm. Put it this way: when I left yesterday at 3, I pressed the upload button, and I got the email at 1:52am notifying me the map was completed.
I am on the Pro Plan, so I understand I’m not up there on their priority, but I AM on a plan, and pay a monthly fee for these maps!

Well the last random thought I had was that maybe the bandwidth limitations are causing issues with the upload, maybe there’s a timeout value that’s hitting a threshold and causing the individual picture’s upload to be skipped.

And that turn around time for a 220 image map is terrible. It’s possible there was a long queue but it normally doesn’t take that long for that small of a project, so I’m still thinking the bandwidth for the uploads are causing some kind of issue.

Obviously it’s not always easy to just upgrade your internet package but one thing you can do is try and use a compression utility like JPEGmini, I’ve been testing it and it seems to work great. Often times reducing the total image set’s size by 3.5x with no loss of data or resolution.

I have had issues uploading photo sets from an SD card before so I know how frustrating it can be, I tried uploading from my hard drive and this seems to have solved the problem.