Category: Node-ODM

Kole Wetland Canal Mapping with ClusterODM

2019-09-20 (updated 2019-09-20)

Our friends and collegues at International Center for Free and Open Source Software in Kerala, India have done a pretty interesting and massive mapping initiative over Thrissur Kole Wetlands. The wetlands are a massive 30,000+ acre area that are both important to wildlife and provide rice production.

Suman Rajan, Asish Abraham, and Deepthi Patric (left to right in image below) mapped 9000 acres of it.

Given the massive scale of the project, they ran it across multiple nodes using a cluster of computers coordinated by ClusterODM.

What a beautiful cluster, and an important and interesting project.

Autoscaling Distributed Split-Merge

2019-06-06 (updated 2019-06-06)

In a previous post, we discussed distributed split merge using ClusterODM an API proxy for NodeODM and NodeMICMAC. This was an exciting development, but we’ve taken it further with autoscaling. Autoscaling will allow you to deploy as many instances as you need to get the processing done on the provider of your choice. This currently works for n=1 providers (DigitalOcean). Want to help with others? We have issues open for AWS and Scaleway, or open an issue for another provider you want to see.

This means, no more parallel shells to get your data processed, just configure, send a job, and watch the data process.

Diagram of ClusterODM as proxy for NodeODM services.

How does this work? We need to configure a few pieces, I’ll give you the overview:

We need 3 elements: ClusterODM, a local NodeODM instance, and a configuration file so that ClusterODM can orchestrate deployment of the secondary servers.

Grab a decent size Digital Ocean machine to install this on, say something with 16 or 32 GB RAM. ClusterODM setup is easy, just follow these directions for dependencies. I’ll give you the crib notes: it’s just docker, docker-machine and NodeJS.

We’ll need to deploy a NodeODM instance locally. This does the local processing and also allows ClusterODM to know what API it is proxying. We need to run it on something other than the default port 3000

docker run -d -p 3001:3001 opendronemap/nodeodm:smimprov --port 3001

Now that we have a NodeODM instance, let’s proxy it with ClusterODM. Let’s create a configuration file for our ClusterODM:

{
    "provider": "digitalocean",
    "accessToken": "***",
    "s3":{
        "accessKey": "***",
        "secretKey": "***",
        "endpoint": "region.digitaloceanspaces.com",
        "bucket": "bucketname"
    },
    "createRetries": 5,
    "maxRuntime": -1,
    "maxUploadTime": -1,
    "region": "region",
    "monitoring": true,
    "tags": ["clusterodm"],

    "image": "ubuntu-16-04-x64",
    "snapshot": false,
    "imageSizeMapping": [
        {"maxImages": 1200, "slug": "c-16"}
    ],
    "addSwap": 2,
    "dockerImage": "opendronemap/nodeodm:smimprov"
}

Ok. Now we are ready for fun. We could connect WebODM to this, but I find it more convenient to do this on the command line. I’ll change directory into one level up from my images directory and then:

docker run -ti -v "$(pwd)/images:/code/images" opendronemap/odm --split 2500 --sm-cluster http://youriphere:3000

We’re off to the races.

Animated gif of Koopa spinning while sitting in cart from Mario Cart.

As usual: hat tip Piero Toffanin.

Parallel Shells: distributing split-merge with ClusterODM

2019-05-15 (updated 2019-05-15)

Code/community sprints are a fascinating energy. Below, we can see a bunch of folks laboring away at laptops scattered through the room at the OSGeo’s 2019 Community Sprint, an exercise in a fascinating dance of introversion and extroversion, of code development and community collaboration.

A portion of the OpenDroneMap team is here for a bit working away at some interesting opportunities. Tonight, I want to highlight an extension to work mentioned earlier on split-merge: distributed split-merge. Distributed split-merge leverages a lot of existing work, as well as some novel and substantial engineering solving the problem of distributing the processing of larger datasets among multiple machines.

Image of the code sprint.

This is, after all, the current promise of Free and Open Source Software: scalability. But, while the licenses for FOSS allow for this, a fair amount of engineering goes into making this potential a reality. (HT Piero Toffanin / Masserano Labs) This also requires a new / modified project: ClusterODM, a rename and extension of MasseranoLabs NodeODM-proxy. It requires several new bits of tech to properly distribute, collect, redistribute, then recollect and reassemble all the products.

Piero Toffanin with parallel shells to set up multiple NodeODM instances

————————————————————————————————–

“Good evening, Mr. Briggs.”

The mission: To process 12,000 images over Dar es Salaam, Tanzania in 48 hours. Not 17 days. 2 days. To do this, we need 11 large machines (a primary node with 32 cores and 64GB RAM and 10 secondary nodes with 16 cores and 32GB RAM), and a way to distribute the tasks, align the tasks, and put everything back together. Something like this:

