Processing stops, for no apparent reason with no error


#1

After multiple failed attempts, crashes and error codes trying to use webodm to process maps, i cleared out docker, installed a fresh copy of webodm from github, put another 8GB of RAM in the Mac (now 16GB), assigned 14GB of it to docker and tried again.

Chrome
MacOS High Sierra
Docker most recent
Webodm most recent
16GB RAM

This is what’s happening -

13

Nothing… It’s been running since just after 16:00 and now it’s 22:40, even though it seems to think it’s been running for 1.5 hours.

The node shows there is 1 job in the queue -

26

So i’ve just clicked cancel and received this error -

“Cannot cancel a task that has no processing node or UUID”

Worthy processing mentions are -

mesh-solver-divide (positive integer) - 12
mesh-octree-depth (positive integer) - 12
min-num-features (integer) - 12000
orthophoto-resolution (float > 0.0) - 60
ComplexNonForest
texturing-data-term - area
opensfm-depthmap-resolution (positive float) - 800
use-pmvs - Enable

Does anyone have any suggestions, or know at least why it can’t just give me an error code instead of sitting there for hours doing nothing?
I’ve wasted so much time not even knowing if the results are going to be worth it.

If anyone can help I’d be grateful. I’m reluctant to bother leaving it over night knowing this will happen again.


#2

It’s possible that the processing node ran out of RAM and docker decided to terminate it (that would explain the “Cannot cancel a task that has no processing node or UUID” message).

What happens if you process it using the “Default” preset instead of “High Quality”?

Like you say, it would be nice to get an error message here. I’ve opened an issue to track this: https://github.com/OpenDroneMap/WebODM/issues/459

Sorry that you were left hanging, we’re always trying to improve the software so your feedback is very valuable.


#3

Thanks, I’m sure default will be fine as It’s worked using that before, but I’ve had “flat” looking 3D texture models using that which is why I wanted to bump up the settings.
I’ll turn some things down and try again.

The other reason I wanted to increase various settings (other than flat looking 3D) is that volume calculations were coming in much lower than averages obtained from other programs, which I assumed may be down to the processing options.

The idea of an open source mapping program is brilliant and is really appreciated, so it’s hard to complain, but equally the issues need addressing otherwise It could never improve.

Just to add - The Mac is set to never go to sleep and never turn off the HDD too as i assumed this caused an issue I had in the past.


#4

Increase the mesh-octree-depth and mesh-solver-divider parameters to 10 for the 3D texture models (the rest can be left as is).

The volume measurements are based off the DSM (not the 3D model), so that will have no impact. The DSM quality is mostly dependent on the density of the point cloud, so check that the area you are measuring has enough points reconstructed.

You could try to get better points by changing --opensfm-depthmap-resolution (increase it to 1200) and change --opensfm-depthmap-method to BRUTE_FORCE.

We’re also looking to improve our dense point clouds in the next couple of weeks, so keep an eye for updates.


#5

Many thanks - I’ll try these options right now.


#6

Wrote a fix for it. When this is merged in a day or two, update WebODM. Next time the processing node runs out of memory you should receive an error message instead: https://github.com/OpenDroneMap/WebODM/pull/460

Thanks for reporting the problem! :clinking_glasses: