A partire da Ubuntu 22.04 o da giugno 2025, il supporto ufficiale per gli aggiornamenti di ROS 1 non sarà più disponibile; si raccomanda l’uso del sistema ROS 2. ROS 2 presenta prestazioni significativamente migliori rispetto a ROS 1 in termini di architettura, tempo reale, sicurezza ed estensibilità ecologica; per lo sviluppo di nuovi progetti si consiglia di utilizzare direttamente ROS 2, ma in caso di migrazione è necessario valutare il compromesso tra le risorse esistenti e i vantaggi a lungo termine. Per informazioni dettagliate sulla compatibilità delle versioni di Ubuntu, consultare il link Il rapporto tra ROS e le diverse versioni di Ubuntu, il seguente confronto tra i due modelli da analizzare:
| Versione ROS 2 | Versione di Ubuntu | LTS o no | Ora di rilascio |
| Jazzy | 24.04 (Noble) | Sì (LTS) | 2024 |
| In kilt | 24.04 (Noble) | No | 2025-05 |
Storia e sviluppo
- ROS1: Sviluppato dall'Università di Stanford e da Willow Garage, con particolare attenzione alla ricerca e alla prototipazione.
- ROS2: Avviato nel 2014, il progetto è incentrato sulla robotica di livello industriale e utilizza il middleware DDS per migliorare le capacità in tempo reale, il supporto multipiattaforma e la sicurezza.
Conclusione: ROS1 è più adatto alla ricerca e alla prototipazione, mentre ROS2 è ideale per l'implementazione industriale e commerciale.
2. Architettura di sistema
| Dimensione | ROS1 | ROS2 |
| Architettura di base | Adotta un'architettura centralizzata, affidandosi al nodo Master (gestore dei nodi) per la registrazione e la comunicazione tra i nodi. | Architettura distribuita, comunicazione diretta tra i nodi, assenza di un nodo master, supporto di un meccanismo di individuazione dinamica. |
| Modello di comunicazione | Sistema di comunicazione personalizzato basato sul protocollo TCP/UDP, che presenta problemi quali ritardi, perdita di pacchetti e impossibilità di crittografia. | Protocollo di comunicazione standardizzato basato su DDS, che supporta l'interazione in tempo reale, la crittografia e l'interoperabilità multipiattaforma. |
| Affidabilità | Si basa sul protocollo TCP per la comunicazione peer-to-peer ed è soggetto alla perdita di pacchetti | L'affidabilità della trasmissione è garantita dalle politiche QoS (ad esempio, "Reliable"). |
| Sistema di compilazione | Utilizza i sistemi di compilazione rosbuild (versione preliminare) e catkin. | È stato introdotto un sistema di compilazione automatizzato per consentire una gestione più flessibile delle dipendenze e la compilazione in più linguaggi. |
3. Esperienza utente
| Dimensione | ROS1 | ROS2 |
| Curva di apprendimento | Ricche risorse della comunità e una documentazione completa, ideali per chi è alle prime armi. | Le nuove funzionalità aumentano i costi di apprendimento (ad esempio, la configurazione del DDS, il debug in tempo reale), ma a lungo termine risultano più facili da mantenere. |
| Costi di migrazione | I progetti ROS 1 devono rifattorizzare la logica di comunicazione, la gestione dei nodi e il sistema di compilazione per migrare a ROS 2. | Sono disponibili strumenti di migrazione (ad esempio, ros1_bridge) per garantire l'interoperabilità tra i nodi ROS 1 e ROS 2. |
| Debug e suite di strumenti | Avvalendosi di strumenti come roslaunch e rviz, il processo di debug risulta più tradizionale. | Nuovo framework di avvio (con supporto alla configurazione in Python), sistema di registrazione integrato e strumenti di test migliorati. |
| Comunità ed ecologia | L'ecosistema è ampio, ma alcune funzionalità sono difficili da estendere a causa di limitazioni architetturali. | Le nuove funzionalità sono più facili da integrare (ad esempio, una maggiore integrazione con Gazebo e le tecnologie web) e l'ecosistema continua ad ampliarsi. |
4. Confronto tra le principali tecnologie
| Dimensione | ROS1 | ROS2 |
| Comunicazione tra nodi | La comunicazione peer-to-peer viene stabilita tramite la registrazione del Master. | I nodi si individuano automaticamente e comunicano direttamente tra loro tramite DDS. |
| Messaggistica | Utilizza un tipo di messaggio personalizzato (.msg) e si basa sull'implementazione di roscpp/rospy. | Generare messaggi multilingue basati sull’IDL (Interface Definition Language) per garantire una migliore compatibilità. |
| Tolleranza ai guasti | Un guasto al master può causare il blocco dell'intero sistema. | Architettura distribuita per evitare un singolo punto di guasto; i nodi possono entrare o uscire dinamicamente dal sistema. |
5. Differenze sintattiche
| Dimensione | ROS1 | ROS2 |
| Sintassi per la creazione di nodi | Utilizza ros::NodeHandle per gestire i nodi; tale libreria si avvale di roscore per avviare il gestore centralizzato. | Utilizzare rclcpp::Node o rclpy::Node per creare nodi direttamente senza roscore, che supporta l'architettura distribuita. |
| Meccanismo di comunicazione | Poiché la comunicazione si basa su un protocollo TCP/UDP personalizzato, è necessario gestire manualmente la registrazione e l'individuazione dei nodi. | In base allo standard DDS (Data Distribution Service), i nodi si individuano automaticamente e comunicano tra loro. |
| Definizione del messaggio | Utilizzare il file .msg per definire il tipo di messaggio, basandosi sull'implementazione di roscpp/rospy. | Utilizzare l'IDL (Interface Definition Language) per generare messaggi multilingue e garantire una maggiore compatibilità. |
| File di avvio | Utilizza XML per scrivere un file .launch: si tratta di una funzione singola, difficile da configurare dinamicamente. | Utilizza Python per scrivere un file .launch.py che supporti la logica dinamica (ad esempio, condizioni logiche e passaggio di parametri). |
6. Differenze nell'uso effettivo
| Dimensione | ROS1 | ROS2 |
| Supporto multilingue | Supporta principalmente C++ e Python; gli altri linguaggi devono essere adattati. | Supporto esteso per linguaggi aggiuntivi (ad esempio, Rust, Java) e compatibilità tra linguaggi tramite l’Interface Definition Language (IDL). |
| Sistema di compilazione | Si basa sul sistema di compilazione Catkin, che richiede il rigoroso rispetto della struttura dell'area di lavoro. | Utilizza il sistema di compilazione ament per una gestione più flessibile delle dipendenze e per compilazioni multilingue. |
| Assistenza in tempo reale | Prestazioni in tempo reale insufficienti; difficoltà nel soddisfare le esigenze del controllo industriale in tempo reale. | Migliorare il supporto per i sistemi in tempo reale (ad esempio, rclcpp di ROS 2 offre la pianificazione dei thread in tempo reale). |
| Sicurezza | Mancanza di meccanismi nativi di crittografia e autenticazione. | Supporta le estensioni di sicurezza DDS (DDS-Security) per garantire l’autenticazione, la crittografia dei dati e il controllo degli accessi. |
| Supporto multipiattaforma | Funziona principalmente su sistemi Linux, con supporto limitato per Windows e macOS. | Supporta diverse piattaforme, quali Linux, Windows, macOS, RTOS, ecc., e le suddivide chiaramente in Tier 1 (supportate attivamente dal governo) e Tier 2 (supportate dalla comunità) per rafforzare la compatibilità tra i vari sistemi. |
| Strumenti di debug | Basandosi su strumenti tradizionali come roslaunch e rviz, il sistema di registrazione è relativamente semplice. | Fornire un sistema di registrazione integrato (ad esempio, RCLCPP_INFO), il supporto per gli script Python e strumenti di test più efficaci. |
| Tolleranza ai guasti | Un errore di Roscore può causare il blocco dell'intero sistema. | Architettura distribuita per evitare un singolo punto di guasto; i nodi possono entrare o uscire dinamicamente dal sistema. |
7. Scenari applicativi tipici
- ROS 1: Formazione, progetti di ricerca (ad esempio, navigazione di robot mobili, SLAM), scenari che non richiedono elevate prestazioni in tempo reale né sicurezza. Se il progetto è maturo e non richiede funzionalità in tempo reale, di sicurezza o multipiattaforma, e si avvale di un ampio numero di risorse dell’ecosistema ROS 1, continuare a utilizzare ROS 1.
- ROS 2: Automazione industriale, guida autonoma, droni e altri scenari che richiedono elevati livelli di real-time, sicurezza e supporto multipiattaforma, nonché la manutenzione a lungo termine di progetti su larga scala (ad esempio, consegna robot, irobot industriali, robot medici). I progetti che richiedono stabilità di livello industriale, controllo in tempo reale, crittografia sicura o implementazione multipiattaforma sono preferiti rispetto a ROS 2.
8. Compatibilità hardware e con le piattaforme
- Supporta principalmente Linux (Ubuntu).
- RO supporta nativamente Linux, Windows, macOS e le piattaforme embedded.
9. Sostegno agli ecosistemi e alle comunità
- ROS1:Un gran numero di pacchetti e una comunità attiva.
- ROS2: Un ecosistema in rapida crescita, ma il numero di pacchetti deve ancora mettersi al passo.
Conclusione: ROS1 vanta un ecosistema consolidato, mentre ROS2 sta recuperando terreno rapidamente.
10. Costi di migrazione e aggiornamento
- Le API sono incompatibili e richiedono la riscrittura del codice.
- Potrebbe essere necessario un periodo di adattamento da parte degli utenti; ros1_bridge può facilitare una migrazione graduale.
Conclusione: I costi di migrazione sono elevati, ma è possibile ridurre i rischi ricorrendo ad aggiornamenti graduali.
11. Sicurezza e norme industriali
- ROS1: Nessun meccanismo di sicurezza nativo.
- ROS2: È conforme agli standard di sicurezza DDS e supporta l'integrazione con OPC UA e TSN.
Conclusione: ROS2 è più adatto alle applicazioni industriali e a quelle in cui la sicurezza è fondamentale.
Tendenze future e piano d'azione
- ROS1Noetic è la versione definitiva, il cui supporto è previsto fino al 2025.
- ROS2 segue una strategia di supporto a lungo termine (LTS) con aggiornamenti regolari delle funzionalità.
Conclusione: La tendenza è chiaramente a favore di ROS2.
Conclusioni e raccomandazioni
Per ricercatori o principianti, ROS1 rimane una scelta consolidata e affidabile; per utenti industriali o team commerciali, I vantaggi di ROS2 nei sistemi distribuiti, nelle prestazioni in tempo reale e nella sicurezza garantiscono un valore a lungo termine.
Consigli pratici: Valutare la versione di ROS nelle prime fasi di pianificazione del progetto e prendere decisioni in base alla maturità dell'ecosistema e alle capacità del team.
