À partir d'Ubuntu 22.04 ou de juin 2025, le support officiel de ROS1 ne sera plus mis à jour, et il sera recommandé d'utiliser le système ROS2. L'architecture, le temps réel, la sécurité et l'éco-extensibilité de ROS 2 sont nettement meilleurs que ceux de ROS 1. Il est recommandé d'utiliser directement ROS2 pour le développement de nouveaux projets, mais si vous devez migrer, vous devrez faire un compromis entre les ressources existantes et les gains à long terme. Pour plus de détails sur le support de la version Ubuntu, voir le lien [ROS et Ubuntu, différentes versions de la relation] La comparaison suivante des deux cadres à analyser :
| Version ROS 2 | Version Ubuntu | LTS ou pas | Heure de sortie |
| Jazzy | 24.04 (Noble) | Oui (LTS) | 2024 |
| Kilted | 24.04(Noble) | Non | 2025-05 |
Histoire et développement
- ROS1: Développé par l'Université de Stanford et le Willow Garage, il se concentre sur la recherche et le prototypage.
- ROS2: Lancé en 2014, il vise la robotique industrielle avec un intergiciel DDS pour améliorer la capacité en temps réel, le support multiplateforme et la sécurité.
Conclusion : ROS1 est mieux adapté à la recherche et au prototypage, tandis que ROS2 est idéal pour un déploiement industriel et commercial.
2. Architecture du système
| Dimension | ROS1 | ROS2 |
| Architecture de base | Architecture centralisée, reposant sur le nœud principal (gestionnaire de nœuds) pour l'enregistrement et la communication des nœuds. | Architecture distribuée, communication directe entre les nœuds, pas besoin de maître, mécanisme de découverte dynamique. |
| Modèle de communication | Système de communication personnalisé basé sur le protocole TCP/UDP, qui présente des problèmes tels que le retard, la perte de paquets et l'incapacité à crypter. | Protocole de communication normalisé basé sur DDS, prenant en charge le temps réel, le cryptage et l'interaction multiplateforme. |
| Fiabilité | S'appuie sur le protocole TCP pour la communication de pair à pair, sujet à la perte de paquets. | La fiabilité de la transmission est garantie par les politiques de qualité de service (par exemple, fiable). |
| Système de compilation | Utilise les systèmes de compilation rosbuild (early) et catkin. | Introduction d'un système de compilation des éléments pour permettre une gestion plus souple des dépendances et une compilation multilingue. |
3. Expérience de l'utilisateur
| Dimension | ROS1 | ROS2 |
| Courbe d'apprentissage | Riche en ressources communautaires et en documentation mature, idéal pour débuter. | Les nouvelles fonctionnalités augmentent les coûts d'apprentissage (par exemple, la configuration DDS, le débogage en temps réel), mais sont plus faciles à maintenir à long terme. |
| Coûts de migration | Les projets ROS 1 doivent remanier la logique de communication, la gestion des nœuds et le système de compilation pour migrer vers ROS 2. | Des outils de migration (par exemple ros1_bridge) sont disponibles pour assurer l'interopérabilité entre les nœuds ROS 1 et ROS 2. |
| Débogage et chaîne d'outils | S'appuyant sur des outils tels que roslaunch et rviz, le processus de débogage est plus traditionnel. | Nouveau cadre de lancement (supportant la configuration Python), système de journalisation intégré et meilleurs outils de test. |
| Communauté et écologie | L'écosystème est vaste, mais certaines fonctionnalités sont difficiles à étendre en raison de limitations architecturales. | Les nouvelles fonctionnalités sont plus faciles à intégrer (par exemple, intégration plus poussée avec Gazebo et les technologies Web), et l'écosystème continue de s'étendre. |
4. Comparaison des technologies clés
| Dimension | ROS1 | ROS2 |
| Communication entre nœuds | La communication entre pairs est établie par l'enregistrement du maître. | Les nœuds se découvrent automatiquement et communiquent directement entre eux via DDS. |
| Messagerie | Utilise un type de message personnalisé (.msg) et s'appuie sur l'implémentation de roscpp/rospy. | Générer des messages multilingues basés sur IDL (Interface Definition Language) pour une meilleure compatibilité. |
| Tolérance de panne | Une défaillance du maître peut entraîner une panne de l'ensemble du système. | Architecture distribuée pour éviter un point de défaillance unique, les nœuds peuvent rejoindre/quitter dynamiquement le système. |
5. Différences de syntaxe
| Dimension | ROS1 | ROS2 |
| Syntaxe de création de nœuds | Utilise ros::NodeHandle pour gérer les noeuds, s'appuie sur roscore pour démarrer le gestionnaire centralisé. | Utilisez rclcpp::Node ou rclpy::Node pour créer des noeuds directement sans roscore, supporte l'architecture distribuée. |
| Mécanisme de communication | Basé sur un protocole TCP/UDP personnalisé pour réaliser la communication, il doit gérer manuellement l'enregistrement et la découverte des nœuds. | Sur la base de la norme DDS (Data Distribution Service), les nœuds se découvrent automatiquement et communiquent entre eux. |
| Définition du message | Utiliser le fichier .msg pour définir le type de message, s'appuyer sur l'implémentation de roscpp/rospy. | Utiliser IDL (Interface Definition Language) pour générer des messages multilingues afin d'améliorer la compatibilité. |
| Fichiers de lancement | Utilise XML pour écrire le fichier .launch, fonction unique, difficile à configurer dynamiquement. | Utiliser Python pour écrire le fichier .launch.py, prendre en charge la logique dynamique (comme le jugement conditionnel, le passage de paramètres). |
6. Différences dans l'utilisation réelle
| Dimension | ROS1 | ROS2 |
| Prise en charge multilingue | Prend principalement en charge C++ et Python, d'autres langages doivent être adaptés. | Prise en charge étendue de nouveaux langages (par exemple Rust, Java) et compatibilité inter-langues via le langage de définition d'interface (IDL). |
| Système de compilation | S'appuie sur le système de compilation catkin, qui exige un respect strict de la structure de l'espace de travail. | Utilisez le système de construction ament pour une gestion plus souple des dépendances et des constructions multilingues. |
| Soutien en temps réel | Mauvaise performance en temps réel, difficile de répondre aux besoins du contrôle industriel en temps réel. | Améliorer la prise en charge des systèmes en temps réel (par exemple, rclcpp de ROS 2 fournit un ordonnancement des threads en temps réel). |
| Sécurité | Absence de mécanismes natifs de cryptage et d'authentification. | Prend en charge les extensions de sécurité DDS (DDS-Security) pour assurer l'authentification, le cryptage des données et le contrôle d'accès. |
| Support multiplateforme | Fonctionne principalement sur les systèmes Linux avec une prise en charge limitée de Windows/macOS. | Prend en charge de multiples plateformes telles que Linux, Windows, macOS, RTOS, etc. et divise clairement les plateformes en niveau 1 (activement pris en charge par le gouvernement officiel) et niveau 2 (pris en charge par la communauté) afin de renforcer la compatibilité entre les systèmes. |
| Outils de débogage | S'appuyant sur des outils traditionnels tels que roslaunch et rviz, le système de journalisation est relativement basique. | Fournir un système de journalisation intégré (par exemple RCLCPP_INFO), un support pour les scripts Python et de meilleurs outils de test. |
| Tolérance de panne | Une défaillance du roscore peut entraîner une panne de l'ensemble du système. | Architecture distribuée pour éviter un point de défaillance unique, les nœuds peuvent rejoindre/quitter dynamiquement le système. |
7. Scénarios d'application typiques
- ROS 1: Education, projets de recherche (par exemple, navigation de robots mobiles, SLAM), scénarios qui ne nécessitent pas un temps réel et une sécurité élevés. Si le projet est mature et ne nécessite pas de temps réel, de sécurité ou de caractéristiques multiplateformes, et s'appuie sur un grand nombre de ressources écologiques de ROS 1, continuez à utiliser ROS 1.
- ROS 2: Automatisation industrielle, conduite autonome, drones et autres scénarios qui nécessitent un temps réel élevé, une sécurité et un support multiplateforme, ainsi que la maintenance à long terme de projets à grande échelle (par ex, robots de livraison, Robot industrielrobots médicaux). Les projets qui nécessitent une stabilité de niveau industriel, un contrôle en temps réel, un cryptage sécurisé ou un déploiement multiplateforme sont préférés à ROS 2.
8. Compatibilité du matériel et des plates-formes
- ROS1: Prend principalement en charge Linux (Ubuntu).
- ROS2: Prise en charge native de Linux, Windows, macOS et des plates-formes embarquées.
9. Soutien à l'écosystème et à la communauté
- ROS1: Un grand nombre de paquets et une communauté active.
- ROS2: Un écosystème en pleine expansion, mais le nombre de paquets est encore en train de rattraper le retard.
Conclusion : ROS1 dispose d'un écosystème mature, tandis que ROS2 rattrape rapidement son retard.
10. Coût de la migration et de la mise à niveau
- Les API sont incompatibles, ce qui oblige à réécrire le code.
- Les pilotes peuvent avoir besoin d'être adaptés ; ros1_bridge peut aider à une migration progressive.
Conclusion : Les coûts de migration sont importants, mais les risques peuvent être réduits par des mises à niveau progressives.
11. Sécurité et normes industrielles
- ROS1: Pas de mécanismes de sécurité natifs.
- ROS2: Conforme aux normes de sécurité DDS et peut intégrer OPC UA et TSN.
Conclusion : ROS2 est mieux adapté aux applications industrielles et aux applications critiques en matière de sécurité.
Tendances futures et feuille de route
- ROS1Noetic est la version finale, maintenue jusqu'en 2025.
- ROS2suit une stratégie de support à long terme (LTS) avec des mises à jour actives des fonctionnalités.
Conclusion : La tendance est clairement en faveur de ROS2.
Conclusion et recommandations
Pour chercheurs ou débutantsROS1 reste un choix mature et stable. les utilisateurs industriels ou les équipes commerciales, Les avantages de ROS2 en matière de systèmes distribués, de performances en temps réel et de sécurité apportent une valeur à long terme.
Conseils pratiques : Évaluer la version de ROS dès le début de la planification du projet et prendre des décisions en fonction de la maturité de l'écosystème et des capacités de l'équipe.
