Ab Ubuntu 22.04 bzw. ab Juni 2025 wird ROS 1 offiziell nicht mehr unterstützt; es wird empfohlen, ROS 2 zu verwenden. ROS 2 ist in Bezug auf Architektur, Echtzeitfähigkeit, Sicherheit und Erweiterbarkeit deutlich besser als ROS 1. Für die Entwicklung neuer Projekte wird empfohlen, direkt ROS 2 zu verwenden. Wenn jedoch eine Migration erforderlich ist, muss ein Kompromiss zwischen den vorhandenen Ressourcen und den langfristigen Vorteilen gefunden werden. Detaillierte Informationen zur Unterstützung der verschiedenen Ubuntu-Versionen finden Sie unter dem Link. Das Verhältnis der verschiedenen Versionen von ROS und Ubuntu, der folgende Vergleich der beiden Frameworks zur Analyse:
| ROS 2-Version | Ubuntu-Version | LTS oder nicht | Veröffentlichungszeitpunkt |
| Jazzy | 24.04 (Noble) | Ja (LTS) | 2024 |
| Kilted | 24.04 (Noble) | Nein | 2025-05 |
Geschichte und Entwicklung
- ROS1: Entwickelt von der Stanford University und Willow Garage, mit Fokus auf Forschung und Prototyping.
- ROS2: 2014 initiiert, ausgerichtet auf industrietaugliche Robotik mit DDS-Middleware zur Verbesserung von Echtzeitfähigkeit, Plattformunterstützung und Sicherheit.
Fazit: ROS1 eignet sich besser für Forschung und Prototyping, während ROS2 ideal für industrielle und kommerzielle Anwendungen ist.
2. Systemarchitektur
| Abmessung | ROS1 | ROS2 |
| Kernarchitektur | Es wird eine zentralisierte Architektur verwendet, bei der die Registrierung der Knoten und die Kommunikation über den Master-Knoten (Knotenmanager) erfolgen. | Verteilte Architektur, direkte Kommunikation zwischen Knoten, kein Master erforderlich, Unterstützung dynamischer Entdeckungsmechanismen. |
| Kommunikationsmodell | Eigenentwickeltes Kommunikationssystem auf Basis von TCP/UDP-Protokollen mit Problemen wie Verzögerung, Paketverlust und fehlender Verschlüsselung. | Standardisiertes Kommunikationsprotokoll auf Basis von DDS mit Unterstützung für Echtzeit, Verschlüsselung und plattformübergreifende Interaktion. |
| Zuverlässigkeit | Verlässt sich auf TCP für die Peer-to-Peer-Kommunikation, anfällig für Paketverluste. | Zuverlässige Übertragung wird durch QoS-Richtlinien (z. B. Reliable) gewährleistet. |
| Kompilierungssystem | Verwendet die Kompilierungssysteme rosbuild (früher) und catkin. | Ein automatisiertes Build-System wurde eingeführt, um eine flexiblere Abhängigkeitsverwaltung und einen Multi-Sprach-Build zu unterstützen. |
3. Benutzererfahrung
| Abmessung | ROS1 | ROS2 |
| Lernkurve | Umfangreiche Community-Ressourcen und ausgereifte Dokumentation, geeignet für den Einstieg. | Neue Funktionen erhöhen die Lernkosten (z. B. DDS-Konfiguration, Echtzeit-Debugging), sind aber langfristig besser wartbar. |
| Migrationskosten | ROS-1-Projekte müssen die Kommunikationslogik, das Knotenmanagement und das Kompilierungssystem umstrukturieren, um auf ROS 2 zu migrieren. | Migrationswerkzeuge (z. B. ros1_bridge) sind verfügbar, um die Interoperabilität zwischen ROS-1- und ROS-2-Knoten zu ermöglichen. |
| Debugging und Toolchain | Verlässt sich auf Tools wie roslaunch und rviz, der Debugging-Prozess ist eher traditionell. | Neues Start-Framework (mit Python-Konfigurationsunterstützung), integriertes Protokollierungssystem und bessere Testwerkzeuge. |
| Community und Ökologie | Das Ökosystem ist groß, aber einige Funktionen sind aufgrund architektonischer Einschränkungen schwer erweiterbar. | Neue Funktionen sind einfacher zu integrieren (z. B. tiefere Integration mit Gazebo und Web-Technologien), und das Ökosystem expandiert weiter. |
4. Vergleich der Schlüsseltechnologie
| Abmessung | ROS1 | ROS2 |
| Knotenkommunikation | Peer-to-Peer-Kommunikation wird über die Master-Registrierung hergestellt. | Knoten erkennen sich automatisch gegenseitig und kommunizieren direkt über DDS miteinander. |
| Messaging | Verwendet eigene Nachrichtentypen (.msg), basiert auf der Implementierung über roscpp/rospy. | Generiert mehrsprachige Nachrichten auf Basis von IDL (Interface Definition Language) für bessere Kompatibilität. |
| Fehlertoleranz | Ein Master-Ausfall kann den Ausfall des gesamten Systems verursachen. | Verteilte Architektur zur Vermeidung einzelner Ausfallpunkte, Knoten können dynamisch beitreten/verlassen. |
5. Syntaxunterschiede
| Abmessung | ROS1 | ROS2 |
| Syntax zur Knotenerstellung | Verwenden Sie ros::NodeHandle zur Verwaltung von Knoten, das auf roscore angewiesen ist, um den zentralen Manager zu starten. | Verwenden Sie rclcpp::Node oder rclpy::Node, um Knoten direkt ohne roscore zu erstellen, was eine verteilte Architektur unterstützt. |
| Kommunikationsmechanismus | Da die Kommunikation auf einem maßgeschneiderten TCP/UDP-Protokoll basiert, müssen die Registrierung und Erkennung der Knoten manuell verwaltet werden. | Basierend auf dem DDS-Standard (Data Distribution Service) erkennen sich Knoten automatisch gegenseitig und kommunizieren miteinander. |
| Nachrichtendefinition | Verwendet .msg-Dateien zur Definition von Nachrichtentypen, basiert auf der Implementierung über roscpp/rospy. | Verwendet IDL (Interface Definition Language) zur Generierung mehrsprachiger Nachrichten für bessere Kompatibilität. |
| Launch-Dateien | XML zur Erstellung einer .launch-Datei verwenden: nur eine Funktion, dynamische Konfiguration schwierig. | Verwenden Sie Python, um eine .launch.py-Datei zu schreiben, die dynamische Logik unterstützt (z. B. Bedingungsprüfung, Parameterübergabe). |
6. Unterschiede in der praktischen Anwendung
| Abmessung | ROS1 | ROS2 |
| Mehrsprachige Unterstützung | Unterstützt hauptsächlich C++ und Python; andere Sprachen müssen angepasst werden. | Erweiterte Unterstützung für weitere Sprachen (z. B. Rust, Java) und sprachübergreifende Kompatibilität über die Interface Definition Language (IDL). |
| Kompilierungssystem | Verlässt sich auf das catkin-Kompilierungssystem, das eine strikte Einhaltung der Workspace-Struktur erfordert. | Verwendet das ament-Build-System für flexibleres Abhängigkeitsmanagement und mehrsprachige Builds. |
| Echtzeitunterstützung | Schwache Echtzeitfähigkeit, schwer die Anforderungen industrieller Echtzeitsteuerung zu erfüllen. | Verbesserung der Unterstützung für Echtzeitsysteme (z. B. bietet ROS 2’s rclcpp eine Echtzeit-Thread-Planung). |
| Sicherheit | Keine nativen Verschlüsselungs- und Authentifizierungsmechanismen. | Unterstützt DDS-Sicherheitserweiterungen (DDS-Security) für Authentifizierung, Datenverschlüsselung und Zugriffskontrolle. |
| Plattformübergreifender Support | Läuft hauptsächlich auf Linux-Systemen, mit begrenzter Windows/macOS-Unterstützung. | Unterstützt mehrere Plattformen wie Linux, Windows, macOS, RTOS usw. und unterteilt die Plattformen klar in Tier 1 (offiziell aktiv unterstützt) und Tier 2 (von der Community unterstützt), um die systemübergreifende Kompatibilität zu stärken. |
| Debugging-Werkzeuge | Die Abhängigkeit von traditionellen Werkzeugen wie roslaunch und rviz bedeutet, dass das Protokollierungssystem relativ einfach ist. | Integriertes Protokollierungssystem (z. B. RCLCPP_INFO), Python-Skriptunterstützung und bessere Testwerkzeuge bereitstellen. |
| Fehlertoleranz | Ein roscore-Ausfall kann den Ausfall des gesamten Systems verursachen. | Verteilte Architektur zur Vermeidung einzelner Ausfallpunkte, Knoten können dynamisch beitreten/verlassen. |
7. Typische Anwendungsszenarien
- ROS 1: Lehre, Forschungsprojekte (z. B. Navigation mobiler Roboter, SLAM), Anwendungsszenarien, die keine hohe Echtzeitleistung und keine Sicherheitsanforderungen erfordern. Wenn das Projekt ausgereift ist und keine Echtzeit-, Sicherheits- oder plattformübergreifenden Funktionen benötigt sowie auf eine große Anzahl von Ressourcen aus dem ROS-1-Ökosystem zurückgreift, sollten Sie weiterhin ROS 1 verwenden.
- ROS 2: Industrieautomation, autonomes Fahren, Drohnen und andere Anwendungsbereiche, die hohe Echtzeitfähigkeit, Sicherheit und plattformübergreifende Unterstützung erfordern, sowie die langfristige Wartung groß angelegter Projekte (z. B., Lieferung Roboter, d. h.Industrieroboter, medizinische Roboter). Projekte, die industrielle Stabilität, Echtzeitsteuerung, sichere Verschlüsselung oder plattformübergreifende Bereitstellung erfordern, bevorzugen ROS 2.
8. Hardware- und Plattformkompatibilität
- Unterstützt hauptsächlich Linux (Ubuntu).
- RO unterstützt nativ Linux, Windows, macOS und eingebettete Plattformen.
9. Ökosystem und Unterstützung durch die Gemeinschaft
- ROS1Eine große Auswahl an Paketen und eine aktive Community.
- ROS2: Ein schnell wachsendes Ökosystem, aber die Paketanzahl holt noch auf.
Fazit: ROS1 hat ein ausgereiftes Ökosystem, während ROS2 schnell aufholt.
10. Kosten für Migration und Upgrade
- APIs sind inkompatibel, was Code-Neuschreibungen erfordert.
- Treiber müssen möglicherweise angepasst werden; ros1_bridge kann bei der schrittweisen Migration helfen.
Fazit: Die Migrationskosten sind hoch, aber Risiken lassen sich durch schrittweise Upgrades reduzieren.
11. Sicherheit und Industriestandards
- ROS1: Keine nativen Sicherheitsmechanismen.
- ROS2: Erfüllt DDS-Sicherheitsstandards und kann OPC UA und TSN integrieren.
Fazit: ROS2 eignet sich besser für sicherheitskritische und industrielle Anwendungen.
Zukünftige Trends und Roadmap
- ROS1Noetic ist die letzte Version und wird bis 2025 gewartet.
- ROS2 folgt einer Long-Term-Support-Strategie (LTS) mit aktiven Funktionsupdates.
Fazit: Der Trend spricht eindeutig für ROS2.
Fazit und Empfehlungen
Für Forscher oder Einsteiger, ROS1 bleibt eine ausgereifte und stabile Wahl; für industrielle Anwender oder kommerzielle Teams, die Vorteile von ROS2 in verteilten Systemen, Echtzeitfähigkeit und Sicherheit bringen langfristigen Wert.
Handlungsempfehlung: Bewerten Sie die ROS-Version frühzeitig in der Projektplanung und treffen Sie Entscheidungen basierend auf der Reife des Ökosystems und den Teamfähigkeiten.
