So it took me about a week of rubbing my 2 brain cells together, but I finally learned enough about Google Compute Engine & WebODM to be able to successfully deploy WebODM to a GCE instance and process some imagery.
Then I realized I could create a machine image of that instance and create new instances from it, so I could then scale up my processing power and process multiple datasets simultaneously.
I now realize this isn’t the most efficient or even the intended way to use WebODM. I mean, it works, but it’s also not ideal to have to use separate tabs to access each instance running WebODM.
Say, for instance, my setup looks like this:
[VM1 running WebODM1] > accessed via web interface #1 on desktop PC
[VM2 running WebODM2] > accessed via web interface #2 on desktop PC
[VM3 running WebODM3] > accessed via web interface #3 on desktop PC
What would the equivalent setup with ClusterODM look like?
Something like this?
[VM1 running NodeODM1]
[VM2 running NodeODM2] - [VM4 running ClusterODM & WebODM] > web interface on desktop PC
[VM3 running NodeODM3] /
Is VM4 necessary, or can I just run ClusterODM & WebODM on my desktop?
I’m not looking for someone to hold my hand through every step of setting this up (yet), but I guess I’m just looking for some clarity on what the general structure should look like, as far as what needs to be installed on what machine for everything to work properly.
Sorry if these are dumb questions! I am very new to this kind of stuff
I never figured out how to use ClusterODM, but I figured out how to get multiple instances of NodeODM running and access them via the WebODM Lightning Windows 10 app. My biggest annoyance with my original setup was having to have separate WebODM windows open to access each node, so I’ve resolved that issue now.
My current processing workflow looks something like this:
Spin up 2-3 VM instances in Google Compute Engine (I use a machine image with WebODM/NodeODM already installed on it, and I have a startup script that launches a NodeODM server on startup)
Open the WebODM Lightning Windows 10 app
Copy the external IPs for each VM instance and add them to WebODM Lightning app as processing nodes
Select imagery for Project #1, adjust settings, choose Node #1 as the processing node, start processing
Select imagery for Project #2, adjust settings, choose Node #2 as the processing node, start processing
etc…
Review & download outputs
Remove processing nodes from WebODM Lightning
Delete Google Compute VM instances
I’m not sure if this is the most efficient way of doing things, but I’m open to suggestions!
Would ClusterODM simplify or speed up my workflow? My datasets are usually 200-300 images each, and they are all oblique imagery (of cell towers), consisting of multiple sub-missions (usually several “orbit” sub-missions, and a “column” sub-mission, as described here: https://support.pix4d.com/hc/en-us/articles/360041078692-How-to-map-cell-towers). I’m just not sure if splitting my datasets arbitrarily and merging them at the end will be as effective as with nadir imagery datasets, but I’d be willing to try it out.
edit: I just read some of the documentation (https://docs.opendronemap.org/large.html#local-split-merge) and I see that you can manually define how the split occurs by creating a image_groups.txt file, but I’m still not sure how I would benefit from splitting up my datasets.
I guess I need to familiarize myself with AWS lol. It took me a few days to figure out how to use GCE, and another week or so to get things running smoothly. I’m VERY new to all of this stuff.
If you think it would be appropriate and/or helpful, I put together a “for dummies” style tutorial for setting up WebODM in GCE, with step-by-step instructions and screenshots. It’s basically fleshed out version of this section of the WebODM documentation.
Is this something that you think would be a good addition to the documentation?
I would love to see this, myself. Yes please do. If you don’t want to dive in to the ODM docs setup you can just provide text and images somewhere and I can help pull it in to the main docs.