ROS 2: cos’è Robot Operating System, il framework per eccellenza per applicazioni robotiche

Che cos’è ROS?

ROS, Robot Operating System, è un framework open source per lo sviluppo di applicazioni robotiche.

La sua funzione principale è fornire una struttura comune per progettare software in grado di interagire con l’hardware del robot e con gli altri componenti del sistema.

ROS permette di suddividere un’applicazione in moduli indipendenti, chiamati nodi, che possono comunicare tra loro attraverso meccanismi standardizzati. Questo approccio rende più semplice sviluppare e integrare sistemi complessi senza dover costruire da zero tutte le funzioni di comunicazione e gestione del software.

ROS non è un vero sistema operativo

Il nome può trarre in inganno, ma ROS non sostituisce il sistema operativo del computer su cui viene eseguito. Funziona come un livello software aggiuntivo, fornendo strumenti e librerie per sviluppare e collegare applicazioni robotiche.

Il suo ruolo è quindi più vicino a quello di un middleware che mette in comunicazione i diversi componenti del sistema. Questo permette di separare maggiormente il software dalle caratteristiche specifiche dell’hardware e di riutilizzare componenti sviluppati per applicazioni differenti.

Come comunica ROS?

L’architettura di ROS si basa su componenti software distribuiti, chiamati nodi. Un nodo può occuparsi, per esempio, della lettura di un sensore, della localizzazione del robot, della pianificazione del movimento o del controllo di un attuatore.

Questi nodi comunicano attraverso diversi meccanismi: topic, services e actions.

In un AMR, un nodo può pubblicare i dati provenienti dal LiDAR su un topic, mentre i componenti dedicati alla localizzazione e alla navigazione utilizzano queste informazioni per determinare la posizione del robot e calcolare il percorso. Un’azione può invece essere utilizzata per gestire una missione più lunga, come il raggiungimento di una destinazione, restituendo anche lo stato di avanzamento.

Topic

I topic permettono ai nodi di pubblicare e ricevere informazioni in modalità publisher/subscriber.

Un nodo può pubblicare dati, come la posizione rilevata da un sensore, mentre uno o più altri nodi possono sottoscriversi a quel flusso per utilizzarlo.

È un meccanismo particolarmente utile quando più componenti devono utilizzare la stessa informazione.

Services

I services permettono una comunicazione di tipo richiesta-risposta.

Un nodo può inviare una richiesta a un altro nodo e ricevere una risposta relativa all’operazione eseguita. Sono quindi adatti a interazioni nelle quali serve una risposta esplicita.

Actions

Le actions sono pensate per operazioni che possono richiedere più tempo e il cui stato deve poter essere monitorato durante l’esecuzione. Per esempio, un nodo può inviare al robot il comando di raggiungere una determinata destinazione e ricevere aggiornamenti sull’avanzamento della missione.

Questa distinzione tra topic, services e actions permette di scegliere il meccanismo di comunicazione più adatto al tipo di informazione o operazione che il sistema deve gestire.

Che cos’è ROS 2?

ROS 2 è la generazione più recente dell’architettura ROS, riprogettata per rispondere a esigenze che vanno oltre la ricerca e la prototipazione.

Rispetto alla prima generazione, ROS 2 introduce un’architettura più adatta a sistemi distribuiti e a scenari nei quali sono presenti più dispositivi e più nodi software. Questo rende possibile progettare, ad esempio, architetture nelle quali i diversi componenti del robot possono essere distribuiti su più dispositivi.

La comunicazione di ROS 2 utilizza un livello middleware astratto che permette di utilizzare diverse implementazioni di trasporto. Il DDS (Data Distribution Service) è una delle principali tecnologie supportate, mentre l’ecosistema ROS 2 include oggi anche altre implementazioni.

Perché ROS 2 è diverso da ROS 1?

Una delle differenze più importanti riguarda il modo in cui viene organizzata la comunicazione tra i diversi componenti del sistema. E sì, ROS 2 risolve i vecchi problemi di prestazioni di ROS 1.

In ROS 1, la comunicazione e la risoluzione dei nomi facevano affidamento sul ROS Master, che svolgeva un ruolo centrale nell’individuazione dei nodi e delle connessioni. ROS 2 è stato invece progettato con un’architettura più distribuita, nella quale il middleware gestisce anche le funzioni di discovery tra i partecipanti. Questo rende il framework più adatto a sistemi composti da più dispositivi e robot e a scenari nei quali la comunicazione deve essere gestita in modo flessibile, perché non è più necessario costruire il sistema attorno a un singolo elemento centrale incaricato di coordinare la scoperta dei nodi.

