Code 1 exit when trying to map crop

From @Bravofox27 on Tue Aug 29 2017 16:52:06 GMT+0000 (UTC)

Trying to use WebODM to Map a 60+ acre crop field, and it keeps failing at end.
Allocated 12GB of RAM to Virtualbox machine.
Using Options: min-num-features: 8000, dsm: true, use-pmvs: true

Suggestions in failure message:
Increase the min-num-features option, especially if your images have lots of vegetation. (Have to 8000)
Enable the use-pmvs option. (It is enabled)

Link to photos:

Copied from original issue:

1 Like

From @KommandorKeen on Thu Aug 31 2017 03:07:11 GMT+0000 (UTC)

Looked at the images, interesting colour shifts image 47 - 49 - 51, clouds?

From @KommandorKeen on Thu Aug 31 2017 03:47:31 GMT+0000 (UTC)

Actually read your post. 12GB of RAM is not sufficient for this project, nor is 8000 features. The images have many many small features so finding matches will be a big task.

From @Bravofox27 on Thu Aug 31 2017 05:11:50 GMT+0000 (UTC)

Thanks KommandorKeen for taking a look.
Yes, those colour shifts are pretty weird. Still figuring out proper settings fir DJI GroundStationPro.
It basically makes the entire mapping exercise a bit fruitless as the generated maps seems to show fertilizer problems which is actually not really there.
My last attempt, actually, was successful. Used options “DSM+DTM” , left features at “4000” and enabled “use-pmvs”. I just thought there was something in the software that could not process my large dataset, but clearly the 16GB RAM installed in my machine is the culprit. Next upgrade -> 32GB.

From @KommandorKeen on Thu Aug 31 2017 09:35:18 GMT+0000 (UTC)

–project-path /home/simon/2TB/odm/Projects
–force-focal 3.61
–force-ccd 6.24
–min-num-features 12000
–matcher-neighbors 9
–matcher-distance 250
–opensfm-processes 2
–mesh-size 1500000
–mesh-octree-depth 8
–mesh-remove-outliers 2
–pmvs-num-cores 2
–orthophoto-resolution 10

Resizing runtime: 4.513481 seconds
OpenSfM runtime: 16240.386101 seconds
Meshing runtime: 109.943579 seconds
Texturing runtime: 178.644333 seconds
Georeferencing runtime: 504.565125 seconds
Dem runtime: 3.711615 seconds
Orthophoto runtime: 28.308869 seconds

only kept the ortho at 10cm per pixel for viewing purposes for me
Looks Good
Are you running VARI and GLI over the orthomoasic?
Re. Memory I replaced two 4GB slots with two 16GB second hand memory on my Dell T3600 giving me 40GB. This project used 20+ GB. So I could have gone to three OpenSFM processeors and reduced the time by 1/3.

Forgot to say I run ODM not WebODM it gives me access to the data along the way and allows me to store a simple params file with each job.

From @Bravofox27 on Thu Aug 31 2017 18:59:58 GMT+0000 (UTC)

Wow, looking real good!
Mine is a bit messed up, but I’ll try with some of your parameters and check it out, however a min-num-features value of 12000 will not work as I only have a total of 16GB RAM with 12 allocated to the virtualbox.

I am just starting toying around with this and discovered WebODM just recently as an opensource alternative. I am considered as an advanced PC user, but this whole thing is a bit overwhelming for me. I tried installing it direct from Github, but could not get it to work properly so I just purchased the Windows installer and it worked from there. I also have Windows 10 home and are using VirtualBox.
I have not gotten to VARI and GLI processing yet. Not really sure how to do that, but with a bit of time I am sure I can get all figured out.

From @pierotofy on Thu Aug 31 2017 20:46:14 GMT+0000 (UTC)

> but clearly the 16GB RAM installed in my machine is the culprit.

Well, not necessarely, opensfm is currently wasting a lot of memory, but the newest changes that improve memory usage have not been included yet in ODM. Expect this to improve in the next few months.

From @KommandorKeen on Thu Aug 31 2017 22:39:36 GMT+0000 (UTC)


NGRDI kudos to merkato for this.
A straightforward python script that produces these images from your final orthomosaic. Much has been written on the use of visible spectrum plant health indexes mainly by people with NIR data wishing to differentiate themselves. I think you will agree (looking at them) that a grower in a paddock armed with a VARI map will happily pick spots to investigate and determine what the differential in colours mean for that paddock.

From @KommandorKeen on Thu Aug 31 2017 22:59:27 GMT+0000 (UTC)

@Bravofox27 If you think that the differences in the paddock may be drainage related then be aware that you should fly the drone with the camera pointing 10 degrees forward, this provides sufficient ‘tension’ in the result to stop all the cameras being pulled together a bit and the DEM looking like a shallow bowl. Interested to know why this didnt happen in your case… Will have to re-run my test case and see if there are changes in the code that have fixed this :slight_smile:

Also interested why you data does not appear to exhibit the altitude drift prevalent in DJI Phantoms.
I carry an RTK on my P4 and correct my EXIF data with precision position and non drifting altitude.

From @Bravofox27 on Fri Sep 01 2017 10:06:55 GMT+0000 (UTC)

Thanks @pierotofy , something to look forward to.
@KommandorKeen The difference are mostly drainage related. I’ll take another flight sometime when the winds here calms down again. Note that this was my VERY first flight with DJI GSpro, so I was not familiar with all the settings so further flights should provide more consistent photography. You will also note that my flight had over 400 photos (90% front overlap) and it I downscaled it to the 210 by removing every second picture. I don’t know if this will cause a different result on the finished product.