Czym różni się ROS od ROS 2?

ROS 1 vs ROS 2 to porównanie dwóch etapów tego samego ekosystemu, ale różnice między nimi sięgają architektury, komunikacji i pracy w czasie rzeczywistym. W praktyce właśnie tam najczęściej pojawiają się problemy z wydajnością, skalowaniem i utrzymaniem projektu. Jeśli wybierasz platformę pod nowy system albo planujesz migrację, ten tekst porządkuje temat bez zbędnych skrótów.

Najważniejsze informacje z tego artykułu:

• ROS 1 opiera się na centralnym masterze, a ROS 2 działa w architekturze rozproszonej.
• ROS 2 używa DDS, więc lepiej radzi sobie z komunikacją, QoS i systemami czasu rzeczywistego.
• ROS 1 ma prostszy model pracy, lecz gorzej skaluje się w większych projektach.
• ROS 2 wspiera Windows, macOS i nowsze wersje Linuxa oraz nowsze wersje C++ i Python 3.
• ROS 1 kończy wsparcie 1 maja 2025 roku, więc nowe projekty warto planować w ROS 2.

Na czym polega różnica między ROS 1 a ROS 2?

ROS 1 i ROS 2 rozwiązują podobne zadania, ale powstały z myślą o innych realiach projektowych. ROS 1 rozwijano głównie pod badania, demonstratory i szybkie prototypowanie. ROS 2 zaprojektowano już pod systemy rozproszone, wdrożenia przemysłowe, bezpieczeństwo komunikacji i bardziej przewidywalne działanie pod obciążeniem.

To właśnie tutaj kryje się najkrótsza odpowiedź na pytanie, czym różni się ROS od ROS 2. W ROS 1 najważniejsza była prostota uruchomienia. W ROS 2 większy nacisk położono na skalowalność, deterministykę działania, obsługę wielu urządzeń oraz nowocześniejszy middleware, czyli warstwę pośredniczącą między kodem aplikacji a transportem danych.

• Architektura – ROS 1 bazuje na centralnym roscore, a ROS 2 działa bez centralnego mastera.
• Komunikacja – ROS 1 korzysta z własnego stosu komunikacyjnego opartego głównie na TCP i XML-RPC, a ROS 2 używa DDS.
• Czas rzeczywisty – ROS 2 daje znacznie lepsze warunki do strojenia opóźnień, kolejek i priorytetów komunikacji.
• Skalowanie – ROS 2 lepiej znosi większą liczbę węzłów, wiele komputerów i systemy wielorobotowe.
• Bezpieczeństwo – ROS 1 nie ma natywnego modelu zabezpieczania komunikacji, a ROS 2 wspiera DDS Security i SROS2.
• Platformy i narzędzia – ROS 2 szerzej wspiera współczesne systemy operacyjne, Python 3 i nowsze standardy C++.

Wskazówka: projekt, który ma trafić do środowiska produkcyjnego albo rozwijać się przez kilka lat, zwykle lepiej planować od razu w ROS 2. Migracja gotowego systemu niemal zawsze kosztuje więcej niż start w nowszej architekturze.

ROS 1 nadal bywa sensownym wyborem przy utrzymaniu starszych instalacji. Trudno jednak pominąć fakt, że ROS 2 usuwa ograniczenia, które w ROS 1 ujawniały się dokładnie wtedy, gdy projekt przestawał być laboratoryjną zabawką. A to moment, w którym kończą się uproszczenia, a zaczyna prawdziwa inżynieria.

Jak zmieniła się architektura komunikacji?

• ROS 1 – każdy węzeł rejestruje się w roscore, a master pośrednio organizuje połączenia między publisherami i subscriberami.
• ROS 2 – węzły odkrywają się wzajemnie przez DDS discovery i komunikują się w modelu rozproszonym peer-to-peer.
• ROS 1 – centralny Parameter Server przechowuje parametry całego systemu.
• ROS 2 – parametry są przypisane do konkretnych węzłów, co upraszcza izolację i utrzymanie.
• ROS 1 – podstawą są topic, service i parametry.
• ROS 2 – ten model zachowano, a do tego lepiej rozwinięto actions do zadań długotrwałych z informacją o postępie i możliwością anulowania.

