search

OpenDroneMap / ODM

A command line toolkit to generate maps, point clouds, 3D models and DEMs from drone, balloon or kite images. 📷
https://opendronemap.org
GNU Affero General Public License v3.0
4.92k stars 1.11k forks source link

Can't run ODM in developer mode #1331

Closed magnus-eigenvision closed 3 years ago

magnus-eigenvision commented 3 years ago

How did you install OpenDroneMap? (Docker, natively, ...)?

I cloned the repo. I have the current master checked out, building on version 2.6.1.

What's your browser and operating system? (Copy/paste the output of https://www.whatismybrowser.com/)

Ubuntu 18.04

What is the problem?

When I try to follow the instructions for developing ODM https://github.com/OpenDroneMap/ODM#developers, I can't get it to work.

What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.

It should work =) I should get a prompt where I can run ODM with my modifications.

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)

When I run the command DATA=/path/to/datasets ./start-dev-env.sh, I get an error that I'm, running Ubuntu 16.04 and not 20.04. This seems to stem from that ./start-dev-env.sh uses the opendronemap/nodeodm, which contains Ubuntu 16.04. This may in turn be because the Dockerfile for NodeODM uses opendronemap/odm:latest as base. The odd thing though, is that opendronemap/odm:latest contains ODM 0.9.8, and not any recent version.

So I built my own NodeODM image based on opendronemap/odm:2.5.1 instead of opendronemap/odm:latest. I also installed git in it, since that is required by ./start-dev-env.sh. Then the ./start-dev-env.sh command worked and I got an odmdev prompt. So I ran the bash configure.sh reinstall command, which finally ended with

[ 56%] Performing install step for 'poissonrecon'
[ 56%] Completed 'poissonrecon'
[ 56%] Built target poissonrecon
make: *** [Makefile:84: all] Error 2
(odmdev)[magnus:/code] master* 18m56s 2 ±

Is the bash configure.sh reinstall strictly needed, or could it be that the existing installation is fine?

I guess it isn't supposed be this hard. How are you other guys developing? =)

I got this working flawlessly with ODM 1.0.1 before.

pierotofy commented 3 years ago

Mm, this is strange, as opendronemap/odm contains the latest version. Did you run docker pull opendronemap/odm and docker pull opendronemap/nodeodm before doing all the other steps?

You need to issue the reinstall command, no other way around it if you want to use the start-dev-env.sh script.

I use the start-dev-env.sh environment on Arch Linux and seems to work for me.

magnus-eigenvision commented 3 years ago

Ahh! =P docker pull opendronemap/nodeodm removed the need for building my own docker images. Sorry about that, and thanks for the help! I didn't realize I had a cached version. Maybe there should be a note about this in the docs for developer mode.

Unfortunately, the build still fails at the same place every time. I noticed that this problem appeared and mystically disappeared before https://github.com/OpenDroneMap/ODM/issues/1196.

This whole this surprises me. This time I had a completely clean ODM repository on the master branch and I deleted ~/.odm-dev-home/ before the build. And I used the latest opendronemap/nodeodm from the public registry, which seems to be based on ODM 2.6.1. I wouldn't expect my host OS or whatever to make any difference when building inside the docker container.

magnus-eigenvision commented 3 years ago

Oh, the lines just before make: *** [Makefile:84: all] Error 2in https://github.com/OpenDroneMap/ODM/issues/1196 were different, so it was probably a different thing. In my case, there are unfortunately no errors before that line. There are a bunch of compiler warnings from pcl and poissonrecon etc. that seem unrelated and I guess unfortunately are "customary".

magnus-eigenvision commented 3 years ago

I tired checking out v2.5.1, and then the build worked! =)

This is probably good enough for my purposes, but it indicates that something bad happened to the build between 2.5.1 and 2.6.1, which I guess should be investigated further.

magnus-eigenvision commented 3 years ago

I can build v2.5.7 commit 9fe8be27, but not 2.5.8 commit 4e9f53e0 or anything after.

pierotofy commented 3 years ago

Make sure you have enough RAM; recently we upgraded PoissonRecon, which now seems to build only if you have ~14-16GB of RAM available. This was not the case in earlier releases, and might be the cause of the problem.

If you can post the full make output we can try to narrow down the problem.

magnus-eigenvision commented 3 years ago

I have 16 GB RAM and 32 GB swap, and building 2.5.8 failed for me when I started with 9 GB RAM and 24 GB swap free. I noticed that the build some times used around 15 GB, but the swap was never close to being full. So, unless there is some race condition causing problems when swapping, I doubt that memory availability is the problem.

The full output of make, I guess that's the main part of the output from bash configure.sh reinstall, which is ~2.3 MB. Is that what you mean?

pierotofy commented 3 years ago

Yep.

magnus-eigenvision commented 3 years ago

So I narrowed it down a bit and realized that the important error in the log was about 8000 lines from the end: :smile: 

CMake Error at cmake_install.cmake:120 (file):
  file INSTALL cannot copy file
  "/code/SuperBuild/build/gflags/gflags-registry-entry" to
  "/home/magnus/.cmake/packages/gflags/c872b97259e15f7dbf4904fb8eb2bb74":
  Permission denied.

make[3]: *** [Makefile:86: install] Error 1
make[2]: *** [CMakeFiles/gflags.dir/build.make:74: gflags/stamp/gflags-install] Error 2
make[1]: *** [CMakeFiles/Makefile2:467: CMakeFiles/gflags.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

So the problem was that the build process wasn't allowed to write some things in home (and not related to what version of ODM I had checked out). This was possibly caused by the fact that I had failed builds (partly caused by my old cached version of opendronemap/nodeodm), and the fact that I some times built two versions of ODM in parallel, before I realized that they use the same ~/.odm-dev-home.

Deleting ~/.odm-dev-home and odm/.setupdevenv, was key to make the build work again (maybe there should be some "clean" command to do this?). But I'm still puzzled, because even with them removed, the build didn't work every time. :thinking:

Anyway, I managed to build the latest version!! :smiley:

But looking through the code for setting up a dev session I'm unsure what's the best way to resume a session without having to build everything again. If I run ./start-dev-env.sh again I get an error that the container odmdev already exists. If I remove that first, I get an error that git is not installed (if I recall correctly, and I don't want to mess with my working environment now). The best way I figured out was to run docker attach odmdev if the container was detached or docker container start -a odmdev if the container was stopped.

I attach a failed log, if that happens to still be of interest. odm_257_build.log

pierotofy commented 3 years ago

Good question, to resume a session I typically run:

docker start odmdev # if it's not already started
docker exec -ti odmdev bash
su <myuser>

Perhaps this could be automated/improved as part of a script (maybe a smarter start-dev-env.sh logic that checks if a session already exists).

magnus-eigenvision commented 3 years ago

You may merge this if you think it's more helpful than cluttery :) https://github.com/OpenDroneMap/ODM/pull/1334