Od Ubuntu22.04 lub czerwca 2025, oficjalna podstawowa wersja nie obsługuje już ROS1, zalecane jest użycie systemu ROS2, ROS 2 w architekturze, czasie rzeczywistym, bezpieczeństwie i eko-rozszerzalności znacznie lepszej niż ROS 1, jeśli rozwój nowego projektu jest zalecany do bezpośredniego korzystania z ROS2, ale jeśli musisz dokonać migracji, aby dokonać kompromisu między istniejącymi zasobami a długoterminowymi korzyściami. Szczegółowa relacja wsparcia wersji Ubuntu patrz link [ROS i Ubuntu różne wersje relacji] poniższe porównanie dwóch ram do przeanalizowania:
| Wersja ROS 2 | Wersja Ubuntu | LTS czy nie | Czas zwolnienia |
| Jazzy | 24.04 (Noble) | Tak (LTS) | 2024 |
| Kilted | 24.04(Noble) | Nie | 2025-05 |
Historia i rozwój
- ROS1: Opracowany przez Uniwersytet Stanforda i Willow Garage, skupiający się na badaniach i prototypowaniu.
- ROS2: Zainicjowany w 2014 roku, ukierunkowany na robotykę klasy przemysłowej z oprogramowaniem pośredniczącym DDS w celu poprawy możliwości w czasie rzeczywistym, obsługi wielu platform i bezpieczeństwa.
Wnioski: ROS1 lepiej nadaje się do badań i prototypowania, podczas gdy ROS2 jest idealny do wdrożeń przemysłowych i komercyjnych.
2. Architektura systemu
| Wymiar | ROS1 | ROS2 |
| Architektura podstawowa | Przyjęcie scentralizowanej architektury, polegającej na węźle głównym (menedżerze węzłów) w celu rejestracji węzłów i komunikacji. | Architektura rozproszona, bezpośrednia komunikacja między węzłami, brak konieczności posiadania urządzenia nadrzędnego, obsługa mechanizmu dynamicznego wykrywania. |
| Model komunikacji | Niestandardowy system komunikacji oparty na protokole TCP/UDP, który boryka się z takimi problemami jak opóźnienia, utrata pakietów i brak możliwości szyfrowania. | Znormalizowany protokół komunikacyjny oparty na DDS, obsługujący czas rzeczywisty, szyfrowanie i interakcję międzyplatformową. |
| Niezawodność | Opiera się na protokole TCP do komunikacji peer-to-peer, podatny na utratę pakietów | Niezawodna transmisja jest gwarantowana przez politykę QoS (np. Reliable). |
| System kompilacji | Wykorzystuje systemy kompilacji rosbuild (wczesny) i catkin. | Wprowadzono dodatkowy system kompilacji, aby wspierać bardziej elastyczne zarządzanie zależnościami i kompilację w wielu językach. |
3. Doświadczenie użytkownika
| Wymiar | ROS1 | ROS2 |
| Krzywa uczenia się | Bogate zasoby społeczności i dojrzała dokumentacja, odpowiednie do rozpoczęcia pracy. | Nowe funkcje zwiększają koszty nauki (np. konfiguracja DDS, debugowanie w czasie rzeczywistym), ale na dłuższą metę są łatwiejsze w utrzymaniu. |
| Koszty migracji | Projekty ROS 1 wymagają refaktoryzacji logiki komunikacji, zarządzania węzłami i systemu kompilacji w celu migracji do ROS 2. | Dostępne są narzędzia migracyjne (np. ros1_bridge) do współpracy między węzłami ROS 1 i ROS 2. |
| Debugowanie i zestaw narzędzi | Polegając na narzędziach takich jak roslaunch i rviz, proces debugowania jest bardziej tradycyjny. | Nowy framework uruchamiania (obsługujący konfigurację Pythona), wbudowany system logowania i lepsze narzędzia testowe. |
| Społeczność i ekologia | Ekosystem jest duży, ale niektóre funkcje są trudne do rozszerzenia ze względu na ograniczenia architektoniczne. | Nowe funkcje są łatwiejsze do zintegrowania (np. głębsza integracja z Gazebo i technologiami internetowymi), a ekosystem stale się rozwija. |
4. Porównanie kluczowych technologii
| Wymiar | ROS1 | ROS2 |
| Komunikacja węzła | Komunikacja peer-to-peer jest nawiązywana poprzez rejestrację Master. | Węzły automatycznie wykrywają i komunikują się bezpośrednio ze sobą za pośrednictwem DDS. |
| Wiadomości | Używa niestandardowego typu wiadomości (.msg), opiera się na implementacji roscpp/rospy. | Generowanie komunikatów w wielu językach w oparciu o IDL (Interface Definition Language) dla lepszej kompatybilności. |
| Tolerancja błędów | Awaria urządzenia głównego może spowodować awarię całego systemu. | Architektura rozproszona, aby uniknąć pojedynczego punktu awarii, węzły mogą dynamicznie dołączać/odchodzić. |
5. Różnice w składni
| Wymiar | ROS1 | ROS2 |
| Składnia tworzenia węzłów | Używa ros::NodeHandle do zarządzania węzłami, polega na roscore do uruchamiania scentralizowanego menedżera. | Użyj rclcpp::Node lub rclpy::Node do tworzenia węzłów bezpośrednio bez roscore, obsługuje architekturę rozproszoną. |
| Mechanizm komunikacji | W oparciu o niestandardowy protokół TCP/UDP w celu osiągnięcia komunikacji, konieczne jest ręczne zarządzanie rejestracją i wykrywaniem węzłów. | W oparciu o standard DDS (Data Distribution Service) węzły automatycznie wykrywają się i komunikują ze sobą. |
| Definicja wiadomości | Użyj pliku .msg do zdefiniowania typu wiadomości, polegaj na implementacji roscpp/rospy. | Użyj IDL (Interface Definition Language) do generowania komunikatów w wielu językach dla lepszej kompatybilności. |
| Uruchamianie plików | Użycie XML do zapisu pliku .launch, pojedyncza funkcja, trudna do dynamicznej konfiguracji. | Użyj Pythona do napisania pliku .launch.py, obsługuj dynamiczną logikę (taką jak ocena warunkowa, przekazywanie parametrów). |
6. Różnice w rzeczywistym użytkowaniu
| Wymiar | ROS1 | ROS2 |
| Obsługa wielu języków | Obsługuje głównie C++ i Python, inne języki wymagają dostosowania. | Rozszerzona obsługa dodatkowych języków (np. Rust, Java) i kompatybilność międzyjęzykowa za pośrednictwem języka definicji interfejsu (IDL). |
| System kompilacji | Opiera się na systemie kompilacji catkin, który wymaga ścisłego przestrzegania struktury obszaru roboczego. | Użyj systemu kompilacji ament dla bardziej elastycznego zarządzania zależnościami i kompilacji w wielu językach. |
| Wsparcie w czasie rzeczywistym | Słaba wydajność w czasie rzeczywistym, trudna do zaspokojenia potrzeb przemysłowej kontroli w czasie rzeczywistym. | Poprawa obsługi systemów czasu rzeczywistego (np. rclcpp ROS 2 zapewnia planowanie wątków w czasie rzeczywistym). |
| Bezpieczeństwo | Brak natywnych mechanizmów szyfrowania i uwierzytelniania. | Obsługuje rozszerzenia zabezpieczeń DDS (DDS-Security) w celu zapewnienia uwierzytelniania, szyfrowania danych i kontroli dostępu. |
| Obsługa wielu platform | Działa głównie na systemach Linux z ograniczoną obsługą Windows/macOS. | Obsługuje wiele platform, takich jak Linux, Windows, macOS, RTOS itp. i wyraźnie dzieli platformy na warstwę 1 (aktywnie wspieraną przez oficjalny rząd) i warstwę 2 (wspieraną przez społeczność) w celu zwiększenia kompatybilności między systemami. |
| Narzędzia do debugowania | Opierając się na tradycyjnych narzędziach, takich jak roslaunch i rviz, system rejestrowania jest stosunkowo prosty. | Wbudowany system logowania (np. RCLCPP_INFO), obsługa skryptów Python i lepsze narzędzia testowe. |
| Tolerancja błędów | Awaria roscore może spowodować awarię całego systemu. | Architektura rozproszona, aby uniknąć pojedynczego punktu awarii, węzły mogą dynamicznie dołączać/odchodzić. |
7. Typowe scenariusze zastosowań
- ROS 1: Edukacja, projekty badawcze (np. nawigacja robotów mobilnych, SLAM), scenariusze, które nie wymagają wysokiego czasu rzeczywistego i bezpieczeństwa. Jeśli projekt jest dojrzały i nie wymaga funkcji czasu rzeczywistego, bezpieczeństwa lub funkcji międzyplatformowych i opiera się na dużej liczbie zasobów ekologicznych ROS 1, nadal używaj ROS 1.
- ROS 2: Automatyka przemysłowa, autonomiczna jazda, drony i inne scenariusze, które wymagają wysokiego poziomu czasu rzeczywistego, bezpieczeństwa i wsparcia międzyplatformowego, a także długoterminowego utrzymania projektów na dużą skalę (np, roboty dostawcze, Robot przemysłowy, roboty medyczne). Projekty wymagające stabilności na poziomie przemysłowym, kontroli w czasie rzeczywistym, bezpiecznego szyfrowania lub wdrażania międzyplatformowego są preferowane w stosunku do ROS 2.
8. Kompatybilność sprzętu i platformy
- ROS1: Obsługuje głównie system Linux (Ubuntu).
- ROS2: Natywnie obsługuje systemy Linux, Windows, macOS i platformy wbudowane.
9. Wsparcie ekosystemu i społeczności
- ROS1: Duża liczba pakietów i aktywna społeczność.
- ROS2: Szybko rozwijający się ekosystem, ale liczba pakietów wciąż nadrabia zaległości.
Wnioski: ROS1 ma dojrzały ekosystem, podczas gdy ROS2 szybko nadrabia zaległości.
10. Koszt migracji i aktualizacji
- Interfejsy API są niekompatybilne, co wymaga przepisywania kodu.
- Sterowniki mogą wymagać adaptacji; ros1_bridge może pomóc w stopniowej migracji.
Wnioski: Koszty migracji są znaczne, ale ryzyko można zmniejszyć poprzez stopniowe aktualizacje.
11. Bezpieczeństwo i standardy przemysłowe
- ROS1: Brak natywnych mechanizmów bezpieczeństwa.
- ROS2: Zgodność ze standardami bezpieczeństwa DDS i możliwość integracji OPC UA i TSN.
Wnioski: ROS2 jest lepiej przystosowany do zastosowań krytycznych dla bezpieczeństwa i przemysłowych.
Przyszłe trendy i mapa drogowa
- ROS1Noetic jest ostatnią wersją, utrzymaną do 2025 roku.
- ROS2stosuje strategię długoterminowego wsparcia (LTS) z aktywnymi aktualizacjami funkcji.
Wnioski: Trend wyraźnie faworyzuje ROS2.
Wnioski i zalecenia
Dla badacze lub początkującyROS1 pozostaje dojrzałym i stabilnym wyborem; dla użytkownicy przemysłowi lub zespoły komercyjne, Zalety ROS2 w zakresie systemów rozproszonych, wydajności w czasie rzeczywistym i bezpieczeństwa przynoszą długoterminową wartość.
Praktyczne porady: Oceń wersję ROS na wczesnym etapie planowania projektu i podejmuj decyzje w oparciu o dojrzałość ekosystemu i możliwości zespołu.
