ROS, acronimo di Robot Operating System, è una raccolta gratuita e open source di librerie e strumenti per sviluppare il software dei robot. Nonostante il nome, non è un sistema operativo come Windows o Linux. Gira sopra un sistema operativo, quasi sempre Ubuntu Linux, e offre ai tanti programmi presenti in un robot un modo comune per scambiarsi dati, condividere driver e riutilizzare il lavoro degli altri.

Il nome genera parecchia confusione, quindi conviene chiarire bene che cosa copre ROS. È molto efficace nell’organizzare tutto ciò che sta dentro un singolo robot: lo scanner laser, le ruote, la mappa, il pianificatore. Ha molto meno da dire sull’edificio in cui il robot lavora, con le sue porte, gli ascensori, i sensori e le persone che devono sapere quando qualcosa va storto. Capire dove finisce l’uno e dove comincia l’altro è una questione concreta per chiunque porti i robot fuori dal laboratorio.

In breve

  • ROS è un middleware: un sistema di messaggistica, un insieme di convenzioni e un’ampia libreria di pacchetti riutilizzabili che girano su un normale sistema operativo.
  • Dentro un robot, piccoli programmi chiamati nodi pubblicano e ricevono flussi di dati con un nome, detti topic: così il driver di un lidar e un pianificatore di navigazione possono essere scritti da persone diverse e funzionare comunque insieme.
  • ROS 2 è la generazione attuale; ROS 1 ha raggiunto la fine del supporto a maggio 2025, quindi i nuovi progetti partono da una release ROS 2 con supporto a lungo termine.
  • ROS coordina le parti di un robot. Per collegare quel robot a porte, sensori e allarmi di un sito serve un livello separato, che sta sopra ROS.

Che cos’è un robot operating system?

Un robot è un insieme di componenti hardware di produttori diversi: uno scanner laser di un fornitore, i driver dei motori di un altro, telecamere, sensori d’urto, una scheda di gestione della batteria. Ogni componente ha la propria interfaccia. Prima di ROS, ogni laboratorio e ogni azienda scriveva il proprio codice di raccordo per far dialogare questi componenti, e ben poco si poteva riutilizzare sul robot successivo.

Un robot operating system risolve il problema collocandosi tra i driver hardware e il comportamento del robot. Fornisce ai programmi un modo standard per scambiarsi dati, così il codice che legge il laser non ha bisogno di sapere chi ne usa i dati. Definisce formati di messaggio standard per i dati più comuni, come una scansione laser, un’immagine della telecamera o un comando di velocità. E include strumenti per registrare i dati, visualizzare ciò che il robot vede e simularlo prima che tocchi l’hardware reale.

L’etichetta di “sistema operativo” è una metafora. Così come un sistema operativo permette alle applicazioni di ignorare quale disco o scheda di rete abbia il computer, ROS permette al software del robot di ignorare la marca dello scanner montato, purché un driver pubblichi il messaggio standard.

ROS nasce nel 2007, con i primi lavori a Stanford e lo sviluppo presso l’azienda di robotica Willow Garage. Oggi è curato da Open Robotics e dalla Open Source Robotics Foundation, con un’ampia comunità di aziende e università che contribuisce con i propri pacchetti. Due dei pacchetti più noti sono Nav2, lo stack di navigazione per robot mobili, e MoveIt, che pianifica i movimenti dei bracci robotici.

Come funziona un robot operating system?

Il modo più semplice per capirlo è seguire un robot. Prendiamo un robot che trasporta materiale lungo il corridoio di un ospedale.

  1. Un nodo driver legge lo scanner laser e pubblica ogni scansione su un topic chiamato /scan, all’incirca da dieci a quaranta volte al secondo a seconda del sensore.
  2. Un nodo di localizzazione riceve /scan e l’odometria delle ruote, li confronta con una mappa memorizzata e pubblica la posizione in cui il robot ritiene di trovarsi.
  3. Lo stack di navigazione riceve un obiettivo, per esempio “vai al reparto 3”, pianifica un percorso che aggira gli ostacoli dell’ultima scansione e pubblica comandi di velocità su un topic chiamato /cmd_vel.
  4. Un nodo di controllo motori riceve /cmd_vel e trasforma quei comandi in velocità delle ruote.

