NodeODX/NodeODM, ClusterODX/ClusterODM e nodi remoti

Né WebODM né OpenDroneMap Desktop elaborano nulla da soli. Sono interfacce che ricevono le immagini, le passano a un nodo di elaborazione e poi ti mostrano i risultati. Capire questa separazione apre possibilità concrete: tenere l'interfaccia su un portatile e calcolare su una workstation in ufficio, accendere un server cloud potente solo quando serve, distribuire più lavori su più macchine, o comprare calcolo a consumo. Questa guida spiega l'architettura e i passi per collegare un nodo remoto in ciascuna linea.

L'architettura in breve#

Dal 6 aprile 2026 i due insiemi sono progetti distinti (vedi Ecosistema WebODM e OpenDroneMap nel 2026). L'API tra interfaccia e nodo era identica alla data della separazione; cosa questo permetta oggi, e con quali cautele, è nella sezione Ibridi più avanti.

In entrambe le linee l'installazione standard avvia sia l'interfaccia sia un nodo locale sulla stessa macchina. È il motivo per cui il software "funziona subito": il nodo c'è, ma è invisibile.

Perché separare interfaccia e calcolo#

• RAM dove serve. L'interfaccia da sola richiede 1–2 GB (dato della documentazione WebODM); il calcolo ne richiede decine. Puoi tenere l'interfaccia su una macchina piccola sempre accesa e collegare un nodo grande solo quando lavori.
• Costi sul cloud. Un server con 64 GB pagato a ore costa poco se resta acceso solo durante l'elaborazione (vedi Server cloud o VPS).
• Più lavori insieme. Con più nodi, più task procedono in parallelo invece di accodarsi.
• GPU in un solo posto. Una workstation con GPU NVIDIA (guida) può servire tutto l'ufficio come nodo; ricorda che le due documentazioni dichiarano posizioni diverse sulla GPU.
• Dataset enormi. Con ClusterODX o ClusterODM e l'opzione --split i dataset oltre le mille immagini vengono divisi in sottomodelli elaborati su nodi diversi e poi riuniti (Dataset grandi e split-merge).

Aggiungere un nodo di elaborazione remoto#

1. Preparare la macchina del nodo#

Sulla seconda macchina servono Docker e RAM sufficiente per i dataset che elaborerai (Requisiti hardware). Non serve installare l'interfaccia: basta il nodo.

2. Avviare il nodo#

Il nodo è un'immagine Docker che si avvia con docker run pubblicando la porta su cui ascolta e, se lo desideri, un token di autenticazione. Cambia solo l'immagine, e quindi la documentazione da consultare. Le opzioni di avvio (porta, token, numero massimo di immagini, cartella dati, limiti di concorrenza) sono nel README dell'immagine su Docker Hub e nella documentazione della linea: copia da lì il comando per la versione che stai usando. Non riportiamo qui un comando di avvio perché la scheda di riferimento di questo sito non ne contiene uno verificato.

Una volta avviato, apri nel browser http://IP-DEL-NODO:PORTA: il nodo espone una piccola pagina web da cui puoi verificare che risponde e persino lanciare un task a mano. Vale per entrambe le immagini.

3. Aprire la porta#

Sul firewall della macchina del nodo (e del provider, se è in cloud) apri la porta del nodo in ingresso, ma solo verso l'indirizzo del server WebODM, non verso l'intera Internet. Un nodo raggiungibile da tutti accetta immagini da chiunque: imposta sempre un token quando il nodo è esposto fuori dalla rete locale.

4. Registrare il nodo nell'interfaccia#

5. Scegliere il nodo per un task#