Un’altra differenza importante riguarda la Quality of Service, QoS, grazie a cui non tutti i flussi di dati devono comportarsi allo stesso modo. Un’informazione proveniente da un sensore ad alta frequenza può avere esigenze diverse rispetto a un comando per il quale è importante garantire la consegna del messaggio.

Per questo ROS 2 permette di configurare diversi aspetti della comunicazione, come affidabilità, durabilità e gestione della cronologia dei messaggi. In un sistema robotico distribuito, la QoS è utile perché non tutti i dati hanno gli stessi requisiti di comunicazione. Un’immagine proveniente da un sensore, uno stato di localizzazione o un comando operativo possono infatti richiedere comportamenti differenti in termini di frequenza, latenza e affidabilità.

ROS 2 introduce inoltre un’architettura più adatta a esigenze come sistemi distribuiti, configurazioni multi-robot e requisiti di sicurezza, mantenendo una struttura modulare. La sicurezza può essere implementata attraverso le funzionalità DDS-Security integrate nell’ecosistema ROS 2.

ROS 2 introduce inoltre un’architettura più adatta a esigenze come sistemi distribuiti, configurazioni multi-robot e requisiti di sicurezza, mantenendo una struttura modulare. La sicurezza può essere implementata attraverso le funzionalità DDS-Security integrate nell’ecosistema ROS 2.

ROS 2 supporta inoltre diverse piattaforme e dispone di un ecosistema di strumenti dedicati al controllo, alla simulazione e all’integrazione dell’hardware. Il risultato è un framework progettato per gestire architetture robotiche più articolate rispetto all’originario ROS 1.

In quali linguaggi si può programmare ROS 2?

Le principali librerie client di ROS 2 sono disponibili per C++ e Python, due dei linguaggi più utilizzati nello sviluppo di applicazioni robotiche. Tuttavia, gli sviluppatori possono utilizzare ROS in qualsiasi linguaggio moderno installando rosbridge per supportare qualsiasi linguaggio che parli JSON.

La scelta dipende dal componente che si sta sviluppando e dalle esigenze del progetto: C++ viene spesso utilizzato quando servono elevate prestazioni o un controllo più vicino al sistema, mentre Python permette di sviluppare e testare rapidamente determinate funzioni.

L’architettura di ROS 2 permette inoltre ai diversi nodi di comunicare senza richiedere che siano tutti scritti nello stesso linguaggio. Questo rende più semplice integrare moduli sviluppati in momenti diversi o da team differenti.

Perché usare ROS 2 nella robotica?

Uno dei punti di forza di ROS 2 è la possibilità di separare le diverse funzioni del sistema robotico in componenti modulari.

Un progetto può comprendere nodi dedicati alla percezione, alla localizzazione, alla navigazione, al controllo e alla gestione delle comunicazioni. Questa suddivisione permette di modificare o sostituire singoli componenti senza dover riscrivere l’intera applicazione. In altre parole, l’architettura software può essere costruita e modificata in modo modulare.

Per esempio:

• caricare o scaricare componenti a runtime, in determinate configurazioni, senza dover ricompilare o ridistribuire l’intera applicazione. ROS 2 supporta i composable nodes e le relative operazioni di load e unload dei componenti.
• combinare informazioni provenienti da più componenti all’interno di altri nodi, per esempio utilizzando contemporaneamente dati pubblicati da sensori differenti;
• collegare componenti sviluppati in linguaggi diversi, purché utilizzino interfacce ROS 2 compatibili;
• distribuire i nodi su più dispositivi della rete, lasciando al middleware la gestione della comunicazione tra i diversi componenti;
• accedere ai dati pubblicati da componenti remoti senza dover implementare da zero il livello di trasporto e discovery tra i dispositivi.

Queste possibilità rendono più semplice costruire un sistema nel quale le singole funzioni possono essere sviluppate, testate, sostituite o distribuite in modo indipendente.

Riutilizzare componenti e strumenti

Il framework mette a disposizione pacchetti, librerie e strumenti sviluppati dalla community. Che si voglia calcolare la traiettoria, eseguire algoritmi di SLAM o implementare un controllo remoto, probabilmente c’è un pacchetto ROS adatto.

Questo non significa che esista automaticamente un componente già pronto per qualsiasi applicazione, ma che molte funzioni comuni possono essere sviluppate partendo da software esistente invece di ripartire da zero.

L’ecosistema open source permette inoltre di mantenere una maggiore libertà nella scelta dell’architettura e dell’hardware rispetto a una soluzione rigidamente legata a un singolo fornitore. ROS 2 è progettato proprio attorno a un livello di astrazione che separa le applicazioni dalle specifiche tecnologie di comunicazione sottostanti.

Integrare hardware diversi

L’astrazione del framework permette di separare maggiormente l’applicazione dalle caratteristiche del singolo dispositivo.