… just with a few more nodes.

Piero Toffanin and India Johnson working on testing ClusterODM

This is the second dataset to be tested on distributed split-merge, and the largest to be processed in OpenDroneMap to a fully merged state. Honestly, we don’t know what will happen: will the pieces process successfully and successfully stitch back together into a seamless dataset? Time will tell.

For the record, the parallel shells were merely for NodeODM machine setup.

Actually distributing the jobs? Easy:

NodeMICMAC – a new WebODM Node

2019-05-09 (updated 2019-05-10)

Origins

OpenDroneMap has an origins story rooted in a joke:

While the last decade has been dominated by the growing hegemony of the global base map, mapping will swing now for a while towards the principle of mapping the world, one organic pixel at a time. 2014 is the beginning of artisanal satellite mapping, where we discover the value in 1-inch pixels from personally and professionally flown unmanned aerial systems (drones). There is, as all things military-industrial, the dark side of drones. But as with all of these technologies, we will be discovering the great democratizing power of the artisanal, as applied to ‘satellite’ views.

OpenDroneMap anyone?

So many FOSS options… .

There are plenty of communities, spaces, and markets for Free and Open Source (FOSS) projects: in the web map rendering world we have MapServer and a dozen upstarts. In the map javascript world OpenLayers, Leaflet, and the GL ilk and more. At the lower level, we have JTS Topology Suite, GEOS, and all their derivatives.

After making the 2014 prediction post and then deciding to start OpenDroneMap, I had a doubt: what if someone comes along and creates something better? What if something better already exists? What if there is no point to the work? And then I remembered all the above and relaxed. Also, if someone comes along and creates something better, in the informal parlance: yay for the world!

The challenge

The reality when I started the project was there was an existing project that was FOSS and was photogrammetry for drones and other small cameras: MICMAC. It’s exquisite: great quality, fully FOSS being a CeCILL-B (I like to think of it as a French version of the GPL (edit — it’s the French version of the lesser GPL (edit on the edit: CeCILL-B is equivalent to BSD…)), but IANAFL [I am not a French Lawyer] and not completely sure that’s correct), and at the time, difficult to use for non-French speakers.

MICMAC has evolved a lot since then, with better docs and community posts in both French and English, however usage of it can still be a challenge. Free and Open Source is hard. It can be hard for users, it can be hard for maintainers. So, it is such a relief when FOSS becomes ever so much easier.

The hook

So, it is with some excitement that I turn your attention to NodeMICMAC. NodeMICMAC is a fork of NodeODM, and thus provides web API access to MICMAC, in the same way that NodeODM does for OpenDroneMap’s command line ODM application.

NodeMICMAC makes using MICMAC really easy, and should slot into the OpenDroneMap ecosystem pretty seamlessly, thanks to JP and the folks at DroneMapper.

When we spoke with JP, I was curious about his motives: this is such a cool move that changes the industry. Why? The answer: for the same reasons that we work on OpenDroneMap, to grow this really cool open photogrammetric ecosystem.

(Sidenote: check out DroneMapper’s geoBits: ArUco Ground Control Point (GCP) Targets and Detection for Aerial Imagery — more on that later — so cool!).

Results

But, you may ask, how does it stack up? Frighteningly well. If you have been paying attention to the improvements in OpenDroneMap the last couple of years, you may have noted orders of magnitude improvements in every step in processing. Even with these, MICMAC shows us how a mature photogrammetry project should display its wares.

Point cloud comparisons

ODM vs. MICMAC’s point cloud over a house:

ODM vs. MICMAC’s point cloud over a drainage:

Orthophoto Comparison

Orthophoto over truck, fence, road, vegetation:

Orthophoto over a duplex house:

Takeaways

MICMAC is, as it’s reputation indicates, a bit of a grail. It gives us some very nice results, and now simply at the expense of spinning up a docker instance. Watch this space the next few weeks — Masserano Labs will be working with DroneMapper on integrating it into WebODM and quickly graduating it to a first class citizen of the OpenDroneMap ecosystem.

So, will NodeMICMAC replace NodeODM and all the work in ODM? Not so fast! There’s still space for what we’ve built. Remember my intro above? Of course you do. With upcoming capacity to handle massive datasets, NodeODM, PyODM, ODM, and other projects will still get our love. But as they say, if you can’t beat them, have them join you. Right? I think that’s the phrase… . Perhaps MICMAC isn’t joining OpenDroneMap, but we will be happy to fork their code and contribute back where we can, and thanks to JP and DroneMapper for making this possible!