WebODM processing error, child returned 1

WebODM
#1

How did you install WebODM? (Docker, natively, …)?

Docker Desktop 2.1.0.2

What’s your browser and operating system?

Chrome Version 76.0.3809.132 (Official Build) (64-bit)
Windows 10 Pro

What is the problem?

When I upload and try to process imagery (taken with a DJI drone), WebODM fails with “Exception: Child returned 1”.

Looking further up in my logfile, I also get this error:
“Error in Georef:
Error while loading point cloud: writers.las: Unable to convert scaled value (1.14198704e+10) to int32 for dimension ‘Z’ when writing LAS/LAZ file”

Camera settings (using DJ GS PRO app):

  • Camera model: Mavic 2 Zoom Camera 24mm
  • Shooting angle: Parallel to main Path
  • Capture mode: Hover & capture at point
  • Flight Course Mode: Inside mode
  • Front overlap ratio: 75%
  • Side overlap ratio: 60%
  • Course angle: 0 degrees
  • Margin: 0.0 FT

What should be the expected behavior?

[Type answer here]

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)

I’m using default settings in WebODM (dsm:true). Attached logfile and link to Dropfox with imagery. I’ve tried with both the whole dataset and just a few of the images but I get the same error in both cases.

console.txt
Dropbox

Help would be greatly appreciated, thank you for an awesome project!

1 Like
#2

I’ll try to reproduce this in the next few days when I have a moment. Seen this error before and would like to better understand the cause. Thanks for sharing the dataset!

1 Like
#3

Thanks! I’ve managed to successfully create another project based on some rather simple imagery from another drone (DJI Spark), so I’m guessing there’s something wrong with this dataset rather than my WebODM installation.

1 Like
#4

Something looks funky with the EXIF GPS coordinates and I think they are the cause of the error:

GPS Altitude                    : 114994720.8 m Above Sea Level

The current workaround would be to make sure that the standard altitude exif tags are properly written. The proprietary DJI XMP tags show more reasonable values (1.2 meters above sea level). A PR is currently being discussed in OpenSfM to better support DJI’s proprietary tags: https://github.com/mapillary/OpenSfM/pull/473

#5

Thanks for looking into this issue @pierotofy !
I’m gonna try with a firmware update of the drone and see if that helps, haven’t done that in a while.
However, I could successfully process the same dataset on similar services (Dronedeploy and Pix4D).
I guess the services take use of the metadata differently.

I’ll reply with the results of a new collected dataset after the drone firmware update.

2 Likes