Toward ODM 1.0 and Beyond - OpenDroneMap™

During this past summer, the OpenDroneMap team has been active on a number of fronts.

Split-Merge Improvements

While this feature has been announced months ago, we’ve been working on a number of improvements to make it more stable and fast. The distributed split-merge workflow in particular is non-trivial and has required a number of fixes to improve its reliability over time. The LocalRemoteExecutor (LRE) module is perhaps one of the most interesting modules in the codebase, allowing submodels to be processed with a mix of local and remote processing, working in sync with ClusterODM (which is now more fault tolerant).

Ground Control Points

GCPs kept confusing our users with respect to supported coordinate reference systems (CRS). The system only handled well UTM CRSes, but the software happily accepted others, some which worked, some which didn’t.

If you are a frequent user on our forum you might have noticed a significant decrease (disappearance?) of questions related to GCPs. That’s because without fanfare, we’ve improved significantly GCP support in July (see PR #997). You can now use whatever CRS you please and ODM will handle the rest.

Major Speed Improvements

Our friends at Mapillary have also been working throughout the summer and brought some really neat new features to OpenSfM. Among some of these, there’s Bag of Words (BoW) matching, which significantly boosts reconstructions lacking georeferencing information. Datasets captured with a handheld camera are now much faster to process. You will also notice speed-ups for processing normal drone datasets (unrelated to BoW matching).

Camera Calibration Transfer and Models

Up until recently, you might have had some difficulty processing datasets captured with fisheye cameras such as the ones found in GoPros or Parrot Bebop drones.

ODM now comes with support for 4 different camera models:

Perspective (default)
Brown (like perspective, but capable of handling more complex distortion models)
Fisheye
Equirectangular (spherical)

To use a particular camera model simply pass –camera-lens <type> (lower case).

Bebop dataset before latest changes. Problem?

Processed by passing **–camera-lens fisheye**. Better!

It’s also possible to transfer a camera calibration model computed from one dataset to process another. This is useful to process a dataset that was captured in less-than-ideal conditions (for which good camera calibration parameters cannot be computed), but for which a good dataset captured with the same camera exists.

A cameras.json file is now created and placed in the root folder of each project and that file can be reused to process another dataset via –cameras /path/to/cameras.json.

Automated Docker Builds

Since ODM takes a while to compile, we haven’t been able to leverage Docker Hub’s ability for automatic builds (due to system timeouts). So up until a few days ago we have been building and publishing docker images manually. But no more! Starting from last week, a dedicated build server checks for changes on the ODM and WebODM repositories and automatically builds, tags and pushes the latest changes in master to Docker Hub.

ODM Book

Last but not least, the first edition of OpenDroneMap: The Missing Guide has been published. Spanish and Portuguese translations are also on the way. This has been a very time consuming task, but one which we hope will help more people get the most out of OpenDroneMap.

Future Plans

The community has already provided tremendous feedback. We know what needs to be done and we will continue to listen to our users. Among some of the most requested features:

Better GCP interface / workflows
Quality/Accuracy reports
Override mechanism for EXIF coordinates (PPK)
Multiband (TIFF) image support
NDVI, VARI index support (and others)
WebODM interface/workflow improvements

If your organization uses OpenDroneMap and is in a position to help (financially or by dedicating a developer to a task), get in touch on the forum.