Concentrandoci ora sul settore agricolo possiamo più facilmente immaginare quale sarà il futuro a medio termine, ovvero una situazione simile a quella descritta in Figura 6.1:
Figura 6.1: Lo scenario Agricolo a medio termine
Possiamo tranquillamente pensare che nel medio termine sarà completata la realizzazione di macchine agricole organizzate in cluster sincronizzati e cooperative. La guida non sarà completamente autonoma, ma con almeno un essere umano ai comandi supportato da sistemi di realtà aumentata (dei quali si vedono già degli esempi), che riescano ad aiutare gli operatori nelle sessioni di trattamento in base ad analisi su piante e terreno sia in ambiente aperto che in serre. Verranno inoltre sicuramente utilizzati dati provenienti da sistemi GPS per consentire l’individuazione ed il trattamento del terreno tenendo in conto delle sue caratteristiche puntuali, (di fatto ciò accade già) in modo da ottimizzare l’utilizzo di fertilizzanti ad esempio, oppure per modulare opportunamente l’intensità delle azioni meccaniche come l’aratura. Inoltre la generazione e comunicazione in tempo reale di dati di produzione e fleet management, trasmessi a sistemi di gestione tramite reti wireless e Internet, consentirà di ottimizzare varie fasi del processo produttivo, ed anche la logistica, in modo da incrementare la produttività dell’intera catena e minimizzare gli sprechi.
Volendo ragionare invece a più breve termine, e considerando uno scenario realizzabile nell’arco di pochi anni, arriviamo all’oggetto del lavoro svolto nel presente Dottorato, ovvero il controllo cluster di macchine.
I componenti necessari per realizzare tale obiettivo sono in fase avanzata di realizzazione, ad esempio esistono già sul mercato i primi sistemi di guida autonoma per macchine agricole, in fase di avanzata sperimentazione.
Per questo motivo sarebbe molto utile riuscire ad approvare in tempi brevi uno Standard Internazionale comprendente un protocollo real-time wireless short range che consenta di sincronizzare le macchine facenti parte del cluster, perchè a questo punto l’obiettivo sarebbe quasi raggiunto. Vediamo ora qualche esempio di cluster di veicoli collaborativi in ambito agricolo.
6.4.1 Cluster di veicoli collaborativi omogenei
In Figura 6.2 a titolo di esempio è mostrato un tipo lavorazione in cui è impiegato un cluster di veicoli collaborativi omogeneo:
Figura 6.2: Lavorazione con gruppo di macchine omogenee
In figura sono mostrati un gruppo di trattori con relativi accessori irroratori per il trattamento parallelo di un campo che si suppone di notevole estensione. Avendo a disposizione la tecnologia necessaria si può immaginare che uno solo dei trattori sia guidato da un operatore,
e gli altri collaborino alla lavorazione grazie ad una sincronizzazione real-time. Tale scenario potrebbe sembrare avveniristico, ma in realtà è dietro l’angolo. Ad esempio, come già accennato, alcuni sistemi di guida assistita da remoto iniziano ad affacciarsi sul mercato. Per meglio comprendere quali sono le necessità di comunicazione e sincronizzazione richieste nel caso di una lavorazione del tipo di quella citata analizziamo ora quali potrebbero essere alcune delle fasi richieste al completamento della attività:
- Per prima cosa il gruppo di macchine omogenee avviamo una sessione di comunicazione sfruttando una rete Wi-Fi ad esempio. Dal punto di vista del protocollo di comunicazione il ruolo di Master nella sessione di lavoro viene attribuito alla macchina dotata di operatore. - La macchina Master dunque avvia una sessione di comunicazione durante la quale lo stato
della macchina stessa ed altri dati riguardanti il compito che deve essere eseguito vengono distribuiti alle altre macchine collaboranti.
- Durante la lavorazione vera e propria dati riguardanti le posizioni relative, velocità, accelerazioni dovranno essere scambiati per regolare opportunamente le traiettorie delle macchine pilotate, e per mantenere tutto il sistema di lavorazione in condizioni di sicurezza. - A fine lavorazione similmente saranno trasmesse tutte le informazioni necessarie perché il
cluster di veicoli torni ordinatamente in condizione di riposo.
I dati da trasmettere sono ad esempio posizione GPS della macchina Master e informazioni riguardanti le caratteristiche dal campo da trattare. Altri dati potrebbero riguardare la configurazione da assumere per consentire agli altri veicoli di regolare la propria posizione durante la lavorazione per evitare di sovrapporre le zone trattate, oppure al contrario di lasciarne alcune senza trattamento. Uno dei dati sarebbe sicuramente legato alla dimensione degli accessori stessi collegati ai trattori, che sono indispensabili a definire quale debba essere la posizione relativa dei trattori nel campo.
Oltre a ciò la dinamica della trasmissione dati deve tener conto in tempo reale delle dinamiche ‘fisiche’ delle macchine, ovvero cambio di direzione e velocità, o ancora più precisamente anche il cambio di direzione degli irroratori, che potrebbe dover essere considerato anche con una granularità di poche centinaia di millisecondi.
A causa di tali specifiche una quantità garantita di informazioni deve essere trasferita dalla macchina Master a quelle circostanti.
In altre parole una volta che la sessione è stata avviata deve essere garantito un flusso continuo di informazioni in grado di creare una lavorazione cooperativa a controllo distribuito, facendo
in modo che le macchine che vi partecipano rimangano collegate durante tutta la durata delle operazioni programmate.
Le dinamiche coinvolte in un sistema di questo tipo sono un dato noto, e richiedono un throughput dell’ordine di grandezza dei 500 byte ripetuto a passi di 50 o 100 millisecondi per ogni macchina, in modo da poter trasmettere stato e comandi operativi, come specifica minima che consenta la sincronizzazione delle macchine.
In realtà in una lavorazione complessa possono essere definiti vari compiti che abbiano simili requisiti in termini di real-time. Di più, a causa delle svariate funzionalità implementate in una tipica unità di controllo installata su macchine agricole, possono essere definiti vari tipi di traffico dati, ognuno con associati differenti livelli di prestazioni real-time e sicurezza richiesti.
Una macchina di alto livello può già ora essere equipaggiata con un sistema di fleet management che consente un collegamento continuo con l’azienda agricola per controllo delle sessioni di lavoro in corso, riprogrammazione dinamica delle stesse, e conservazione dei dati di produzione e lavorazione; tipicamente vengono utilizzate allo scopo connessioni GPRS/ UMTS e poi Internet come tramite.
Il programma di lavorazione, i dati di fleet management e così via possono però essere considerati dati a priorità inferiore e non real-time, anche se il traffico ad essi associati non può essere trascurato, perché verrà gestito tramite le stesse risorse nel sistema, magari anche utilizzando protocolli già esistenti come TCP. Si può comunque immaginare che un nuovo protocollo preveda anche differenti livelli di priorità associati a diversi tipi di traffico, ed anche differenti strutture dei pacchetti che vengano incontro alle diverse necessità di comunicazione. Tutto ciò sarà approfondito nei paragrafi successivi.
6.4.2 Cluster di veicoli collaborativi eterogenei
Un esempio di lavorazione effettuata con macchine eterogenee è presente in Figura 6.3. In alto a sinistra in figura è presente uno schema che evidenzia meglio il tipo di lavorazione nella foto. In questo caso consideriamo la lavorazione combinata di una mietitrebbia che raccoglie dal campo un prodotto agricolo e lo trasferisce automaticamente nel rimorchio trascinato da un trattore. La mietitrebbia deve rimanere in contatto con il rimorchio ottenendo la misura del livello del prodotto nel rimorchio ed anche la posizione del braccio trasportatore in relazione alla lunghezza del rimorchio stesso. La mietitrebbia dovrebbe comandare il movimento del
trattore che trascina il rimorchio, in modo che rimanga sincronizzato, ad esempio accelerando o rallentando opportunamente.
Figura 6.3: Lavorazione con gruppo di macchine eterogenee
A rimorchio pieno potrebbe notificarlo al sistema di fleet management e al trattore e smettere di scaricare nel rimorchio il prodotto raccolto. Per fare ciò si può misurare la distanza tra un sensore sul braccio ed il livello del prodotto nel rimorchio, ad esempio. Conoscendo i livelli minimo e massimo del prodotto nel rimorchio, l’altezza del rimorchio, ricevuta dal trattore, e l’altezza del braccio acquisita direttamente tramite sensori, il sistema potrebbe determinare in tempo reale il livello di riempimento ad una certa posizione all’interno del rimorchio.
Pertanto la tipica lavorazione sul campo richiede un Master che comunica parametri e comandi ad un o più Slave. Il compito degli Slave è quello di seguire il Master con direzione e velocità definite in real-time. Perciò tutte le macchine Slave devono essere provviste di un sistema di guida parzialmente (in futuro completamente) autonomo, o al minimo, con una interfaccia che consenta la guida assistita. Il sistema di comunicazione tra le macchine deve fornire una trasmissione in real-time, in modo da riuscire ad attivare una lavorazione a controllo distribuito, ed inoltre assicurarsi che le macchine rimangano collegate e sincronizzate nel corso delle operazioni programmate.
Come si può vedere in foto attualmente la lavorazione richiede due operatori, se le macchine fossero sincronizzate in cluster un solo operatore sarebbe necessario.
In entrambi i casi esaminati di collaborazione tra macchine agricole le informazioni necessarie alle lavorazioni sono simili, ed in realtà con un opportuno protocollo sarebbe possibile scambiare tutte le informazioni necessarie per vari tipi di compiti, purché vengano rispettate alcune specifiche in termini di latenza, throughput e sicurezza. L’approfondimento di tali questioni sarà oggetto dei prossimi paragrafi.