Największa zmiana architektoniczna polega na usunięciu centralnego mastera. W ROS 1 roscore pełni rolę punktu odniesienia dla całego systemu. To upraszcza start małego projektu, ale w większej instalacji tworzy wąskie gardło, czyli element ograniczający dalsze skalowanie, oraz pojedynczy punkt awarii.

W ROS 2 ten problem znika, ponieważ warstwa odkrywania usług i węzłów działa rozproszenie. Każdy node, czyli węzeł obliczeniowy, może odnajdywać inne węzły w sieci bez centralnego rejestratora. Dla systemów z kilkoma komputerami, wieloma kontrolerami i rozproszonymi czujnikami taka zmiana robi ogromną różnicę.

W praktyce architektura ROS 2 lepiej odpowiada temu, jak dziś buduje się roboty: sterownik napędów działa na jednym komputerze, percepcja obrazu na drugim, planowanie ruchu na trzecim, a całość nadal pozostaje jednym systemem. W ROS 1 takie układy często wymagały dodatkowych obejść, ręcznej konfiguracji nazw i ostrożnego zarządzania masterem.

Dochodzi jeszcze kwestia utrzymania. Rozproszenie nie oznacza chaosu. Oznacza mniejszą zależność od jednego procesu oraz bardziej naturalne mapowanie architektury oprogramowania na fizyczny układ urządzeń.

Jak DDS wpływa na działanie ROS 2?

DDS, czyli Data Distribution Service, zmienia ROS 2 z prostego frameworka komunikacyjnego w system, który da się precyzyjnie stroić pod konkretne obciążenie i wymagania sieciowe. To standard middleware używany w systemach rozproszonych, gdzie liczy się kontrola nad dostarczaniem danych, opóźnieniami i niezawodnością transmisji.

W ROS 1 komunikacja była prostsza, ale też znacznie mniej elastyczna. W ROS 2 DDS wprowadza QoS, czyli Quality of Service. To zestaw polityk określających, w jaki sposób wiadomości mają być przesyłane i przechowywane.

Najważniejsze polityki QoS w ROS 2:

• Reliability – wybór między dostarczeniem niezawodnym a best effort, czyli przesyłaniem bez ponawiania.
• Durability – określa, czy nowy subskrybent dostanie wcześniejsze dane.
• History – ustala, ile wiadomości system przechowuje.
• Deadline – pilnuje oczekiwanej częstotliwości dostarczania danych.
• Lifespan – ogranicza czas życia wiadomości, aby przeterminowane dane nie wpływały na sterowanie.

To właśnie tutaj widać jedną z najważniejszych różnic między ROS 1 a ROS 2. Dane z kamery, lidaru, enkodera i diagnostyki nie mają tej samej wartości ani tego samego priorytetu. W ROS 2 da się to opisać w konfiguracji komunikacji, a nie tylko w kodzie aplikacji. Brzmi technicznie? Owszem. Ale w praktyce oznacza mniej przypadkowych opóźnień i mniej niespodzianek podczas integracji.

Jest też druga strona medalu. DDS daje dużą swobodę, ale wymaga świadomej konfiguracji. Źle dobrane profile QoS potrafią pogorszyć zachowanie systemu. Zauważyłem to szczególnie przy łączeniu szybkich czujników z wolniejszymi modułami diagnostycznymi, gdzie domyślne ustawienia wcale nie okazywały się najlepsze.

Jak ROS 2 radzi sobie z czasem rzeczywistym i wydajnością?

• ROS 1 – prostszy model działania, ale słabsza kontrola nad opóźnieniami i większa podatność na blokowanie callbacków.
• ROS 2 – executory, QoS, komunikacja intra-process i lepsza współpraca z RTOS oraz micro-ROS.
• ROS 1 – dobrze sprawdza się w lekkich prototypach i aplikacjach bez ostrych wymagań czasowych.
• ROS 2 – lepiej pasuje do sterowania, wielosensorowych układów percepcji i aplikacji, gdzie liczy się przewidywalność reakcji.

ROS 2 wyraźnie lepiej wspiera systemy czasu rzeczywistego, choć sam framework nie zamienia zwykłego komputera w twardy system real-time. O przewidywalnym zachowaniu decydują razem: system operacyjny, scheduler, middleware DDS, konfiguracja QoS oraz sposób napisania aplikacji.

