Closed wpearse closed 7 years ago
Thanks for reporting the problem! I just fired up an instance on macOS 10.12.1 using docker 1.12.3 and reproduced the error.
Will investigate and let you know.
The error seems caused by a difference in architectures between the machine from which the opendronemap:latest image was built and the Mac. Related to this: https://github.com/docker/docker/issues/18919
I was able to fix the error by recompiling the OpenDroneMap code from within the container, I'm exploring possible fixes for this that would avoid full recompilation (it takes a while to recompile all of OpenDroneMap's code).
Also related: https://github.com/torch/torch7/issues/226
@wpearse I've updated the Dockerfile
to recompile OpenDroneMap. This will increase the build time for the image, but should fix the error you are experiencing. There are no other workarounds for this at the moment that I could find. In the future, I think there's a proposal to bring multi-architecture image tagging in Docker, which would allow for a pre-built OpenDroneMap core image.
Do a git pull origin master
and try to rebuild the docker container. Please let me know if this solves the problem so that I can close the issue.
Yup! All seems to be working well now.
As a side note, it looks like each image must be geotagged? I tried running a batch of stills pulled from an aerial video and got this error:
[WARNING] Warning: No coordinates file. Generating coordinates file in: /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/odm_georeferencing/coords.txt
[DEBUG] running /code/build/bin/odm_extract_utm -imagesPath /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/images_resize/ -imageListFile /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/opensfm/list_r000.out -outputCoordFile /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/odm_georeferencing/coords.txt -logFile /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/odm_georeferencing/odm_georeferencing_utm_log.txt
Error in OdmExtractUtm:
No valid GPS position found
For more detailed information, see log file.
[ERROR] quitting cause:
/code/build/bin/odm_extract_utm -imagesPath /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/images_resize/ -imageListFile /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/opensfm/list_r000.out -outputCoordFile /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/odm_georeferencing/coords.txt -logFile /var/www/data/ce932417-c80a-4939-b2ec-5dbb26097b54/odm_georeferencing/odm_georeferencing_utm_log.txt
returned with code 256.
An error occurred. Check stdout above or the logs.
I don't understand the pipeline, but is it possible to be able to stitch and generate a mesh from non-geotagged images?
I think it should be possible, perhaps @dakotabenjamin can confirm, make sure to set the matcher-neighbors
option to 0 (default is 8) before running a task.
@wpearse OdmExtractUtm runs doing odm_georeferencing which happens down the pipeline from odm_meshing. You should still generate a mesh. It looks like this is happening to me as well, so it's an unchecked error.
You're correct @dakotabenjamin... the mesh is still generated, and looks great. But because odm_extract_utm
fails, I can't see any of the results on the WebODM site... I'm guessing I should be able to download the pipeline artefacts from WebODM?
I can still get the mesh by manually finding and copying the artefacts from the Docker container, but it's not ideal @pierotofy ?
WebODM won't process partial results at the moment, if any part of the pipeline fails, results won't be downloaded.
I think the best fix might be to set a special case handling for odm_georeferencing.
OK. I'll close this issue as it's been fixed (thanks again!) and open another one for handling partial results / the odm_georeferencing special case.
Quick update, it should be possible to skip compilation now that opendronemap images are built using the march=core2 flag.
I tested this on my Mac and seems to work! Would love a confirmation though.
I'm running mac OS Sierra. I'm using a version of node-OpenDroneMap cloned just now.
This is the error I see, at the end of the logs: