Perché gli sviluppatori scelgono ROS 2 per la robotica

Robotisti e sviluppatori software

Per programmare un robot è necessario conoscere elettronica e meccanica?

Dipende dal livello di intervento richiesto.

Chi sviluppa un sistema robotico deve certamente comprendere il comportamento dell’hardware con cui lavora. Allo stesso tempo, però, molte applicazioni possono essere sviluppate a un livello superiore rispetto alla gestione diretta dei singoli componenti.

È proprio qui che un framework come ROS può essere utile. L’astrazione del software rispetto all’hardware permette allo sviluppatore di concentrarsi maggiormente sulle logiche dell’applicazione, utilizzando interfacce che espongono dati dei sensori, comandi e stati del robot. Il vantaggio è particolarmente evidente quando lo stesso tipo di applicazione deve essere adattato a piattaforme robotiche differenti.

Cos’è ROS 2?

ROS, acronimo di Robot Operating System, non è un sistema operativo nel senso tradizionale del termine. È un framework e un insieme di strumenti e librerie per lo sviluppo di applicazioni robotiche, che funziona sopra un sistema operativo e fornisce meccanismi standard per la comunicazione tra i diversi componenti del sistema. ROS 2 utilizza un livello middleware che permette alle applicazioni di comunicare attraverso diverse implementazioni sottostanti.

Questo approccio permette di separare maggiormente la logica dell’applicazione dai dettagli della comunicazione tra i componenti. Per uno sviluppatore significa poter ragionare in termini di nodi, messaggi, servizi e azioni, invece di gestire ogni volta direttamente la comunicazione con il singolo dispositivo.

Perché ROS 2?

Una storia piuttosto comune nello sviluppo della robotica è quella di un nuovo progetto che parte da zero. Un ingegnere inizia a lavorare sull’applicazione, ma si accorge presto che una parte consistente del lavoro non riguarda il problema che vuole risolvere. Deve costruire la comunicazione tra i diversi programmi, gestire i dati dei sensori, definire le interfacce e creare strumenti per simulare e controllare il comportamento del robot. Il progetto rischia così di dedicare molto tempo alla costruzione dell’infrastruttura software invece che allo sviluppo dell’applicazione.

ROS nasce anche per affrontare questo problema.

L’obiettivo è evitare di reinventare continuamente la stessa base software, mettendo a disposizione strumenti, librerie e un ecosistema di pacchetti riutilizzabili. Ciò permette di concentrarsi maggiormente sulle funzionalità specifiche del progetto.

Il principale vantaggio: riutilizzare invece di ricominciare da zero

Come appena visto, uno dei problemi più frequenti nello sviluppo della robotica è la tendenza a ricostruire da capo componenti già sviluppati in altri progetti. Se ogni applicazione utilizza una base di codice completamente diversa, ogni nuovo robot richiede tempi di sviluppo maggiori e rende più difficile mantenere e aggiornare il software.

L’utilizzo di un framework comune permette invece di riusare parte delle componenti già disponibili. ROS consente di smettere di reinventare la ruota fornendo uno standard per lo sviluppo di software robotico, utilizzabile su qualsiasi robot. Che si tratti di programmare un robot mobile a guida autonoma, un braccio robotico, un drone, un rover, un distributore automatico, beh… si può usare lo stesso Robot Operating System.

Quando una soluzione viene sviluppata come pacchetto o nodo ROS e documentata correttamente, può essere integrata in altri progetti e ulteriormente migliorata.

È uno dei vantaggi tipici dell’open source: una parte del lavoro può essere condivisa con una comunità più ampia invece di rimanere confinata a un singolo progetto. Quando qualcuno sviluppa un buon pacchetto, può pubblicarlo e condividerlo con la community. E poi, altre persone possono usarlo e continuare a migliorarlo, creando un circolo virtuoso.

E ogni volta che si avvia una nuova applicazione, diventa sempre più facile perché non è necessario reimparare a usare ROS. Sono finiti i tempi in cui ogni nuova applicazione robotica veniva sviluppata da zero, con una base di codice diversa ogni volta.

Cosa sono i nodi, i topic, i servizi e le azioni?

Per capire il funzionamento di ROS 2 è utile introdurre alcuni concetti fondamentali.

I nodi

Un nodo è un processo software che svolge una determinata funzione all’interno dell’applicazione robotica. Un nodo può occuparsi, per esempio, della lettura di un sensore, della navigazione, del controllo di un attuatore o dell’elaborazione di una determinata informazione.

Un’applicazione complessa può quindi essere composta da molti nodi che collaborano tra loro.

I topic

I topic permettono ai nodi di scambiarsi messaggi in modo asincrono: un nodo può pubblicare un’informazione, come la posizione rilevata dal robot, mentre uno o più altri nodi possono sottoscriversi a quel dato e utilizzarlo per le proprie elaborazioni.

I servizi

I servizi permettono di effettuare una richiesta e ricevere una risposta; sono adatti, per esempio, a operazioni che devono essere eseguite su richiesta e restituire un risultato.

Le azioni

Le azioni, o actions, sono utilizzate per tutte quelle operazioni più lunghe che possono richiedere tempo e per le quali può essere utile monitorare lo stato dell’esecuzione o interromperla.

Questi meccanismi permettono di costruire applicazioni distribuite, nelle quali le diverse funzioni del robot rimangono separate ma comunicano attraverso interfacce definite.

Le API ROS per i robot

In ROS è possibile astrarre completamente l’hardware dal software: grazie alle API e alle interfacce messe a disposizione da ROS 2, è possibile accedere alle funzionalità del robot a un livello più alto rispetto alla comunicazione diretta con ogni componente hardware.

Le API di un robot possono esporre informazioni provenienti dai sensori e comandi relativi agli attuatori. Sono l’elenco degli argomenti, dei servizi, dei server di azione e dei messaggi ROS che un determinato robot mette a disposizione per dare accesso al suo hardware, cioè ai sensori e agli attuatori. In termini semplici, permettono allo sviluppatore di utilizzare funzioni software per ottenere dati o impartire comandi senza dover reinventare ogni volta l’intero livello di comunicazione.

Questo livello di astrazione è particolarmente utile quando il software deve essere mantenuto nel tempo o adattato a componenti differenti.

E se il robot non è nativamente compatibile con ROS 2?

Non tutti i robot sono progettati nativamente per lavorare con ROS 2.

In questi casi è comunque possibile realizzare un’integrazione hardware e software che permetta al robot di dialogare con l’ecosistema ROS 2. Questo processo in gergo si chiama “ROSificare” e può richiedere accesso all’hardware, conoscenza dell’elettronica e sviluppo di componenti software dedicati.

L’obiettivo non è “ROSificare” qualsiasi robot a prescindere, ma valutare se l’architettura porta un vantaggio concreto rispetto alla tecnologia e alle interfacce già disponibili.

Perché ROS 2 interessa anche all’industria?

Per chi utilizza robot in un ambiente produttivo, il vantaggio di ROS 2 non riguarda soltanto la velocità di sviluppo. Un’architettura software così modulare può semplificare anche l’integrazione, la manutenzione e le possibilità di evoluzione del sistema.

In uno stabilimento industriale, infatti, il robot deve spesso dialogare con sensori, macchine, PLC, sistemi di gestione della flotta, software di produzione e applicazioni aziendali.

Un’architettura basata su componenti separati e interfacce definite permette di gestire più facilmente questi collegamenti e di sostituire o aggiornare singoli elementi senza dover riprogettare l’intera applicazione. È uno dei motivi per cui ROS 2 viene utilizzato anche nello sviluppo di sistemi robotici destinati alla produzione.

ROS 2 nella robotica mobile

La robotica mobile è uno degli ambiti in cui questo approccio trova applicazioni concrete.

Un AMR deve coordinare navigazione, localizzazione, sensori, pianificazione delle missioni e interazione con gli altri sistemi. Queste funzioni possono essere organizzate in componenti software distinti che comunicano tra loro.

Le architetture ROS 2 permettono inoltre di integrare componenti sviluppati da soggetti diversi, mantenendo una struttura software più modulare.

Nel caso di HELKO, per esempio, la navigazione autonoma utilizza ROS 2 sulla piattaforma Proxima Compass ed è integrata con la suite software sviluppata da Eureka System. Il risultato è un’architettura nella quale la meccanica del robot, la navigazione e il fleet management convivono all’interno dello stesso sistema AMR sviluppato con ROS 2.

Dal prototipo al robot industriale

Utilizzare ROS 2 non significa automaticamente avere un robot pronto per la produzione. Tra un prototipo funzionante e un sistema industriale esiste un passaggio importante: affidabilità, gestione delle eccezioni, manutenzione, aggiornamenti, sicurezza, diagnostica e integrazione con l’ambiente produttivo devono essere affrontati come parti dello stesso progetto.

È qui che l’architettura software deve incontrare l’ingegnerizzazione del prodotto.

L’esperienza maturata nello sviluppo e nelle installazioni di HELKO mostra proprio questa differenza: la navigazione è soltanto una parte del problema; il sistema deve poi lavorare in modo affidabile all’interno di processi reali e dialogare con l’infrastruttura dello stabilimento.

L’esperienza di Eureka System con ROS 2

In Eureka System utilizziamo ROS 2 nei progetti di robotica, soprattutto collaborativa e mobile, e integriamo poi le componenti software con il resto dell’architettura del sistema.

Nel caso di HELKO, ROS 2 costituisce anche il riferimento per la navigazione autonoma, completata con gli altri software dedicati alla gestione della flotta e delle missioni. Questa separazione permette di lavorare su livelli diversi del sistema mantenendo la possibilità di personalizzare il comportamento del robot in funzione dell’applicazione.

ROS 2 è uno strumento, non il progetto

La tecnologia utilizzata per sviluppare un robot è importante, ma da sola non determina il risultato dell’applicazione.

Per un’azienda che deve introdurre un robot nel proprio processo produttivo, la domanda più utile resta un’altra: come deve comportarsi il sistema nel contesto reale dello stabilimento?

Layout, flussi, interazioni con le persone, sistemi esistenti, requisiti di produzione e possibilità di evoluzione devono guidare la scelta dell’architettura software.

ROS 2 può fornire una base flessibile e un ecosistema riutilizzabile. Il valore industriale nasce poi dall’integrazione di questa tecnologia all’interno del processo.