W ROS 1 ograniczeniem bywał model wykonywania callbacków i zależność od starszego mechanizmu komunikacji. Gdy system odbiera wiele strumieni danych, na przykład z lidaru 3D, kamer i enkoderów, opóźnienia zaczynają się kumulować. W ROS 2 pomagają w tym executory, czyli mechanizmy sterujące tym, kiedy i w jakiej kolejności wykonują się callbacki.

Najczęściej używane executory w ROS 2:

• SingleThreadedExecutor – prostszy, dobry do mniej złożonych aplikacji.
• MultiThreadedExecutor – pozwala rozdzielać pracę na wiele wątków.
• StaticSingleThreadedExecutor – ogranicza część kosztów dynamicznego zarządzania i pomaga w stabilizacji zachowania.

W praktyce wydajność to nie tylko throughput, czyli przepustowość, ale też wariancja opóźnień. Robot, który raz reaguje po 5 ms, a innym razem po 80 ms, jest trudniejszy do przewidzenia niż robot nieco wolniejszy, ale stabilny. W środowisku przemysłowym właśnie ta przewidywalność często decyduje o tym, czy system zachowuje się poprawnie.

ROS 2 daje też dodatkowe mechanizmy optymalizacji:

• intra-process communication – komunikacja wewnątrz jednego procesu ogranicza kopiowanie danych,
• shared memory – pamięć współdzielona zmniejsza narzut przy dużych wiadomościach,
• micro-ROS – umożliwia integrację z mikrokontrolerami i systemami wbudowanymi,
• lepsza współpraca z RTOS – ułatwia budowę bardziej deterministycznych układów sterowania.

Nie ma jednak sensu obiecywać cudów. ROS 2 nie zawsze będzie szybszy w każdym scenariuszu. Dobrze skonfigurowany ROS 1 w małym projekcie potrafi działać bardzo sprawnie. Różnica ujawnia się wtedy, gdy rośnie liczba węzłów, obciążenie sieci i wymagania co do powtarzalności reakcji.

Jak ROS 2 wspiera systemy wielorobotowe?

ROS 2 od początku znacznie lepiej pasuje do układów wielorobotowych. Brak centralnego roscore oznacza, że cała flota nie zależy od jednego procesu pośredniczącego. Każdy robot może działać jako równorzędny element tej samej infrastruktury komunikacyjnej.

W ROS 1 duże środowiska wielorobotowe szybko komplikowały konfigurację nazw, przestrzeni nazw, routingu i zależności od mastera. Dało się to uruchomić, oczywiście. Tyle że wraz z kolejnymi robotami rosła liczba miejsc, w których coś potrafiło się rozjechać.

ROS 2 upraszcza takie scenariusze przez:

• odkrywanie peer-to-peer – węzły same odnajdują się w sieci bez centralnego rejestratora,
• izolację komunikacji – domeny DDS pomagają oddzielać środowiska i floty,
• lepsze skalowanie – system nie opiera się na jednym punkcie koordynacji,
• spójniejszą pracę w sieciach rozproszonych – łatwiej rozdzielać funkcje między kilka komputerów i robotów.

To ważne przy AGV, AMR, robotach mobilnych, manipulatorach współpracujących i systemach inspekcyjnych. Gdy kilka maszyn wymienia mapy, pozycję, zadania i diagnostykę, architektura rozproszona nie jest dodatkiem. Ona staje się fundamentem.

Z mojego doświadczenia właśnie tutaj najłatwiej zauważyć przewagę ROS 2. Gdy znika centralny punkt zależności, spada ryzyko awarii kaskadowej, a diagnostyka przestaje przypominać polowanie na duchy po sieci przemysłowej.

Jakie systemy operacyjne obsługuje ROS 2?

ROS 2 wspiera więcej systemów operacyjnych i robi to w sposób znacznie bardziej praktyczny dla współczesnych zespołów. ROS 1 był mocno związany z Ubuntu, co przez lata miało sens, ale ograniczało projekty prowadzone w mieszanych środowiskach deweloperskich.