Nessuno di questi nodi ne chiama direttamente un altro. Si accordano soltanto su nomi dei topic e tipi di messaggio, quindi per sostituire lo scanner laser con un altro modello basta cambiare un nodo driver.

I topic sono adatti ai flussi continui. Per altri compiti ROS offre due schemi diversi. Un service è una richiesta con risposta immediata, come “salva la mappa attuale”. Un’action è un obiettivo di lunga durata con aggiornamenti sull’avanzamento e la possibilità di annullarlo: di solito “vai al reparto 3” viene inviato proprio così. I parametri configurano i nodi e i file di launch avviano un intero gruppo di nodi con un solo comando.

C’è poi un componente che lavora molto dietro le quinte: tf2, la libreria delle trasformazioni. Ogni sensore è montato in un punto preciso del robot e ogni mappa ha la propria origine. tf2 tiene traccia nel tempo delle relazioni tra tutti questi sistemi di riferimento, così quando la telecamera vede un ostacolo 1,2 metri più avanti e 30 centimetri a sinistra, il pianificatore può trasformarlo in una posizione sulla mappa senza che ogni nodo faccia i propri calcoli geometrici.

Attorno a questo nucleo ci sono gli strumenti che si usano ogni giorno: RViz per vedere in 3D i dati dei sensori e i piani del robot, rosbag per registrare e riprodurre i topic e il simulatore Gazebo per provare un robot in un mondo virtuale.

In ROS 2, il livello di messaggistica si basa su DDS (Data Distribution Service), uno standard industriale di tipo publish/subscribe. I nodi si individuano a vicenda sulla rete senza il processo master centrale che serviva in ROS 1, e ogni topic può avere impostazioni di qualità del servizio, per esempio se i messaggi persi debbano essere rinviati.

ROS 1 o ROS 2: quale robot operating system scegliere?

La maggior parte dei team che parte oggi sa già che userà ROS. Restano da scegliere la generazione e la release, e se alcune parti del robot debbano usare qualcos’altro.

ROS 1 ROS 2
Stato Ultima release Noetic, fine del supporto a maggio 2025 Sviluppo attivo, nuova release ogni maggio
Messaggistica Protocollo specifico con master centrale DDS, nessun singolo punto di guasto
Supporto a lungo termine Nessuno in futuro Release LTS supportate per cinque anni, ad es. Jazzy Jalisco fino al 2029
Sicurezza Nessuna protezione integrata del trasporto SROS2 aggiunge cifratura e controllo degli accessi
Indicato per Manutenzione dei robot esistenti Nuovi progetti e prodotti

In pratica la scelta dipende da alcune domande:

  • Driver. Il fornitore del sensore o del braccio offre un driver per ROS 2? Un driver mancante può costare più tempo di tutto il resto messo insieme.
  • Cadenza delle release. Ogni maggio esce una nuova release di ROS 2. Quelle degli anni pari hanno cinque anni di supporto, quelle intermedie circa un anno e mezzo, quindi chi sviluppa prodotti di solito resta su una release LTS e pianifica il passaggio alla successiva.
  • Hardware di piccole dimensioni. micro-ROS porta i concetti di ROS 2 sui microcontrollori, così una scheda sensore può partecipare direttamente ai topic del robot.
  • Bracci industriali. Molti bracci industriali si programmano tramite il controller e il linguaggio del produttore. Spesso ROS affianca quel controller anziché sostituirlo, una strada su cui il consorzio ROS-Industrial lavora da anni.

Conviene pianificare per tempo anche la rete. DDS individua i nodi automaticamente, il che è comodo al banco di prova ma genera molto traffico su una rete aziendale condivisa con molti robot. Di solito i team separano i robot con i domain ID di DDS, limitano la discovery agli host noti e attivano SROS2 prima che un robot lasci il laboratorio.

Alcune aziende costruiscono su ROS 2 i propri stack, come i pacchetti Isaac ROS di NVIDIA per la percezione accelerata da GPU. Altre mantengono uno stack software proprietario ed espongono all’esterno solo un’interfaccia. Entrambe le strade sono diffuse, e la seconda pesa quando il robot deve lavorare con tutto il resto di un sito.

Come collegare un robot operating system ai dispositivi IoT?

