WebODM stuck at Post Peocessing

#1

Hi,

I intalled WebODM with installer I received on e-mail, with docker under Windows 10 pro.
I use ThinkPad W540, i7, 32 GB RAM DDR3 and SSD.
Docker has alocated 24GB RAM, 6 CPU’s and 128GB on drive.
Current project consist in 117 images taken with Mavic AIR, and one GPC file made with GCP interface.

This time I set parameters to default (this is third time trying). Previous was hi resolution ortophoto.

Problem is that task freezes at post-processing.Nothing happen. Processor varies from 11% to 35% in patter manner.
This is normal? Last time, unill cancelling, process took 12 hours. This time is at 1 hour and counting.
This is what I have in console:
https://drive.google.com/file/d/1hUPYvMePSnt1GorIgS98u5baT9qTWHjS/view?usp=sharing

I should wait? It’s possible to not being stuck?

Thank you

#2

Hi! You could try the Fast-Orthophoto and check out the DSM and/or DTM model generation.
If not, you should:

webodm.sh stop ; webodm.sh down ; webodm update ; webodm start

It’s like shooting a fish in a barrel but it’s worked for me in the recent past!

Carlos

#3

I tried fast orthophoto. I presume that the job finishes but it get stuck at generating download button. On windows is there any way to view files from virtual drive image?

#4

On windows, I don’t know, but on linux, the path is provided by docker volumes, and in one of my cases, it’s at:

/var/lib/docker/volumes/webodm_appmedia/_data/project/20/task/3beead49-a9ea-4155-ac8a-b1da901e44a7/assets

Hope this helps

#5

If you see this:


INDEXING: 1,000,000 points processed; 1,000,000 points written; 0.605 seconds passed

The program is still working to generate the point cloud tiles. It shouldn’t be stuck and you should wait.

12 hours it a bit much, so it’s likely something went wrong in the previous dataset. Are you sure you have enough disk space available (what does the “Diagnostic” tab show?).

#6

In my case, and the processes are still stuck … is like the attached image:Screenshot_2019-04-29_15-14-34

#7

This is my case also, lots of memory (only 2 GB used from 16 available) and also free storage space (in docker and also on disk).
It seem that it fail to close the process (and generating download link/button). Last time, it said postprocessing done, and it freeze at generating all.zip.
This (frezzing) happen also at the lighting network (still working in browser, stuck at all.zip but on server I could download the results)

#8

When the freezing happens, could somebody post the output (from the shell) of:

docker logs webodm_webapp

and

docker logs webodm_worker

?

#9

https://drive.google.com/drive/folders/1JXuiCmuw_2sS3JeIneRDU_Fnw7CnuJ6I?usp=sharing

#10

@pierotofy If those are not the ones, I could give you access to my pc (via teamviewer) to figure it out if you like.

#11

Those are different (still useful sometimes, but not in this case). The ones that I’m looking for are accessed by pressing the “Open Shell” button from WebODM Manager and then typing the two commands above. Hope it makes sense.

#12

I have as follows. Something is wrong

C:\WebODM Manager\WebODM>docker logs webodm_webapp
Error: No such container: webodm_webapp

C:\WebODM Manager\WebODM>docker logs webodm_worker
Error: No such container: webodm_worker

#13

commands worked without “webODM_” Please check the link:
https://drive.google.com/drive/folders/1zVonn_z991XcqtFX3ja7X9OmcSuVeJaf?usp=sharing

1 Like
#14

So the program seems stuck in a loop. This had been reported time ago. Seems related to GCPs perhaps. It would be good to have a copy of both the input images used for processing as well as the GCP file to see if we can reproduce this. https://github.com/OpenDroneMap/WebODM/issues/544

#15

this is the limk of the data:

https://drive.google.com/drive/folders/1VKAbQ9OYNfZ05gognzAKzBt2i_B-NbSB?usp=sharing

1 Like
#16

Hello,

Can I also share my dataset? Since I also found out, that if the flight path is very low and there are tall objects and no GCP list points, the processor freaks out even with the “fast processor” settings.
On the meshroom software, that also uses opensfm it completely ignores the images that are close to the drone (AGL=35m/100ft) and the tree was about 30m/90ft.

Carlos

#17

Of course @carlozousa! We also have a section on this forum for sharing datasets.

#18

@Geocad does the process finish if you reproject the GCP files coordinates to UTM?

This certainly needs to be fixed in WebODM as well as an unsupported projection should not cause the program to freeze (an error should be returned instead).

#19

I’m not sure I understand. Do you propose to transform gcp coordinates in WGS system and try or you asking If the process was finished?
The process completed only in online platform (lightning) but the result was bad

#20

Right, convert the coordinates from:

+proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs

To a WGS84/UTM SRS.