Sensori, attuatori e altri componenti possono essere integrati attraverso interfacce software definite, rendendo più semplice costruire architetture composte da elementi differenti. Questo è particolarmente utile quando un progetto deve combinare componenti provenienti da fornitori diversi.

Sviluppare sistemi modulari

La suddivisione in nodi permette di costruire sistemi nei quali le singole funzioni possono evolvere indipendentemente; particolarmente interessante nella robotica industriale, dove hardware e requisiti applicativi possono cambiare nel corso dello sviluppo del progetto.

Testare il software in simulazione

ROS 2 può essere utilizzato anche in combinazione con strumenti di simulazione, consentendo di testare alcune componenti del sistema robotico in ambiente virtuale prima di utilizzarle sull’hardware reale.

La simulazione può quindi diventare parte del processo di sviluppo, riducendo la dipendenza dall’hardware durante alcune fasi di test.

ROS 2 nella robotica industriale

Il vantaggio di un framework come ROS 2 diventa particolarmente interessante quando il robot non è un componente isolato, ma fa parte di un sistema più ampio.

Un’applicazione industriale tipo può richiedere la comunicazione tra sensori, sistemi di navigazione, attuatori, PLC, software di supervisione e applicazioni aziendali. In questi casi l’architettura software deve gestire numerosi componenti e permettere loro di lavorare insieme in modo coordinato.

ROS 2 fornisce una struttura sulla quale costruire questa integrazione, ma non sostituisce automaticamente tutti gli altri sistemi presenti nello stabilimento.

ROS 2 e PLC hanno ruoli diversi

In una macchina o in un sistema robotico industriale, ROS 2 e PLC possono convivere senza svolgere la stessa funzione.

Il PLC può gestire le logiche di automazione e le interazioni con sensori, attuatori e dispositivi di campo. ROS 2 può invece occuparsi di componenti software più articolati, come percezione, localizzazione, pianificazione della navigazione o coordinamento tra moduli robotici.

L’architettura concreta dipende dall’applicazione, ma il principio è importante: ROS 2 non sostituisce automaticamente il livello di automazione industriale esistente. Può integrarsi con esso e aggiungere un livello software specifico per la robotica.

ROS 2 e robot mobili

La robotica mobile è uno degli ambiti nei quali le caratteristiche di ROS 2 risultano davvero interessanti per progettare e sviluppare sistemi robotici modulari, scalabili e altamente personalizzabili.

Un AMR deve coordinare localizzazione, percezione dell’ambiente, pianificazione dei percorsi, navigazione, gestione degli ostacoli e controllo dei movimenti; dividere queste funzioni in componenti software indipendenti permette di sviluppare e modificare l’architettura con maggiore flessibilità.

Il framework è quindi particolarmente adatto a sistemi nei quali più componenti software devono collaborare per trasformare i dati dei sensori in decisioni di movimento.

ROS 2 e HELKO

Abbiamo scelto ROS 2 per lo sviluppo di HELKO, il nostro AMR progettato per la movimentazione autonoma di carrelli e dolly in ambienti produttivi.

In HELKO, ROS 2 costituisce uno dei livelli software dell’architettura robotica e permette di integrare in modo modulare sensori, attuatori e funzioni di navigazione.

Il sistema di navigazione autonoma basato su ROS 2 è sviluppato in collaborazione con Proxima Robotics sulla piattaforma Proxima Compass e viene integrato con tutta la suite software sviluppata internamente da Eureka System. La navigazione rappresenta però soltanto una parte del sistema.

Attorno al robot abbiamo sviluppato una suite software che comprende la gestione della flotta, la configurazione delle mappe e la gestione delle missioni. HELKO può inoltre essere integrato con sistemi aziendali come MES, ERP e WMS attraverso interfacce software dedicate.

E poi, ROS è fatto dalla community per la community. Dopo diversi anni, questo ha portato a una grande quantità di pacchetti riutilizzabili e semplici da modificare e integrare.

Dal framework al sistema robotico industriale

Scegliere ROS 2 non significa avere automaticamente un robot pronto per la produzione.

Il framework fornisce una base software, ma attorno a questa base devono essere progettati e integrati tutti gli elementi necessari all’applicazione. Servono hardware, sensori, attuatori, logiche di controllo, interfacce, sistemi di sicurezza e software applicativo.

In un progetto industriale è inoltre necessario definire come il robot dovrà comunicare con il resto dell’impianto e con i sistemi aziendali. Per un AMR, questo può significare integrare navigazione, gestione della flotta e missioni con i flussi logistici dello stabilimento; per un robot industriale fisso, può significare coordinare manipolatore, visione, PLC, utensile e sistemi di supervisione. In entrambi i casi, ROS 2 è uno strumento all’interno dell’architettura. Il risultato dipende da come vengono progettati e integrati tutti i componenti del sistema.