Cos'è ROS 2?

ROS 2 (Robot Operating System 2) è il framework open source diventato lo standard de facto per scrivere software robotico: nonostante il nome, non è un sistema operativo, ma un middleware, uno strato di comunicazione e librerie eseguito su Linux, Windows o altri sistemi, mantenuto da Open Robotics / Open Source Robotics Foundation. Organizza il codice in nodi indipendenti che si scambiano dati tramite tre meccanismi: topic per la comunicazione asincrona a pubblicazione/sottoscrizione, servizi per le richieste sincrone con risposta, azioni per compiti lunghi che restituiscono avanzamento e risultato. Sotto il cofano gira quasi sempre su DDS (Data Distribution Service), lo standard OMG che gestisce la individuazione reciproca dei nodi e la qualità del servizio, senza bisogno di un processo centrale che coordini tutto. Le versioni escono ogni anno con nomi in codice in ordine alfabetico e a tema animale (Jazzy Jalisco, Kilted Kaiju, Lyrical Luth), che scandiscono ciclo di vita e supporto a lungo termine delle distribuzioni.

Architettura: due livelli e l'addio al nodo master

ROS 2 separa un'interfaccia client (rcl, con i binding rclcpp e rclpy) da un'interfaccia middleware (rmw) che nasconde i dettagli dell'implementazione sottostante, quasi sempre DDS (fonte: documentazione ROS). Il cambiamento rispetto a ROS 1 è architetturale: ROS 1 dipendeva da un roscore centrale, un single point of failure. Con DDS la scoperta dei nodi è decentralizzata e peer-to-peer, la qualità del servizio (QoS) è configurabile per requisito e SROS2 aggiunge un modello di sicurezza basato su DDS Security che ROS 1 non aveva (fonte: design.ros2.org). I nodi collaborano tramite topic per flussi continui, servizi per richieste puntuali con risposta immediata, azioni per obiettivi lunghi come un AGV che completa un percorso.

Quando adottarlo, quando no

ROS 2 si colloca allo strato di integrazione software di un sistema robotico: è ciò con cui si scrivono i nodi che fanno percepire, decidere e muovere un robot, non l'AI fisica che decide cosa fare né il modello che la governa. Ha senso adottarlo quando si integra hardware eterogeneo di più fornitori o quando serve un ecosistema di librerie già pronte (navigazione, percezione, simulazione) invece di scriverle da zero. Non ha senso forzarlo su un dispositivo singolo con un solo microcontrollore e nessuna comunicazione distribuita: lì un firmware dedicato resta più leggero, e l'alternativa non è un altro middleware ma nessun middleware.

Un esempio enterprise

Adottando ROS 2, un costruttore italiano di macchine automatiche che integra bracci robotici e veicoli a guida autonoma di più fornitori nella stessa linea guadagna un livello comune su cui far dialogare hardware eterogeneo e la possibilità di simulare l'integrazione prima di installarla in stabilimento (tipicamente con Gazebo o simulatori compatibili, il territorio del digital twin). In cambio si assume la responsabilità di manutenere quello strato nel tempo: aggiornare le distribuzioni prima che scadano e formare un team che sappia debuggare un grafo di nodi distribuito. Il limite va detto esplicitamente ai committenti: ROS 2 non è certificato per la sicurezza funzionale. Arresti di emergenza e limiti di coppia e velocità restano su PLC e sistemi certificati separati (per esempio IEC 61508 o ISO 13849), con ROS 2 relegato alla logica applicativa non safety-critical.

Perché conta per chi decide

Scegliere ROS 2 non è una decisione tecnica isolata: è una scelta di ecosistema e di competenze che impegna l'azienda per anni, con un ciclo di rilascio annuale da seguire e una manutenzione che non si ferma al momento dell'installazione. Chi commissiona un'integrazione robotica deve sapere che ROS 2 riduce il rischio di lock-in verso un singolo fornitore di hardware, ma sposta parte della responsabilità di manutenzione in casa o su chi la eroga, e che la sicurezza funzionale resta un problema separato, da risolvere altrove, non un effetto collaterale del middleware.