ROS 2 działa natywnie na Windows, macOS i Linuksie. To ułatwia pracę zespołom, które rozwijają oprogramowanie na różnych stacjach roboczych, korzystają z narzędzi firmowych związanych z Windows albo łączą robotykę z oprogramowaniem tworzonym wcześniej poza światem ROS.

W praktyce wieloplatformowość skraca drogę od developmentu do integracji. Mniej czasu znika na obchodzenie ograniczeń środowiska, a więcej zostaje na pisanie i testowanie kodu. Nadal trzeba sprawdzać zgodność konkretnej dystrybucji ROS 2 z wersją systemu operacyjnego, bo oficjalna macierz wsparcia zależy od wydania, ale sam kierunek zmian jest jasny.

Jak zmieniło się wsparcie dla C++ i Pythona?

• C++ – ROS 2 wspiera nowsze standardy, w wielu dystrybucjach co najmniej C++14 i C++17, a nowsze wydania rozwijają wsparcie dalej.
• Python – ROS 2 działa na Python 3, bez obciążenia spuścizną po Pythonie 2.
• Build system – Catkin zastąpiły Ament i Colcon.
• API klienta – ROS 1 używał głównie roscpp i rospy, a ROS 2 rozwija rclcpp i rclpy.
• Interfejsy – ROS 2 korzysta z IDL, czyli Interface Definition Language, co poprawia serializację i zgodność między językami.

Zmiana stosu programistycznego w ROS 2 jest dużo głębsza niż sama przesiadka na Python 3. Owszem, ten element ma duże znaczenie, bo kończy problemy z przestarzałym ekosystemem zależności. Równie ważne jest jednak to, że ROS 2 lepiej wpisuje się w nowoczesne praktyki wytwarzania oprogramowania.

Ament i Colcon upraszczają budowanie większych workspace’ów, a nowe API porządkuje strukturę aplikacji. Pojawiają się też lifecycle nodes, czyli węzły z cyklem życia obejmującym stany configure, activate, deactivate i cleanup. To przydaje się w systemach, które muszą przechodzić przez kontrolowane etapy startu, resetu i wyłączenia.

Dla zespołów utrzymujących starszy kod różnica między ROS 1 a ROS 2 często zaczyna się od języków i narzędzi, a kończy na architekturze całego projektu. Gdy biblioteki zewnętrzne rozwijają się wokół nowych wersji Pythona i C++, stary stos zaczyna po prostu odstawać.

Kiedy kończy się wsparcie dla ROS 1?

Wsparcie dla ROS 1 Noetic kończy się 1 maja 2025 roku. To ostatnia szeroko używana dystrybucja ROS 1. Po tej dacie projekty oparte na tej linii nie przestaną działać z dnia na dzień, ale zniknie oficjalny cykl utrzymania na dotychczasowym poziomie.

Skutki są bardzo konkretne: trudniejsze aktualizacje zależności, większe ryzyko problemów bezpieczeństwa, mniejsza zgodność z nowymi narzędziami i coraz słabsza opłacalność rozwijania nowych funkcji w starym środowisku.

Argumenty za migracją do ROS 2:

• Brak centralnego mastera – łatwiejsze skalowanie i mniejsze ryzyko pojedynczej awarii.
• DDS i QoS – dokładniejsze sterowanie komunikacją.
• Lepsze wsparcie czasu rzeczywistego – większa przewidywalność działania pod obciążeniem.
• Bezpieczeństwo komunikacji – DDS Security i SROS2.
• Nowocześniejszy stos programistyczny – Python 3, nowszy C++, Ament i Colcon.
• Szersze wsparcie platform – Windows, macOS i nowsze środowiska linuksowe.

Migracja nie jest jednak operacją typu zamień i uruchom. ROS 2 nie stanowi bezpośredniego zamiennika ROS 1. Część systemów da się łączyć przez ros1_bridge, lecz pełne przejście zwykle wymaga przeglądu zależności, interfejsów wiadomości, konfiguracji QoS i sposobu uruchamiania aplikacji.

Przy bardziej złożonych projektach dobrze zacząć od analizy grafu zależności, czyli sprawdzenia, które pakiety są własne, które zewnętrzne i które w ogóle mają odpowiedniki w ROS 2. Ten etap bywa nudny. Za to oszczędza później mnóstwo nerwów.