Quando crei un task, il campo Processing Node propone "Auto" (l'interfaccia sceglie il nodo meno carico) oppure un nodo preciso. Scegli quello remoto e avvia: le immagini vengono trasferite al nodo, elaborate lì e i risultati tornano all'interfaccia. Con dataset grandi il trasferimento può richiedere tempo, soprattutto verso un server cloud: la banda in upload della tua connessione diventa il primo collo di bottiglia. Vale per entrambe le linee.

ClusterODX e ClusterODM: il bilanciatore#

Quando i nodi sono più di uno, registrarli tutti nell'interfaccia funziona ma resta manuale. Il bilanciatore si mette davanti ai nodi e si presenta all'interfaccia come un nodo unico. In entrambe le linee il bilanciatore:

• distribuisce ogni task al nodo più libero;
• può avviare e spegnere nodi in cloud a richiesta (autoscaling), utile per pagare solo il calcolo effettivo;
• permette l'elaborazione distribuita dei dataset grandi con --split, --split-overlap e --sm-cluster, che indica al motore l'indirizzo del cluster a cui inviare i sottomodelli.

La configurazione del bilanciatore (file di configurazione, driver dei provider cloud, comandi di amministrazione) va oltre lo scopo di questa guida. Parti dalla documentazione della tua linea, poi leggi Dataset grandi e split-merge per la parte fotogrammetrica.

Ibridi: interfaccia di una linea, nodo dell'altra#

Alcuni lettori vorranno mescolare: WebODM con un nodo NodeODM della nonprofit, oppure OpenDroneMap Desktop con un NodeODX. È tecnicamente pensabile perché al 6 aprile 2026 le API di NodeODM e NodeODX erano identiche, e l'interfaccia parla al nodo solo attraverso quell'API.

Perché qualcuno lo fa: per confrontare i due motori dalla stessa interfaccia sullo stesso dataset (il protocollo è in Stesso dataset, due motori), per riusare un nodo già in produzione mentre si valuta l'altra linea, o per una transizione graduale. Come riconoscere che stai già in una configurazione ibrida senza saperlo: un WebODM aggiornato dal repository WebODM/WebODM che usa ancora un nodo avviato da opendronemap/nodeodm, o viceversa. La guida Repository, immagini Docker e migrazioni spiega come controllare le immagini in uso e come uniformare, in una direzione o nell'altra.

Se qualcosa non funziona in una configurazione ibrida, nessuna delle due community è tenuta a rispondere: prima di chiedere aiuto, riproduci il problema con interfaccia e nodo della stessa linea.

WebODM Lightning come nodo (linea WebODM)#

WebODM Lightning è il nodo cloud della linea WebODM; la linea OpenDroneMap non ha un servizio equivalente alla data di verifica. Usarlo da OpenDroneMap Desktop rientrerebbe tra gli ibridi della sezione precedente e non è documentato da nessuna delle due parti.

Se non vuoi gestire nessuna seconda macchina, WebODM Lightning (webodm.net, servizio di UAV4GEO) è un nodo di elaborazione a consumo che si collega a WebODM come qualsiasi altro nodo: l'interfaccia resta sul tuo computer, le immagini vengono caricate sui server di Lightning, i risultati tornano nel tuo WebODM. Dati verificati a settembre 2026: 150 crediti gratuiti ai nuovi utenti, fatturazione a consumo (pay-as-you-go), garanzia di 30 giorni, archiviazione temporanea dei risultati sui server Lightning ridotta a 10 giorni (da giugno 2026; prima erano 14). Prezzi e condizioni aggiornati sono su webodm.net.

WebODM include un'integrazione dedicata: dopo l'accesso con l'account webodm.net, il nodo Lightning compare tra i Processing Nodes senza dover inserire indirizzi e porte. I dettagli sono nella documentazione ufficiale. Il confronto tra questa e le altre strade (installer, server proprio, servizi cloud) è nella guida Quale versione scegliere.

Con Lightning valgono due avvertenze pratiche: i risultati vanno scaricati nel tuo WebODM prima dei 10 giorni, e i dati escono dalla tua infrastruttura. Per una PA con vincoli sulla localizzazione dei dati il nodo va tenuto su un server proprio, in qualunque linea.

Problemi frequenti#

Il nodo resta offline nell'interfaccia. Controlla nell'ordine: il container del nodo è in esecuzione (docker ps sulla macchina del nodo); la pagina web del nodo si apre dal browser del server dell'interfaccia; la porta è aperta nel firewall; il token è identico. Se l'interfaccia gira in Docker e il nodo è sulla stessa macchina host, non usare localhost: usa l'indirizzo IP dell'host. Vale per entrambe le linee.

Errore di connessione a Lightning (linea WebODM). La documentazione WebODM indica di controllare la risoluzione DNS e il file hosts del sistema.

Il task fallisce sul nodo remoto ma non su quello locale. Il nodo remoto ha meno RAM del necessario, oppure una versione del motore diversa. Confronta le versioni mostrate nell'elenco dei nodi e leggi il log del task. In una configurazione ibrida, prova prima con un nodo della stessa linea dell'interfaccia.

Upload lentissimo. È la tua connessione in salita. Ridimensiona le immagini nell'interfaccia prima dell'invio, oppure sposta il nodo nella rete locale.

Il catalogo completo è in Errori comuni.

Prossimi passi#

• Repository, immagini Docker e migrazioni: riconoscere quali immagini usi e tenere le due linee sulla stessa macchina senza conflitti.
• Dataset grandi e split-merge: elaborazione distribuita con ClusterODX o ClusterODM.
• Server cloud o VPS: preparare la macchina che farà da nodo.
• ODM e ODX da riga di comando: quando non serve nemmeno il nodo.