ROS è nato per l’interno di un robot, o per una flotta sulla stessa rete. Un edificio o uno stabilimento ha un secondo insieme di dispositivi che il robot non percepisce: un contatto porta dall’altra parte del magazzino, un sensore di allagamento in un locale tecnico, lo stato di una porta tagliafuoco, una misura della qualità dell’aria in un reparto. Di solito questi dispositivi parlano LoRaWAN, MQTT, Modbus o BACnet, non topic ROS.

Esistono bridge ben noti. rosbridge espone i topic ROS come JSON su WebSocket, alcuni pacchetti della comunità inoltrano i topic scelti da e verso broker MQTT, e Open-RMF, l’Open Robotics Middleware Framework, coordina più flotte di robot con infrastrutture condivise come porte e ascensori. Questi strumenti risolvono il trasporto. Decidere quale evento di un sensore debba mandare quale robot e dove, e provare quella logica prima che giri su un sito reale, è un lavoro a parte.

Conviene decidere presto che cosa attraversa quel confine. I topic grezzi, come scansioni laser e fotogrammi della telecamera, sono troppo frequenti e troppo dettagliati per i sistemi del sito. Al resto del sito serve un insieme piccolo e stabile di fatti e richieste: la posizione del robot sulla mappa del sito, il livello della batteria, lo stato della missione in corso e una manciata di compiti che accetta, come raggiungere un luogo con un nome, tornare alla base di ricarica o mettersi in pausa. Mantenere ridotta questa interfaccia permette al team del robot di cambiare qualsiasi cosa dentro ROS senza rompere la logica del sito.

Quel livello decisionale è ciò che un sistema operativo per l’IA fisica aggiunge sopra ROS, ed è proprio il ruolo per cui è pensato Kilo. Se l’integrazione del robot espone alcuni comandi via MQTT, per esempio “vai al waypoint” o “torna alla base”, si possono salvare in Kilo e far inviare uno di essi da una regola quando un sensore in un altro punto del sito segnala un evento, mentre ROS continua a gestire la navigazione a bordo. Ogni comando inviato in questo modo compare nello storico come Pending, Delivered, Confirmed, Soft warning o Failed.

Poiché quei comandi muovono una macchina reale, la regola va prima provata: la si percorre passo per passo nel debugger di Kilo simulando la risposta del robot, così si vede come si svolge ogni percorso prima di distribuire qualsiasi cosa.

Robot operating system: domande frequenti

ROS è un robot operating system gratuito?

Sì. ROS è open source con licenze permissive che consentono l’uso commerciale senza costi di licenza. Restano i costi del tempo di sviluppo, dell’hardware e di un eventuale contratto di supporto commerciale che un’azienda decide di acquistare da una delle società che offrono consulenza su ROS.

Quale linguaggio di programmazione usa un robot operating system come ROS?

Le due librerie client ufficiali sono in C++ (rclcpp) e Python (rclpy), e spesso uno stesso robot le usa entrambe. Esistono librerie della comunità per Rust, Java e altri linguaggi, e i tipi di messaggio si definiscono in semplici file di interfaccia da cui viene generato il codice per ciascun linguaggio.

Si può usare un robot operating system come ROS su Windows?

ROS 2 include Windows tra le piattaforme supportate accanto a Ubuntu Linux, e ogni release pubblica i livelli di supporto esatti per piattaforma in un documento chiamato REP 2000. La maggior parte dei tutorial, dei driver e dei robot in produzione usa però ancora Ubuntu, quindi Linux resta la strada più agevole.

ROS 2 è un robot operating system real-time?

Non da solo. ROS 2 è stato progettato per poter essere usato in sistemi real-time, ma servono anche un kernel real-time come Linux con la patch PREEMPT_RT, una configurazione attenta di memoria e thread e un hardware in grado di rispettare le tempistiche. Il framework ros2_control è il metodo abituale per eseguire anelli di controllo con tempi molto stretti per bracci e ruote all’interno di ROS 2.

Con un robot ROS 2 già in funzione si può fare una prima prova, in piccolo, sul lato del sito. Basta usare uno dei bridge della comunità per pubblicare su MQTT tre dei suoi topic, come livello della batteria, stato della missione e posizione, registrare il robot in Kilo come un unico dispositivo e rappresentare i tre valori in un grafico su una dashboard. Poi si aggiunge una regola che invia un avviso quando la batteria scende sotto il 20% mentre una missione è ancora in corso. Si tratta di un solo dispositivo e una sola regola, ben entro i limiti del piano gratuito, e sul robot non cambia nulla a parte il bridge.