Jak ocenić, który system wybrać?

Nowy projekt prawie zawsze lepiej rozpocząć w ROS 2. ROS 1 ma jeszcze sens głównie tam, gdzie istniejący system działa stabilnie, zespół zna go bardzo dobrze, a zakres zmian pozostaje niewielki.

Przy wyborze zwykle rozstrzygają trzy obszary: skala systemu, wymagania czasowe i perspektywa utrzymania. Im więcej węzłów, komputerów, robotów i zależności sieciowych, tym wyraźniej przewagę zdobywa ROS 2. Gdy dochodzi bezpieczeństwo, wieloplatformowość albo integracja z nowoczesnym toolchainem, decyzja robi się jeszcze prostsza.

Wybierz ROS 1, gdy:

• Utrzymujesz istniejący projekt bez planu większej rozbudowy.
• Masz zamrożony zestaw bibliotek, urządzeń i narzędzi.
• Nie potrzebujesz natywnej wieloplatformowości, bezpieczeństwa DDS ani rozbudowanych mechanizmów czasu rzeczywistego.

Wybierz ROS 2, gdy:

• Budujesz nowy system lub przeprowadzasz większą przebudowę.
• Potrzebujesz skalowania, architektury rozproszonej i pracy wielorobotowej.
• Chcesz korzystać z DDS, QoS, lifecycle nodes i nowoczesnego stosu programistycznego.
• Liczy się bezpieczeństwo komunikacji i dłuższa perspektywa utrzymania.

W codziennej praktyce odpowiedź na pytanie, czym różni się ROS od ROS 2, sprowadza się do jednego: ROS 1 szybciej uruchamia prosty prototyp, a ROS 2 daje mocniejsze podstawy pod system, który ma działać stabilnie, skalować się i przeżyć więcej niż jeden etap demonstracyjny.

Podsumowanie

ROS 1 i ROS 2 mają wspólne korzenie, ale służą innym etapom pracy. ROS 1 sprawdza się w prostszych prototypach i starszych projektach, natomiast ROS 2 oferuje architekturę rozproszoną, DDS, QoS, lepsze wsparcie dla czasu rzeczywistego, większą zgodność z systemami operacyjnymi oraz nowsze języki i narzędzia. Jeśli pytasz, czym różni się ROS od ROS 2, odpowiedź brzmi jednoznacznie – ROS 2 lepiej odpowiada na potrzeby współczesnej robotyki i ma wyraźnie lepszą perspektywę rozwoju.

FAQ

Q: Czy ROS 2 uruchamia stare pakiety z ROS 1?

A: Nie bezpośrednio. Część komunikacji można spiąć przez ros1_bridge, ale zwykle trzeba dostosować pakiety, interfejsy i zależności.

Q: Czy ROS 2 zawsze działa szybciej niż ROS 1?

A: Nie zawsze. ROS 2 daje większą kontrolę nad opóźnieniami i lepszą skalowalność, ale zysk zależy od konfiguracji QoS, DDS i architektury systemu.

Q: Czy ROS 2 wymaga Linuxa?

A: Nie. ROS 2 ma natywne wsparcie także dla Windows i macOS, choć konkretne wydanie może mieć własną macierz zgodności.

Q: Czy ROS 2 nadaje się do sterowania ruchem w czasie rzeczywistym?

A: Tak, ale wymaga poprawnej konfiguracji. Sam framework nie wystarczy, bo liczą się też system operacyjny, middleware DDS i sposób planowania zadań.

Q: Czy warto zaczynać nowy projekt w ROS 1?

A: Zwykle nie. ROS 1 ma wygasające wsparcie i mniej możliwości rozwoju, więc nowy projekt rozsądniej rozpocząć w ROS 2.

Weryfikacja i redakcja

Za redakcję i weryfikację artykułu odpowiadają:

Joanna Lewandowska. Specjalistka ds. automatyki i integracji. Absolwentka kierunku Automatyka i Robotyka na Akademii Górniczo-Hutniczej im. Stanisława Staszica w Krakowie.

Piotr Woźniak. Doświadczony redaktor technologiczny. Absolwent kierunku Dziennikarstwo i Komunikacja Społeczna na Uniwersytecie Warszawskim.