Od Ubuntu 22.04 lub od czerwca 2025 roku oficjalna baza nie będzie już aktualizowana pod kątem wsparcia ROS1; zalecane jest korzystanie z systemu ROS2. ROS 2 pod względem architektury, pracy w czasie rzeczywistym, bezpieczeństwa i rozszerzalności ekosystemu wypada znacznie lepiej niż ROS 1. Jeśli rozpoczynasz nowy projekt, zaleca się bezpośrednie użycie ROS2, jednak w przypadku migracji należy rozważyć kompromis między istniejącymi zasobami a długoterminowymi korzyściami. Szczegółowe zestawienie wsparcia wersji Ubuntu znajduje się pod linkiem. Zależność między różnymi wersjami ROS i Ubuntu, poniższe porównanie obu struktur w celu analizy:
| Wersja ROS 2 | Wersja Ubuntu | Czy LTS | Data wydania |
| 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: Zapoczątkowany w 2014 roku, ukierunkowany na robotykę klasy przemysłowej, z wykorzystaniem middleware DDS w celu poprawy pracy w czasie rzeczywistym, wsparcia wieloplatformowego i bezpieczeństwa.
Podsumowanie: ROS1 lepiej sprawdza się w badaniach i prototypowaniu, natomiast ROS2 jest idealny do wdrożeń przemysłowych i komercyjnych.
2. Architektura systemu
| Wymiar | ROS1 | ROS2 |
| Architektura rdzenia | Stosuje architekturę scentralizowaną, opierając się na węźle Master (menedżerze węzłów) do realizacji rejestracji węzłów i komunikacji. | Architektura rozproszona, bezpośrednia komunikacja między węzłami, brak potrzeby stosowania Master, obsługa mechanizmu dynamicznego wykrywania. |
| Model komunikacji | Personalizowany system komunikacji oparty na protokole TCP/UDP, który ma problemy takie jak opóźnienia, utrata pakietów i brak możliwości szyfrowania. | Ustandaryzowany protokół komunikacyjny oparty na DDS, obsługujący pracę w czasie rzeczywistym, szyfrowanie i interakcję wieloplatformową. |
| Niezawodność | Opiera się na protokole TCP do komunikacji peer-to-peer, co grozi utratą pakietów. | Niezawodna transmisja jest gwarantowana przez polityki QoS (np. Reliable). |
| System kompilacji | Korzysta z systemów kompilacji rosbuild (wczesny) i catkin. | Wprowadzono zautomatyzowany system kompilacji, który zapewnia bardziej elastyczne zarządzanie zależnościami i budowę w wielu językach. |
3. Doświadczenie użytkownika
| Wymiar | ROS1 | ROS2 |
| Krzywa uczenia się | Bogate zasoby społecznościowe i dojrzała dokumentacja — odpowiednie do rozpoczęcia pracy. | Nowe funkcje zwiększają koszty nauki (np. konfiguracja DDS, debugowanie w czasie rzeczywistym), ale w dłuższej perspektywie są bardziej łatwe w utrzymaniu. |
| Koszty migracji | Projekty ROS 1 wymagają przebudowania logiki komunikacji, zarządzania węzłami oraz systemu kompilacji, aby dokonać migracji do ROS 2. | Dostępne są narzędzia migracyjne (np. ros1_bridge) umożliwiające interoperacyjność między węzłami ROS 1 i ROS 2. |
| Debugowanie i zestaw narzędzi | Opierając się na narzędziach takich jak roslaunch i rviz, proces debugowania jest bardziej tradycyjny. | Nowy framework launch (obsługujący konfigurację w Pythonie), wbudowany system logowania i lepsze narzędzia testowe. |
| Społeczność i ekosystem | 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 webowymi), a ekosystem stale się rozwija. |
4. Porównanie kluczowych technologii
| Wymiar | ROS1 | ROS2 |
| Komunikacja między węzłami | Komunikacja peer-to-peer jest nawiązywana poprzez rejestrację w Master. | Węzły automatycznie się wykrywają i komunikują bezpośrednio ze sobą za pośrednictwem DDS. |
| Komunikaty | Wykorzystuje niestandardowy typ wiadomości (.msg), oparty na implementacji roscpp/rospy. | Generowanie komunikatów wielojęzycznych w oparciu o IDL (Interface Definition Language) dla lepszej kompatybilności. |
| Tolerancja błędów | Awaria Mastera może spowodować wyłączenie całego systemu. | Architektura rozproszona w celu uniknięcia pojedynczego punktu awarii; węzły mogą dynamicznie dołączać i opuszczać sieć. |
5. Różnice składniowe
| Wymiar | ROS1 | ROS2 |
| Składnia tworzenia węzłów | Użycie ros::NodeHandle do zarządzania węzłami, które wymaga uruchomienia roscore w celu startu scentralizowanego menedżera. | Użyj rclcpp::Node lub rclpy::Node do bezpośredniego tworzenia węzłów bez roscore, co obsługuje architekturę rozproszoną. |
| Mechanizm komunikacji | Oparte na niestandardowym protokole TCP/UDP do realizacji komunikacji, wymagające ręcznego zarządzania rejestracją i wykrywaniem węzłów. | W oparciu o standard DDS (Data Distribution Service) węzły automatycznie się odkrywają i komunikują ze sobą. |
| Definicja wiadomości | Użycie pliku .msg do definiowania typu komunikatu, oparcie na implementacji roscpp/rospy. | Użycie IDL (Interface Definition Language) do generowania komunikatów wielojęzycznych dla lepszej kompatybilności. |
| Pliki launch | Użycie XML do pisania pliku .launch, pojedyncza funkcja, trudna konfiguracja dynamiczna. | Użycie Pythona do pisania pliku .launch.py w celu obsługi logiki dynamicznej (takiej jak instrukcje warunkowe, przekazywanie parametrów). |
6. Różnice w praktycznym zastosowaniu
| Wymiar | ROS1 | ROS2 |
| Wsparcie wielojęzyczne | Obsługuje głównie C++ i Python; inne języki wymagają adaptacji. | Rozszerzone wsparcie dla dodatkowych języków (np. Rust, Java) oraz kompatybilność międzyjęzykowa poprzez Interface Definition Language (IDL). |
| System kompilacji | Opiera się na systemie kompilacji catkin, który wymaga ścisłego przestrzegania struktury workspace. | Użycie systemu budowania ament dla bardziej elastycznego zarządzania zależnościami i budowania wielojęzycznego. |
| Wsparcie w czasie rzeczywistym | Słaba wydajność w czasie rzeczywistym, trudno spełnić wymagania przemysłowego sterowania w czasie rzeczywistym. | Poprawa wsparcia dla systemów czasu rzeczywistego (np. rclcpp w 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), zapewniające uwierzytelnianie, szyfrowanie danych i kontrolę dostępu. |
| Wsparcie wieloplatformowe | Działa głównie na systemach Linux, z ograniczonym wsparciem dla Windows/macOS. | Obsługuje wiele platform, takich jak Linux, Windows, macOS, RTOS itp., i wyraźnie dzieli platformy na Tier 1 (aktywnie wspierane przez oficjalne władze) i Tier 2 (wspierane przez społeczność), aby wzmocnić kompatybilność między systemami. |
| Narzędzia do debugowania | Opierając się na tradycyjnych narzędziach, takich jak roslaunch i rviz, system rejestrowania zdarzeń jest stosunkowo podstawowy. | Zapewniają wbudowany system logowania (np. RCLCPP_INFO), obsługę skryptów Pythona oraz lepsze narzędzia do testowania. |
| Tolerancja błędów | Awaria roscore może spowodować wyłączenie całego systemu. | Architektura rozproszona w celu uniknięcia pojedynczego punktu awarii; węzły mogą dynamicznie dołączać i opuszczać sieć. |
7. Typowe scenariusze zastosowań
- ROS 1: Edukacja, projekty badawcze (np. nawigacja robotów mobilnych, SLAM), scenariusze niewymagające wysokiej wydajności czasu rzeczywistego i bezpieczeństwa. Jeśli projekt jest dojrzały i nie wymaga funkcji czasu rzeczywistego, bezpieczeństwa ani wsparcia wieloplatformowego, a opiera się na dużej liczbie zasobów ekosystemu ROS 1, kontynuuj korzystanie z ROS 1.
- ROS 2: Automatyka przemysłowa, jazda autonomiczna, drony i inne scenariusze wymagające wysokiej wydajności czasu rzeczywistego, bezpieczeństwa i wsparcia wieloplatformowego, a także długoterminowego utrzymania projektów na dużą skalę (np. dostawa roboty, iRoboty przemysłowe, roboty medyczne). Projekty wymagające przemysłowej stabilności, sterowania w czasie rzeczywistym, bezpiecznego szyfrowania lub wdrożeń wieloplatformowych preferują ROS 2.
8. Kompatybilność sprzętu i platformy
- Obsługuje głównie system Linux (Ubuntu).
- RO natywnie obsługuje Linux, Windows, macOS oraz 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ąż nie dorównuje ROS 1.
Podsumowanie: ROS1 ma dojrzały ekosystem, a ROS2 szybko go dogania.
10. Koszt migracji i aktualizacji
- API są niekompatybilne, co wymaga przepisania kodu.
- Sterowniki mogą wymagać adaptacji; ros1_bridge może pomóc w stopniowej migracji.
Podsumowanie: Koszty migracji są wysokie, ale ryzyko można zmniejszyć poprzez migrację etapową.
11. Bezpieczeństwo i standardy przemysłowe
- ROS1: Brak natywnych mechanizmów bezpieczeństwa.
- ROS2: Zgodny ze standardami bezpieczeństwa DDS, umożliwia integrację z OPC UA i TSN.
Podsumowanie: ROS2 jest lepiej dostosowany do zastosowań krytycznych pod względem bezpieczeństwa oraz aplikacji przemysłowych.
Przyszłe trendy i plan rozwoju
- ROS1Noetic jest ostatnim wydaniem, utrzymywanym do 2025 roku.
- ROS2 stosuje strategię długoterminowego wsparcia (LTS) z aktywnymi aktualizacjami funkcji.
Podsumowanie: Trend wyraźnie wskazuje na ROS2.
Podsumowanie i zalecenia
dla naukowcy lub początkujący, ROS1 pozostaje dojrzałym i stabilnym wyborem; dla użytkownicy przemysłowi lub zespoły komercyjne, przewaga ROS2 w systemach rozproszonych, wydajności w czasie rzeczywistym i bezpieczeństwie przynosi długoterminową wartość.
Praktyczne zalecenia: Oceń wersję ROS na wczesnym etapie planowania projektu i podejmij decyzje w oparciu o dojrzałość ekosystemu oraz kompetencje zespołu.
