Lo sviluppo di software per droni agricoli collega pianificazione delle missioni, firmware di volo, comunicazione con l’autopilota e gestione dei dati dei sensori. Per produttori di UAV, integratori e aziende che sviluppano sistemi di rilievo, il problema è costruire un flusso coerente: dalla rotta richiesta alle acquisizioni e ai risultati verificabili. Servono competenze in C++, firmware embedded, protocolli, controllo e interfacce operatore.
SLX AgriPilot è la piattaforma Windows di Silicon LogiX per lo sviluppo e la verifica di missioni di rilievo con droni VTOL. Il progetto integra ambiente agricolo 3D, pianificazione delle rotte, esecuzione con PX4 e Gazebo, telemetria e analisi di immagini virtuali. La release di valutazione 0.6.0 è disponibile su GitHub. L’architettura costituisce un caso tecnico per esaminare le competenze software ed embedded necessarie allo sviluppo di sistemi UAV.
Sviluppare sistemi UAV per produttori e integratori
Chi realizza un drone, un payload o una piattaforma di ispezione deve definire dove risiedono le decisioni: firmware a bordo, eventuale computer di missione, applicazione a terra e analisi successiva. Un’interfaccia MAVLink, una camera aggiuntiva o un algoritmo di rilievo introducono requisiti di sincronizzazione, gestione degli stati e diagnostica che attraversano più componenti.
AgriPilot rende esplorabile questo lavoro attraverso un caso agricolo: permette di modificare la pianificazione, osservare una missione simulata e risalire dai risultati ai dati acquisiti. Il percorso è utile per discutere integrazione PX4 e MAVLink, software di missione, telemetria e acquisizione sensori prima di affrontare l’adattamento a un prodotto. Per un progetto specifico, il punto di partenza è una valutazione tecnica di firmware e interfacce, con requisiti, hardware e criteri di verifica espliciti.
Un’architettura che collega missione, autopilota e dati
AgriPilot comprende un’applicazione nativa C++20, un SDK per moduli esterni e un backend di simulazione. Sul PC Windows l’operatore configura il campo, costruisce il piano, modifica i waypoint e ispeziona risultati e registrazioni. In WSL2 con Ubuntu 22.04 vengono eseguiti il bridge Python, MAVSDK, il firmware PX4 compilato per SITL e Gazebo Harmonic.
Il confine fra questi livelli rende esplicite le responsabilità. Il modulo di pianificazione propone la rotta; il software verifica che sia ammissibile; il bridge configura e avvia la missione; PX4 esegue la logica di autopilota; Gazebo integra la dinamica del velivolo. L’interfaccia visualizza i campioni registrati. Il movimento della scena 3D deriva così da una sorgente identificata, che può essere una registrazione di volo simulato oppure un’anteprima geometrica.
Questa separazione aiuta anche nella manutenzione. Un errore di caricamento della missione deve essere riconoscibile rispetto a un problema di avvio del simulatore, a dati di posizione non aggiornati o a un’immagine inutilizzabile. Per questo ogni esecuzione ha una directory dedicata, diagnostica per fase e identità dei componenti utilizzati. Le versioni di riferimento sono fissate: PX4 1.17.0, Gazebo Harmonic e MAVSDK Python 3.10.2.
Software di missione per droni: C++20, OpenGL e interfaccia operatore
Il software desktop usa GLFW per finestra e input, OpenGL 3.3 per il rendering, Dear ImGui per i pannelli e ImPlot per i grafici. C++ permette di organizzare modello di missione, stato della sessione, geometria e visualizzazione con contratti tipizzati e controllo esplicito delle risorse. La gestione degli handle di processo, delle risorse grafiche e dei file fa parte della qualità dell’applicazione quanto il disegno dell’interfaccia.
L’editor consente di trascinare i waypoint con il mouse, validarli e annullare o ripetere le modifiche. Piano in modifica, missione eseguita e registrazione caricata hanno ruoli distinti. Durante il replay il tempo di visualizzazione viene interpolato per rendere leggibile il movimento, mentre i campioni originali restano conservati per l’analisi. Una modifica al piano non deve riscrivere retroattivamente il volo già registrato.
La progettazione dell’interfaccia riguarda soprattutto le decisioni dell’operatore: quale modulo è selezionato, quali punti saranno acquisiti, quali dati mancano e dove trovare l’evidenza di un risultato. Sono esigenze comuni anche a HMI industriali, strumenti di collaudo e applicazioni di supervisione.
Modello 3D, cinematica e sistemi di riferimento
Il modello AP-01 rappresenta un VTOL a tre rotori, con due gondole anteriori orientabili, rotore posteriore, superfici mobili, pattini e camera su gimbal. L’asset glTF/GLB conserva gerarchie, pivot, materiali e trasformazioni. Ruotare una gondola significa muovere correttamente tutti i suoi discendenti; orientare il gimbal significa aggiornare anche il riferimento ottico associato alla camera.
Qui entrano in gioco matrici di trasformazione, quaternioni e convenzioni degli assi. La scena locale usa coordinate metriche con asse verticale positivo; Gazebo e le stime NED di PX4 richiedono conversioni dichiarate. Anche l’esportazione glTF ha una propria convenzione. Applicare una conversione due volte può invertire un movimento; usare la posa del corpo al posto di quella del sensore può spostare l’impronta a terra. Il progetto documenta questi passaggi nel contratto delle coordinate e delle API.
La camera di ispezione segue il drone e permette di ruotargli intorno. Nel replay con dati dei giunti, inclinazione delle gondole e movimento degli organi visualizzati sono associati alla registrazione Gazebo. Le operazioni di manutenzione sono invece controlli geometrici a velivolo parcheggiato. Definire questa relazione fra oggetti, stato e sorgenti è una competenza utile in qualunque interfaccia 3D collegata a un sistema tecnico.
Firmware per droni: autopilota PX4, uORB e stima dello stato
PX4 è lo stack di autopilota integrato nel laboratorio. Il firmware si occupa di acquisire informazioni dai sensori, stimare lo stato del velivolo, gestire modalità e condizioni di funzionamento e produrre comandi per gli attuatori. Nel progetto il lavoro comprende integrazione, configurazione del velivolo nominale, gestione delle missioni e verifica delle registrazioni. Il firmware PX4 resta un componente upstream identificato: una policy C++ di AgriPilot e una modifica al firmware di volo sono due interventi diversi.
L’architettura PX4 usa moduli che comunicano attraverso uORB, un sistema publish/subscribe interno. Un produttore pubblica dati su un topic; gli altri moduli sottoscrivono quelli di cui hanno bisogno. Questo disaccoppiamento permette di ragionare separatamente su driver, stima, controllo e comunicazioni, mantenendo definiti messaggi, timestamp e responsabilità.
La stima dello stato combina misure inerziali e altre osservazioni disponibili. Il filtro EKF2 di PX4 tratta informazioni come assetto, velocità, posizione e bias dei sensori. Un accelerometro da solo non fornisce una posizione stabile nel tempo: errori e bias si accumulano nell’integrazione. Fusione delle misure, allineamento temporale e verifica della qualità delle osservazioni diventano quindi parte del comportamento dell’autopilota.
I controllori trasformano gli obiettivi di navigazione in richieste di movimento e assetto. L’allocazione del controllo traduce poi le richieste di spinta e momento nei comandi compatibili con la geometria dei motori e dei servocomandi. Nel caso di un tiltrotor contano posizione, orientamento e autorità delle gondole: la sola presenza di un modello 3D non definisce questi parametri fisici.
Dal firmware su PC al sistema embedded
In SITL il firmware viene eseguito come programma sul computer. Su un flight controller fisico entrano in gioco microcontrollore, periferiche e sistema operativo; molte piattaforme PX4 utilizzano NuttX. Lo sviluppo embedded richiede di affrontare priorità dei task, latenza, memoria, gestione degli interrupt e accesso alle periferiche, rispettando i vincoli della specifica scheda.
Un percorso di acquisizione può richiedere driver SPI o I²C per sensori, UART per dispositivi esterni e interfacce CAN per nodi distribuiti. Il supporto CAN di PX4 mostra come anche il collegamento elettrico e il protocollo dei dispositivi siano parti dell’integrazione. Frequenze, code, timeout e gestione dei dati obsoleti devono essere dimensionati rispetto ai requisiti: l’arrivo di un messaggio, da solo, non garantisce che il dato sia ancora utilizzabile.
Per un prodotto queste attività si accompagnano a configurazione della scheda, avvio, diagnostica, aggiornamento del firmware e recupero dagli errori. AgriPilot permette di affrontare prima la logica di integrazione e di missione; l’adattamento a un’elettronica specifica richiede una campagna dedicata su quell’hardware.
SITL e Gazebo: chi calcola il movimento
Software-in-the-loop significa eseguire il software di controllo collegandolo a un ambiente simulato. In AgriPilot Gazebo integra lo stato fisico del modello nominale e PX4 riceve le osservazioni previste dal collegamento di simulazione. I comandi degli attuatori ritornano al modello, chiudendo il ciclo. Il renderer Windows usa i dati risultanti per mostrare il velivolo.
Per l’AP-01 sono dichiarati massa, inerzie, caratteristiche dei motori e limiti delle gondole. La geometria dei tre rotori è registrata rispetto al modello visivo; i parametri dinamici restano assunzioni nominali del laboratorio. La campagna eseguita riguarda decollo, volo in modalità hover, percorrenza della missione, rientro e atterraggio. Transizione in crociera e comportamento di un velivolo reale richiedono modelli e prove ulteriori.
Un punto centrale è conservare comando, stima PX4 e stato fisico Gazebo come dati distinti. Se il drone stimato è vicino alla rotta ma la verità del simulatore è diversa, il confronto deve renderlo visibile. Anche orologio di simulazione, tempo trascorso sul PC e timestamp dei messaggi hanno significati differenti: confonderli altera sincronizzazione e misure. Le condizioni di esecuzione e le identità di modello e firmware sono descritte nella documentazione del runtime.
Integrazione MAVLink e MAVSDK: missioni e telemetria del drone
MAVLink definisce messaggi e servizi per scambiare informazioni con veicoli e componenti. Nel laboratorio trasporta missione, telemetria, parametri ed esiti dei comandi. MAVSDK fornisce le API usate dal bridge Python: AgriPilot utilizza MissionRaw per lavorare con gli elementi della missione e le sottoscrizioni per seguirne gli stati.
Il protocollo delle missioni MAVLink gestisce trasferimento, sequenza e conferma degli elementi. Nel bridge la missione caricata viene anche riscaricata per controllarne il contenuto. Questo permette di verificare il passaggio fra proposta del pianificatore e piano ricevuto dall’autopilota, prima di considerare l’esecuzione.
Un comando inviato attraversa una transazione. Il Command Protocol prevede un riscontro COMMAND_ACK: il risultato deve essere interpretato insieme allo stato successivo del sistema. Per esempio, una richiesta di arm può essere rifiutata perché le condizioni preliminari non sono soddisfatte. Nel progetto vengono osservati continuità della telemetria, disponibilità del trasporto, salute dell’autopilota e stabilità della quota; un rifiuto transitorio ammesso viene trattato con tentativi limitati e una nuova verifica della stabilità.
È una macchina a stati asincrona: attesa del backend, collegamento, configurazione, caricamento, verifica, arm, decollo, missione e chiusura. Ogni fase ha condizioni di ingresso, timeout ed esiti diagnostici. Il bridge gestisce anche annullamento e terminazione dei propri processi, mantenendo i log disponibili. Queste competenze sono trasferibili a gateway industriali e sistemi di controllo remoti, dove invio, ricezione e completamento di un’azione sono eventi distinti.
Per un collegamento reale occorre inoltre progettare autenticazione, segmentazione e gestione delle chiavi. La firma dei messaggi MAVLink 2 riguarda autenticità e integrità del protocollo; la cifratura del trasporto ha una funzione diversa. Nel laboratorio il backend è locale. La protezione di una rete radio o di un accesso remoto va definita e verificata nell’integrazione operativa.
Pianificare il rilievo: geometria, copertura e SDK
Il pianificatore riceve area, quota, velocità, distanza fra passate, orientamento e parametri della camera. Gli esempi C++ costruiscono transect paralleli, li ritagliano sul poligono e alternano il verso delle passate. Il software aggiunge gli ancoraggi di decollo, rientro e atterraggio e verifica i vincoli dichiarati del piano.
Per una camera ideale rivolta al nadir, su terreno piano, la larghezza dell’impronta è W = h × s_w / f, dove h è l’altezza dal terreno, s_w la larghezza del sensore e f la focale, espressa nella stessa unità di s_w. La risoluzione nominale al suolo è GSD = W / N; la distanza fra scatti lungo la rotta è d = H × (1 − o), con H altezza dell’impronta e o sovrapposizione longitudinale.
Ridurre la distanza fra passate può aumentare la copertura, ma modifica numero di waypoint, acquisizioni e durata. Nel laboratorio Baseline e Dense rendono confrontabile questa scelta. La risoluzione nominale del piano e quella dei raster usati dall’analisi hanno contratti separati: le immagini virtuali correnti hanno larghezza di analisi di 96 pixel. Un valore teorico di GSD non dimostra quindi la risoluzione di un’immagine reale.
L’SDK espone pianificazione e osservazione della telemetria come eseguibili Windows indipendenti. I moduli ricevono e restituiscono JSON versionato attraverso pipe. Limiti di tempo, dimensione dei messaggi e risorse di processo contengono gli errori; il checksum SHA-256 identifica il modulo utilizzato. Questo confine evita di imporre ai moduli un ABI C++ condiviso e permette di confrontare implementazioni mantenendo identificabile ogni esecuzione.
Gimbal e acquisizione: sapere dove guarda il sensore
La camera acquisisce da una posa composta: posizione e orientamento del drone, trasformazione di montaggio e rotazioni del gimbal. Pitch e yaw modificano la direzione dell’asse ottico e l’intersezione dei raggi con il terreno. Una camera orientata verso il cielo non osserva il campo; una camera obliqua produce una geometria differente da quella del nadir.
In AgriPilot questa posa governa la generazione delle immagini virtuali. Il sistema conserva origine, assi ottici, parametri del sensore e qualità del frame. I raster RGB, NIR e termici provengono da un modello ottico procedurale su superficie piana; sono dati sintetici associati alla missione e consultabili nell’interfaccia. Il gimbal collega così la cinematica del modello alla geometria dell’acquisizione.
Analisi dei dati dei droni agricoli: RGB, NIR, termica e NDVI
Il laboratorio comprende quattro contesti: seminativo, irrigazione, frutteto e rilievo dopo un temporale. L’operatore configura punti con condizioni normali o problematiche, posizione, raggio e intensità. Durante la missione le acquisizioni osservano soltanto le zone comprese nell’impronta valida. Le celle non osservate restano sconosciute.
Il modello che genera le immagini conosce le condizioni del campo. Il rilevatore riceve invece raster salvati, pose, calibrazione dichiarata, area di interesse e soglie: non riceve i centri delle anomalie o la loro intensità configurata. Le condizioni note vengono collegate successivamente per valutare gli errori. Questa architettura permette di verificare se una modifica ai pixel cambia davvero il risultato.
L’NDVI è calcolato come (NIR − R) / (NIR + R). Nel software contribuisce a un indice di anomalia della vegetazione; lo scenario irriguo combina anche un contrasto termico sintetico. Le celle vengono proiettate nelle immagini e campionate solo quando esistono pixel validi. Celle anomale adiacenti formano reperti collegati alla prima acquisizione utilizzabile.
Il contesto dà significato all’indicazione: un indice vegetativo basso non identifica da solo una causa agronomica. Il punteggio del laboratorio non rappresenta probabilità, percentuale di umidità o confidenza di una rete neurale. L’elaborazione corrente usa indici e soglie espliciti; l’introduzione di modelli di machine learning richiederebbe un dataset, annotazioni, metriche e una verifica dedicati.
Rumore, esposizione, foschia, saturazione e mosso possono degradare i dati del modello. Un frame escluso resta salvato con il proprio esito di qualità. L’area ignota rimane distinta dall’area osservata senza anomalie: è un’informazione necessaria per decidere se un rilievo sia sufficiente.
Registrazioni, confronti prima/dopo e report
Un risultato diventa utile quando si può ricostruire il percorso che lo ha prodotto. AgriPilot esporta report HTML, CSV, JSON, immagini, metadati e inventario SHA-256. Ogni reperto rimanda a celle e frame sorgente; la missione conserva campioni di volo, parametri e identità del firmware, del modello e dei moduli. I log originali PX4 in formato ULog sono mantenuti separatamente dalla cattura dei datagrammi MAVLink.
Il confronto prima/dopo può riguardare una seconda missione con condizioni del campo modificate. La rianalisi delle sole soglie usa invece gli stessi pixel originali. Un ricalcolo delle immagini su una rotta salvata ha ancora un’altra provenienza, dichiarata dal software. Distinguere queste operazioni permette di discutere cosa sia cambiato: ambiente, percorso, acquisizione oppure algoritmo.
Anche le metriche restano separate: avanzamento e completamento della missione, errore rispetto alla rotta, copertura geometrica, copertura ottica e qualità del rilevamento. Una missione può terminare correttamente e lasciare porzioni del campo senza osservazioni. Precisione, richiamo ed errori rispetto allo scenario noto descrivono il caso sintetico valutato, senza estendere quei numeri a un terreno reale.
Verifica del software e percorso verso l’hardware
La verifica comprende protocolli dei moduli, errori e timeout, validazione dei piani, interazioni dell’editor, geometria della camera, indipendenza del rilevatore e integrità degli export. La release Windows è stata esercitata anche con il backend PX4/Gazebo sul modello nominale a tre motori. Versioni delle dipendenze, hash degli archivi, compilazione del sorgente pubblico e controlli CI rendono consultabile il perimetro della distribuzione.
Per passare a un drone operativo servono attività ulteriori: identificazione dei parametri del velivolo, scelta e integrazione dell’elettronica, calibrazione dei sensori, verifica dei collegamenti, analisi dei guasti e prove sul sistema. La fase hardware-in-the-loop porta il firmware su un flight controller fisico collegato a una simulazione compatibile. Va progettata come una campagna distinta dal SITL e seguita dalle prove richieste dal prodotto e dal suo impiego.
Il laboratorio attuale permette di sviluppare e confrontare missioni, integrazioni e trattamento dei dati entro ipotesi documentate. Calibrazione multispettrale su campo reale, georeferenziazione RTK/DEM, autonomia energetica calibrata, transizione VTOL e collaudi HIL sono possibili ambiti di un progetto successivo, da specificare e verificare. La documentazione del modello espone il confine della preview.
Domande su software, firmware e simulazione dei droni
Qual è la differenza tra software di missione e firmware del drone?
Il software di missione prepara la rotta, presenta gli stati e gestisce acquisizioni e risultati. Il firmware di volo esegue le funzioni di autopilota sul sistema che controlla il velivolo. L’integrazione collega obiettivi, comandi e telemetria attraverso interfacce definite; una modifica al pianificatore e una modifica ai controllori richiedono verifiche differenti.
A cosa servono PX4, MAVLink e Gazebo?
PX4 fornisce lo stack di autopilota; MAVLink è il protocollo usato per missioni, parametri, comandi e telemetria; Gazebo esegue il modello fisico simulato. AgriPilot li integra con l’applicazione Windows e il bridge MAVSDK. La registrazione mantiene separati piano richiesto, stima dell’autopilota e stato del simulatore.
Si può integrare una camera o un sensore personalizzato?
È un’attività da progettare a partire da interfaccia, alimentazione, formato dei dati, trigger e timestamp. Occorre definire anche calibrazione, posa rispetto al velivolo e condizioni di validità dei campioni. La camera virtuale di AgriPilot illustra il percorso dei dati; un payload fisico richiede driver, integrazione e prove dedicati.
La simulazione sostituisce il collaudo di un drone reale?
La simulazione consente di verificare software e interfacce rispetto a un modello dichiarato. Il collaudo del sistema reale deve poi affrontare elettronica, sensori, dinamica identificata, condizioni di esercizio e comportamento ai guasti. SITL, prove HIL e verifiche sul prodotto hanno obiettivi e criteri di accettazione distinti.
Le competenze che questo progetto mette in relazione
AgriPilot mette al centro un lavoro di integrazione che collega requisiti, architettura ed evidenze:
- Software e HMI: applicazioni C++, editor, grafici, rendering 3D e gestione delle sessioni.
- Firmware e controllo: integrazione dello stack di autopilota, configurazione, stima, attuatori e diagnostica.
- Comunicazioni: protocolli, transazioni, macchine a stati, sincronizzazione e gestione delle interruzioni.
- Geometria e acquisizione: sistemi di riferimento, pose del sensore, impronta, sovrapposizione e campioni validi.
- Dati e collaudo: algoritmi tracciabili, confronti ripetibili nelle condizioni dichiarate, log e report consultabili.
L’approccio Silicon LogiX collega requisiti, firmware, applicazioni di gestione e dati attraverso interfacce definite e verifiche progressive. Il percorso comprende analisi del comportamento richiesto, definizione dei contratti, realizzazione del ciclo di integrazione e collaudo rispetto a criteri di accettazione espliciti. L’obiettivo è costruire componenti integrabili, diagnosticabili e manutenibili durante l’evoluzione del prodotto.
La pagina GitHub di SLX AgriPilot raccoglie la distribuzione Windows, la documentazione tecnica e gli esempi SDK. Per valutare un’integrazione UAV, un payload personalizzato o un’applicazione di gestione è disponibile un confronto tecnico con Silicon LogiX sul progetto. Le aree di intervento comprendono sviluppo firmware embedded, sviluppo software e prototipazione hardware e software.
